哪个更好？ 长 TCP 连接还是长轮询？
我计划在我的网站上建立一个网络聊天。 我知道有两种方法：一种是使用 XMPP Web 客户端（通过 flash，长 TCP 连接），另一种是 facebook 方式，长轮询。
但是 facebook 将更新他们的聊天以支持 Jabber (XMPP)，所以有人能告诉我哪种方式更好吗？ （包括升级到XMPP）
I am planning to build a web chat on my site. I know two way of doing this: one is using XMPP web client (through flash, long TCP connection), and the other is facebook way， long-polling.
But facebook is going to update their chat to support Jabber (XMPP), so can some one tell what way is better? (including upgrading to XMPP)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我在我的应用程序中通过长时间轮询获得了相当好的结果，但更大的问题是您是否会面临 C10K 问题。 如果是这样，构建代码来处理这种密集的工作负载可能会主导所有其他设计考虑因素，至少在短期内如此。 :-)
除了服务器负载之外，使用哪种策略的主要考虑因素是客户端环境兼容性——为了能够在仅允许 HTTP 的严格防火墙后面或在禁止任何插件的浏览器环境中工作，长轮询是唯一的选择的生存方式，但它比简单的 TCP 连接方法有更多的开销。
I've had pretty good results with long polling in my applications, but the bigger question is whether you're going to face the C10K problem. If so, structuring your code to deal with that kind of intense workload will likely dominate all other design considerations, at least in the short term. :-)
Other than server load, the primary consideration for which strategy to use will be client environment compatibility -- to be able to work from behind draconian firewalls that only allow HTTP or in browser environments that prohibit any plugins, long polling is the only way to survive, but it has more overhead than the simple TCP connection approach.
它们有不同的优点和缺点，例如：TCP 需要插件（至少在 HTML5 Web 套接字得到广泛支持之前）、长轮询性能较差等。我不是这种差异方面的专家，这就是为什么我会推荐您要避免做出这种选择，避免每种方法涉及的开发和调整，避免可用技术的未来变化（即 HTML5 的到来），使用抽象所使用的传输方法的库，并根据客户端功能选择最佳方法：
http://socket.io/
这个精彩的库使创建实时应用程序变得异常简单！ 除了Node.js（服务器端JavaScript）中的主流实现之外，还有各种服务器端实现：Python（Tornado）、Java、Google GO、Rack（Ruby）
They have different pros and cons, for eg: TCP requires a plugin (at least until HTML5 web sockets get widely supported), Long Polling is less performant, etc. I'm not an specialist on this differences, that's why I'll recomend you to avoid making this choice, avoid developing and tuning that each approach involves, avoid the future changes in available technologies (ie. as HTML5 arrival), using a library that abstracts the transport method used, and chooses the best approach based on client capabilities:
http://socket.io/
this wonderful library makes creating realtime apps amazingly simple! and there are various server-side implementations: Python (Tornado), Java, Google GO, Rack (Ruby), besides the mainstream implementation in Node.js (server-side JavaScript)