Ajax、Comet、HTML 5 Web Sockets技术比较分析

最近由于考虑研究B/S结构网站即时消息处理

参考了

JAVA怎么样实现即时消息提醒
http://bbs.csdn.net/topics/330015611
http://www.ibm.com/developerworks/cn/web/wa-lo-comet/

http://blog.csdn.net/ant_ren/article/details/4231809 （关注）

发现技术也是突飞猛进。就看看别人怎么对比的。

九十年代中期，WWW以迅猛之势转眼跻身传播信息的主要渠道之一。浏览器的身影开始无 处不在，用户也随之开始适应这种信息传播方式。显然，WWW提 供的应用平台可以赢得历史上任何一个平台都没法比及的用户量。但当时很难实现这样的目标是由于一些标准（HTML、HTTP等）都不很完善，这些标准设计 的时候都没有考虑到高度交互和富客户体验。最初的一些富在线应用基本上都是由Microsoft Exchange开发组实现的。96年以来，他们曾采用IFrame为邮件服务器系统提供Outlook类型的前端应用。这些早期尝试在响应能力和总体的 用户体验方面都很是落后，但从这些应用身上却能够清楚地看到即将兴起的网络应用。1998年，团队开始为MS Exchange Server 2000编写web前端，他们开发了XMLHTTP，这个控件实现了单个web页面与服务器间的异步交互。能够看到，XMLHTTP实际上根本没有当即和 XML捆绑起来。XMLHTTP这个名字是Alex Hopmann提出的，他是后来加入开发团队的，听说名字采用这个前缀的惟一的缘由是IE5当时正在准备第二个beta版本，而这个控件必须做为这个版本 的MSXML库的一部分发布，这才冠上了XML。 

 

Mozilla基金会在2002年开发他们的浏览器的一个版本时，也以 XMLHttpRequest的形式实现这一新技术，这个浏览器就是后来的 Firefox。尽管当时有一些商家也曾尝试运用这些新API，但他们采用的的这种远程脚本程序的模式一直没有引发公众的注意，直到Google开始部署 基于JavaScript和XHR的一系列新型服务。当时的第一个服务是2005年2月8日Google Blog上发布的Google Maps。以后不久，XHR就一跃成为业界最煊赫一时的话题。直到那时，也还没人预料到XHR给Web应用开发带来的革命性的推进，但它的成功开始让咱们 转变以前对WWW的一些见解。 

 

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

 

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

 

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

 

要经过Ajax来模拟服务器端起始的通讯就须要轮询机制，而这一机制不顾应用的状态改 变盲目检查更新，结果就是CPU周期和内存毫无必要地过早或者 太晚侦测服务器的更新，客户和服务器两端的资源利用情况所以都至关差劲。因此，传统的Ajax应用必须根据服务器上事件的发布率不停地调整轮询时间隙的长 短，才能改善各个请求的准确度。另外，高频率轮询会加剧网络承载，拖累服务器；低频率轮询又会错过更新和传送一些失去时效的信息。不管哪一种状况，消息传递 过程都没法避免传输延时。短间隙轮询开销很大，由于要支持这样的小型服务器ping须要大量服务器资源。 

 

Comet维护服务器和浏览器之间的持续链接和长时间有效的HTTP请求，以此来尝试 “push”型通讯。这种链接下，服务器能够发送事件，但链接是由客户端浏览器发起。逆流请 求也能够看作是浏览器向服务器发送的请求，这须要一个额外的HTTP链接。Comet所以能够利用跨两个HTTP链接的双向通讯。可是，维护这两个链接会 消耗服务器端大量资源，由于这也意味着服务一个顾客须要消耗双倍资源。并且，浏览器的配置每每都是经过域来限制HTTP链接。Comet的应用所以更为复 杂，还经常会要求运用一些像多路复用那样复杂的技术，再或者就是要管理多个域。 

 

有一些Comet解决方案试图下降长轮询技术致使的资源消耗，但这一技术发送太多的 HTTP请求/回复头信息。好比，服务器发送的 每一个事件，都经过客户浏览器为链接提供服务，这迫使浏览器必须和服务器从新创建链接。这一动做又引起了另外一个客户端请求以及服务器在长轮询时间隙中发送回 复。不少时候，回复中的HTTP头内容彻底超过了传送的信息。

 

用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的各类问题

 

尽管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的支持也可说是准备就绪了。

 

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、网上交易平台、在线游戏等消息发送应用就更为简单了。

 

它所提供的类库可以让目前的浏览器都支持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等等）。

 

原文出处：http://www.infoq.com/cn/news/2008/12/websockets-vs-comet-ajax