WebSocket 与长轮询与 TCP 可扩展性/易用性
我正在为基于 Java 的移动 Web 应用程序编写后端，我想知道就可扩展性和易用性而言，使用 WebSocket 与 Comet 等长轮询解决方案相比有何优缺点。另一种选择是使用 TCP 实现我自己的解决方案。根据我的阅读，您似乎需要在专用服务器上运行长轮询解决方案，因为当您开始处理大量用户时，它们在 Tomcat/Jetty 中运行不佳。 WebSockets 听起来扩展性更好。与 Comet 相比，使用 Websockets 是否有任何缺点，或者我应该使用 TCP 连接诉诸我自己的解决方案？我正在寻找使用最少流量的选项。
I'm writing a backend for a mobile web-app based in Java and I was wondering as far as scalability and ease of use go what are the pros and cons associated with using WebSockets versus Long-Polling solutions like comet. Another option would also be implementing my own solution using TCP. From what I've read it seems that you need to run Long-polling solutions on dedicated servers as they don't run well in Tomcat/Jetty when you start dealing with large numbers of users. WebSockets sounds like it scales better. Are there any disadvantages to going with Websockets over Comet or should I just resort to my own solution using TCP connections? I'm looking for the option that uses the least traffic.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我想这取决于您的用例和对学习新事物的容忍度，但可以肯定的是，出于多种原因，使用 WebSocket API 甚至 SSE 进行通信会比传统的长轮询/Comet 解决方案更好 - 其中之一您提到了可扩展性，还有带宽利用率和延迟。理解 WebSocket 之于 Web 就像 TCP 之于桌面（例如套接字）也很重要。在桌面解决方案中，您不一定要针对 TCP 进行编码，您可以使用支持 STOMP 或 XMPP over TCP 等传输协议的客户端库。使用 WebSocket 时也可以执行相同的操作，选择一个服务器与 XMPP 服务器进行通信，并选择一个 XMPP 客户端库通过 WebSocket 与服务器进行通信。
您可以在此处查看我们的示例，我们有您可以在此处阅读文档。
需要注意的是浏览器对 HTML5 WebSocket 的采用 - 目前在 Chrome 和 Safari 中，很快就会在 FF 和 Opera 中推出。我们已经解决了这个问题，但如果您计划构建自己的服务器，则必须为旧版浏览器创建后备解决方案。
I guess it depends on your usecase and tolerance for learning new things but, for sure, going down the path of using WebSocket APIs for communication, or even SSE, would better than a traditional long-polling/Comet solution for many reason - one that you mentioned - scalability, but also for bandwidth utilization and latency. It is important to also understand that WebSocket is to the Web what TCP is to the desktop e.g. a socket. In a desktop solution you don't necessarily code against TCP, you use a client library supporting a transport protocol like STOMP or XMPP over TCP. You do the same when using WebSocket, pick a server to communicate with e.g. XMPP server, and a XMPP client library to communicate with the server over WebSockets.
You can see our example of it here and we have docs you can read here.
The thing to watch out for is browser adoption of HTML5 WebSocket - currently in Chrome and Safari, and coming soon in FF and Opera. We have addressed this, but in case you plan to build your own server you will have to create a fall back solution for older browsers.