是“长轮询”吗？创建网络实时应用程序最有效的方法是什么？
I want to create an application like this:
What is the most efficient way to create this real time application?
Flash? Long polling? Http Streaming? or something else?
Thanks ;)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
目前，长轮询可能是最好的解决方案。许多知名网站都实施了长轮询，包括 Facebook、Google 和 eBay。并非每个人的浏览器中都安装/启用了 Flash。未来 Web 套接字 也许可以为我们做更容易的工作。
更新：在撰写本文时，WebSocket API 已实现在最新的 WebKit (Chrome/Safari) 和 Firefox 4 beta 中。还有 Opera 的公共快照版本可供下载以及 API 的实现。这意味着 API 测试可以广泛使用。有关详细信息，请参阅此答案。
For now, long polling is probably the best solution. Many big-name sites have long polling implementations, including Facebook, Google and eBay. Not everyone has Flash installed/enabled in their browsers. In the future Web Sockets might be able to do an easier job of it for us.
Update: As of this writing, the WebSocket API is implemented in the latest WebKit (Chrome/Safari) and Firefox 4 beta. There is also a public snapshot build of Opera available for download with an implementation of the API. This means testing the API is widely available. For more information, see this answer.
所有不同的方法都有不同的优缺点，我不是差异方面的专家，这就是为什么我建议您避免做出选择，避免每种方法涉及的开发和调整，避免可用技术的未来变化（即 HTML5 Web 套接字到来），使用抽象所使用的传输方法的库，并根据客户端功能选择最佳方法：
http://socket.io/
这个精彩的库使创建实时应用程序变得异常简单！除了Node.js（服务器端JavaScript）中的主流实现之外，还有各种服务器端实现：Python（Tornado）、Java、Google GO、Rack（Ruby）
All the different methods have different pros and cons, I'm not an specialist on the differences, that's why I'll recomend you to avoid making the choice, avoid the development and tuning that each approach involves, avoid the future changes in available technologies (ie. as HTML5 web sockets 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)
我不认为长轮询是执行 Comet 的最有效方法。不管怎样，它在得到响应后发送新的 HTTP 请求。与 HTTP 流相比，它需要花费更多的额外 HTTP 请求。
但是，长轮询可能比 HTTP 流更可靠且更容易实现。根据这篇 Google 代码中的文章，HTTP 流式传输如果中间 HTTP 代理缓冲内容，则可能无法正常工作。
有趣的是，GMail 不使用长轮询。在Http嗅探器的帮助下，很明显它使用了Comet的HTTP流。
I don't think long-polling is most efficient way to do Comet. Anyway, it sends new HTTP request after response is got. It cost more extra HTTP requests than HTTP streaming.
But, long-polling might be more reliable and easier to implement than HTTP streaming. According to this article in Google Code, HTTP streaming might not be functional if intermediate HTTP proxy buffers content.
It is interesting that GMail doesn't use long-polling. With the help of Http sniffer, it is clear that it uses HTTP streaming for Comet.