傳統(tǒng)模式的 Web 系統(tǒng)以客戶端發(fā)出請求、服務(wù)器端響應(yīng)的方式工作。這種方式并不能滿足很多現(xiàn)實(shí)應(yīng)用的需求，譬如：

• 監(jiān)控系統(tǒng)：后臺硬件熱插拔、LED、溫度、電壓發(fā)生變化；
• 即時(shí)通信系統(tǒng)：其它用戶登錄、發(fā)送信息；
• 即時(shí)報(bào)價(jià)系統(tǒng)：后臺數(shù)據(jù)庫內(nèi)容發(fā)生變化；

這些應(yīng)用都需要服務(wù)器能實(shí)時(shí)地將更新的信息傳送到客戶端，而無須客戶端發(fā)出請求。“服務(wù)器推”技術(shù)在現(xiàn)實(shí)應(yīng)用中有一些解決方案，本文將這些解決方案分為兩類：一類需要在瀏覽器端安裝插件，基于套接口傳送信息，或是使用 RMI、CORBA 進(jìn)行遠(yuǎn)程調(diào)用；而另一類則無須瀏覽器安裝任何插件、基于 HTTP 長連接。

將“服務(wù)器推”應(yīng)用在 Web 程序中，首先考慮的是如何在功能有限的瀏覽器端接收、處理信息：

1. 客戶端如何接收、處理信息，是否需要使用套接口或是使用遠(yuǎn)程調(diào)用。客戶端呈現(xiàn)給用戶的是 HTML 頁面還是 Java applet 或 Flash 窗口。如果使用套接口和遠(yuǎn)程調(diào)用，怎么和 JavaScript 結(jié)合修改 HTML 的顯示。
2. 客戶與服務(wù)器端通信的信息格式，采取怎樣的出錯(cuò)處理機(jī)制。
3. 客戶端是否需要支持不同類型的瀏覽器如 IE、Firefox，是否需要同時(shí)支持 Windows 和 Linux 平臺。

回頁首

基于客戶端套接口的“服務(wù)器推”技術(shù)

Flash XMLSocket

如果 Web 應(yīng)用的用戶接受應(yīng)用只有在安裝了 Flash 播放器才能正常運(yùn)行， 那么使用 Flash 的 XMLSocket 也是一個(gè)可行的方案。

這種方案實(shí)現(xiàn)的基礎(chǔ)是：

1. Flash 提供了 XMLSocket 類。
2. JavaScript 和 Flash 的緊密結(jié)合：在 JavaScript 可以直接調(diào)用 Flash 程序提供的接口。

具體實(shí)現(xiàn)方法：在 HTML 頁面中內(nèi)嵌入一個(gè)使用了 XMLSocket 類的 Flash 程序。JavaScript 通過調(diào)用此 Flash 程序提供的套接口接口與服務(wù)器端的套接口進(jìn)行通信。JavaScript 在收到服務(wù)器端以 XML 格式傳送的信息后可以很容易地控制 HTML 頁面的內(nèi)容顯示。

關(guān)于如何去構(gòu)建充當(dāng)了 JavaScript 與 Flash XMLSocket 橋梁的 Flash 程序，以及如何在 JavaScript 里調(diào)用 Flash 提供的接口，我們可以參考 AFLAX（Asynchronous Flash and XML）項(xiàng)目提供的 Socket Demo 以及 SocketJS（請參見 參考資源 ）。

Javascript 與 Flash 的緊密結(jié)合，極大增強(qiáng)了客戶端的處理能力。從 Flash 播放器 V7.0.19 開始，已經(jīng)取消了 XMLSocket 的端口必須大于 1023 的限制。Linux 平臺也支持 Flash XMLSocket 方案。但此方案的缺點(diǎn)在于：

1. 客戶端必須安裝 Flash 播放器；
2. 因?yàn)?XMLSocket 沒有 HTTP 隧道功能，XMLSocket 類不能自動(dòng)穿過防火墻；
3. 因?yàn)槭鞘褂锰捉涌冢枰O(shè)置一個(gè)通信端口，防火墻、代理服務(wù)器也可能對非 HTTP 通道端口進(jìn)行限制；

不過這種方案在一些網(wǎng)絡(luò)聊天室，網(wǎng)絡(luò)互動(dòng)游戲中已得到廣泛使用。

Java Applet 套接口

在客戶端使用 Java Applet，通過 java.net.Socket 或 java.net.DatagramSocket 或 java.net.MulticastSocket 建立與服務(wù)器端的套接口連接，從而實(shí)現(xiàn)“服務(wù)器推”。

這種方案最大的不足在于 Java applet 在收到服務(wù)器端返回的信息后，無法通過 JavaScript 去更新 HTML 頁面的內(nèi)容。

回頁首

基于 HTTP 長連接的“服務(wù)器推”技術(shù)

Comet 簡介

瀏覽器作為 Web 應(yīng)用的前臺，自身的處理功能比較有限。瀏覽器的發(fā)展需要客戶端升級軟件，同時(shí)由于客戶端瀏覽器軟件的多樣性，在某種意義上，也影響了瀏覽器新技術(shù)的推廣。在 Web 應(yīng)用中，瀏覽器的主要工作是發(fā)送請求、解析服務(wù)器返回的信息以不同的風(fēng)格顯示。AJAX 是瀏覽器技術(shù)發(fā)展的成果，通過在瀏覽器端發(fā)送異步請求，提高了單用戶操作的響應(yīng)性。但 Web 本質(zhì)上是一個(gè)多用戶的系統(tǒng)，對任何用戶來說，可以認(rèn)為服務(wù)器是另外一個(gè)用戶。現(xiàn)有 AJAX 技術(shù)的發(fā)展并不能解決在一個(gè)多用戶的 Web 應(yīng)用中，將更新的信息實(shí)時(shí)傳送給客戶端，從而用戶可能在“過時(shí)”的信息下進(jìn)行操作。而 AJAX 的應(yīng)用又使后臺數(shù)據(jù)更新更加頻繁成為可能。

圖 1. 傳統(tǒng)的 Web 應(yīng)用模型與基于 AJAX 的模型之比較

“服務(wù)器推”是一種很早就存在的技術(shù)，以前在實(shí)現(xiàn)上主要是通過客戶端的套接口，或是服務(wù)器端的遠(yuǎn)程調(diào)用。因?yàn)闉g覽器技術(shù)的發(fā)展比較緩慢，沒有為“服務(wù)器推”的實(shí)現(xiàn)提供很好的支持，在純?yōu)g覽器的應(yīng)用中很難有一個(gè)完善的方案去實(shí)現(xiàn)“服務(wù)器推”并用于商業(yè)程序。最近幾年，因?yàn)?AJAX 技術(shù)的普及，以及把 IFrame 嵌在“htmlfile“的 ActiveX 組件中可以解決 IE 的加載顯示問題，一些受歡迎的應(yīng)用如 meebo，gmail+gtalk 在實(shí)現(xiàn)中使用了這些新技術(shù)；同時(shí)“服務(wù)器推”在現(xiàn)實(shí)應(yīng)用中確實(shí)存在很多需求。因?yàn)檫@些原因，基于純?yōu)g覽器的“服務(wù)器推”技術(shù)開始受到較多關(guān)注，Alex Russell（Dojo Toolkit 的項(xiàng)目 Lead）稱這種基于 HTTP 長連接、無須在瀏覽器端安裝插件的“服務(wù)器推”技術(shù)為“Comet”。目前已經(jīng)出現(xiàn)了一些成熟的 Comet 應(yīng)用以及各種開源框架；一些 Web 服務(wù)器如 Jetty 也在為支持大量并發(fā)的長連接進(jìn)行了很多改進(jìn)。關(guān)于 Comet 技術(shù)最新的發(fā)展?fàn)顩r請參考關(guān)于 Comet 的 wiki。

下面將介紹兩種 Comet 應(yīng)用的實(shí)現(xiàn)模型。

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

如 圖 1 所示，AJAX 的出現(xiàn)使得 JavaScript 可以調(diào)用 XMLHttpRequest 對象發(fā)出 HTTP 請求，JavaScript 響應(yīng)處理函數(shù)根據(jù)服務(wù)器返回的信息對 HTML 頁面的顯示進(jìn)行更新。使用 AJAX 實(shí)現(xiàn)“服務(wù)器推”與傳統(tǒng)的 AJAX 應(yīng)用不同之處在于：

1. 服務(wù)器端會阻塞請求直到有數(shù)據(jù)傳遞或超時(shí)才返回。
2. 客戶端 JavaScript 響應(yīng)處理函數(shù)會在處理完服務(wù)器返回的信息后，再次發(fā)出請求，重新建立連接。
3. 當(dāng)客戶端處理接收的數(shù)據(jù)、重新建立連接時(shí)，服務(wù)器端可能有新的數(shù)據(jù)到達(dá)；這些信息會被服務(wù)器端保存直到客戶端重新建立連接，客戶端會一次把當(dāng)前服務(wù)器端所有的信息取回。

圖 2. 基于長輪詢的服務(wù)器推模型

一些應(yīng)用及示例如 “Meebo”, “Pushlet Chat” 都采用了這種長輪詢的方式。相對于“輪詢”（poll），這種長輪詢方式也可以稱為“拉”（pull）。因?yàn)檫@種方案基于 AJAX，具有以下一些優(yōu)點(diǎn)：請求異步發(fā)出；無須安裝插件；IE、Mozilla FireFox 都支持 AJAX。

在這種長輪詢方式下，客戶端是在 XMLHttpRequest 的 readystate 為 4（即數(shù)據(jù)傳輸結(jié)束）時(shí)調(diào)用回調(diào)函數(shù)，進(jìn)行信息處理。當(dāng) readystate 為 4 時(shí)，數(shù)據(jù)傳輸結(jié)束，連接已經(jīng)關(guān)閉。Mozilla Firefox 提供了對 Streaming AJAX 的支持， 即 readystate 為 3 時(shí)（數(shù)據(jù)仍在傳輸中），客戶端可以讀取數(shù)據(jù)，從而無須關(guān)閉連接，就能讀取處理服務(wù)器端返回的信息。IE 在 readystate 為 3 時(shí)，不能讀取服務(wù)器返回的數(shù)據(jù)，目前 IE 不支持基于 Streaming AJAX。

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

iframe 是很早就存在的一種 HTML 標(biāo)記， 通過在 HTML 頁面里嵌入一個(gè)隱蔵幀，然后將這個(gè)隱蔵幀的 SRC 屬性設(shè)為對一個(gè)長連接的請求，服務(wù)器端就能源源不斷地往客戶端輸入數(shù)據(jù)。

圖 3. 基于流方式的服務(wù)器推模型

上節(jié)提到的 AJAX 方案是在 JavaScript 里處理 XMLHttpRequest 從服務(wù)器取回的數(shù)據(jù)，然后 Javascript 可以很方便的去控制 HTML 頁面的顯示。同樣的思路用在 iframe 方案的客戶端，iframe 服務(wù)器端并不返回直接顯示在頁面的數(shù)據(jù)，而是返回對客戶端 Javascript 函數(shù)的調(diào)用，如“ <script type="text/javascript">js_func(“data from server ”)</script> ”。服務(wù)器端將返回的數(shù)據(jù)作為客戶端 JavaScript 函數(shù)的參數(shù)傳遞；客戶端瀏覽器的 Javascript 引擎在收到服務(wù)器返回的 JavaScript 調(diào)用時(shí)就會去執(zhí)行代碼。

從 圖 3 可以看到，每次數(shù)據(jù)傳送不會關(guān)閉連接，連接只會在通信出現(xiàn)錯(cuò)誤時(shí)，或是連接重建時(shí)關(guān)閉（一些防火墻常被設(shè)置為丟棄過長的連接， 服務(wù)器端可以設(shè)置一個(gè)超時(shí)時(shí)間， 超時(shí)后通知客戶端重新建立連接，并關(guān)閉原來的連接）。

使用 iframe 請求一個(gè)長連接有一個(gè)很明顯的不足之處：IE、Morzilla Firefox 下端的進(jìn)度欄都會顯示加載沒有完成，而且 IE 上方的圖標(biāo)會不停的轉(zhuǎn)動(dòng)，表示加載正在進(jìn)行。Google 的天才們使用一個(gè)稱為“htmlfile”的 ActiveX 解決了在 IE 中的加載顯示問題，并將這種方法用到了 gmail+gtalk 產(chǎn)品中。Alex Russell 在 “What else is burried down in the depth's of Google's amazing JavaScript?”文章中介紹了這種方法。Zeitoun 網(wǎng)站提供的 comet-iframe.tar.gz，封裝了一個(gè)基于 iframe 和 htmlfile 的 JavaScript comet 對象，支持 IE、Mozilla Firefox 瀏覽器，可以作為參考。（請參見 參考資源 ）

回頁首

使用 Comet 模型開發(fā)自己的應(yīng)用

上面介紹了兩種基于 HTTP 長連接的“服務(wù)器推”架構(gòu)，更多描述了客戶端處理長連接的技術(shù)。對于一個(gè)實(shí)際的應(yīng)用而言，系統(tǒng)的穩(wěn)定性和性能是非常重要的。將 HTTP 長連接用于實(shí)際應(yīng)用，很多細(xì)節(jié)需要考慮。

不要在同一客戶端同時(shí)使用超過兩個(gè)的 HTTP 長連接

我們使用 IE 下載文件時(shí)會有這樣的體驗(yàn)，從同一個(gè) Web 服務(wù)器下載文件，最多只能有兩個(gè)文件同時(shí)被下載。第三個(gè)文件的下載會被阻塞，直到前面下載的文件下載完畢。這是因?yàn)?HTTP 1.1 規(guī)范中規(guī)定，客戶端不應(yīng)該與服務(wù)器端建立超過兩個(gè)的 HTTP 連接， 新的連接會被阻塞。而 IE 在實(shí)現(xiàn)中嚴(yán)格遵守了這種規(guī)定。

HTTP 1.1 對兩個(gè)長連接的限制，會對使用了長連接的 Web 應(yīng)用帶來如下現(xiàn)象：在客戶端如果打開超過兩個(gè)的 IE 窗口去訪問同一個(gè)使用了長連接的 Web 服務(wù)器，第三個(gè) IE 窗口的 HTTP 請求被前兩個(gè)窗口的長連接阻塞。

所以在開發(fā)長連接的應(yīng)用時(shí)， 必須注意在使用了多個(gè) frame 的頁面中，不要為每個(gè) frame 的頁面都建立一個(gè) HTTP 長連接，這樣會阻塞其它的 HTTP 請求，在設(shè)計(jì)上考慮讓多個(gè) frame 的更新共用一個(gè)長連接。

服務(wù)器端的性能和可擴(kuò)展性

一般 Web 服務(wù)器會為每個(gè)連接創(chuàng)建一個(gè)線程，如果在大型的商業(yè)應(yīng)用中使用 Comet，服務(wù)器端需要維護(hù)大量并發(fā)的長連接。在這種應(yīng)用背景下，服務(wù)器端需要考慮負(fù)載均衡和集群技術(shù)；或是在服務(wù)器端為長連接作一些改進(jìn)。

應(yīng)用和技術(shù)的發(fā)展總是帶來新的需求，從而推動(dòng)新技術(shù)的發(fā)展。HTTP 1.1 與 1.0 規(guī)范有一個(gè)很大的不同：1.0 規(guī)范下服務(wù)器在處理完每個(gè) Get/Post 請求后會關(guān)閉套接口連接； 而 1.1 規(guī)范下服務(wù)器會保持這個(gè)連接，在處理兩個(gè)請求的間隔時(shí)間里，這個(gè)連接處于空閑狀態(tài)。 Java 1.4 引入了支持異步 IO 的 java.nio 包。當(dāng)連接處于空閑時(shí)，為這個(gè)連接分配的線程資源會返還到線程池，可以供新的連接使用；當(dāng)原來處于空閑的連接的客戶發(fā)出新的請求，會從線程池里分配一個(gè)線程資源處理這個(gè)請求。 這種技術(shù)在連接處于空閑的機(jī)率較高、并發(fā)連接數(shù)目很多的場景下對于降低服務(wù)器的資源負(fù)載非常有效。

但是 AJAX 的應(yīng)用使請求的出現(xiàn)變得頻繁，而 Comet 則會長時(shí)間占用一個(gè)連接，上述的服務(wù)器模型在新的應(yīng)用背景下會變得非常低效，線程池里有限的線程數(shù)甚至可能會阻塞新的連接。Jetty 6 Web 服務(wù)器針對 AJAX、Comet 應(yīng)用的特點(diǎn)進(jìn)行了很多創(chuàng)新的改進(jìn)，請參考文章“AJAX，Comet and Jetty”（請參見 參考資源 ）。

控制信息與數(shù)據(jù)信息使用不同的 HTTP 連接

使用長連接時(shí)，存在一個(gè)很常見的場景：客戶端網(wǎng)頁需要關(guān)閉，而服務(wù)器端還處在讀取數(shù)據(jù)的堵塞狀態(tài)，客戶端需要及時(shí)通知服務(wù)器端關(guān)閉數(shù)據(jù)連接。服務(wù)器在收到關(guān)閉請求后首先要從讀取數(shù)據(jù)的阻塞狀態(tài)喚醒，然后釋放為這個(gè)客戶端分配的資源，再關(guān)閉連接。

所以在設(shè)計(jì)上，我們需要使客戶端的控制請求和數(shù)據(jù)請求使用不同的 HTTP 連接，才能使控制請求不會被阻塞。

在實(shí)現(xiàn)上，如果是基于 iframe 流方式的長連接，客戶端頁面需要使用兩個(gè) iframe，一個(gè)是控制幀，用于往服務(wù)器端發(fā)送控制請求，控制請求能很快收到響應(yīng)，不會被堵塞；一個(gè)是顯示幀，用于往服務(wù)器端發(fā)送長連接請求。如果是基于 AJAX 的長輪詢方式，客戶端可以異步地發(fā)出一個(gè) XMLHttpRequest 請求，通知服務(wù)器端關(guān)閉數(shù)據(jù)連接。

在客戶和服務(wù)器之間保持“心跳”信息

在瀏覽器與服務(wù)器之間維持一個(gè)長連接會為通信帶來一些不確定性：因?yàn)閿?shù)據(jù)傳輸是隨機(jī)的，客戶端不知道何時(shí)服務(wù)器才有數(shù)據(jù)傳送。服務(wù)器端需要確保當(dāng)客戶端不再工作時(shí)，釋放為這個(gè)客戶端分配的資源，防止內(nèi)存泄漏。因此需要一種機(jī)制使雙方知道大家都在正常運(yùn)行。在實(shí)現(xiàn)上：

1. 服務(wù)器端在阻塞讀時(shí)會設(shè)置一個(gè)時(shí)限，超時(shí)后阻塞讀調(diào)用會返回，同時(shí)發(fā)給客戶端沒有新數(shù)據(jù)到達(dá)的心跳信息。此時(shí)如果客戶端已經(jīng)關(guān)閉，服務(wù)器往通道寫數(shù)據(jù)會出現(xiàn)異常，服務(wù)器端就會及時(shí)釋放為這個(gè)客戶端分配的資源。
2. 如果客戶端使用的是基于 AJAX 的長輪詢方式；服務(wù)器端返回?cái)?shù)據(jù)、關(guān)閉連接后，經(jīng)過某個(gè)時(shí)限沒有收到客戶端的再次請求，會認(rèn)為客戶端不能正常工作，會釋放為這個(gè)客戶端分配、維護(hù)的資源。
3. 當(dāng)服務(wù)器處理信息出現(xiàn)異常情況，需要發(fā)送錯(cuò)誤信息通知客戶端，同時(shí)釋放資源、關(guān)閉連接。

Pushlet - 開源 Comet 框架

Pushlet 是一個(gè)開源的 Comet 框架，在設(shè)計(jì)上有很多值得借鑒的地方，對于開發(fā)輕量級的 Comet 應(yīng)用很有參考價(jià)值。

觀察者模型

Pushlet 使用了觀察者模型：客戶端發(fā)送請求，訂閱感興趣的事件；服務(wù)器端為每個(gè)客戶端分配一個(gè)會話 ID 作為標(biāo)記，事件源會把新產(chǎn)生的事件以多播的方式發(fā)送到訂閱者的事件隊(duì)列里。

客戶端 JavaScript 庫

pushlet 提供了基于 AJAX 的 JavaScript 庫文件用于實(shí)現(xiàn)長輪詢方式的“服務(wù)器推”；還提供了基于 iframe 的 JavaScript 庫文件用于實(shí)現(xiàn)流方式的“服務(wù)器推”。

JavaScript 庫做了很多封裝工作：

1. 定義客戶端的通信狀態(tài)： STATE_ERROR 、 STATE_ABORT 、 STATE_NULL 、 STATE_READY 、 STATE_JOINED 、 STATE_LISTENING ；
2. 保存服務(wù)器分配的會話 ID，在建立連接之后的每次請求中會附上會話 ID 表明身份；
3. 提供了 join() 、 leave() 、 subscribe() 、 unsubsribe() 、 listen() 等 API 供頁面調(diào)用；
4. 提供了處理響應(yīng)的 JavaScript 函數(shù)接口 onData() 、 onEvent() …

網(wǎng)頁可以很方便地使用這兩個(gè) JavaScript 庫文件封裝的 API 與服務(wù)器進(jìn)行通信。

客戶端與服務(wù)器端通信信息格式

pushlet 定義了一套客戶與服務(wù)器通信的信息格式，使用 XML 格式。定義了客戶端發(fā)送請求的類型： join 、 leave 、 subscribe 、 unsubscribe 、 listen 、 refresh ；以及響應(yīng)的事件類型： data 、 join_ack 、 listen_ack 、 refresh 、 heartbeat 、 error 、 abort 、 subscribe_ack 、 unsubscribe_ack 。

服務(wù)器端事件隊(duì)列管理

pushlet 在服務(wù)器端使用 Java Servlet 實(shí)現(xiàn)，其數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)框架仍可適用于 PHP、C 編寫的后臺客戶端。

Pushlet 支持客戶端自己選擇使用流、拉（長輪詢）、輪詢方式。服務(wù)器端根據(jù)客戶選擇的方式在讀取事件隊(duì)列（fetchEvents）時(shí)進(jìn)行不同的處理。“輪詢”模式下 fetchEvents() 會馬上返回。”流“和”拉“模式使用阻塞的方式讀事件，如果超時(shí)，會發(fā)給客戶端發(fā)送一個(gè)沒有新信息收到的“heartbeat“事件，如果是“拉”模式，會把“heartbeat”與“refresh”事件一起傳給客戶端，通知客戶端重新發(fā)出請求、建立連接。

客戶服務(wù)器之間的會話管理

服務(wù)端在客戶端發(fā)送 join 請求時(shí)，會為客戶端分配一個(gè)會話 ID， 并傳給客戶端，然后客戶端就通過此會話 ID 標(biāo)明身份發(fā)出 subscribe 和 listen 請求。服務(wù)器端會為每個(gè)會話維護(hù)一個(gè)訂閱的主題集合、事件隊(duì)列。

服務(wù)器端的事件源會把新產(chǎn)生的事件以多播的方式發(fā)送到每個(gè)會話（即訂閱者）的事件隊(duì)列里。

回頁首

小結(jié)

本文介紹了如何在現(xiàn)有的技術(shù)基礎(chǔ)上選擇合適的方案開發(fā)一個(gè)“服務(wù)器推”的應(yīng)用，最優(yōu)的方案還是取決于應(yīng)用需求的本身。相對于傳統(tǒng)的 Web 應(yīng)用， 目前開發(fā) Comet 應(yīng)用還是具有一定的挑戰(zhàn)性。

“服務(wù)器推”存在廣泛的應(yīng)用需求，為了使 Comet 模型適用于大規(guī)模的商業(yè)應(yīng)用，以及方便用戶構(gòu)建 Comet 應(yīng)用，最近幾年，無論是服務(wù)器還是瀏覽器都出現(xiàn)了很多新技術(shù)，同時(shí)也出現(xiàn)了很多開源的 Comet 框架、協(xié)議。需求推動(dòng)技術(shù)的發(fā)展，相信 Comet 的應(yīng)用會變得和 AJAX 一樣普及。

“服務(wù)器推”技術(shù)的應(yīng)用