Ajax、Comet、HTML 5 Web Sockets

 

Ajax为HTTP通信模型提供了很好的解决方案，它在客户端异步轮询服务器端事件。服务器事件依次排列在待处理队列中，根据轮询时间隙依次传送到 浏览器，这样模拟服务器发起的通信，在轮询时间隙间进行实时消息传递。因此，仅仅依靠Ajax,我们永远都不可能实现真正的实时通信。

 

Comet引入的优化针对的是HTTP通信初始之时，它在HTTP基础上采用“push”通信风格。Comet提供的几项技术能够在没有客户端发送 请求的前提下让服务器主动将信息发送到浏览器。如果再增加一个额外的HTTP连接的话，Comet甚至可以在两个HTTP连接上实现双向通信。但 Comet的绊脚石在于各个浏览器提供商对XHR、iFrames——这两种实现Comet所需的数据块的支持程度不尽相同，没有统一的实现标准。另外， 无论是从网络还是开发角度来看，Comet管理两个连接的开销都很大。这些开销带来的直接影响就是Comet应用中的传输延时，限制了它们所提供的实时通 信的精确性。

---->

用Comet开发有很多挑战。实现你自己的解决方案不是不可能，但这需要开发JavaScript类库，借用frame和XHR Streaming等很多技术来维护持续连接。这时候，问题就在于不同的浏览器对这些技术有不同的实现，更糟的是，它们往往都依赖服务器端代码推送 JavaScript代码段，不仅增加了整个实现的复杂程度，还引入了移植性的问题。 

还好，现在有几个框架提供了这些传输的抽象，简化了Comet开发。其中最著名的就是SitePen的Cometd，其实现完全参 考Bayuex规范。Bayuex规范定义了Comet的publish-subscribe模型。Jetty近期版本也包含了基于Java的服务器端的 Bayeux实现。 

Bayuex和Cometd着实简化了Comet，然而它的API和wire协议还是有很多争议。Comet Daily上有一个 “Coliding Comet: Battle of the Bayuex”系列就专门深入讨论关于Bayuex的各种问题。

 

HTML 5 WebSocket代表的是Comet和Ajax推进HTTP通信新一轮的尝试。HTML 5 WebSocket规范中定义，在浏览器和服务器之间采用单socket全双工（或者叫双向）传输来push和pull信息。这不但可以避免Comet中 存在的连接和可移植问题，还能够提供比Ajax轮询更高效的解决方案。目前，HTML 5 WebSocket是推动web全双工实时通信的主要机制。

---->

尽管Comet和Ajax都可以实现提供桌面应用功能的终端用户体验，而且传输延时也可以缩短到用户无法感知的程度，但仍然只有Web Sockets才能真正为浏览器提供精确、高效的流事件，保证传输延时可以微乎其微，直至忽略不计。这是目前为止通过web发送实时信息最出色的解决方 案。它不仅通过单个TCP/IP连接提供完整的异步双工道流通信，而且新的HTTP头的应用也非常有利，更重要的是它能够支持浏览器和源服务的消息采用同 样的格式。 

多数Comet实现都依赖Bayeux协议。该协议要求源服务发出的消息必须转换成Bayeux协议支持的格式，这一并不必要的转 换反而使得整个系统更加复杂，开发员不得不在服务器端处理一种消息格式（比如JMS、IMAP、XMPP等），在客户端又要处理另一种消息格式（比如 Bayeux、JSON）。而且实现将源协议转换到Bayeux的代码硬是要在发送消息之前对消息本身进行解析和处理，这又给系统增添了不必要的性能负 载。采用Web Sockets的话，就不会有因为转换代码而增加系统的复杂性，也就不用为这方面的性能担忧。 

WebSockets经常遇到的一个问题是它是否可行。目前来看，浏览器本身没法直接支持这项技术。但再过几个月就肯定可以了，像 WebKit、Firefox和Opera这样的浏览器从来就对HTML 5的特性——比如Canvas、postMessage、离线存储和服务器端发送信息(SSE)等反应迅速，及时添加相应的支持。 

WebSockets还需要服务端一定程度的支持，因为现存HTTP连接更新到新连接需要HTTP的一个起始“握手”。 Kaazing Gateway开源项目实现了第一个支持这一动作的服务器，并且拥有能够支持成千上万持续连接所需的扩展性。 Kaazing Gateway的供应商Kaazing还提供了一个可以让当前所有web浏览器都支持WebSockets的JavaScript类库。所以，目前对 WebSocket的支持也可说是准备就绪了。

为了支持HTML 5 WebSockets，Kaazing发布了Kaazing Gateway 8.09_2 Atlantis，这是一个开源HTML 5 WebSocket服务器，可以在Mozilla公共许可的衍生许可—— OSI approved Common Public Attribution License (CPAL)下使用：

Kaazing Gateway提供JavaScript类库来模拟HTML 5 WebSocket，开发员现在就可以开始运用WebSockets，结合WebSocket接口创建的应用在当前甚或是未来的浏览器上都可以部署。 

Kaazing Gateway背后的超高性能服务器的单个节点能够支持成千上万的并发连接。多实例通过传统的HTTP负载平衡或者DNS round robin算法集群分类，因此能够支持无数个持续客户连接。除了大量的连接之外，Kaazing Gateway的高性能和分级事件驱动构架（SEDA）还推动它本身能够处理高数据吞吐量。 

Kaazing Gateway的Atlantis发布还为流行的消息服务（诸如Apache ActiveMQ、RabbittMQ）和XMPP服务（诸如OpenFire、Jabberd和其它一些流行的聊天服务器）打包了JavaScript 客户端。这样，创建那些基于web的聊天应用或是stock matrixes、网上交易平台、在线游戏等消息发送应用就更为简单了。

计划中的Kaazing Gateway 8.12发布把目标瞄准了更多的HTML 5特性，例如服务器端发送事件（Server-sent Event）、更先进的安全服务，以及对XMPP（Jabber）、STOMP (比如ActiveMQ、RabbitMQ或OpenMQ)等的扩展支持：

它所提供的类库能够让目前的浏览器都支持HTML 5服务器发送事件，引进了HTML 5 postMessage的支持，无疑方便了跨文档的消息传递。Kaazing的HTML 5类库还包括对HTML 5离线存储的支持，提供简易、基于DOM的存储解决方案。Kaazing Gateway及其客户类库现在还为跨站请求支持W3C访问控制，这一机制能够让客户端启动跨站请求，比较多的提法是跨站 XmlHttpRequests。 

除了对HTML 5的扩展支持以外，Kaazing Gateway 8.12还提供更高级的XMPP特性，比如群聊。这一发布版本还引进了STOMP-JMS适配器，因此，结合Kaazing Gateway还能适配任何现存的Java消息服务（JMS）（例如JBoss Messaging、Tibco EMS、OpenMQ、SwiftMQ、WebSphere MQ等等）。

 

英文原文:HTML 5 Web Sockets vs. Comet and Ajax