Html5的通信機(jī)制及效率的研究

吳曉東，王鵬

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

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

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

在HTML5出現(xiàn)以前實(shí)現(xiàn)服務(wù)器向客戶端推送消息主要有兩種方式，一是服務(wù)器推送（Server Push），二是客戶端拉拽（Client Pull）。然而這兩種方式存在著效率低、實(shí)現(xiàn)稍顯復(fù)雜的問題。HTML5的出現(xiàn)有效的解決了這些問題，解決方案出于HTML5的兩個(gè)新特性：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)頭報(bào)文，＜META＞的用處很多，其中之一就是通過指定HTTP-EQUIV="Refresh"來實(shí)現(xiàn)對(duì)特定的網(wǎng)頁的刷新。如：

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

1.2 服務(wù)器推送

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

1.2.1 流方式（streaming）

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

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

1.2.2.長輪詢方式（long pooling）

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

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

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

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

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

2 Web Socket

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

“握手”的過程實(shí)際是在HTTP報(bào)頭中加入交互的信息，服務(wù)器端按照協(xié)議的格式響應(yīng)這種請(qǐng)求后，連接便成功建立。在連接建立成功后，Web-Socket會(huì)以定義的數(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對(duì)象時(shí)也有兩種方式，一種是普通創(chuàng)建方式（ws），另一種則是基于安全機(jī)制的創(chuàng)建方式（wss），創(chuàng)建格式如下：

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

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

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

3.實(shí)現(xiàn)更加簡單。在客戶端只需要?jiǎng)?chuàng)建Web-Socket對(duì)象同時(shí)對(duì)其的相應(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ù)時(shí)因?yàn)闆]有額外的消息頭等信息，使得消息的報(bào)文同樣簡約有效。

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

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

圖1 WebSocket、Server-Sent Events、XHR流和Iframe流請(qǐng)求/響應(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)制）如下：

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

表1 服務(wù)器返回?cái)?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ù)報(bào)文以達(dá)到建立長連接的效果，從表1的統(tǒng)計(jì)數(shù)據(jù)可以看出，每次從服務(wù)器端獲取更新數(shù)據(jù)時(shí)，噪音數(shù)據(jù)（除數(shù)據(jù)外的其他報(bào)文）還是比較低的，在表1中WebSocket由于定義數(shù)據(jù)起始格式（0x00開始，0xFF結(jié)束），比其他方式多出2個(gè)字節(jié)。

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

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

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

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

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

5 結(jié)論

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

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

然而在基于XHR（XmlHttpRequest）流和Iframe流的實(shí)現(xiàn)上都存在著明顯的缺陷，這些缺陷限制了其在服務(wù)器推送方面的應(yīng)用，隨著瀏覽器支持的深入，基于HTML5的WebSocket和Server-Sent Events無疑成為更好的選擇，這兩個(gè)特性不僅繼承了流方式的優(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ù)傳輸格式對(duì)Aiax實(shí)時(shí)性響應(yīng)的研究［J］.長春理工大學(xué)學(xué)報(bào)：自然科學(xué)版，2011，34（2）：146-149.

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