Ajax，全称Asynchronous JavaScript+XML，在Web应用领域已经家喻户晓。在这种机制下，不需要页面重载，浏览器就获取RESTful Web服务并更新GUI。这种开发方法已经从网上地图和日历的创新起源，扩展为多数新Web应用的标准功能。但是，直到最近，出现一个与该方法互补的新名词，目前它通常被称为Reverse-Ajax (反向Ajax)，即Comet。

　　为了理解为什么需要像reverse-Ajax或Comet的东西，就得先看一下实时事件的本质，例如那些发生在股票市场或运动比赛的实时事件。假设你负责用Ajax创建一个不能全屏重载、基于Web的应用，运用在之前提到的场景中，你会使用多长的时间间隔，向你的数据服务发送新的异步请求？记住，你不想用户错过比赛中的任何新动作，或者更糟的是，错过股票报价而无法下单。

　　这种类型的设计没有简单的答案，如果你使用的间隔太久，用户可能错过新的信息，但如果你使用的间隔太短，那么你的数据服务将被大量无用的请求给淹没。这个问题的核心当然是Web应用的无状态本质。不过，对此难题有一个解决办法，那就是服务器通知客户端有新的数据，这也被经常叫做服务器端推（serverside push）。

　　对于那些始于富客户端(rich-client)的技术，如Flash或Java，这个过程可能是老调重弹，特别是因为这些技术已经集成如远程和流程的机制来处理异步请求。这些请求既可以从客户端到服务器端，也可以从服务器端到客户端。但是，Comet所做的就是使用和Ajax一样的技术（具体而言，就是JavaScript和HTML），处理实时响应这个过程。现在让我们看看这个设计需要如何处理。

　　首先你需要了解，服务器端的数据服务设计，需要代表浏览器客户端来保留状态。这个过程可能非常困难，也可能非常容易，这要视你使用的平台和语言而定。这样，我们再次回到Web应用无状态的本质问题。浏览器需要不断识别自身的方法，或者通过cookies，或者通过session ID，或者类似好莱坞的规则“不要打电话给我们，我们会打电话给你”。这是指只有浏览器能够提出请求，而不能反之亦然。

　　创建异步服务器应用中，我们面临的最后一个问题是基于HTTP的事件路由总线，换言之，服务器端有一个潜在的应用程序能够记录希望收到更新的客户端。这种设计很像运用于基于出版/订阅渠道的企业系统里的消息系统。

　　但是，由于最后的机制与多数Web平台使用的基本方式背道而驰，所以，这也是为什么目前Comet的应用依赖定制修改的应用服务器，或者嵌入版本来处置这些问题的最大原因。在使用Java的情况下，Jetty和Grizzly是目前能够支持Comet类型设计的两种服务器，还可以支持其他语言，如Python，同时也支持其他流行的Java服务器，如Tomcat。这种支持技术上叫做“连续支持”（continuation support），这样，应用程序与Web的无状态本质相分离。连续支持也是使用Smalltalk和Lisp编写的更高水平的Web framework引以为豪的特点。

　　如果把注意力转向客户端，一个浏览器能够采用不同的方式与这种服务器应用程序保持联系。这些方式包括long-polling，动态脚本标签和包括使用IFrames的工作区。这些都还不是标准的方式，这也是为什么许多客户端Comet设计依赖framework的使用，抽象化浏览器部署之间存在的不兼容性。与Ajax相似，使用像Dojo的 framework，其本身现在就同时作为Ajax和Comet的framework在使用。

　　事实上，在后面那种情况下，已经有标准在制定中，例如HTML 5。这是通过一种叫event-source的简单标签，来部署和支持Comet类型的负载，在这种情况下，减少了为显示Comet发出的数据对framework和分段方式的需求。

　　Comet提供的服务是当服务器端有数据时，就传送数据给浏览器。显然这种技术将具有和Ajax一样的影响，并与Ajax相得益彰。