| 2007 年 8 月 31 日 很多應用譬如監控、即時(shí)通信、即時(shí)報價(jià)系統都需要將后臺發(fā)生的變化實(shí)時(shí)傳送到客戶(hù)端而無(wú)須客戶(hù)端不停地刷新、發(fā)送請求。本文首先介紹、比較了常用的“服務(wù)器推”方案，著(zhù)重介紹了 Comet － 使用 HTTP 長(cháng)連接、無(wú)須瀏覽器安裝插件的兩種“服務(wù)器推”方案：基于 AJAX 的長(cháng)輪詢(xún)方式；基于 iframe 及 htmlfile 的流方式。最后分析了開(kāi)發(fā) Comet 應用需要注意的一些問(wèn)題，以及如何借助開(kāi)源的 Comet 框架－pushlet 構建自己的“服務(wù)器推”應用。 傳統模式的 Web 系統以客戶(hù)端發(fā)出請求、服務(wù)器端響應的方式工作。這種方式并不能滿(mǎn)足很多現實(shí)應用的需求，譬如：
這些應用都需要服務(wù)器能實(shí)時(shí)地將更新的信息傳送到客戶(hù)端，而無(wú)須客戶(hù)端發(fā)出請求?！胺?wù)器推”技術(shù)在現實(shí)應用中有一些解決方案，本文將這些解決方案分為兩類(lèi)：一類(lèi)需要在瀏覽器端安裝插件，基于套接口傳送信息，或是使用 RMI、CORBA 進(jìn)行遠程調用；而另一類(lèi)則無(wú)須瀏覽器安裝任何插件、基于 HTTP 長(cháng)連接。 將“服務(wù)器推”應用在 Web 程序中，首先考慮的是如何在功能有限的瀏覽器端接收、處理信息：
基于客戶(hù)端套接口的“服務(wù)器推”技術(shù) 如果 Web 應用的用戶(hù)接受應用只有在安裝了 Flash 播放器才能正常運行， 那么使用 Flash 的 XMLSocket 也是一個(gè)可行的方案。 這種方案實(shí)現的基礎是：
具體實(shí)現方法：在 HTML 頁(yè)面中內嵌入一個(gè)使用了 XMLSocket 類(lèi)的 Flash 程序。JavaScript 通過(guò)調用此 Flash 程序提供的套接口接口與服務(wù)器端的套接口進(jìn)行通信。JavaScript 在收到服務(wù)器端以 XML 格式傳送的信息后可以很容易地控制 HTML 頁(yè)面的內容顯示。 關(guān)于如何去構建充當了 JavaScript 與 Flash XMLSocket 橋梁的 Flash 程序，以及如何在 JavaScript 里調用 Flash 提供的接口，我們可以參考 AFLAX（Asynchronous Flash and XML）項目提供的 Socket Demo 以及 SocketJS（請參見(jiàn) 參考資源）。 Javascript 與 Flash 的緊密結合，極大增強了客戶(hù)端的處理能力。從 Flash 播放器 V7.0.19 開(kāi)始，已經(jīng)取消了 XMLSocket 的端口必須大于 1023 的限制。Linux 平臺也支持 Flash XMLSocket 方案。但此方案的缺點(diǎn)在于：
不過(guò)這種方案在一些網(wǎng)絡(luò )聊天室，網(wǎng)絡(luò )互動(dòng)游戲中已得到廣泛使用。 在客戶(hù)端使用 Java Applet，通過(guò) 這種方案最大的不足在于 Java applet 在收到服務(wù)器端返回的信息后，無(wú)法通過(guò) JavaScript 去更新 HTML 頁(yè)面的內容。
基于 HTTP 長(cháng)連接的“服務(wù)器推”技術(shù) 瀏覽器作為 Web 應用的前臺，自身的處理功能比較有限。瀏覽器的發(fā)展需要客戶(hù)端升級軟件，同時(shí)由于客戶(hù)端瀏覽器軟件的多樣性，在某種意義上，也影響了瀏覽器新技術(shù)的推廣。在 Web 應用中，瀏覽器的主要工作是發(fā)送請求、解析服務(wù)器返回的信息以不同的風(fēng)格顯示。AJAX 是瀏覽器技術(shù)發(fā)展的成果，通過(guò)在瀏覽器端發(fā)送異步請求，提高了單用戶(hù)操作的響應性。但 Web 本質(zhì)上是一個(gè)多用戶(hù)的系統，對任何用戶(hù)來(lái)說(shuō)，可以認為服務(wù)器是另外一個(gè)用戶(hù)?，F有 AJAX 技術(shù)的發(fā)展并不能解決在一個(gè)多用戶(hù)的 Web 應用中，將更新的信息實(shí)時(shí)傳送給客戶(hù)端，從而用戶(hù)可能在“過(guò)時(shí)”的信息下進(jìn)行操作。而 AJAX 的應用又使后臺數據更新更加頻繁成為可能。 圖 1. 傳統的 Web 應用模型與基于 AJAX 的模型之比較  “服務(wù)器推”是一種很早就存在的技術(shù)，以前在實(shí)現上主要是通過(guò)客戶(hù)端的套接口，或是服務(wù)器端的遠程調用。因為瀏覽器技術(shù)的發(fā)展比較緩慢，沒(méi)有為“服務(wù)器推”的實(shí)現提供很好的支持，在純?yōu)g覽器的應用中很難有一個(gè)完善的方案去實(shí)現“服務(wù)器推”并用于商業(yè)程序。最近幾年，因為 AJAX 技術(shù)的普及，以及把 IFrame 嵌在“htmlfile“的 ActiveX 組件中可以解決 IE 的加載顯示問(wèn)題，一些受歡迎的應用如 meebo，gmail+gtalk 在實(shí)現中使用了這些新技術(shù)；同時(shí)“服務(wù)器推”在現實(shí)應用中確實(shí)存在很多需求。因為這些原因，基于純?yōu)g覽器的“服務(wù)器推”技術(shù)開(kāi)始受到較多關(guān)注，Alex Russell（Dojo Toolkit 的項目 Lead）稱(chēng)這種基于 HTTP 長(cháng)連接、無(wú)須在瀏覽器端安裝插件的“服務(wù)器推”技術(shù)為“Comet”。目前已經(jīng)出現了一些成熟的 Comet 應用以及各種開(kāi)源框架；一些 Web 服務(wù)器如 Jetty 也在為支持大量并發(fā)的長(cháng)連接進(jìn)行了很多改進(jìn)。關(guān)于 Comet 技術(shù)最新的發(fā)展狀況請參考關(guān)于 Comet 的 wiki。 下面將介紹兩種 Comet 應用的實(shí)現模型。 基于 AJAX 的長(cháng)輪詢(xún)（long-polling）方式 如 圖 1 所示，AJAX 的出現使得 JavaScript 可以調用 XMLHttpRequest 對象發(fā)出 HTTP 請求，JavaScript 響應處理函數根據服務(wù)器返回的信息對 HTML 頁(yè)面的顯示進(jìn)行更新。使用 AJAX 實(shí)現“服務(wù)器推”與傳統的 AJAX 應用不同之處在于：
圖 2. 基于長(cháng)輪詢(xún)的服務(wù)器推模型 一些應用及示例如 “Meebo”, “Pushlet Chat” 都采用了這種長(cháng)輪詢(xún)的方式。相對于“輪詢(xún)”（poll），這種長(cháng)輪詢(xún)方式也可以稱(chēng)為“拉”（pull）。因為這種方案基于 AJAX，具有以下一些優(yōu)點(diǎn)：請求異步發(fā)出；無(wú)須安裝插件；IE、Mozilla FireFox 都支持 AJAX。 在這種長(cháng)輪詢(xún)方式下，客戶(hù)端是在 XMLHttpRequest 的 readystate 為 4（即數據傳輸結束）時(shí)調用回調函數，進(jìn)行信息處理。當 readystate 為 4 時(shí)，數據傳輸結束，連接已經(jīng)關(guān)閉。Mozilla Firefox 提供了對 Streaming AJAX 的支持， 即 readystate 為 3 時(shí)（數據仍在傳輸中），客戶(hù)端可以讀取數據，從而無(wú)須關(guān)閉連接，就能讀取處理服務(wù)器端返回的信息。IE 在 readystate 為 3 時(shí)，不能讀取服務(wù)器返回的數據，目前 IE 不支持基于 Streaming AJAX。 基于 Iframe 及 htmlfile 的流（streaming）方式 iframe 是很早就存在的一種 HTML 標記， 通過(guò)在 HTML 頁(yè)面里嵌入一個(gè)隱蔵幀，然后將這個(gè)隱蔵幀的 SRC 屬性設為對一個(gè)長(cháng)連接的請求，服務(wù)器端就能源源不斷地往客戶(hù)端輸入數據。 圖 3. 基于流方式的服務(wù)器推模型 上節提到的 AJAX 方案是在 JavaScript 里處理 XMLHttpRequest 從服務(wù)器取回的數據，然后 Javascript 可以很方便的去控制 HTML 頁(yè)面的顯示。同樣的思路用在 iframe 方案的客戶(hù)端，iframe 服務(wù)器端并不返回直接顯示在頁(yè)面的數據，而是返回對客戶(hù)端 Javascript 函數的調用，如“ 從 圖 3 可以看到，每次數據傳送不會(huì )關(guān)閉連接，連接只會(huì )在通信出現錯誤時(shí)，或是連接重建時(shí)關(guān)閉（一些防火墻常被設置為丟棄過(guò)長(cháng)的連接， 服務(wù)器端可以設置一個(gè)超時(shí)時(shí)間， 超時(shí)后通知客戶(hù)端重新建立連接，并關(guān)閉原來(lái)的連接）。 使用 iframe 請求一個(gè)長(cháng)連接有一個(gè)很明顯的不足之處：IE、Morzilla Firefox 下端的進(jìn)度欄都會(huì )顯示加載沒(méi)有完成，而且 IE 上方的圖標會(huì )不停的轉動(dòng)，表示加載正在進(jìn)行。Google 的天才們使用一個(gè)稱(chēng)為“htmlfile”的 ActiveX 解決了在 IE 中的加載顯示問(wèn)題，并將這種方法用到了 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 瀏覽器，可以作為參考。（請參見(jiàn) 參考資源）
上面介紹了兩種基于 HTTP 長(cháng)連接的“服務(wù)器推”架構，更多描述了客戶(hù)端處理長(cháng)連接的技術(shù)。對于一個(gè)實(shí)際的應用而言，系統的穩定性和性能是非常重要的。將 HTTP 長(cháng)連接用于實(shí)際應用，很多細節需要考慮。 不要在同一客戶(hù)端同時(shí)使用超過(guò)兩個(gè)的 HTTP 長(cháng)連接 我們使用 IE 下載文件時(shí)會(huì )有這樣的體驗，從同一個(gè) Web 服務(wù)器下載文件，最多只能有兩個(gè)文件同時(shí)被下載。第三個(gè)文件的下載會(huì )被阻塞，直到前面下載的文件下載完畢。這是因為 HTTP 1.1 規范中規定，客戶(hù)端不應該與服務(wù)器端建立超過(guò)兩個(gè)的 HTTP 連接， 新的連接會(huì )被阻塞。而 IE 在實(shí)現中嚴格遵守了這種規定。 HTTP 1.1 對兩個(gè)長(cháng)連接的限制，會(huì )對使用了長(cháng)連接的 Web 應用帶來(lái)如下現象：在客戶(hù)端如果打開(kāi)超過(guò)兩個(gè)的 IE 窗口去訪(fǎng)問(wèn)同一個(gè)使用了長(cháng)連接的 Web 服務(wù)器，第三個(gè) IE 窗口的 HTTP 請求被前兩個(gè)窗口的長(cháng)連接阻塞。 所以在開(kāi)發(fā)長(cháng)連接的應用時(shí)， 必須注意在使用了多個(gè) frame 的頁(yè)面中，不要為每個(gè) frame 的頁(yè)面都建立一個(gè) HTTP 長(cháng)連接，這樣會(huì )阻塞其它的 HTTP 請求，在設計上考慮讓多個(gè) frame 的更新共用一個(gè)長(cháng)連接。 一般 Web 服務(wù)器會(huì )為每個(gè)連接創(chuàng )建一個(gè)線(xiàn)程，如果在大型的商業(yè)應用中使用 Comet，服務(wù)器端需要維護大量并發(fā)的長(cháng)連接。在這種應用背景下，服務(wù)器端需要考慮負載均衡和集群技術(shù)；或是在服務(wù)器端為長(cháng)連接作一些改進(jìn)。 應用和技術(shù)的發(fā)展總是帶來(lái)新的需求，從而推動(dòng)新技術(shù)的發(fā)展。HTTP 1.1 與 1.0 規范有一個(gè)很大的不同：1.0 規范下服務(wù)器在處理完每個(gè) Get/Post 請求后會(huì )關(guān)閉套接口連接； 而 1.1 規范下服務(wù)器會(huì )保持這個(gè)連接，在處理兩個(gè)請求的間隔時(shí)間里，這個(gè)連接處于空閑狀態(tài)。 Java 1.4 引入了支持異步 IO 的 java.nio 包。當連接處于空閑時(shí)，為這個(gè)連接分配的線(xiàn)程資源會(huì )返還到線(xiàn)程池，可以供新的連接使用；當原來(lái)處于空閑的連接的客戶(hù)發(fā)出新的請求，會(huì )從線(xiàn)程池里分配一個(gè)線(xiàn)程資源處理這個(gè)請求。 這種技術(shù)在連接處于空閑的機率較高、并發(fā)連接數目很多的場(chǎng)景下對于降低服務(wù)器的資源負載非常有效。 但是 AJAX 的應用使請求的出現變得頻繁，而 Comet 則會(huì )長(cháng)時(shí)間占用一個(gè)連接，上述的服務(wù)器模型在新的應用背景下會(huì )變得非常低效，線(xiàn)程池里有限的線(xiàn)程數甚至可能會(huì )阻塞新的連接。Jetty 6 Web 服務(wù)器針對 AJAX、Comet 應用的特點(diǎn)進(jìn)行了很多創(chuàng )新的改進(jìn)，請參考文章“AJAX，Comet and Jetty”（請參見(jiàn) 參考資源）。 使用長(cháng)連接時(shí)，存在一個(gè)很常見(jiàn)的場(chǎng)景：客戶(hù)端網(wǎng)頁(yè)需要關(guān)閉，而服務(wù)器端還處在讀取數據的堵塞狀態(tài)，客戶(hù)端需要及時(shí)通知服務(wù)器端關(guān)閉數據連接。服務(wù)器在收到關(guān)閉請求后首先要從讀取數據的阻塞狀態(tài)喚醒，然后釋放為這個(gè)客戶(hù)端分配的資源，再關(guān)閉連接。 所以在設計上，我們需要使客戶(hù)端的控制請求和數據請求使用不同的 HTTP 連接，才能使控制請求不會(huì )被阻塞。 在實(shí)現上，如果是基于 iframe 流方式的長(cháng)連接，客戶(hù)端頁(yè)面需要使用兩個(gè) iframe，一個(gè)是控制幀，用于往服務(wù)器端發(fā)送控制請求，控制請求能很快收到響應，不會(huì )被堵塞；一個(gè)是顯示幀，用于往服務(wù)器端發(fā)送長(cháng)連接請求。如果是基于 AJAX 的長(cháng)輪詢(xún)方式，客戶(hù)端可以異步地發(fā)出一個(gè) XMLHttpRequest 請求，通知服務(wù)器端關(guān)閉數據連接。 在瀏覽器與服務(wù)器之間維持一個(gè)長(cháng)連接會(huì )為通信帶來(lái)一些不確定性：因為數據傳輸是隨機的，客戶(hù)端不知道何時(shí)服務(wù)器才有數據傳送。服務(wù)器端需要確保當客戶(hù)端不再工作時(shí)，釋放為這個(gè)客戶(hù)端分配的資源，防止內存泄漏。因此需要一種機制使雙方知道大家都在正常運行。在實(shí)現上：
Pushlet 是一個(gè)開(kāi)源的 Comet 框架，在設計上有很多值得借鑒的地方，對于開(kāi)發(fā)輕量級的 Comet 應用很有參考價(jià)值。 觀(guān)察者模型 Pushlet 使用了觀(guān)察者模型：客戶(hù)端發(fā)送請求，訂閱感興趣的事件；服務(wù)器端為每個(gè)客戶(hù)端分配一個(gè)會(huì )話(huà) ID 作為標記，事件源會(huì )把新產(chǎn)生的事件以多播的方式發(fā)送到訂閱者的事件隊列里。 客戶(hù)端 JavaScript 庫 pushlet 提供了基于 AJAX 的 JavaScript 庫文件用于實(shí)現長(cháng)輪詢(xún)方式的“服務(wù)器推”；還提供了基于 iframe 的 JavaScript 庫文件用于實(shí)現流方式的“服務(wù)器推”。 JavaScript 庫做了很多封裝工作：
網(wǎng)頁(yè)可以很方便地使用這兩個(gè) JavaScript 庫文件封裝的 API 與服務(wù)器進(jìn)行通信。 客戶(hù)端與服務(wù)器端通信信息格式 pushlet 定義了一套客戶(hù)與服務(wù)器通信的信息格式，使用 XML 格式。定義了客戶(hù)端發(fā)送請求的類(lèi)型： 服務(wù)器端事件隊列管理 pushlet 在服務(wù)器端使用 Java Servlet 實(shí)現，其數據結構的設計框架仍可適用于 PHP、C 編寫(xiě)的后臺客戶(hù)端。 Pushlet 支持客戶(hù)端自己選擇使用流、拉（長(cháng)輪詢(xún)）、輪詢(xún)方式。服務(wù)器端根據客戶(hù)選擇的方式在讀取事件隊列（fetchEvents）時(shí)進(jìn)行不同的處理?！拜喸?xún)”模式下 客戶(hù)服務(wù)器之間的會(huì )話(huà)管理 服務(wù)端在客戶(hù)端發(fā)送 服務(wù)器端的事件源會(huì )把新產(chǎn)生的事件以多播的方式發(fā)送到每個(gè)會(huì )話(huà)（即訂閱者）的事件隊列里。
本文介紹了如何在現有的技術(shù)基礎上選擇合適的方案開(kāi)發(fā)一個(gè)“服務(wù)器推”的應用，最優(yōu)的方案還是取決于應用需求的本身。相對于傳統的 Web 應用， 目前開(kāi)發(fā) Comet 應用還是具有一定的挑戰性。 “服務(wù)器推”存在廣泛的應用需求，為了使 Comet 模型適用于大規模的商業(yè)應用，以及方便用戶(hù)構建 Comet 應用，最近幾年，無(wú)論是服務(wù)器還是瀏覽器都出現了很多新技術(shù)，同時(shí)也出現了很多開(kāi)源的 Comet 框架、協(xié)議。需求推動(dòng)技術(shù)的發(fā)展，相信 Comet 的應用會(huì )變得和 AJAX 一樣普及。 學(xué)習
|
聯(lián)系客服
