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