comet研究

最新推荐文章于 2025-07-24 08:00:00 发布

转载最新推荐文章于 2025-07-24 08:00:00 发布 · 606 阅读

php基础专栏收录该内容

120 篇文章

订阅专栏

comet研究[http://lync.in/research-on-comet/]

在Web应用中，客户端的AJAX技术已经非常普遍也非常深入人心了，但与此同时，另一些应用，诸如在线监控，实时数据显示，即时通讯等需要将后台数据变化情况实时显示到前台，这样的由服务器push的行为（也许会让你想到blackberry）则需要另一种方案来解决，也就是本文所要介绍的Comet —— 无需安装插件，保持http长连接的服务器推方案。
以下两点是方案中必须顾及到的。

浏览器通用性，对各种不同实现结构模型的支持。
长连接对于服务器资源的占用，以及服务器的承受能力。

Comet的客户端与服务端交互流

业界对于Comet实现有两种主要的解决方案：

基于AJAX的轮询(long polling)方式

这种方式就是由客户端发出AJAX请求，然后服务端阻塞请求直至有响应或超时。客户端在接收到服务端的指令之后会进行响应并发出新的请求。

从实现层面上来说，当XMLHttpRequest的状态为4也就是load的状态时会进行客户端处理，而Gecko（Firefox）和Webkit（Chrome，Safari）目前支持在readystate为3的时候读取（当然只能读取到所有该请求已返回的串内容，所以需要自行确定指令边界），Trident（IE）目前如果中途去读取会抛出错误，IE8中使用XDomainRequest可以适当解决这个问题（参见Eric Law的COMET Streaming in Internet Explorer[]）。

目前，开心网采用的是这一种方式。

基于iframe及htmlfile的流(streaming)方式

这种方式是使用了iframe的机制，然后使得这个iframe请求一个特定的URL，并通过对这个页面的加载不断的从服务端抓回数据，这里从服务端抓回的数据大多是对页面当前JavaScript函数的引用和操作。

这个方案的一个明显不足之处是页面会一直显示正在加载，而这在IE上会更明显。Google的天才们想到了用htmlfile的ActiveX控件来解决这个问题的方案，详细描述可以参见Alex Russell的What else is burried down in the depth's of Google's amazing JavaScript?

目前，人人网和GTalk采用的是这种方式。

除了文首所提到的通用性和性能之外，还有几点是需要列入考量范围的。

数据交换的格式。由于数据交换的形式是推送，所以不可避免的会有指令队列的存在，于是数据结构是需要前后台详细约定的，执行指令和数据指令都需要有严格的界定，一般来说，JSON的方案比较普遍。
浏览器本身的连接数限制。HTTP 1.1规范中声明客户端不应该与服务器端建立超过两个的 HTTP 连接，而IE又严格遵守了这一点，所以前台在处理请求的时候需要谨慎控制请求的数量。

其实，Comet技术在AJAX大红大紫的2005年之后的2006年时是业界一个很热的讨论点，目前的这两种方式非常成熟，在dojo，dwr等前端框架中都已经有这样的实现，而Bayeux协议的出现也已经在实质上订下了一种业界的标准。

Comet的框架前端有Pushlet，dwr和dojo等，服务端有Jetty，Meteor，Orbited，Glassfish，Alpha，实现的产品语言也覆盖了Java，C++，Python，Perl，Ruby，Erlang，.Net等。

下一代HTML5中的WebSocket会是Comet的一个新起点，但在那之前，在非插件的web层面应该不会有更进一步的讨论与技术出现。

本文只是对Comet这个技术进行大体的概述，粗陋不明之处难免，在后续的文章中将会对WebSocket进行一定的解释和演示。

参考资料：

这里有一个php的comet的例子How to implement COMET with PHP。这个要看看
这是developerWorks上对于Comet的介绍。
这是当前Comet的服务器端的一些产品及介绍。
当然，Wikipedia上面对Comet的解释也是非常详尽。
还可以看看AjaxPatterns上面的一些介绍。
最后，CometDaily是个值得去了解最新Comet新闻和知识的地方。
=====================================================================================================