Comet：基於 HTTP 長串連的“伺服器推”技術

周 婷 (zhouting@cn.ibm.com), 軟體工程師, IBM 中國軟體開發技術實驗室

 

2007 年 8 月 31 日

很多應用譬如監控、即時通訊、即時報價系統都需要將後台發生的變化即時傳送到用戶端而無須用戶端不停地重新整理、發送請求。本文首先介紹、比較了常用的“伺服器推”方案，著重介紹了 Comet － 使用 HTTP 長串連、無須瀏覽器安裝外掛程式的兩種“伺服器推”方案：基於 AJAX 的長輪詢方式；基於 iframe 及 htmlfile 的流方式。最後分析了開發 Comet 應用需要注意的一些問題，以及如何藉助開源的 Comet 架構－pushlet 構建自己的“伺服器推”應用。

“伺服器推”技術的應用

傳統模式的 Web 系統以用戶端發出請求、伺服器端響應的方式工作。這種方式並不能滿足很多現實應用的需求，譬如：

• 監控系統：後台硬體熱插拔、LED、溫度、電壓發生變化；
• 即時通訊系統：其它使用者登入、發送資訊；
• 即時報價系統：後台資料庫內容發生變化；

這些應用都需要伺服器能即時地將更新的資訊傳送到用戶端，而無須用戶端發出請求。“伺服器推”技術在現實應用中有一些解決方案，本文將這些解決方案分為兩類：一類需要在瀏覽器端安裝外掛程式，基於套介面傳送資訊，或是使用 RMI、CORBA 進行遠程調用；而另一類則無須瀏覽器安裝任何外掛程式、基於 HTTP 長串連。

將“伺服器推”應用在 Web 程式中，首先考慮的是如何在功能有限的瀏覽器端接收、處理資訊：

1. 用戶端如何接收、處理資訊，是否需要使用套介面或是使用遠程調用。用戶端轉譯給使用者的是 HTML 頁面還是 Java applet 或 Flash 視窗。如果使用套介面和遠程調用，怎麼和 JavaScript 結合修改 HTML 的顯示。
2. 客戶與伺服器端通訊的資訊格式，採取怎樣的出錯處理機制。
3. 用戶端是否需要支援不同類型的瀏覽器如 IE、Firefox，是否需要同時支援 Windows 和 Linux 平台。

基於用戶端套介面的“伺服器推”技術

Flash XMLSocket

如果 Web 應用程式的使用者接受應用只有在安裝了 Flash 播放器才能正常運行， 那麼使用 Flash 的 XMLSocket 也是一個可行的方案。

這種方案實現的基礎是：

1. Flash 提供了 XMLSocket 類。
2. JavaScript 和 Flash 的緊密結合：在 JavaScript 可以直接調用 Flash 程式提供的介面。

具體實現方法：在 HTML 頁面中內嵌入一個使用了 XMLSocket 類的 Flash 程式。JavaScript 通過調用此 Flash 程式提供的套介面介面與伺服器端的套介面進行通訊。JavaScript 在收到伺服器端以 XML 格式傳送的資訊後可以很容易地控制 HTML 頁面的內容顯示。

關於如何去構建充當了 JavaScript 與 Flash XMLSocket 橋樑的 Flash 程式，以及如何在 JavaScript 裡調用 Flash 提供的介面，我們可以參考 AFLAX（Asynchronous Flash and XML）項目提供的 Socket Demo 以及 SocketJS（請參見 參考資源）。

Javascript 與 Flash 的緊密結合，極大增強了用戶端的處理能力。從 Flash 播放器 V7.0.19 開始，已經取消了 XMLSocket 的連接埠必須大於 1023 的限制。Linux 平台也支援 Flash XMLSocket 方案。但此方案的缺點在於：

1. 用戶端必須安裝 Flash 播放器；
2. 因為 XMLSocket 沒有 HTTP 隧道功能，XMLSocket 類不能自動穿過防火牆；
3. 因為是使用套介面，需要設定一個通訊連接埠，防火牆、Proxy 伺服器也可能對非 HTTP 通道連接埠進行限制；

不過這種方案在一些網路聊天室，網路互動遊戲中已得到廣泛使用。

Java Applet 套介面

在用戶端使用 Java Applet，通過 java.net.Socket 或 java.net.DatagramSocket 或 java.net.MulticastSocket 建立與伺服器端的套介面串連，從而實現“伺服器推”。

這種方案最大的不足在於 Java applet 在收到伺服器端返回的資訊後，無法通過 JavaScript 去更新 HTML 頁面的內容。

基於 HTTP 長串連的“伺服器推”技術

Comet 簡介

瀏覽器作為 Web 應用程式的前台，自身的處理功能比較有限。瀏覽器的發展需要用戶端升級軟體，同時由於用戶端瀏覽器軟體的多樣性，在某種意義上，也影響了瀏覽器新技術的推廣。在 Web 應用程式中，瀏覽器的主要工作是發送請求、解析伺服器返回的資訊以不同的風格顯示。AJAX 是瀏覽器技術發展的成果，通過在瀏覽器端發送非同步請求，提高了單使用者操作的響應性。但 Web 本質上是一個多使用者的系統，對任何使用者來說，可以認為伺服器是另外一個使用者。現有 AJAX 技術的發展並不能解決在一個多使用者的 Web 應用程式中，將更新的資訊即時傳送給用戶端，從而使用者可能在“過時”的資訊下進行操作。而 AJAX 的應用又使後台資料更新更加頻繁成為可能。

圖 1. 傳統的 Web 應用程式模型與基於 AJAX 的模型之比較

“伺服器推”是一種很早就存在的技術，以前在實現上主要是通過用戶端的套介面，或是伺服器端的遠程調用。因為瀏覽器技術的發展比較緩慢，沒有為“伺服器推”的實現提供很好的支援，在純瀏覽器的應用中很難有一個完善的方案去實現“伺服器推”並用於商業程式。最近幾年，因為 AJAX 技術的普及，以及把 IFrame 嵌在“htmlfile“的 ActiveX 組件中可以解決 IE 的載入顯示問題，一些受歡迎的應用如 meebo，gmail+gtalk 在實現中使用了這些新技術；同時“伺服器推”在現實應用中確實存在很多需求。因為這些原因，基於純瀏覽器的“伺服器推”技術開始受到較多關注，Alex Russell（Dojo Toolkit 的項目 Lead）稱這種基於 HTTP 長串連、無須在瀏覽器端安裝外掛程式的“伺服器推”技術為“Comet”。目前已經出現了一些成熟的 Comet 應用以及各種開源架構；一些 Web 服務器如 Jetty 也在為支援大量並發的長串連進行了很多改進。關於 Comet 技術最新的發展狀況請參考關於 Comet 的 wiki。

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

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

如 圖 1 所示，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. 當伺服器處理資訊出現異常情況，需要發送錯誤語音總機用戶端，同時釋放資源、關閉串連。

Pushlet - 開源 Comet 架構

Pushlet 是一個開源的 Comet 架構，在設計上有很多值得借鑒的地方，對於開發輕量級的 Comet 應用很有參考價值。

觀察者模型

Pushlet 使用了觀察者模型：用戶端發送請求，訂閱感興趣的事件；伺服器端為每個用戶端分配一個會話 ID 作為標記，事件來源會把新產生的事件以多播的方式發送到訂閱者的事件隊列裡。

用戶端 JavaScript 庫

pushlet 提供了基於 AJAX 的 JavaScript 庫檔案用於實現長輪詢方式的“伺服器推”；還提供了基於 iframe 的 JavaScript 庫檔案用於實現流方式的“伺服器推”。

JavaScript 庫做了很多封裝工作：

1. 定義用戶端的通訊狀態：STATE_ERROR、STATE_ABORT、STATE_NULL、STATE_READY、STATE_JOINED、STATE_LISTENING；
2. 儲存伺服器分配的會話 ID，在建立串連之後的每次請求中會附上會話 ID 表明身份；
3. 提供了 join()、leave()、subscribe()、 unsubsribe()、listen() 等 API 供頁面調用；
4. 提供了處理響應的 JavaScript 函數介面 onData()、onEvent()…

網頁可以很方便地使用這兩個 JavaScript 庫檔案封裝的 API 與伺服器進行通訊。

用戶端與伺服器端通訊資訊格式

pushlet 定義了一套客戶與伺服器通訊的資訊格式，使用 XML 格式。定義了用戶端發送請求的類型：join、leave、subscribe、unsubscribe、listen、refresh；以及響應的事件類型：data、join_ack、listen_ack、refresh、heartbeat、error、abort、subscribe_ack、unsubscribe_ack。

伺服器端事件隊列管理

pushlet 在伺服器端使用 Java Servlet 實現，其資料結構的設計架構仍可適用於 PHP、C 編寫的後台用戶端。

Pushlet 支援用戶端自己選擇使用流、拉（長輪詢）、輪詢方式。伺服器端根據客戶選擇的方式在讀取事件隊列（fetchEvents）時進行不同的處理。“輪詢”模式下 fetchEvents() 會馬上返回。”流“和”拉“模式使用阻塞的方式讀事件，如果逾時，會發給用戶端發送一個沒有新資訊收到的“heartbeat“事件，如果是“拉”模式，會把“heartbeat”與“refresh”事件一起傳給用戶端，通知用戶端重新發出請求、建立串連。

客戶服務器之間的會話管理

服務端在用戶端發送 join 請求時，會為用戶端分配一個會話 ID， 並傳給用戶端，然後用戶端就通過此會話 ID 標明身份發出 subscribe 和 listen 請求。伺服器端會為每個會話維護一個訂閱的主題集合、事件隊列。

伺服器端的事件來源會把新產生的事件以多播的方式發送到每個會話（即訂閱者）的事件隊列裡。

小結

本文介紹了如何在現有的技術基礎上選擇合適的方案開發一個“伺服器推”的應用，最優的方案還是取決於應用需求的本身。相對於傳統的 Web 應用程式， 目前開發 Comet 應用還是具有一定的挑戰性。

“伺服器推”存在廣泛的應用需求，為了使 Comet 模型適用於大規模的商業應用，以及方便使用者構建 Comet 應用，最近幾年，無論是伺服器還是瀏覽器都出現了很多新技術，同時也出現了很多開源的 Comet 架構、協議。需求推動技術的發展，相信 Comet 的應用會變得和 AJAX 一樣普及。