Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE
1. 前言
Web端即時(shí)通訊技術(shù)因受限于瀏覽器的設(shè)計(jì)限制，一直以來實(shí)現(xiàn)起來并不容易，主流的Web端即時(shí)通訊方案大致有4種：傳統(tǒng)Ajax短輪詢、 Comet技術(shù)、WebSocket技術(shù)、SSE（Server-sent Events）。本文將簡(jiǎn)要介紹這4種技術(shù)的原理，并指出各自的異同點(diǎn)、優(yōu)缺點(diǎn)等。
2. 概述
1996年IETF??HTTP工作組發(fā)布了HTTP協(xié)議的1.0版本 ，到現(xiàn)在普遍使用的版本1.1，HTTP協(xié)議經(jīng)歷了17 年的發(fā)展。這種分布式、無狀態(tài)、基于TCP的請(qǐng)求/響應(yīng)式、在互聯(lián)網(wǎng)盛行的今天得到廣泛應(yīng)用的協(xié)議，相對(duì)于互聯(lián)網(wǎng)的迅猛發(fā)展，它似乎進(jìn)步地很慢。互聯(lián)網(wǎng)從 興起到現(xiàn)在，經(jīng)歷了門戶網(wǎng)站盛行的web1.0時(shí)代，而后隨著ajax技術(shù)的出現(xiàn)，發(fā)展為web應(yīng)用盛行的web2.0時(shí)代，如今又朝著web3.0的方 向邁進(jìn)。反觀http協(xié)議，從版本1.0發(fā)展到1.1，除了默認(rèn)長(zhǎng)連接之外就是緩存處理、帶寬優(yōu)化和安全性等方面的不痛不癢的改進(jìn)。它一直保留著無狀態(tài)、 請(qǐng)求/響應(yīng)模式，似乎從來沒意識(shí)到這應(yīng)該有所改變。
好在HTML5的時(shí)代已經(jīng)到來，為Web端即時(shí)通訊的實(shí)現(xiàn)帶來了WebSocket和SSE（Server-sent Events）兩種技術(shù)方案。
3. Ajax短輪詢：腳本發(fā)送的http請(qǐng)求
傳統(tǒng)的web應(yīng)用要想與服務(wù)器交互，必須提交一個(gè)表單（form），服務(wù)器接收并處理傳來的表單，然后返回全新的頁(yè)面，因?yàn)榍昂髢蓚€(gè)頁(yè)面的數(shù)據(jù)大部分都是相同的，這個(gè)過程傳輸了很多冗余的數(shù)據(jù)、浪費(fèi)了帶寬。于是Ajax技術(shù)便應(yīng)運(yùn)而生。
Ajax是Asynchronous JavaScript and XML的簡(jiǎn)稱，由Jesse James Garrett 首先提出。這種技術(shù)開創(chuàng)性地允許瀏覽器腳本（JS）發(fā)送http請(qǐng)求。Outlook Web Access小組于98年使用，并很快成為IE4.0的一部分，但是這個(gè)技術(shù)一直很小眾，直到2005年初，google在他的goole groups、gmail等交互式應(yīng)用中廣泛使用此種技術(shù)，才使得Ajax迅速被大家所接受。
Ajax的出現(xiàn)使客戶端與服務(wù)器端傳輸數(shù)據(jù)少了很多，也快了很多，也滿足了以豐富用戶體驗(yàn)為特點(diǎn)的web2.0時(shí)代 初期發(fā)展的需要，但是慢慢地也暴露了他的弊端。比如無法滿足即時(shí)通信等富交互式應(yīng)用的實(shí)時(shí)更新數(shù)據(jù)的要求。這種瀏覽器端的小技術(shù)畢竟還是基于http協(xié) 議，http協(xié)議要求的請(qǐng)求/響應(yīng)的模式也是無法改變的，除非http協(xié)議本身有所改變。
4. Comet：一種hack技術(shù)
以即時(shí)通信為代表的web應(yīng)用程序?qū)?shù)據(jù)的Low Latency要求，傳統(tǒng)的基于輪詢的方式已經(jīng)無法滿足，而且也會(huì)帶來不好的用戶體驗(yàn)。于是一種基于http長(zhǎng)連接的“服務(wù)器推”技術(shù)便被hack出來。這種技術(shù)被命名為Comet，這個(gè)術(shù)語(yǔ)由Dojo Toolkit 的項(xiàng)目主管Alex Russell在博文Comet: Low Latency Data for the Browser首次提出，并沿用下來。
其實(shí)，服務(wù)器推很早就存在了，在經(jīng)典的client/server模型中有廣泛使用，只是瀏覽器太懶了，并沒有對(duì)這種技術(shù)提供很好的支持。但是 Ajax的出現(xiàn)使這種技術(shù)在瀏覽器上實(shí)現(xiàn)成為可能， google的gmail和gtalk的整合首先使用了這種技術(shù)。隨著一些關(guān)鍵問題的解決（比如 IE 的加載顯示問題），很快這種技術(shù)得到了認(rèn)可，目前已經(jīng)有很多成熟的開源Comet框架。
以下是典型的Ajax和Comet數(shù)據(jù)傳輸方式的對(duì)比，區(qū)別簡(jiǎn)單明了。典型的Ajax通信方式也是http協(xié)議的經(jīng)典使用方式，要想取得數(shù)據(jù)，必須 首先發(fā)送請(qǐng)求。在Low Latency要求比較高的web應(yīng)用中，只能增加服務(wù)器請(qǐng)求的頻率。Comet則不同，客戶端與服務(wù)器端保持一個(gè)長(zhǎng)連接，只有客戶端需要的數(shù)據(jù)更新時(shí)， 服務(wù)器才主動(dòng)將數(shù)據(jù)推送給客戶端。
Comet的實(shí)現(xiàn)主要有兩種方式，基于Ajax的長(zhǎng)輪詢（long-polling）方式和基于 Iframe 及 htmlfile 的流（http streaming）方式。
有關(guān)Comet技術(shù)的詳細(xì)介紹文章請(qǐng)參見：《Comet技術(shù)詳解：基于HTTP長(zhǎng)連接的Web端實(shí)時(shí)通信技術(shù)》、《WEB端即時(shí)通訊：HTTP長(zhǎng)連接、長(zhǎng)輪詢（long polling）詳解》、《WEB端即時(shí)通訊：不用WebSocket也一樣能搞定消息的即時(shí)性》、《開源Comet服務(wù)器iComet：支持百萬(wàn)并發(fā)的Web端即時(shí)通訊方案》。
?
4.1 基于Ajax的長(zhǎng)輪詢（long-polling）方式
瀏覽器發(fā)出XMLHttpRequest 請(qǐng)求，服務(wù)器端接收到請(qǐng)求后，會(huì)阻塞請(qǐng)求直到有數(shù)據(jù)或者超時(shí)才返回，瀏覽器JS在處理請(qǐng)求返回信息（超時(shí)或有效數(shù)據(jù)）后再次發(fā)出請(qǐng)求，重新建立連接。在此 期間服務(wù)器端可能已經(jīng)有新的數(shù)據(jù)到達(dá)，服務(wù)器會(huì)選擇把數(shù)據(jù)保存，直到重新建立連接，瀏覽器會(huì)把所有數(shù)據(jù)一次性取回。
?
4.2 基于 Iframe 及 htmlfile 的流（http streaming）方式
Iframe是html標(biāo)記，這個(gè)標(biāo)記的src屬性會(huì)保持對(duì)指定服務(wù)器的長(zhǎng)連接請(qǐng)求，服務(wù)器端則可以不停地返回?cái)?shù)據(jù)，相對(duì)于第一種方式，這種方式跟傳統(tǒng)的服務(wù)器推則更接近。
在第一種方式中，瀏覽器在收到數(shù)據(jù)后會(huì)直接調(diào)用JS回調(diào)函數(shù)，但是這種方式該如何響應(yīng)數(shù)據(jù)呢？可以通過在返回?cái)?shù)據(jù)中嵌入JS腳本的方式，如 “<script type="text/javascript">js_func(“data from server ”)</script>”，服務(wù)器端將返回的數(shù)據(jù)作為回調(diào)函數(shù)的參數(shù)，瀏覽器在收到數(shù)據(jù)后就會(huì)執(zhí)行這段JS腳本。
但是這種方式有一個(gè)明顯的不足之處：IE、Morzilla Firefox 下端的進(jìn)度欄都會(huì)顯示加載沒有完成，而且 IE 上方的圖標(biāo)會(huì)不停的轉(zhuǎn)動(dòng)，表示加載正在進(jìn)行。Google 的天才們使用一個(gè)稱為“htmlfile”的 ActiveX 解決了在 IE 中的加載顯示問題，并將這種方法應(yīng)用到了 gmail+gtalk 產(chǎn)品中。
5. Websocket：未來的解決方案1
如果說Ajax的出現(xiàn)是互聯(lián)網(wǎng)發(fā)展的必然，那么Comet技術(shù)的出現(xiàn)則更多透露出一種無奈，僅僅作為一種hack技術(shù)，因?yàn)闆]有更好的解決方案。 Comet解決的問題應(yīng)該由誰(shuí)來解決才是合理的呢？瀏覽器，html標(biāo)準(zhǔn)，還是http標(biāo)準(zhǔn)？主角應(yīng)該是誰(shuí)呢？本質(zhì)上講，這涉及到數(shù)據(jù)傳輸方式，http 協(xié)議應(yīng)首當(dāng)其沖，是時(shí)候改變一下這個(gè)懶惰的協(xié)議的請(qǐng)求/響應(yīng)模式了。
W3C給出了答案，在新一代html標(biāo)準(zhǔn)html5中提供了一種瀏覽器和服務(wù)器間進(jìn)行全雙工通訊的網(wǎng)絡(luò)技術(shù)Websocket。從 Websocket草案得知，Websocket是一個(gè)全新的、獨(dú)立的協(xié)議，基于TCP協(xié)議，與http協(xié)議兼容、卻不會(huì)融入http協(xié)議，僅僅作為 html5的一部分。于是乎腳本又被賦予了另一種能力：發(fā)起websocket請(qǐng)求。這種方式我們應(yīng)該很熟悉，因?yàn)锳jax就是這么做的，所不同的 是，Ajax發(fā)起的是http請(qǐng)求而已。?
與http協(xié)議不同的請(qǐng)求/響應(yīng)模式不同，Websocket在建立連接之前有一個(gè)Handshake（Opening Handshake）過程，在關(guān)閉連接前也有一個(gè)Handshake（Closing Handshake）過程，建立連接之后，雙方即可雙向通信。
有關(guān)WebSocket的詳細(xì)介，請(qǐng)參見即時(shí)通訊網(wǎng)有關(guān)WebSocket的系列文章：《WebSocket詳解（一）：初步認(rèn)識(shí)WebSocket技術(shù)》、《WebSocket詳解（二）：技術(shù)原理、代碼演示和應(yīng)用案例》、《WebSocket詳解（三）：深入WebSocket通信協(xié)議細(xì)節(jié)》。
從瀏覽器支持角度來看，WebSocket已經(jīng)近在眼前，但仍有一段較長(zhǎng)的路要走，特別是在中國(guó)這個(gè)IE6、7、8依然盛行的國(guó)家，舊版本瀏覽器的 消亡需要很長(zhǎng)一段時(shí)間，在完全實(shí)現(xiàn)瀏覽器全兼容前，Comet技術(shù)可能仍然是最好的解決方案。不過，當(dāng)前也已存在一些比較成熟的封裝方案來解決這種兼容性 限制，比如：開源的Socket.io，詳見《Socket.IO介紹：支持WebSocket、用于WEB端的即時(shí)通訊的框架》。
6. SSE：未來的解決方案2
SSE（Server-Sent Event，服務(wù)端推送事件）是一種允許服務(wù)端向客戶端推送新數(shù)據(jù)的HTML5技術(shù)。與由客戶端每隔幾秒從服務(wù)端輪詢拉取新數(shù)據(jù)相比，這是一種更優(yōu)的解決方案。
與WebSocket相比，它也能從服務(wù)端向客戶端推送數(shù)據(jù)。那如何決定你是用SSE還是WebSocket呢？概括來說，WebSocket能做的，SSE也能做，反之亦然，但在完成某些任務(wù)方面，它們各有千秋。
WebSocket是一種更為復(fù)雜的服務(wù)端實(shí)現(xiàn)技術(shù)，但它是真正的雙向傳輸技術(shù)，既能從服務(wù)端向客戶端推送數(shù)據(jù)，也能從客戶端向服務(wù)端推送數(shù)據(jù)。
WebSocket和SSE的瀏覽器支持率差不多，大多數(shù)主流桌面瀏覽器兩者都支持。在Android 4.3以及更早的版本中，系統(tǒng)默認(rèn)瀏覽器兩者都不支持，Firefox和Chrome則完全支持；Android 4.4中，系統(tǒng)默認(rèn)瀏覽器兩者都支持；Safari從5.0開始支持SSE（iOS系統(tǒng)從4.0開始），但直到6.0才正確地支持 WebSocket（6.0之前的Safari所實(shí)現(xiàn)的WebSocket協(xié)議存在安全問題，所以一些主流瀏覽器已經(jīng)禁用了基于這個(gè)協(xié)議的實(shí)現(xiàn)）。
與WebSocket相比，SSE有一些顯著的優(yōu)勢(shì)。個(gè)人認(rèn)為它最大的優(yōu)勢(shì)就是便利：不需要添加任何新組件，用任何你習(xí)慣的后端語(yǔ)言和框架就能繼續(xù) 使用。你不用為新建虛擬機(jī)、弄一個(gè)新的IP或新的端口號(hào)而勞神，就像在現(xiàn)有網(wǎng)站中新增一個(gè)頁(yè)面那樣簡(jiǎn)單。我喜歡把這稱為既存基礎(chǔ)設(shè)施優(yōu)勢(shì)。
SSE的第二個(gè)優(yōu)勢(shì)是服務(wù)端的簡(jiǎn)潔。相對(duì)而言，WebSocket則很復(fù)雜，不借助輔助類庫(kù)基本搞不定（我試過，令人痛苦）。
因?yàn)镾SE能在現(xiàn)有的HTTP/HTTPS協(xié)議上運(yùn)作，所以它能直接運(yùn)行于現(xiàn)有的代理服務(wù)器和認(rèn)證技術(shù)。而對(duì)WebSocket而言，代理服務(wù)器需 要做一些開發(fā)（或其他工作）才能支持，在寫這本書時(shí)，很多服務(wù)器還沒有（雖然這種狀況會(huì)改善）。SSE還有一個(gè)優(yōu)勢(shì)：它是一種文本協(xié)議，腳本調(diào)試非常容 易。事實(shí)上，在本書中，我們會(huì)在開發(fā)和測(cè)試時(shí)用curl，甚至直接在命令行中運(yùn)行后端腳本。
不過，這就引出了WebSocket相較SSE的一個(gè)潛在優(yōu)勢(shì)：WebSocket是二進(jìn)制協(xié)議，而SSE是文本協(xié)議（通常使用UTF-8編碼）。 當(dāng)然，我們可以通過SSE連接傳輸二進(jìn)制數(shù)據(jù)：在SSE中，只有兩個(gè)具有特殊意義的字符，它們是CR和LF，而對(duì)它們進(jìn)行轉(zhuǎn)碼并不難。但用SSE傳輸二進(jìn) 制數(shù)據(jù)時(shí)數(shù)據(jù)會(huì)變大，如果需要從服務(wù)端到客戶端傳輸大量的二進(jìn)制數(shù)據(jù)，最好還是用WebSocket。
WebSocket相較SSE最大的優(yōu)勢(shì)在于它是雙向交流的，這意味向服務(wù)端發(fā)送數(shù)據(jù)就像從服務(wù)端接收數(shù)據(jù)一樣簡(jiǎn)單。用SSE時(shí)，一般通過一個(gè)獨(dú)立 的Ajax請(qǐng)求從客戶端向服務(wù)端傳送數(shù)據(jù)。相對(duì)于WebSocket，這樣使用Ajax會(huì)增加開銷，但也就多一點(diǎn)點(diǎn)而已。如此一來，問題就變成了“什么時(shí) 候需要關(guān)心這個(gè)差異？”如果需要以1次/秒或者更快的頻率向服務(wù)端傳輸數(shù)據(jù)，那應(yīng)該用WebSocket。0.2次/秒到1次/秒的頻率是一個(gè)灰色地帶， 用WebSocket和用SSE差別不大；但如果你期望重負(fù)載，那就有必要確定基準(zhǔn)點(diǎn)。頻率低于0.2次/秒左右時(shí)，兩者差別不大。
?
從服務(wù)端向客戶端傳輸數(shù)據(jù)的性能如何？如果是文本數(shù)據(jù)而非二進(jìn)制數(shù)據(jù)（如前文所提到的），SSE和WebSocket沒什么區(qū)別。它們都用TCP/IP套接字，都是輕量級(jí)協(xié)議。延遲、帶寬、服務(wù)器負(fù)載等都沒有區(qū)別，除非……呃？除非什么？
當(dāng)你在享用SSE的既存基礎(chǔ)設(shè)施優(yōu)勢(shì)，并在客戶端和服務(wù)端腳本之間設(shè)了一個(gè)網(wǎng)絡(luò)服務(wù)器，區(qū)別就顯現(xiàn)出來了。一個(gè)SSE連接不僅使用一個(gè)套接字，還會(huì) 占用一個(gè)Apache線程或進(jìn)程，如果用PHP，它會(huì)為這個(gè)連接專門創(chuàng)建一個(gè)PHP新實(shí)例。Apache和PHP會(huì)使用大量的內(nèi)存，這會(huì)限制服務(wù)器所能支 持的并行連接數(shù)。所以，要做到用SSE在數(shù)據(jù)傳輸性能上和WebSocket完全一樣，需要寫一個(gè)自己的后端服務(wù)器，當(dāng)然，那些在任何情況下都會(huì)用自己的 服務(wù)器并使用Node.js的人，會(huì)覺得這有什么稀奇的。
說一下WebSocket在舊版本瀏覽器上的兼容。當(dāng)前，大約超過2/3的瀏覽器支持這些新技術(shù)，移動(dòng)端瀏覽器的支持率會(huì)低一些。依慣例，每當(dāng)需要 雙向套接字時(shí)，就會(huì)用到Flash，并且WebSocket的向后兼容通常是用Flash來做，這已經(jīng)相當(dāng)復(fù)雜了，如果瀏覽器上沒有Flash，情況更 糟。概括來說，WebSocket難兼容，SSE易兼容。有關(guān)SSE的專項(xiàng)介紹文章請(qǐng)參見：《SSE技術(shù)詳解：一種全新的HTML5服務(wù)器推送事件技術(shù)》。
（本文同步發(fā)布于：http://www.52im.net/thread-336-1-1.html）
轉(zhuǎn)載于:https://www.cnblogs.com/huifeideyu/p/5671487.html
總結(jié)
以上是生活随笔為你收集整理的Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 移动端资源
- 下一篇： 无向图求桥 UVA 796