|
<noscript></noscript> <noscript><tr valign="top"> <td width="8"><img alt="" height="1" width="8" src="http://www.ibm.com/i/c.gif"></td> <td width="16"><img alt="" width="16" height="16" src="http://www.ibm.com/i/c.gif"></td> <td class="small" width="122"><p><span class="ast">未顯示需要 JavaScript 的文檔選項</span></p></td> </tr></noscript>
|
<!--START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- this content will be automatically generated across all content areas --><!--END RESERVED FOR FUTURE USE INCLUDE FILES-->
|
級別: 中級
周 婷
(
zhouting@cn.ibm.com
), 軟件工程師, IBM 中國軟件開發(fā)技術(shù)實驗室
2007 年 8 月 31 日
很 多應(yīng)用譬如監(jiān)控、即時通信、即時報價系統(tǒng)都需要將后臺發(fā)生的變化實時傳送到客戶端而無須客戶端不停地刷新、發(fā)送請求。本文首先介紹、比較了常用的“服務(wù)器 推”方案,著重介紹了 Comet - 使用 HTTP 長連接、無須瀏覽器安裝插件的兩種“服務(wù)器推”方案:基于 AJAX 的長輪詢方式;基于 iframe 及 htmlfile 的流方式。最后分析了開發(fā) Comet 應(yīng)用需要注意的一些問題,以及如何借助開源的 Comet 框架-pushlet 構(gòu)建自己的“服務(wù)器推”應(yīng)用。
<!--START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- include java script once we verify teams wants to use this and it will work on dbcs and cyrillic characters --> <!--END RESERVED FOR FUTURE USE INCLUDE FILES-->
“服務(wù)器推”技術(shù)的應(yīng)用
|
請訪問
Ajax 技術(shù)資源中心
,這是有關(guān) Ajax 編程模型信息的一站式中心,包括很多文檔、教程、論壇、blog、wiki 和新聞。任何 Ajax 的新信息都能在這里找到。
|
|
傳統(tǒng)模式的 Web 系統(tǒng)以客戶端發(fā)出請求、服務(wù)器端響應(yīng)的方式工作。這種方式并不能滿足很多現(xiàn)實應(yīng)用的需求,譬如:
-
監(jiān)控系統(tǒng):后臺硬件熱插拔、LED、溫度、電壓發(fā)生變化;
-
即時通信系統(tǒng):其它用戶登錄、發(fā)送信息;
-
即時報價系統(tǒng):后臺數(shù)據(jù)庫內(nèi)容發(fā)生變化;
這 些應(yīng)用都需要服務(wù)器能實時地將更新的信息傳送到客戶端,而無須客戶端發(fā)出請求。“服務(wù)器推”技術(shù)在現(xiàn)實應(yīng)用中有一些解決方案,本文將這些解決方案分為兩 類:一類需要在瀏覽器端安裝插件,基于套接口傳送信息,或是使用 RMI、CORBA 進(jìn)行遠(yuǎn)程調(diào)用;而另一類則無須瀏覽器安裝任何插件、基于 HTTP 長連接。
將“服務(wù)器推”應(yīng)用在 Web 程序中,首先考慮的是如何在功能有限的瀏覽器端接收、處理信息:
-
客戶端如何接收、處理信息,是否需要使用套接口或是使用遠(yuǎn)程調(diào)用。客戶端呈現(xiàn)給用戶的是 HTML 頁面還是 Java applet 或 Flash 窗口。如果使用套接口和遠(yuǎn)程調(diào)用,怎么和 JavaScript 結(jié)合修改 HTML 的顯示。
-
客戶與服務(wù)器端通信的信息格式,采取怎樣的出錯處理機(jī)制。
-
客戶端是否需要支持不同類型的瀏覽器如 IE、Firefox,是否需要同時支持 Windows 和 Linux 平臺。
基于客戶端套接口的“服務(wù)器推”技術(shù)
Flash XMLSocket
如果 Web 應(yīng)用的用戶接受應(yīng)用只有在安裝了 Flash 播放器才能正常運(yùn)行, 那么使用 Flash 的 XMLSocket 也是一個可行的方案。
這種方案實現(xiàn)的基礎(chǔ)是:
-
Flash 提供了 XMLSocket 類。
-
JavaScript 和 Flash 的緊密結(jié)合:在 JavaScript 可以直接調(diào)用 Flash 程序提供的接口。
具 體實現(xiàn)方法:在 HTML 頁面中內(nèi)嵌入一個使用了 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)項目提供的 Socket Demo 以及 SocketJS(請參見
參考資源
)。
Javascript 與 Flash 的緊密結(jié)合,極大增強(qiáng)了客戶端的處理能力。從 Flash 播放器 V7.0.19 開始,已經(jīng)取消了 XMLSocket 的端口必須大于 1023 的限制。Linux 平臺也支持 Flash XMLSocket 方案。但此方案的缺點在于:
-
客戶端必須安裝 Flash 播放器;
-
因為 XMLSocket 沒有 HTTP 隧道功能,XMLSocket 類不能自動穿過防火墻;
-
因為是使用套接口,需要設(shè)置一個通信端口,防火墻、代理服務(wù)器也可能對非 HTTP 通道端口進(jìn)行限制;
不過這種方案在一些網(wǎng)絡(luò)聊天室,網(wǎng)絡(luò)互動游戲中已得到廣泛使用。
Java Applet 套接口
在客戶端使用 Java Applet,通過
java.net.Socket
或
java.net.DatagramSocket
或
java.net.MulticastSocket
建立與服務(wù)器端的套接口連接,從而實現(xiàn)“服務(wù)器推”。
這種方案最大的不足在于 Java applet 在收到服務(wù)器端返回的信息后,無法通過 JavaScript 去更新 HTML 頁面的內(nèi)容。
基于 HTTP 長連接的“服務(wù)器推”技術(shù)
Comet 簡介
瀏 覽器作為 Web 應(yīng)用的前臺,自身的處理功能比較有限。瀏覽器的發(fā)展需要客戶端升級軟件,同時由于客戶端瀏覽器軟件的多樣性,在某種意義上,也影響了瀏覽器新技術(shù)的推廣。 在 Web 應(yīng)用中,瀏覽器的主要工作是發(fā)送請求、解析服務(wù)器返回的信息以不同的風(fēng)格顯示。AJAX 是瀏覽器技術(shù)發(fā)展的成果,通過在瀏覽器端發(fā)送異步請求,提高了單用戶操作的響應(yīng)性。但 Web 本質(zhì)上是一個多用戶的系統(tǒng),對任何用戶來說,可以認(rèn)為服務(wù)器是另外一個用戶。現(xiàn)有 AJAX 技術(shù)的發(fā)展并不能解決在一個多用戶的 Web 應(yīng)用中,將更新的信息實時傳送給客戶端,從而用戶可能在“過時”的信息下進(jìn)行操作。而 AJAX 的應(yīng)用又使后臺數(shù)據(jù)更新更加頻繁成為可能。
圖 1. 傳統(tǒng)的 Web 應(yīng)用模型與基于 AJAX 的模型之比較
“服 務(wù)器推”是一種很早就存在的技術(shù),以前在實現(xiàn)上主要是通過客戶端的套接口,或是服務(wù)器端的遠(yuǎn)程調(diào)用。因為瀏覽器技術(shù)的發(fā)展比較緩慢,沒有為“服務(wù)器推”的 實現(xiàn)提供很好的支持,在純?yōu)g覽器的應(yīng)用中很難有一個完善的方案去實現(xiàn)“服務(wù)器推”并用于商業(yè)程序。最近幾年,因為 AJAX 技術(shù)的普及,以及把 IFrame 嵌在“htmlfile“的 ActiveX 組件中可以解決 IE 的加載顯示問題,一些受歡迎的應(yīng)用如 meebo,gmail+gtalk 在實現(xiàn)中使用了這些新技術(shù);同時“服務(wù)器推”在現(xiàn)實應(yīng)用中確實存在很多需求。因為這些原因,基于純?yōu)g覽器的“服務(wù)器推”技術(shù)開始受到較多關(guān)注,Alex Russell(Dojo Toolkit 的項目 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)用的實現(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 實現(xiàn)“服務(wù)器推”與傳統(tǒng)的 AJAX 應(yīng)用不同之處在于:
-
服務(wù)器端會阻塞請求直到有數(shù)據(jù)傳遞或超時才返回。
-
客戶端 JavaScript 響應(yīng)處理函數(shù)會在處理完服務(wù)器返回的信息后,再次發(fā)出請求,重新建立連接。
-
當(dāng)客戶端處理接收的數(shù)據(jù)、重新建立連接時,服務(wù)器端可能有新的數(shù)據(jù)到達(dá);這些信息會被服務(wù)器端保存直到客戶端重新建立連接,客戶端會一次把當(dāng)前服務(wù)器端所有的信息取回。
圖 2. 基于長輪詢的服務(wù)器推模型
一 些應(yīng)用及示例如 “Meebo”, “Pushlet Chat” 都采用了這種長輪詢的方式。相對于“輪詢”(poll),這種長輪詢方式也可以稱為“拉”(pull)。因為這種方案基于 AJAX,具有以下一些優(yōu)點:請求異步發(fā)出;無須安裝插件;IE、Mozilla FireFox 都支持 AJAX。
在 這種長輪詢方式下,客戶端是在 XMLHttpRequest 的 readystate 為 4(即數(shù)據(jù)傳輸結(jié)束)時調(diào)用回調(diào)函數(shù),進(jìn)行信息處理。當(dāng) readystate 為 4 時,數(shù)據(jù)傳輸結(jié)束,連接已經(jīng)關(guān)閉。Mozilla Firefox 提供了對 Streaming AJAX 的支持, 即 readystate 為 3 時(數(shù)據(jù)仍在傳輸中),客戶端可以讀取數(shù)據(jù),從而無須關(guān)閉連接,就能讀取處理服務(wù)器端返回的信息。IE 在 readystate 為 3 時,不能讀取服務(wù)器返回的數(shù)據(jù),目前 IE 不支持基于 Streaming AJAX。
基于 Iframe 及 htmlfile 的流(streaming)方式
iframe 是很早就存在的一種 HTML 標(biāo)記, 通過在 HTML 頁面里嵌入一個隱蔵幀,然后將這個隱蔵幀的 SRC 屬性設(shè)為對一個長連接的請求,服務(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)用時就會去執(zhí)行代碼。
從
圖 3
可以看到,每次數(shù)據(jù)傳送不會關(guān)閉連接,連接只會在通信出現(xiàn)錯誤時,或是連接重建時關(guān)閉(一些防火墻常被設(shè)置為丟棄過長的連接, 服務(wù)器端可以設(shè)置一個超時時間, 超時后通知客戶端重新建立連接,并關(guān)閉原來的連接)。
使 用 iframe 請求一個長連接有一個很明顯的不足之處:IE、Morzilla Firefox 下端的進(jìn)度欄都會顯示加載沒有完成,而且 IE 上方的圖標(biāo)會不停的轉(zhuǎn)動,表示加載正在進(jìn)行。Google 的天才們使用一個稱為“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,封裝了一個基于 iframe 和 htmlfile 的 JavaScript comet 對象,支持 IE、Mozilla Firefox 瀏覽器,可以作為參考。(請參見
參考資源
)
使用 Comet 模型開發(fā)自己的應(yīng)用
上面介紹了兩種基于 HTTP 長連接的“服務(wù)器推”架構(gòu),更多描述了客戶端處理長連接的技術(shù)。對于一個實際的應(yīng)用而言,系統(tǒng)的穩(wěn)定性和性能是非常重要的。將 HTTP 長連接用于實際應(yīng)用,很多細(xì)節(jié)需要考慮。
不要在同一客戶端同時使用超過兩個的 HTTP 長連接
我 們使用 IE 下載文件時會有這樣的體驗,從同一個 Web 服務(wù)器下載文件,最多只能有兩個文件同時被下載。第三個文件的下載會被阻塞,直到前面下載的文件下載完畢。這是因為 HTTP 1.1 規(guī)范中規(guī)定,客戶端不應(yīng)該與服務(wù)器端建立超過兩個的 HTTP 連接, 新的連接會被阻塞。而 IE 在實現(xiàn)中嚴(yán)格遵守了這種規(guī)定。
HTTP 1.1 對兩個長連接的限制,會對使用了長連接的 Web 應(yīng)用帶來如下現(xiàn)象:在客戶端如果打開超過兩個的 IE 窗口去訪問同一個使用了長連接的 Web 服務(wù)器,第三個 IE 窗口的 HTTP 請求被前兩個窗口的長連接阻塞。
所以在開發(fā)長連接的應(yīng)用時, 必須注意在使用了多個 frame 的頁面中,不要為每個 frame 的頁面都建立一個 HTTP 長連接,這樣會阻塞其它的 HTTP 請求,在設(shè)計上考慮讓多個 frame 的更新共用一個長連接。
服務(wù)器端的性能和可擴(kuò)展性
一般 Web 服務(wù)器會為每個連接創(chuàng)建一個線程,如果在大型的商業(yè)應(yīng)用中使用 Comet,服務(wù)器端需要維護(hù)大量并發(fā)的長連接。在這種應(yīng)用背景下,服務(wù)器端需要考慮負(fù)載均衡和集群技術(shù);或是在服務(wù)器端為長連接作一些改進(jìn)。
應(yīng) 用和技術(shù)的發(fā)展總是帶來新的需求,從而推動新技術(shù)的發(fā)展。HTTP 1.1 與 1.0 規(guī)范有一個很大的不同:1.0 規(guī)范下服務(wù)器在處理完每個 Get/Post 請求后會關(guān)閉套接口連接; 而 1.1 規(guī)范下服務(wù)器會保持這個連接,在處理兩個請求的間隔時間里,這個連接處于空閑狀態(tài)。 Java 1.4 引入了支持異步 IO 的 java.nio 包。當(dāng)連接處于空閑時,為這個連接分配的線程資源會返還到線程池,可以供新的連接使用;當(dāng)原來處于空閑的連接的客戶發(fā)出新的請求,會從線程池里分配一個線 程資源處理這個請求。 這種技術(shù)在連接處于空閑的機(jī)率較高、并發(fā)連接數(shù)目很多的場景下對于降低服務(wù)器的資源負(fù)載非常有效。
但 是 AJAX 的應(yīng)用使請求的出現(xiàn)變得頻繁,而 Comet 則會長時間占用一個連接,上述的服務(wù)器模型在新的應(yīng)用背景下會變得非常低效,線程池里有限的線程數(shù)甚至可能會阻塞新的連接。Jetty 6 Web 服務(wù)器針對 AJAX、Comet 應(yīng)用的特點進(jìn)行了很多創(chuàng)新的改進(jìn),請參考文章“AJAX,Comet and Jetty”(請參見
參考資源
)。
控制信息與數(shù)據(jù)信息使用不同的 HTTP 連接
使用長連接時,存在一個很常見的場景:客戶端網(wǎng)頁需要關(guān)閉,而服務(wù)器端還處在讀取數(shù)據(jù)的堵塞狀態(tài),客戶端需要及時通知服務(wù)器端關(guān)閉數(shù)據(jù)連接。服務(wù)器在收到關(guān)閉請求后首先要從讀取數(shù)據(jù)的阻塞狀態(tài)喚醒,然后釋放為這個客戶端分配的資源,再關(guān)閉連接。
所以在設(shè)計上,我們需要使客戶端的控制請求和數(shù)據(jù)請求使用不同的 HTTP 連接,才能使控制請求不會被阻塞。
在 實現(xiàn)上,如果是基于 iframe 流方式的長連接,客戶端頁面需要使用兩個 iframe,一個是控制幀,用于往服務(wù)器端發(fā)送控制請求,控制請求能很快收到響應(yīng),不會被堵塞;一個是顯示幀,用于往服務(wù)器端發(fā)送長連接請求。如果是基 于 AJAX 的長輪詢方式,客戶端可以異步地發(fā)出一個 XMLHttpRequest 請求,通知服務(wù)器端關(guān)閉數(shù)據(jù)連接。
在客戶和服務(wù)器之間保持“心跳”信息
在瀏覽器與服務(wù)器之間維持一個長連接會為通信帶來一些不確定性:因為數(shù)據(jù)傳輸是隨機(jī)的,客戶端不知道何時服務(wù)器才有數(shù)據(jù)傳送。服務(wù)器端需要確保當(dāng)客戶端不再工作時,釋放為這個客戶端分配的資源,防止內(nèi)存泄漏。因此需要一種機(jī)制使雙方知道大家都在正常運(yùn)行。在實現(xiàn)上:
-
服務(wù)器端在阻塞讀時會設(shè)置一個時限,超時后阻塞讀調(diào)用會返回,同時發(fā)給客戶端沒有新數(shù)據(jù)到達(dá)的心跳信息。此時如果客戶端已經(jīng)關(guān)閉,服務(wù)器往通道寫數(shù)據(jù)會出現(xiàn)異常,服務(wù)器端就會及時釋放為這個客戶端分配的資源。
-
如果客戶端使用的是基于 AJAX 的長輪詢方式;服務(wù)器端返回數(shù)據(jù)、關(guān)閉連接后,經(jīng)過某個時限沒有收到客戶端的再次請求,會認(rèn)為客戶端不能正常工作,會釋放為這個客戶端分配、維護(hù)的資源。
-
當(dāng)服務(wù)器處理信息出現(xiàn)異常情況,需要發(fā)送錯誤信息通知客戶端,同時釋放資源、關(guān)閉連接。
Pushlet - 開源 Comet 框架
Pushlet 是一個開源的 Comet 框架,在設(shè)計上有很多值得借鑒的地方,對于開發(fā)輕量級的 Comet 應(yīng)用很有參考價值。
觀察者模型
Pushlet 使用了觀察者模型:客戶端發(fā)送請求,訂閱感興趣的事件;服務(wù)器端為每個客戶端分配一個會話 ID 作為標(biāo)記,事件源會把新產(chǎn)生的事件以多播的方式發(fā)送到訂閱者的事件隊列里。
客戶端 JavaScript 庫
pushlet 提供了基于 AJAX 的 JavaScript 庫文件用于實現(xiàn)長輪詢方式的“服務(wù)器推”;還提供了基于 iframe 的 JavaScript 庫文件用于實現(xiàn)流方式的“服務(wù)器推”。
JavaScript 庫做了很多封裝工作:
-
定義客戶端的通信狀態(tài):
STATE_ERROR
、
STATE_ABORT
、
STATE_NULL
、
STATE_READY
、
STATE_JOINED
、
STATE_LISTENING
;
-
保存服務(wù)器分配的會話 ID,在建立連接之后的每次請求中會附上會話 ID 表明身份;
-
提供了
join()
、
leave()
、
subscribe()
、
unsubsribe()
、
listen()
等 API 供頁面調(diào)用;
-
提供了處理響應(yīng)的 JavaScript 函數(shù)接口
onData()
、
onEvent()
…
網(wǎng)頁可以很方便地使用這兩個 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ù)器端事件隊列管理
pushlet 在服務(wù)器端使用 Java Servlet 實現(xiàn),其數(shù)據(jù)結(jié)構(gòu)的設(shè)計框架仍可適用于 PHP、C 編寫的后臺客戶端。
Pushlet 支持客戶端自己選擇使用流、拉(長輪詢)、輪詢方式。服務(wù)器端根據(jù)客戶選擇的方式在讀取事件隊列(fetchEvents)時進(jìn)行不同的處理。“輪詢”模式下
fetchEvents()
會馬上返回。”流“和”拉“模式使用阻塞的方式讀事件,如果超時,會發(fā)給客戶端發(fā)送一個沒有新信息收到的“heartbeat“事件,如果是“拉”模式,會把“heartbeat”與“refresh”事件一起傳給客戶端,通知客戶端重新發(fā)出請求、建立連接。
客戶服務(wù)器之間的會話管理
服務(wù)端在客戶端發(fā)送
join
請求時,會為客戶端分配一個會話 ID, 并傳給客戶端,然后客戶端就通過此會話 ID 標(biāo)明身份發(fā)出
subscribe
和
listen
請求。服務(wù)器端會為每個會話維護(hù)一個訂閱的主題集合、事件隊列。
服務(wù)器端的事件源會把新產(chǎn)生的事件以多播的方式發(fā)送到每個會話(即訂閱者)的事件隊列里。
小結(jié)
本文介紹了如何在現(xiàn)有的技術(shù)基礎(chǔ)上選擇合適的方案開發(fā)一個“服務(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ù),同時也出現(xiàn)了很多開源的 Comet 框架、協(xié)議。需求推動技術(shù)的發(fā)展,相信 Comet 的應(yīng)用會變得和 AJAX 一樣普及。
Comet:基于 HTTP 長連接的“服務(wù)器推”技術(shù)(輪詢)