溫照松 易仁偉 姚寒冰

摘要：由于用戶對Web信息實(shí)時性要求的提高，實(shí)時Web應(yīng)用開始被廣泛關(guān)注，基于各種服務(wù)器推送技術(shù)的實(shí)時Web應(yīng)用解決方案被提出并廣泛應(yīng)用。然而這些解決方案都存在系統(tǒng)資源消耗大等方面的問題，有待進(jìn)一步的改進(jìn)和完善。該文介紹了當(dāng)前較為廣泛應(yīng)用的兩種基于HTTP協(xié)議的實(shí)時Web應(yīng)用方案，即基于Ajax的長輪詢方式和基于Iframe的流方式，并分析了這兩種方案存在的不足。在對HTML5標(biāo)準(zhǔn)中的WebSocket協(xié)議進(jìn)行深入分析的基礎(chǔ)上，該文提出了一種基于WebSocket協(xié)議的實(shí)時Web解決方案，目的是大幅提升實(shí)時服務(wù)性能，并更高效地利用網(wǎng)絡(luò)負(fù)載和服務(wù)器端的處理能力。

關(guān)鍵詞:服務(wù)器推送技術(shù)；實(shí)時Web應(yīng)用；HTML5；WebSocket協(xié)議；HTTP協(xié)議

中圖分類號：TP393文獻(xiàn)標(biāo)識碼：A文章編號：1009-3044(2012)16-3826-03

WebSocket Based Real Time Web Application Solution

WENG Zhao-song1,YI Ren-wei2,YAO Han-bin2

(1.Wuhan Construction Project Trading Center,Wuhan 430023,China;2.Wuhan Uinversity of Technology,Wuhan 430063,China)

Abstract: Due to the improving demands on instantaneity of web information, real-time web applications is beginning to cause wide spread interest, and a lot of real-time web applications based on server-push technology has been proposed and used widely. Though these solution are effective, all those solutions suffer from problems such as great resource consumption; there is much space for improve ment. This paper introduces two popular HTTP protocol based real-time web application solutions, that is, long polling based on Ajax and streaming based on Iframe, and analysis their weaknesses. With an in-depth study on WebSocket protocol in HTML5 standard, this paper proposes a WebSocket protocol based real-time web application solution, aiming at improving the service instantaneity on a large scale, and more efficiently using the network capacity and processing power of the server.

Key words: server-push;real-time application; HTML5;WebSocket protocol;HTTP protocol

基于HTTP協(xié)議的Web應(yīng)用已得到了十足的發(fā)展和應(yīng)用，成為人們獲取互聯(lián)網(wǎng)上海量信息的主要途徑。然而隨著信息時代的發(fā)展，人們開始對Web應(yīng)用提出了實(shí)時性要求，希望這些信息更新后能夠立即獲取到。對這項(xiàng)需求，多種實(shí)時Web應(yīng)用解決方案被提出，其中較為成功并廣泛應(yīng)用的包括：基于Ajax的長輪詢以及基于Iframe的流方式。基于這些解決方案，互聯(lián)網(wǎng)上涌現(xiàn)出了一系列實(shí)時應(yīng)用，如在線游戲、在線證券、設(shè)備監(jiān)控、RSS閱讀推送、郵件提示等等。

然而這些技術(shù)在廣泛運(yùn)用的過程中也暴露出了大量的問題，如實(shí)現(xiàn)復(fù)雜、資源消耗大、實(shí)時性不高等，這些問題制約了實(shí)時Web應(yīng)用的性能。

隨著HTML5標(biāo)準(zhǔn)的發(fā)展，該標(biāo)準(zhǔn)中提出的一項(xiàng)名為WebSocket的通信協(xié)議得到了廣泛的關(guān)注。WebSocket可以在瀏覽器和服務(wù)器之間提供一條基于TCP連接的雙向通道，服務(wù)器和瀏覽器通過這個通道可以實(shí)現(xiàn)雙向通信。這種雙向通信能力使得利用WebSocket來構(gòu)建實(shí)時web應(yīng)用成為可能。

該文將在總結(jié)現(xiàn)有的兩種實(shí)時Web應(yīng)用方案的基礎(chǔ)上，提出一種基于WebSocket的解決方案，新的方案將在很大程度上解決傳統(tǒng)方案暴露出的問題。

1傳統(tǒng)實(shí)時Web應(yīng)用解決方案

在實(shí)時Web應(yīng)用出現(xiàn)之初，最簡單的實(shí)現(xiàn)方案是輪詢。所謂輪詢就是客戶端以一定的時間間隔向服務(wù)器端發(fā)出請求，以頻繁請求的方式來不斷刷新客戶端呈現(xiàn)的信息。這種方案缺乏靈活性，無論服務(wù)器端是否有信息更新，請求都會不斷被發(fā)送，頻繁的連接請求會給服務(wù)器端帶來巨大的處理壓力。所以這種方案逐漸被舍棄，進(jìn)而發(fā)展出了基于Ajax的長輪詢方式和基于Iframe的流方式。這兩種方式都在原有輪詢的基礎(chǔ)做了改進(jìn)，一定程度上克服了簡單輪詢的不足。

1.1基于Ajax的長輪詢方式和基于Iframe的流方式

1.1.1基于Ajax的長輪詢方式

所謂Ajax，是異步JavaScript和XML技術(shù)的簡稱。采用Ajax方法，客戶端利用JavaScript的XMLHttpRequest對象以異步的方式向服務(wù)器發(fā)送HTTP請求，在不重載頁面的情況下完成與服務(wù)器的數(shù)據(jù)交換。利用Ajax的這一特性，可以避免對于客戶端頁面的頻繁刷新。

基于Ajax的長輪詢是目前實(shí)時Web應(yīng)用中使用頻率較高的方式，這種方式采用Ajax方法向服務(wù)器端發(fā)送請求，在服務(wù)器端沒有信息更新時，服務(wù)器會一直維持這個請求連接，直到有新的信息需要返回給客戶端或者連接超時才會關(guān)閉這個長連接。

基于Ajax的長輪詢的具體工作過程如下：客戶端發(fā)出請求，進(jìn)而與服務(wù)器建立連接；然后服務(wù)器端會將這個連接保持一段時間，通常是數(shù)秒鐘，也可能是一分鐘甚至更長；當(dāng)服務(wù)器端檢測到客戶端請求的數(shù)據(jù)有更新，即有必要將新的數(shù)據(jù)發(fā)送給客戶端時，會立即通過維持的連接將數(shù)據(jù)發(fā)送給客戶端，然后關(guān)閉連接；如果服務(wù)端在維持這個連接過程期間沒有新的數(shù)據(jù)發(fā)送到客戶端，則會在維持時間超時后關(guān)閉連接。無論是否有數(shù)據(jù)更新，在上一次連接關(guān)閉后，客戶端會立即重新發(fā)出一個請求，再次與服務(wù)器端建立連接，如此循環(huán)，確保新的數(shù)據(jù)能及時的發(fā)送到客戶端。

1.1.2基于Iframe的流方式

Ifram是HTML提供的一種標(biāo)簽，利用Iframe可以在HTML頁面中創(chuàng)建一個內(nèi)聯(lián)的文檔框架，該標(biāo)簽的SRC屬性用來設(shè)置該內(nèi)聯(lián)框架需要顯示的文檔的URL。當(dāng)包含Iframe元素的頁面加載顯示時，Iframe會通過SRC屬性設(shè)置的URL獲取文檔內(nèi)容并顯示。

基于Iframe的流方式也是應(yīng)用較為廣泛的方案。基于Iframe的流方式在頁面中內(nèi)置一個隱藏的Iframe元素，將Iframe的SRC屬性設(shè)置為一個長連接請求，服務(wù)器端會不斷更新連接狀態(tài)，使這個長連接在執(zhí)行過程中一直處于連接狀態(tài)，服務(wù)器端在數(shù)據(jù)更新后會立即通過這個長連接將數(shù)據(jù)傳送到客戶端隱藏的Iframe中，客戶端通過Iframe獲取這些數(shù)據(jù)完成頁面內(nèi)容的更新。

基于Iframe的流方式的具體的工作過程如下：客戶端頁面在瀏覽器加載時，其內(nèi)嵌的Iframe發(fā)起長連接請求，服務(wù)器端響應(yīng)請求建立長連接；服務(wù)器端不斷更新該連接的狀態(tài)，使其始終保持連接狀態(tài)；當(dāng)服務(wù)器端檢測到客戶端請求的數(shù)據(jù)有更新時，立即通過該連接將數(shù)據(jù)發(fā)送給客戶端；該連接在出現(xiàn)錯誤或異常關(guān)閉后，客戶端會立即發(fā)出連接請求進(jìn)而再次建立連接。

1.1.3兩種方案的比較

可以看出，這兩種方案相對于輪詢都有了較大的改進(jìn)，而且兩種方案的改進(jìn)方向是一致的，主要包含兩點(diǎn)：客戶端頁面內(nèi)容更新時不會刷新整個頁面，減少了服務(wù)器端返回的數(shù)據(jù)量，并能帶來較好的用戶體驗(yàn)；服務(wù)器端通過維持長連接，減少了客戶端請求的頻率，避免頻繁請求連接的建立和關(guān)閉帶來的資源浪費(fèi)。

但是，兩種方案在實(shí)現(xiàn)方式上存在一些不同：

1）服務(wù)器端傳送給客戶端的數(shù)據(jù)形式不同，頁面內(nèi)容的更新方式不同。采用基于Iframe的流方式，服務(wù)器端返回的是包含新數(shù)據(jù)的JavaScript代碼，客戶端瀏覽器執(zhí)行這些JavaScript代碼即可實(shí)現(xiàn)頁面內(nèi)容的更新；采用基于Ajax的長輪詢方式，服務(wù)器端返回的是XML格式或者JSON格式的數(shù)據(jù)，客戶端瀏覽器的JavaScript引擎需要首先解析這些數(shù)據(jù)，然后再操作頁面元素實(shí)現(xiàn)頁面內(nèi)容的更新；

2）服務(wù)器端對于長連接的處理不同。采用基于Iframe的流方式，服務(wù)器端會不斷更新連接狀態(tài)，一直維持該長連接；而基于Ajax的長輪詢則會在每次返回?cái)?shù)據(jù)給客戶端后關(guān)閉連接，再由客戶端重新發(fā)起請求建立連接。

1.2傳統(tǒng)解決方案的困境

傳統(tǒng)的兩種解決方案雖然被廣泛運(yùn)用，但是都還存在很多問題。

基于Iframe的流方式中，由于Iframe中始終維持一個連接，用戶的瀏覽器會始終顯示當(dāng)前頁面處于加載過程中，始終不能顯示加載完成，這將影響用戶體驗(yàn)。而基于Ajax的長輪詢方案中，當(dāng)服務(wù)器端數(shù)據(jù)更新速度較快時，長輪詢將退化為普通的輪詢，這樣將大大降低其性能，并會對服務(wù)器端帶來較大的處理壓力。除了上述的問題之外，這兩種方案還存在一些共性的不足：

1）由于這兩種方案仍然采用HTTP作為通信協(xié)議，而HTTP連接的建立和關(guān)閉過程都有一定的資源和時間消耗。這不僅會導(dǎo)致服務(wù)器端資源的浪費(fèi)，而且在連接建立和關(guān)閉過程產(chǎn)生的新數(shù)據(jù)無法及時發(fā)送到客戶端，可能導(dǎo)致客戶端數(shù)據(jù)丟失；

2）每一次的HTTP請求和應(yīng)答都帶有完整的HTTP頭信息，這就增加了每次實(shí)時信息更新時的傳輸數(shù)據(jù)量，造成了網(wǎng)絡(luò)帶寬的浪費(fèi)；

3）上述兩種方案沒有區(qū)分Web服務(wù)中實(shí)時信息和非實(shí)時信息，均采用相同的請求方式，服務(wù)器端的響應(yīng)方式也相同，由于實(shí)時信息請求較為頻繁，這就會對服務(wù)器端帶來較大的處理壓力，進(jìn)而可能影響非實(shí)時信息的呈現(xiàn)。

2基于WebSocket的實(shí)時Web應(yīng)用解決方案

WebSocket是HTML5標(biāo)準(zhǔn)中提出的一種新的協(xié)議，它支持瀏覽器與服務(wù)器的雙向通信[2]。不同于傳統(tǒng)的HTTP方式，在使用WebSocket時，服務(wù)端和客戶端處于同等的地位，可以隨時相互發(fā)送消息。

WebSocket協(xié)議本質(zhì)上是一個基于TCP的協(xié)議，WebSocket連接與TCP連接的建立過程類似。瀏覽器通過JavaScript向服務(wù)器發(fā)出建立WebSocket連接的請求，服務(wù)器解析該請求并會向客戶端返回應(yīng)答信息，然后建立連接；連接建立以后，客戶端和服務(wù)器端就可以通過TCP連接直接交換數(shù)據(jù)。

除了具備雙向通訊能力，WebSocket協(xié)議的傳輸數(shù)據(jù)格式相對HTTP更加簡潔。WebSocket在傳輸信息時，相對于HTTP大大降低了數(shù)據(jù)幀中頭信息占用的字節(jié)數(shù)，從而降低了傳輸?shù)臄?shù)據(jù)量，節(jié)省了帶寬資源，降低網(wǎng)絡(luò)負(fù)載。

以往的實(shí)時web系統(tǒng)中，由于采用基于HTTP協(xié)議的通信方式，因此實(shí)時請求和非實(shí)時請求均以相同的方式來處理，這正是傳統(tǒng)方案的癥結(jié)所在。在一個實(shí)時Web應(yīng)用中，并不是所有呈現(xiàn)的內(nèi)容都是需要實(shí)時更新的，因此實(shí)時內(nèi)容和非實(shí)時內(nèi)容在服務(wù)端的處理應(yīng)該加以區(qū)分，避免相互影響，這樣也可以一定程度上減輕服務(wù)器端的處理壓力。

基于WebSocket的實(shí)時Web應(yīng)用解決方案將應(yīng)用中的實(shí)時部分和非實(shí)時部分進(jìn)行了分離，客戶端呈現(xiàn)的非實(shí)時內(nèi)容仍然采用HTTP來獲取，而實(shí)時內(nèi)容則使用WebSocket來獲取。由于HTTP和WebSocket是兩種不同的協(xié)議，服務(wù)器端將采用不同的處理方式。如圖1所示，服務(wù)器端將通過兩個不同的模塊，分別處理非實(shí)時的HTTP請求和實(shí)時的WebSocket連接，確保HTTP和WebSocket各自發(fā)揮自身的優(yōu)勢，而又相互不影響，合理分配服務(wù)端的處理資源。

新的解決方案相對于傳統(tǒng)方案有以下幾點(diǎn)優(yōu)勢：

1）新的應(yīng)用模型可以使服務(wù)器端結(jié)構(gòu)更加明確。兩個模塊的獨(dú)立性可以降低系統(tǒng)的耦合，相互之間不會產(chǎn)生影響，最大程度發(fā)揮不同模塊的效能，并方便針對模塊自身的處理特點(diǎn)添加優(yōu)化措施；

2）由于采用了可以在服務(wù)端和瀏覽器間建立穩(wěn)定TCP連接的WebSocket協(xié)議來實(shí)現(xiàn)實(shí)時服務(wù)，可以保證數(shù)據(jù)傳輸?shù)姆€(wěn)定性和及時性，并降低網(wǎng)絡(luò)負(fù)載，可以較大幅度地提高實(shí)時服務(wù)的性能；

3）WebSocket協(xié)議簡單易用，開發(fā)成本低，降低了系統(tǒng)開發(fā)的復(fù)雜性和代價；

4）相對于傳統(tǒng)方案，降低了對服務(wù)器端處理資源的浪費(fèi)，減輕了服務(wù)器端處理的壓力。

圖1實(shí)時Web應(yīng)用模型

新的方案相對于原有方案可以大幅提升實(shí)時服務(wù)性能，并能更高效地利用網(wǎng)絡(luò)負(fù)載和服務(wù)器端的處理能力。然而新方案也有一定的局限性，主要原因是：

1）WebSocket協(xié)議還處于草案階段，還有變動的可能。目前，F(xiàn)ireFox、Chrome以及Safari等瀏覽器均支持WebSocket，但市場占有率最高的IE瀏覽器還沒有提供對WebSocket的支持。

2）WebSocket協(xié)議提供了統(tǒng)一的客戶端API，然而服務(wù)器端的標(biāo)準(zhǔn)還沒有明確。目前，各個服務(wù)器廠商對服務(wù)器端的支持存在差異，因此增加了服務(wù)器端程序的開發(fā)難度，也妨礙了WebSocket協(xié)議的普及和應(yīng)用。

3結(jié)束語

基于Ajax的長輪詢和基于Iframe的流方式是經(jīng)過長時間的應(yīng)用實(shí)踐而發(fā)展出來的，這兩種方案成為了實(shí)時Web應(yīng)用主要的實(shí)現(xiàn)方式。針對這兩種方案存在的問題，技術(shù)人員進(jìn)行了多種方式的優(yōu)化，但HTTP協(xié)議本身特性的制約卻無法逾越。

WebSocket協(xié)議的出現(xiàn)，提供了一種新的服務(wù)器端和瀏覽器的通信方式，利用該協(xié)議可以更加方便地構(gòu)建出簡單高效的實(shí)時Web應(yīng)用。該文針對傳統(tǒng)解決方案的不足，提出了基于WebSocket的實(shí)時Web解決方案，從理論層面分析了方案的可行性和相對于傳統(tǒng)方案的優(yōu)勢。相信隨著WebSocket協(xié)議的進(jìn)一步發(fā)展，基于WebSocket的實(shí)時web解決方案將逐漸被廣泛接受。

參考文獻(xiàn)：

[1] Clinton Wong.HTTP Pocket Reference-Hypertext Transfer Protocol[M].Beijing:OReilly Media,2006.

[2] IETF.The WebSocket Protocol[EB/OL]. http://grenache.tools.ietf.org/html/rfc6455.

[3] IETF.The WebSocket protocol draft-ietf-hybi-thewebsocketprotocol-10[EB/OL].http://tools.ietf.org/html/draft-ietf-hybi-thewebsocket protocol-10.

[4] W3C.HTML5 differences from HTML4[EB/OL]. http://www.w3.org/TR/html5-diff.

[5]周婷.Comet：基于HTTP長連接的服務(wù)器推技術(shù)[EB/OL].http://www.ibm.com/developerworks/cn/web/wa-lo-comet/#resources/.

[6] Victoria Pimentel,Bradford G.Nickerson.WebSocket for Communication and Display of Real-Time data[J].IEEE Internet Computing,2012: 1-12.

[7]黃曉安,何亮.使用HTML5 WebSocket構(gòu)建實(shí)時Web應(yīng)用[EB/OL].http://www.ibm.com/developerworks/cn/web/1112_huangxa_websocket/.

[8] Peter Lubbers.HTML5 Programing—Using the HTML5 WebSocket API[M].Apress,2010.