反向Ajax，實現服務器向客戶端推送消息之 Comet

　　基於 HTTP 長鏈接、無須在瀏覽器端安裝插件的「服務器推」技術爲「Comet」。

　　　　

　　下面將介紹兩種 Comet 應用的實現模型。

　　基於 AJAX 的長輪詢（long-polling）方式

　　AJAX 的出現使得 JavaScript 能夠調用 XMLHttpRequest 對象發出 HTTP 請求，JavaScript 響應處理函數根據服務器返回的信息對 HTML 頁面的顯示進行更新。使用 AJAX 實現「服務器推」與傳統的 AJAX 應用不一樣之處在於：

1. 服務器端會阻塞請求直到有數據傳遞或超時才返回。
2. 客戶端 JavaScript 響應處理函數會在處理完服務器返回的信息後，再次發出請求，從新創建鏈接。
3. 當客戶端處理接收的數據、從新創建鏈接時，服務器端可能有新的數據到達；這些信息會被服務器端保存直到客戶端從新創建鏈接，客戶端會一次把當前服務器端全部的信息取回。

　　圖 2. 基於長輪詢的服務器推模型

     

　　一些應用及示例如 「Meebo」, 「Pushlet Chat」 都採用了這種長輪詢的方式。相對於「輪詢」（poll），這種長輪詢方式也能夠稱爲「拉」（pull）。由於這種方案基於 AJAX，具備如下一些優勢：請求異步發出；無須安裝插件；IE、Mozilla FireFox 都支持 AJAX。

　　在這種長輪詢方式下，客戶端是在 XMLHttpRequest 的 readystate 爲 4（即數據傳輸結束）時調用回調函數，進行信息處理。當 readystate 爲 4 時，數據傳輸結束，鏈接已經關閉。Mozilla Firefox 提供了對 Streaming AJAX 的支持， 即 readystate 爲 3 時（數據仍在傳輸中），客戶端能夠讀取數據，從而無須關閉鏈接，就能讀取處理服務器端返回的信息。IE 在 readystate 爲 3 時，不能讀取服務器返回的數據，目前 IE 不支持基於 Streaming AJAX。

 

　　基於 Iframe 及 htmlfile 的流（streaming）方式

　　iframe 是很早就存在的一種 HTML 標記， 經過在 HTML 頁面裏嵌入一個隱蔵幀，而後將這個隱蔵幀的 SRC 屬性設爲對一個長鏈接的請求，服務器端就能源源不斷地往客戶端輸入數據。

　　圖 3. 基於流方式的服務器推模型

    

　　上節提到的 AJAX 方案是在 JavaScript 裏處理 XMLHttpRequest 從服務器取回的數據，而後 Javascript 能夠很方便的去控制 HTML 頁面的顯示。一樣的思路用在 iframe 方案的客戶端，iframe 服務器端並不返回直接顯示在頁面的數據，而是返回對客戶端 Javascript 函數的調用，如「<script type="text/javascript">js_func(「data from server 」)</script>」。服務器端將返回的數據做爲客戶端 JavaScript 函數的參數傳遞；客戶端瀏覽器的 Javascript 引擎在收到服務器返回的 JavaScript 調用時就會去執行代碼。

　　從 圖 3 能夠看到，每次數據傳送不會關閉鏈接，鏈接只會在通訊出現錯誤時，或是鏈接重建時關閉（一些防火牆常被設置爲丟棄過長的鏈接， 服務器端能夠設置一個超時時間， 超時後通知客戶端從新創建鏈接，並關閉原來的鏈接）。

　　使用 iframe 請求一個長鏈接有一個很明顯的不足之處：IE、Morzilla Firefox 下端的進度欄都會顯示加載沒有完成，並且 IE 上方的圖標會不停的轉動，表示加載正在進行。Google 的天才們使用一個稱爲「htmlfile」的 ActiveX 解決了在 IE 中的加載顯示問題，並將這種方法用到了 gmail+gtalk 產品中。Alex Russell 在 「What else is burried down in the depth's of Google's amazing JavaScript?」文章中介紹了這種方法。Zeitoun 網站提供的 comet-iframe.tar.gz，封裝了一個基於 iframe 和 htmlfile 的 JavaScript comet 對象，支持 IE、Mozilla Firefox 瀏覽器，能夠做爲參考。（請參見參考資源）

 

　　使用 Comet 模型開發本身的應用

　　上面介紹了兩種基於 HTTP 長鏈接的「服務器推」架構，更多描述了客戶端處理長鏈接的技術。對於一個實際的應用而言，系統的穩定性和性能是很是重要的。將 HTTP 長鏈接用於實際應用，不少細節須要考慮。

　　不要在同一客戶端同時使用超過兩個的 HTTP 長鏈接

　　咱們使用 IE 下載文件時會有這樣的體驗，從同一個 Web 服務器下載文件，最多隻能有兩個文件同時被下載。第三個文件的下載會被阻塞，直到前面下載的文件下載完畢。這是由於 HTTP 1.1 規範中規定，客戶端不該該與服務器端創建超過兩個的 HTTP 鏈接， 新的鏈接會被阻塞。而 IE 在實現中嚴格遵照了這種規定。

　　HTTP 1.1 對兩個長鏈接的限制，會對使用了長鏈接的 Web 應用帶來以下現象：在客戶端若是打開超過兩個的 IE 窗口去訪問同一個使用了長鏈接的 Web 服務器，第三個 IE 窗口的 HTTP 請求被前兩個窗口的長鏈接阻塞。

　　因此在開發長鏈接的應用時， 必須注意在使用了多個 frame 的頁面中，不要爲每一個 frame 的頁面都創建一個 HTTP 長鏈接，這樣會阻塞其它的 HTTP 請求，在設計上考慮讓多個 frame 的更新共用一個長鏈接。

　　服務器端的性能和可擴展性

　　通常 Web 服務器會爲每一個鏈接建立一個線程，若是在大型的商業應用中使用 Comet，服務器端須要維護大量併發的長鏈接。在這種應用背景下，服務器端須要考慮負載均衡和集羣技術；或是在服務器端爲長鏈接做一些改進。

　　應用和技術的發展老是帶來新的需求，從而推進新技術的發展。HTTP 1.1 與 1.0 規範有一個很大的不一樣：1.0 規範下服務器在處理完每一個 Get/Post 請求後會關閉套接口鏈接； 而 1.1 規範下服務器會保持這個鏈接，在處理兩個請求的間隔時間裏，這個鏈接處於空閒狀態。 Java 1.4 引入了支持異步 IO 的 java.nio 包。當鏈接處於空閒時，爲這個鏈接分配的線程資源會返還到線程池，能夠供新的鏈接使用；當原來處於空閒的鏈接的客戶發出新的請求，會從線程池裏分配一個線程資源處理這個請求。 這種技術在鏈接處於空閒的機率較高、併發鏈接數目不少的場景下對於下降服務器的資源負載很是有效。

　　可是 AJAX 的應用使請求的出現變得頻繁，而 Comet 則會長時間佔用一個鏈接，上述的服務器模型在新的應用背景下會變得很是低效，線程池裏有限的線程數甚至可能會阻塞新的鏈接。Jetty 6 Web 服務器針對 AJAX、Comet 應用的特色進行了不少創新的改進，請參考文章「AJAX，Comet and Jetty」（請參見 參考資源）。

　　控制信息與數據信息使用不一樣的 HTTP 鏈接

　　使用長鏈接時，存在一個很常見的場景：客戶端網頁須要關閉，而服務器端還處在讀取數據的堵塞狀態，客戶端須要及時通知服務器端關閉數據鏈接。服務器在收到關閉請求後首先要從讀取數據的阻塞狀態喚醒，而後釋放爲這個客戶端分配的資源，再關閉鏈接。

　　因此在設計上，咱們須要使客戶端的控制請求和數據請求使用不一樣的 HTTP 鏈接，才能使控制請求不會被阻塞。

　　在實現上，若是是基於 iframe 流方式的長鏈接，客戶端頁面須要使用兩個 iframe，一個是控制幀，用於往服務器端發送控制請求，控制請求能很快收到響應，不會被堵塞；一個是顯示幀，用於往服務器端發送長鏈接請求。若是是基於 AJAX 的長輪詢方式，客戶端能夠異步地發出一個 XMLHttpRequest 請求，通知服務器端關閉數據鏈接。

　　在客戶和服務器之間保持「心跳」信息

　　在瀏覽器與服務器之間維持一個長鏈接會爲通訊帶來一些不肯定性：由於數據傳輸是隨機的，客戶端不知道什麼時候服務器纔有數據傳送。服務器端須要確保當客戶端再也不工做時，釋放爲這個客戶端分配的資源，防止內存泄漏。所以須要一種機制使雙方知道你們都在正常運行。在實現上：

1. 服務器端在阻塞讀時會設置一個時限，超時後阻塞讀調用會返回，同時發給客戶端沒有新數據到達的心跳信息。此時若是客戶端已經關閉，服務器往通道寫數據會出現異常，服務器端就會及時釋放爲這個客戶端分配的資源。
2. 若是客戶端使用的是基於 AJAX 的長輪詢方式；服務器端返回數據、關閉鏈接後，通過某個時限沒有收到客戶端的再次請求，會認爲客戶端不能正常工做，會釋放爲這個客戶端分配、維護的資源。
3. 當服務器處理信息出現異常狀況，須要發送錯誤信息通知客戶端，同時釋放資源、關閉鏈接。