Jack Jiang

我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
posts - 132, comments - 13, trackbacks - 0, articles - 0

1. 前言

Web端即時通訊技術因受限于瀏覽器的設計限制,一直以來實現起來并不容易,主流的Web端即時通訊方案大致有4種:傳統Ajax短輪詢、Comet技術、WebSocket技術、SSE(Server-sent Events)。本文將簡要介紹這4種技術的原理,并指出各自的異同點、優缺點等。

2. 概述

1996年IETF  HTTP工作組發布了HTTP協議的1.0版本 ,到現在普遍使用的版本1.1,HTTP協議經歷了17 年的發展。這種分布式、無狀態、基于TCP的請求/響應式、在互聯網盛行的今天得到廣泛應用的協議,相對于互聯網的迅猛發展,它似乎進步地很慢。互聯網從興起到現在,經歷了門戶網站盛行的web1.0時代,而后隨著ajax技術的出現,發展為web應用盛行的web2.0時代,如今又朝著web3.0的方向邁進。反觀http協議,從版本1.0發展到1.1,除了默認長連接之外就是緩存處理、帶寬優化和安全性等方面的不痛不癢的改進。它一直保留著無狀態、請求/響應模式,似乎從來沒意識到這應該有所改變。

好在HTML5的時代已經到來,為Web端即時通訊的實現帶來了WebSocket和SSE(Server-sent Events)兩種技術方案。

3. Ajax短輪詢:腳本發送的http請求

傳統的web應用要想與服務器交互,必須提交一個表單(form),服務器接收并處理傳來的表單,然后返回全新的頁面,因為前后兩個頁面的數據大部分都是相同的,這個過程傳輸了很多冗余的數據、浪費了帶寬。于是Ajax技術便應運而生。

Ajax是Asynchronous JavaScript and XML的簡稱,由Jesse James Garrett 首先提出。這種技術開創性地允許瀏覽器腳本(JS)發送http請求。Outlook Web Access小組于98年使用,并很快成為IE4.0的一部分,但是這個技術一直很小眾,直到2005年初,google在他的goole groups、gmail等交互式應用中廣泛使用此種技術,才使得Ajax迅速被大家所接受。

Ajax的出現使客戶端與服務器端傳輸數據少了很多,也快了很多,也滿足了以豐富用戶體驗為特點的web2.0時代 初期發展的需要,但是慢慢地也暴露了他的弊端。比如無法滿足即時通信等富交互式應用的實時更新數據的要求。這種瀏覽器端的小技術畢竟還是基于http協議,http協議要求的請求/響應的模式也是無法改變的,除非http協議本身有所改變。

4. Comet:一種hack技術

以即時通信為代表的web應用程序對數據的Low Latency要求,傳統的基于輪詢的方式已經無法滿足,而且也會帶來不好的用戶體驗。于是一種基于http長連接的“服務器推”技術便被hack出來。這種技術被命名為Comet,這個術語由Dojo Toolkit 的項目主管Alex Russell在博文Comet: Low Latency Data for the Browser首次提出,并沿用下來。

其實,服務器推很早就存在了,在經典的client/server模型中有廣泛使用,只是瀏覽器太懶了,并沒有對這種技術提供很好的支持。但是Ajax的出現使這種技術在瀏覽器上實現成為可能, google的gmail和gtalk的整合首先使用了這種技術。隨著一些關鍵問題的解決(比如 IE 的加載顯示問題),很快這種技術得到了認可,目前已經有很多成熟的開源Comet框架。

以下是典型的Ajax和Comet數據傳輸方式的對比,區別簡單明了。典型的Ajax通信方式也是http協議的經典使用方式,要想取得數據,必須首先發送請求。在Low Latency要求比較高的web應用中,只能增加服務器請求的頻率。Comet則不同,客戶端與服務器端保持一個長連接,只有客戶端需要的數據更新時,服務器才主動將數據推送給客戶端。



Comet的實現主要有兩種方式,基于Ajax的長輪詢(long-polling)方式和基于 Iframe 及 htmlfile 的流(http streaming)方式。

有關Comet技術的詳細介紹文章請參見:《Comet技術詳解:基于HTTP長連接的Web端實時通信技術》、《WEB端即時通訊:HTTP長連接、長輪詢(long polling)詳解》、《WEB端即時通訊:不用WebSocket也一樣能搞定消息的即時性》、《開源Comet服務器iComet:支持百萬并發的Web端即時通訊方案》。

4.1 基于Ajax的長輪詢(long-polling)方式

瀏覽器發出XMLHttpRequest 請求,服務器端接收到請求后,會阻塞請求直到有數據或者超時才返回,瀏覽器JS在處理請求返回信息(超時或有效數據)后再次發出請求,重新建立連接。在此期間服務器端可能已經有新的數據到達,服務器會選擇把數據保存,直到重新建立連接,瀏覽器會把所有數據一次性取回。

Web端即時通訊技術盤點:短輪詢、Comet、Websocket、SSE_3.jpg 

4.2 基于 Iframe 及 htmlfile 的流(http streaming)方式

Iframe是html標記,這個標記的src屬性會保持對指定服務器的長連接請求,服務器端則可以不停地返回數據,相對于第一種方式,這種方式跟傳統的服務器推則更接近。

在第一種方式中,瀏覽器在收到數據后會直接調用JS回調函數,但是這種方式該如何響應數據呢?可以通過在返回數據中嵌入JS腳本的方式,如“<script type="text/javascript">js_func(“data from server ”)</script>”,服務器端將返回的數據作為回調函數的參數,瀏覽器在收到數據后就會執行這段JS腳本。

Web端即時通訊技術盤點:短輪詢、Comet、Websocket、SSE_4.jpg 

但是這種方式有一個明顯的不足之處:IE、Morzilla Firefox 下端的進度欄都會顯示加載沒有完成,而且 IE 上方的圖標會不停的轉動,表示加載正在進行。Google 的天才們使用一個稱為“htmlfile”的 ActiveX 解決了在 IE 中的加載顯示問題,并將這種方法應用到了 gmail+gtalk 產品中。

5. Websocket:未來的解決方案1

如果說Ajax的出現是互聯網發展的必然,那么Comet技術的出現則更多透露出一種無奈,僅僅作為一種hack技術,因為沒有更好的解決方案。Comet解決的問題應該由誰來解決才是合理的呢?瀏覽器,html標準,還是http標準?主角應該是誰呢?本質上講,這涉及到數據傳輸方式,http協議應首當其沖,是時候改變一下這個懶惰的協議的請求/響應模式了。

W3C給出了答案,在新一代html標準html5中提供了一種瀏覽器和服務器間進行全雙工通訊的網絡技術Websocket。從Websocket草案得知,Websocket是一個全新的、獨立的協議,基于TCP協議,與http協議兼容、卻不會融入http協議,僅僅作為html5的一部分。于是乎腳本又被賦予了另一種能力:發起websocket請求。這種方式我們應該很熟悉,因為Ajax就是這么做的,所不同的是,Ajax發起的是http請求而已。 

與http協議不同的請求/響應模式不同,Websocket在建立連接之前有一個Handshake(Opening Handshake)過程,在關閉連接前也有一個Handshake(Closing Handshake)過程,建立連接之后,雙方即可雙向通信。

有關WebSocket的詳細介,請參見即時通訊網有關WebSocket的系列文章:《WebSocket詳解(一):初步認識WebSocket技術》、《WebSocket詳解(二):技術原理、代碼演示和應用案例》、《WebSocket詳解(三):深入WebSocket通信協議細節》。

從瀏覽器支持角度來看,WebSocket已經近在眼前,但仍有一段較長的路要走,特別是在中國這個IE6、7、8依然盛行的國家,舊版本瀏覽器的消亡需要很長一段時間,在完全實現瀏覽器全兼容前,Comet技術可能仍然是最好的解決方案。不過,當前也已存在一些比較成熟的封裝方案來解決這種兼容性限制,比如:開源的Socket.io,詳見《Socket.IO介紹:支持WebSocket、用于WEB端的即時通訊的框架》。

6. SSE:未來的解決方案2

SSE(Server-Sent Event,服務端推送事件)是一種允許服務端向客戶端推送新數據的HTML5技術。與由客戶端每隔幾秒從服務端輪詢拉取新數據相比,這是一種更優的解決方案。

與WebSocket相比,它也能從服務端向客戶端推送數據。那如何決定你是用SSE還是WebSocket呢?概括來說,WebSocket能做的,SSE也能做,反之亦然,但在完成某些任務方面,它們各有千秋。

WebSocket是一種更為復雜的服務端實現技術,但它是真正的雙向傳輸技術,既能從服務端向客戶端推送數據,也能從客戶端向服務端推送數據。

WebSocket和SSE的瀏覽器支持率差不多,大多數主流桌面瀏覽器兩者都支持。在Android 4.3以及更早的版本中,系統默認瀏覽器兩者都不支持,Firefox和Chrome則完全支持;Android 4.4中,系統默認瀏覽器兩者都支持;Safari從5.0開始支持SSE(iOS系統從4.0開始),但直到6.0才正確地支持WebSocket(6.0之前的Safari所實現的WebSocket協議存在安全問題,所以一些主流瀏覽器已經禁用了基于這個協議的實現)。

與WebSocket相比,SSE有一些顯著的優勢。個人認為它最大的優勢就是便利:不需要添加任何新組件,用任何你習慣的后端語言和框架就能繼續使用。你不用為新建虛擬機、弄一個新的IP或新的端口號而勞神,就像在現有網站中新增一個頁面那樣簡單。我喜歡把這稱為既存基礎設施優勢。

SSE的第二個優勢是服務端的簡潔。相對而言,WebSocket則很復雜,不借助輔助類庫基本搞不定(我試過,令人痛苦)。

因為SSE能在現有的HTTP/HTTPS協議上運作,所以它能直接運行于現有的代理服務器和認證技術。而對WebSocket而言,代理服務器需要做一些開發(或其他工作)才能支持,在寫這本書時,很多服務器還沒有(雖然這種狀況會改善)。SSE還有一個優勢:它是一種文本協議,腳本調試非常容易。事實上,在本書中,我們會在開發和測試時用curl,甚至直接在命令行中運行后端腳本。

不過,這就引出了WebSocket相較SSE的一個潛在優勢:WebSocket是二進制協議,而SSE是文本協議(通常使用UTF-8編碼)。當然,我們可以通過SSE連接傳輸二進制數據:在SSE中,只有兩個具有特殊意義的字符,它們是CR和LF,而對它們進行轉碼并不難。但用SSE傳輸二進制數據時數據會變大,如果需要從服務端到客戶端傳輸大量的二進制數據,最好還是用WebSocket。

WebSocket相較SSE最大的優勢在于它是雙向交流的,這意味向服務端發送數據就像從服務端接收數據一樣簡單。用SSE時,一般通過一個獨立的Ajax請求從客戶端向服務端傳送數據。相對于WebSocket,這樣使用Ajax會增加開銷,但也就多一點點而已。如此一來,問題就變成了“什么時候需要關心這個差異?”如果需要以1次/秒或者更快的頻率向服務端傳輸數據,那應該用WebSocket。0.2次/秒到1次/秒的頻率是一個灰色地帶,用WebSocket和用SSE差別不大;但如果你期望重負載,那就有必要確定基準點。頻率低于0.2次/秒左右時,兩者差別不大。

從服務端向客戶端傳輸數據的性能如何?如果是文本數據而非二進制數據(如前文所提到的),SSE和WebSocket沒什么區別。它們都用TCP/IP套接字,都是輕量級協議。延遲、帶寬、服務器負載等都沒有區別,除非……呃?除非什么?

當你在享用SSE的既存基礎設施優勢,并在客戶端和服務端腳本之間設了一個網絡服務器,區別就顯現出來了。一個SSE連接不僅使用一個套接字,還會占用一個Apache線程或進程,如果用PHP,它會為這個連接專門創建一個PHP新實例。Apache和PHP會使用大量的內存,這會限制服務器所能支持的并行連接數。所以,要做到用SSE在數據傳輸性能上和WebSocket完全一樣,需要寫一個自己的后端服務器,當然,那些在任何情況下都會用自己的服務器并使用Node.js的人,會覺得這有什么稀奇的。

說一下WebSocket在舊版本瀏覽器上的兼容。當前,大約超過2/3的瀏覽器支持這些新技術,移動端瀏覽器的支持率會低一些。依慣例,每當需要雙向套接字時,就會用到Flash,并且WebSocket的向后兼容通常是用Flash來做,這已經相當復雜了,如果瀏覽器上沒有Flash,情況更糟。概括來說,WebSocket難兼容,SSE易兼容。有關SSE的專項介紹文章請參見:《SSE技術詳解:一種全新的HTML5服務器推送事件技術》。

(本文同步發布于:http://www.52im.net/thread-336-1-1.html

學習交流

- 更多即時通訊技術資料:http://www.52im.net/forum.php?mod=collection&op=all

- 即時通訊開發交流群:215891622 [推薦]

系列資料

Web端即時通訊新手入門貼:
新手入門貼:詳解Web端即時通訊技術的原理

關于Ajax短輪詢:
找這方面的資料沒什么意義,除非忽悠客戶,否則請考慮其它3種方案即可。

有關Comet技術的詳細介紹請參見:
Comet技術詳解:基于HTTP長連接的Web端實時通信技術
WEB端即時通訊:HTTP長連接、長輪詢(long polling)詳解
WEB端即時通訊:不用WebSocket也一樣能搞定消息的即時性
開源Comet服務器iComet:支持百萬并發的Web端即時通訊方案

有關WebSocket的詳細介紹請參見:
WebSocket詳解(一):初步認識WebSocket技術
WebSocket詳解(二):技術原理、代碼演示和應用案例
WebSocket詳解(三):深入WebSocket通信協議細節
Socket.IO介紹:支持WebSocket、用于WEB端的即時通訊的框架
socket.io和websocket 之間是什么關系?有什么區別?

有關SSE的詳細介紹文章請參見:
SSE技術詳解:一種全新的HTML5服務器推送事件技術

更多WEB端即時通訊文章請見:
http://www.52im.net/forum.php?mod=collection&action=view&ctid=15


作者:Jack Jiang (點擊作者姓名進入Github) 

出處:http://www.52im.net/space-uid-1.html 

交流:歡迎加入即時通訊開發交流群 215891622 

討論:http://www.52im.net/ 

Jack Jiang同時是【原創Java Swing外觀工程BeautyEye】【輕量級移動端即時通訊框架MobileIMSDK】的作者,可前往下載交流。

歡迎轉載,轉載請注明出處(也可前往 我的52im.net 找到我)。 

Feedback

# re: Web端即時通訊技術盤點:短輪詢、Comet、Websocket、SSE  回復  更多評論   

2016-07-16 20:41 by Dhiya
Really nice information you had posted. Its very informative and definitely it will be useful for many people

# re: Web端即時通訊技術盤點:短輪詢、Comet、Websocket、SSE  回復  更多評論   

2016-07-19 11:57 by 中國演員網
謝謝樓主精彩分享。。。

只有注冊用戶登錄后才能發表評論。


網站導航:
 
Jack Jiang的 Mail: [email protected], 聯系QQ: 413980957, 微信: hellojackjiang
魔法糖果闯关