吳曉東，王鵬

（長春理工大學(xué) 計算機(jī)科學(xué)技術(shù)學(xué)院，長春 130022）

隨著基于瀏覽器訪問的Web應(yīng)用的變得廣泛和深入，一些應(yīng)用需求對Web應(yīng)用提出新的要求，其中服務(wù)器推送技術(shù)是一項(xiàng)備受追捧的技術(shù)。例如在股票交易行情分析、聊天室和 Web版在線游戲中均使用該技術(shù)以實(shí)現(xiàn)服務(wù)器主動推送消息通知客戶端的效果。

然而，HTTP協(xié)議是嚴(yán)格遵循請求-響應(yīng)模型的。即客戶端發(fā)送一個請求到服務(wù)器，服務(wù)器對請求做出響應(yīng)并將響應(yīng)信息發(fā)送回客戶端。不同于C/S應(yīng)用的全雙工Socket連接，面向HTTP請求的連接是單向的?？蛻舳讼蚍?wù)器發(fā)出請求，服務(wù)器做出響應(yīng)后斷開連接，一次通話結(jié)束。

在HTML5出現(xiàn)以前實(shí)現(xiàn)服務(wù)器向客戶端推送消息主要有兩種方式，一是服務(wù)器推送（Server Push），二是客戶端拉拽（Client Pull）。然而這兩種方式存在著效率低、實(shí)現(xiàn)稍顯復(fù)雜的問題。HTML5的出現(xiàn)有效的解決了這些問題，解決方案出于HTML5的兩個新特性：Web Socket和 Server-Sent Events。

1 傳統(tǒng)服務(wù)器推送技術(shù)

傳統(tǒng)的服務(wù)器推送技術(shù)的實(shí)現(xiàn)主要由客戶端拉拽和服務(wù)器推送兩種方式實(shí)現(xiàn)。

1.1 客戶端拉拽

客戶端拉拽主要是由HTML實(shí)現(xiàn)。在HTML的響應(yīng)頭標(biāo)簽中＜META＞能模擬HTTP協(xié)議的響應(yīng)頭報文，＜META＞的用處很多，其中之一就是通過指定HTTP-EQUIV="Refresh"來實(shí)現(xiàn)對特定的網(wǎng)頁的刷新。如：

實(shí)現(xiàn)對目標(biāo)網(wǎng)頁以20秒為間隔的刷新，通過設(shè)定刷新的間隔時間可以定時的從服務(wù)器獲取最新的信息，客戶端拖拽優(yōu)點(diǎn)是實(shí)現(xiàn)簡單，缺點(diǎn)是隔一段時間就需要重新和服務(wù)器建立一次連接，時間間隔的選擇固定，效率比較低。

1.2 服務(wù)器推送

服務(wù)器推送是指在客戶端發(fā)起請求與服務(wù)器建立連接后，服務(wù)器發(fā)送數(shù)據(jù)，客戶端得到這些數(shù)據(jù)，同時保證與服務(wù)器的連接。當(dāng)服務(wù)器需要再次發(fā)送數(shù)據(jù)時，客戶端仍接受數(shù)據(jù)并保持連接。直到客戶端或者服務(wù)器端主動中斷連接。和客戶端拖拽相比服務(wù)器端推送主要特征是使用不同方式建立一個HTTP長連接，基于服務(wù)器端推送的架構(gòu)可統(tǒng)一歸納為Comet應(yīng)用架構(gòu)，在Comet應(yīng)用中，創(chuàng)建長連接的方式有很多種，在實(shí)現(xiàn)上主要分為兩大類：

1.2.1 流方式（streaming）

流方式是指在服務(wù)器和客戶端建立一個持久有效的HTTP長連接。服務(wù)器端向客戶端源源不斷地發(fā)送事件，客戶端依次響應(yīng)這些事件，并逐條處理獲取的數(shù)據(jù)，雙方并不關(guān)閉這個連接。流方式在實(shí)現(xiàn)上主要包括隱藏幀（hidden iframe）和XMLHttpRequest兩種方式。通過隱藏幀實(shí)現(xiàn)主要是依靠iframe標(biāo)簽。iframe是很早就存在的一種 HTML標(biāo)簽，通過在 HTML頁面里嵌入一個隱藏幀，然后將這個隱蔵幀的 SRC屬性設(shè)為對服務(wù)器的長連接請求：

該方式的優(yōu)點(diǎn)是瀏覽器支持比較好，缺點(diǎn)是會導(dǎo)致部分瀏覽器的狀態(tài)條一直為讀取狀態(tài)且鼠標(biāo)狀態(tài)為忙碌，影響用戶體驗(yàn)。Google的工程師們通過包裝特定的js對象，在IE下使用htmlfile（ActiveX組件），F(xiàn)irefox下嵌套Iframe解決了這個問題。流方式的第二種手段是通過XMLHttpRequest的Ajax請求，在客戶端通過截獲XMLHttpRequest的Ready-State的狀態(tài)（狀態(tài)值為3時為數(shù)據(jù)讀取狀態(tài)）就可以獲取來自服務(wù)器端源源不斷地數(shù)據(jù)。但這種方式目前在IE下并不成功，原因是IE缺乏對Ajax請求數(shù)據(jù)傳輸狀態(tài)（ReadyState為3）的有效定義和支持。

1.2.2.長輪詢方式（long pooling）

長輪詢方式和客戶端拖拽有些相似，但是在建立連接的時間選擇上有區(qū)別。客戶端拖拽設(shè)定固定時間從服務(wù)器端取數(shù)據(jù)（刷新或其他方式）。長輪詢方式則是客戶端在一次獲取數(shù)據(jù)成功而自動斷開連接后再次發(fā)出請求以建立連接。長輪詢方式實(shí)現(xiàn)方式也主要分為兩種。

一種是借助XMLHttpRequest對象，通過發(fā)送Ajax請求在成功返回數(shù)據(jù)（ReadyState為4）并自動斷開連接后再次調(diào)用請求函數(shù)，這樣便可以實(shí)現(xiàn)對服務(wù)器的輪詢訪問。

另外一種則是通過腳本標(biāo)簽（Script Tag），和ifarme和XMLHttpRequest對象的同源策略不同，腳本標(biāo)簽?zāi)軌蛟L問任意的URL，實(shí)現(xiàn)跨域輪詢訪問。同源策略阻止從一個域上加載的腳本獲取或操作另一個域上的文檔屬性。也就是說，受到請求的URL的域必須與當(dāng)前 Web頁面的域相同。但是同源策略不阻止將動態(tài)腳本元素插入文檔中。通過訪問來自不同域的攜帶JSON數(shù)據(jù)的腳本，即訪問JSONP（JSON with Padding）服務(wù)，便可以達(dá)到跨域的效果。只要在接收數(shù)據(jù)成功后，再次向JSONP服務(wù)發(fā)起請求，便可以實(shí)現(xiàn)跨域輪詢訪問。

腳本標(biāo)簽在實(shí)現(xiàn)輪詢訪問方式上和XMLHttpRequest對象一致，都是在成功收到數(shù)據(jù)后再次發(fā)起訪問。但是基于JSONP訪問服務(wù)的錯誤處理機(jī)制并不完善，這是因?yàn)槭褂肑SONP不能從服務(wù)器得到有效的反饋提示，既不能得到錯誤提示，也無法獲取其他異常的錯誤信息碼。

除了客戶端拉拽和服務(wù)器端推送外，還可以通過Flash提供的XMLSocket類，Java Applet套接口來實(shí)現(xiàn)。使用Flash XMLSocket需要在客戶端安裝Flash播放器，而且XMLSocket需要單獨(dú)的通信端口，無法自動穿過防火墻。而Java Applet套接口不足在于 Java applet在收到服務(wù)器端返回的信息后，無法通過 JavaScript去更新 HTML頁面的內(nèi)容。

2 Web Socket

WebSocket是HTML5的新標(biāo)準(zhǔn)，它通過定義一個建立在TCP協(xié)議之上的套接字（Socket）來支持建立雙向的通信信道。首先，WebSocket利用已有的HTTP協(xié)議實(shí)現(xiàn)服務(wù)器端和客戶端的“握手”認(rèn)證?！拔帐帧钡耐ㄐ诺母袷饺缦拢?/p>

“握手”的過程實(shí)際是在HTTP報頭中加入交互的信息，服務(wù)器端按照協(xié)議的格式響應(yīng)這種請求后，連接便成功建立。在連接建立成功后，Web-Socket會以定義的數(shù)據(jù)幀的格式進(jìn)行全雙工的通信。根據(jù)最新的工作草案（working draft 76）Web-Socket數(shù)據(jù)幀的格式分為文本幀和text frame）和二進(jìn)制幀（binary frame）。文本幀以字節(jié)0x00開頭，以字節(jié)0xFF結(jié)尾，文本幀的內(nèi)容則以UTF8格式進(jìn)程編碼傳送。二進(jìn)制幀以字節(jié)0x80開始，沒有結(jié)束標(biāo)志。WebSocket定義四種消息響應(yīng)事件：onopen，onclose，onerror，onmessage。和 Http 類似，在創(chuàng)建WebSocket對象時也有兩種方式，一種是普通創(chuàng)建方式（ws），另一種則是基于安全機(jī)制的創(chuàng)建方式（wss），創(chuàng)建格式如下：

與傳統(tǒng)的服務(wù)器推送技術(shù)相比，WebSocket有以下特點(diǎn)：

1.簡約的報文傳送。由于長輪詢在每次請求/響應(yīng)后都會有額外的消息頭信息，在報文內(nèi)容并不復(fù)雜且客戶端連接數(shù)目巨大的情況下，這種額外的報文頭部噪音數(shù)據(jù)對網(wǎng)絡(luò)資源的消耗無疑十分巨大。

2.更完善的瀏覽器支持。實(shí)際上，流技術(shù)已經(jīng)在傳統(tǒng)的推送技術(shù)中占有一席之地。但是礙于其不同方面的缺陷和最新瀏覽器對WebSocket的廣泛支持（WebSocket功能內(nèi)置），WebSocket也漸漸成為一種好的選擇。

3.實(shí)現(xiàn)更加簡單。在客戶端只需要創(chuàng)建Web-Socket對象同時對其的相應(yīng)的事件進(jìn)行監(jiān)聽；在服務(wù)器端可以使用的技術(shù)也很多，如PHP，Java，Asp.net，NodeJS或是任意一種支持Socket通信的服務(wù)器腳本語言，在服務(wù)器端實(shí)現(xiàn)“握手”協(xié)議后便可以進(jìn)行通信。以下是通過NodeJS實(shí)現(xiàn)的服務(wù)器端的簡單模擬環(huán)境：

3 Server-Sent Events

和WebSocket的全雙工通信不同，HTML5的Server-Sent Events事件是基于單工信道通信的，即只能由服務(wù)器端向客戶端發(fā)送消息。實(shí)現(xiàn)Server-Sent Events的方式如下：

Server-Sent Events要求在服務(wù)器端傳回的消息的MIME類型為text/event-stream格式，在每次接受數(shù)據(jù)時因?yàn)闆]有額外的消息頭等信息，使得消息的報文同樣簡約有效。

雖然與WebSocket比較起來在功能上有欠缺，但是Server-Sent Event不需要進(jìn)行“握手”認(rèn)證等操作，在服務(wù)器和客戶端實(shí)現(xiàn)上也更加簡單。而且在一部分實(shí)際應(yīng)用中更直接的需求是服務(wù)器對消息的實(shí)時有效的推送，對客戶端與服務(wù)器端的實(shí)時交互并不嚴(yán)格。因此，在一些情況下使用Server-Sent Events能夠以更簡便的方式完成和Web-Socket同樣效果的功能。

4 實(shí)驗(yàn)

圖1 WebSocket、Server-Sent Events、XHR流和Iframe流請求/響應(yīng)過程圖Fig.1 Request/response process diagram of WebSocket，Server-Sent Events，XHR and Iframe stream

由于WebSocket和Server-Sent Events是由傳統(tǒng)的Comet技術(shù)發(fā)展而來，且在實(shí)現(xiàn)方式上和傳統(tǒng)的流方式實(shí)現(xiàn)類似，所以在實(shí)驗(yàn)過程中將Web-Socket和Server-Sent Events并入流方式的討論范圍，實(shí)驗(yàn)一將比較基于WebSocket、Server-Sent Events、XHR（XmlHttpRequest）流和 Iframe流四種不同流的實(shí)現(xiàn)方式下數(shù)據(jù)幀在收發(fā)上的異同。實(shí)驗(yàn)二則從流機(jī)制（以Server-Sent Event為例）和輪詢機(jī)制進(jìn)行比較，觀察兩者的效率差異。實(shí)驗(yàn)一結(jié)果如圖1所示。

在圖1中保持連接發(fā)送的幀為TCP格式控制幀，以保持客戶端和服務(wù)器端長久的連接，大小為54字節(jié)，幀格式（十六進(jìn)制）如下：

對圖1中服務(wù)器返回數(shù)據(jù)內(nèi)容幀分析如表1。

表1 服務(wù)器返回數(shù)據(jù)幀內(nèi)容大小分析（A：XHR流；B：XHR長輪詢；C：WebSocket；D：Server-Sent Events）Tab.1 Analysis of the frame and data size from server

從圖1可以看出WebSocket和Server-Sent Events和傳統(tǒng)的流方式在實(shí)現(xiàn)上很相似，都是發(fā)送保持連接的TCP格式的數(shù)據(jù)報文以達(dá)到建立長連接的效果，從表1的統(tǒng)計數(shù)據(jù)可以看出，每次從服務(wù)器端獲取更新數(shù)據(jù)時，噪音數(shù)據(jù)（除數(shù)據(jù)外的其他報文）還是比較低的，在表1中WebSocket由于定義數(shù)據(jù)起始格式（0x00開始，0xFF結(jié)束），比其他方式多出2個字節(jié)。

實(shí)驗(yàn)二結(jié)果如圖2。

圖2 Ajax輪詢請求/響應(yīng)過程圖Fig.2 Request/response process diagram of Ajax

在初次建立連接上，輪詢和流方式?jīng)]有明顯的差別，但是在以后的獲取服務(wù)器數(shù)據(jù)過程中輪詢過程每次消耗在連接請求上的帶寬和時間消耗是巨大的，而流方式則通過發(fā)送TCP連接報文建立長連接來替代連接請求。以下是兩者在每次從服務(wù)器獲取數(shù)據(jù)的資源消耗比較情況（不包含數(shù)據(jù)幀）。

表2 流方式和輪詢方式在每次更新數(shù)據(jù)時資源消耗比較Tab.2 Comparison of resource consuming on updating in streaming and pooling manner

同時，在獲取的數(shù)據(jù)幀產(chǎn)生的噪音數(shù)據(jù)上，兩種方式也存在明顯差別，輪詢方式返回的數(shù)據(jù)內(nèi)容幀大小比較如表3所示。

表3 流方式和輪詢方式在數(shù)據(jù)幀大小上的比較情況（流方式數(shù)據(jù)來自表1）Tab.3 Comparison of the frame size in streaming and pooling manner

從圖2可以看出與流方式實(shí)現(xiàn)不同，輪詢方式在一次通信完畢后需要再次發(fā)起請求以便從服務(wù)器再次更新數(shù)據(jù)。而流方式的實(shí)現(xiàn)則比較簡單，僅僅需要發(fā)送一個TCP連接報文便可以繼續(xù)從服務(wù)器獲得數(shù)據(jù)。表2則表明在重新建立連接和保持連接兩種實(shí)現(xiàn)方式下的帶寬和時間上的消耗存在著明顯的差異。輪詢方式需要消耗更多的時間發(fā)送更大的報文來更新客戶端數(shù)據(jù)。通過表3也可以看出，輪詢方式不僅僅在重新建立連接上有消耗，在返回數(shù)據(jù)幀所產(chǎn)生的噪音數(shù)據(jù)方面也遠(yuǎn)遠(yuǎn)大于流方式下的數(shù)據(jù)幀報文。

5 結(jié)論

WebSocket和Server-Sent Events在實(shí)現(xiàn)機(jī)制上和以流方式建立長連接很相似，都是在發(fā)送TCP連接請求報文下建立長久的連接以達(dá)到實(shí)時通信的目的。同時，WebSocket和Server-Sent Events在連接方式稍有區(qū)別，前者為全雙工通信，后者為單工通信方式。

輪詢方式和流方式在資源消耗上產(chǎn)生巨大的差異。輪詢方式在每次建立連接的過程中使用更長的時間消耗了更多的帶寬資源，同時在返回的數(shù)據(jù)幀格式上產(chǎn)生了更大的噪音數(shù)據(jù)。在多用戶訪問的情況下，這種帶寬的消耗是驚人的。相比而言，流方式的有著更為有效的控制方式和簡約的數(shù)據(jù)格式。

然而在基于XHR（XmlHttpRequest）流和Iframe流的實(shí)現(xiàn)上都存在著明顯的缺陷，這些缺陷限制了其在服務(wù)器推送方面的應(yīng)用，隨著瀏覽器支持的深入，基于HTML5的WebSocket和Server-Sent Events無疑成為更好的選擇，這兩個特性不僅繼承了流方式的優(yōu)點(diǎn)，在實(shí)現(xiàn)上也更為簡單。

［1］Client Pull/Server Push［EB/OL］.http：//www.kiv.zcu.cz/～ledvina/vyuka/books/HTMLnya/ch38.htm，2005.

［2］Infrequently Noted［EB/OL］.http：//infrequently.org/2006/03/comet-low-latency-data-for-the-browser/，2006.

［3］使用Iframe來實(shí)現(xiàn)Streaming模式的Comet［EB/OL］.http：//www.tech126.com/iframe-streaming-comet/，2010.

［4］Comet：基于 HTTP 長連接的“服務(wù)器推”技術(shù)［EB/OL］.http：//www.ibm.com/developerworks/cn/web/wa-lo-comet/，2007.

［5］Mark Pilgrim.HTML5：Up and Running［M］.O’Reilly press，2010.

［6］The WebSocket protocol draft-hixie-the websocketprotocol-76［EB/OL］.http：//tools.ietf.org/html/drafthixie-thewebsocketprotocol-76，2010.

［7］Peter Lubbers，Brain Albers，F(xiàn)rank Salim.Pro HTML5 Programming［M］.Apress press，2010.

［8］王鵬，吳曉東，楊華民.基于不同數(shù)據(jù)傳輸格式對Aiax實(shí)時性響應(yīng)的研究［J］.長春理工大學(xué)學(xué)報：自然科學(xué)版，2011，34（2）：146-149.

［9］李國帥，范惠林，竹武林.武器模擬訓(xùn)練系統(tǒng)軟件通機(jī)制的設(shè)計［J］.長春理工大學(xué)學(xué)報：自然科學(xué)版，2010，33（4）：81-83.