Html5的通信機制及效率的研究

吳曉東，王鵬

（長春理工大學 計算機科學技術學院，長春 130022）

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

然而，HTTP協議是嚴格遵循請求-響應模型的。即客戶端發送一個請求到服務器，服務器對請求做出響應并將響應信息發送回客戶端。不同于C/S應用的全雙工Socket連接，面向HTTP請求的連接是單向的。客戶端向服務器發出請求，服務器做出響應后斷開連接，一次通話結束。

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

1 傳統服務器推送技術

傳統的服務器推送技術的實現主要由客戶端拉拽和服務器推送兩種方式實現。

1.1 客戶端拉拽

客戶端拉拽主要是由HTML實現。在HTML的響應頭標簽中＜META＞能模擬HTTP協議的響應頭報文，＜META＞的用處很多，其中之一就是通過指定HTTP-EQUIV="Refresh"來實現對特定的網頁的刷新。如：

實現對目標網頁以20秒為間隔的刷新，通過設定刷新的間隔時間可以定時的從服務器獲取最新的信息，客戶端拖拽優點是實現簡單，缺點是隔一段時間就需要重新和服務器建立一次連接，時間間隔的選擇固定，效率比較低。

1.2 服務器推送

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

1.2.1 流方式（streaming）

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

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

1.2.2.長輪詢方式（long pooling）

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

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

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

腳本標簽在實現輪詢訪問方式上和XMLHttpRequest對象一致，都是在成功收到數據后再次發起訪問。但是基于JSONP訪問服務的錯誤處理機制并不完善，這是因為使用JSONP不能從服務器得到有效的反饋提示，既不能得到錯誤提示，也無法獲取其他異常的錯誤信息碼。

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

2 Web Socket

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

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

與傳統的服務器推送技術相比，WebSocket有以下特點：

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

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

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

3 Server-Sent Events

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

Server-Sent Events要求在服務器端傳回的消息的MIME類型為text/event-stream格式，在每次接受數據時因為沒有額外的消息頭等信息，使得消息的報文同樣簡約有效。

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

4 實驗

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

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

在圖1中保持連接發送的幀為TCP格式控制幀，以保持客戶端和服務器端長久的連接，大小為54字節，幀格式（十六進制）如下：

對圖1中服務器返回數據內容幀分析如表1。

表1 服務器返回數據幀內容大小分析（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和傳統的流方式在實現上很相似，都是發送保持連接的TCP格式的數據報文以達到建立長連接的效果，從表1的統計數據可以看出，每次從服務器端獲取更新數據時，噪音數據（除數據外的其他報文）還是比較低的，在表1中WebSocket由于定義數據起始格式（0x00開始，0xFF結束），比其他方式多出2個字節。

實驗二結果如圖2。

圖2 Ajax輪詢請求/響應過程圖Fig.2 Request/response process diagram of Ajax

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

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

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

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

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

5 結論

WebSocket和Server-Sent Events在實現機制上和以流方式建立長連接很相似，都是在發送TCP連接請求報文下建立長久的連接以達到實時通信的目的。同時，WebSocket和Server-Sent Events在連接方式稍有區別，前者為全雙工通信，后者為單工通信方式。

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

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

［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來實現Streaming模式的Comet［EB/OL］.http：//www.tech126.com/iframe-streaming-comet/，2010.

［4］Comet：基于 HTTP 長連接的“服務器推”技術［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，Frank Salim.Pro HTML5 Programming［M］.Apress press，2010.

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

［9］李國帥，范惠林，竹武林.武器模擬訓練系統軟件通機制的設計［J］.長春理工大學學報：自然科學版，2010，33（4）：81-83.