2016
Web端即時(shí)通訊技術(shù)因受限于瀏覽器的設(shè)計(jì)限制，一直以來(lái)實(shí)現(xiàn)起來(lái)并不容易，主流的Web端即時(shí)通訊方案大致有4種：傳統(tǒng)Ajax短輪詢(xún)、Comet技術(shù)、WebSocket技術(shù)、SSE（Server-sent Events）。本文將簡(jiǎn)要介紹這4種技術(shù)的原理，并指出各自的異同點(diǎn)、優(yōu)缺點(diǎn)等。
更多資料
Web端即時(shí)通訊新手入門(mén)貼：《
新手入門(mén)貼：詳解Web端即時(shí)通訊技術(shù)的原理》
關(guān)于Ajax短輪詢(xún)：找這方面的資料沒(méi)什么意義，除非忽悠客戶(hù)，否則請(qǐng)考慮其它3種方案即可。
有關(guān)Comet技術(shù)的詳細(xì)介紹請(qǐng)參見(jiàn)：《
Comet技術(shù)詳解：基于HTTP長(zhǎng)連接的Web端實(shí)時(shí)通信技術(shù)》
《
WEB端即時(shí)通訊：HTTP長(zhǎng)連接、長(zhǎng)輪詢(xún)（long polling）詳解》
《
WEB端即時(shí)通訊：不用WebSocket也一樣能搞定消息的即時(shí)性》
《
開(kāi)源Comet服務(wù)器iComet：支持百萬(wàn)并發(fā)的Web端即時(shí)通訊方案》
有關(guān)WebSocket的詳細(xì)介紹請(qǐng)參見(jiàn)：《
WebSocket詳解（一）：初步認(rèn)識(shí)WebSocket技術(shù)》
《
WebSocket詳解（二）：技術(shù)原理、代碼演示和應(yīng)用案例》
《
WebSocket詳解（三）：深入WebSocket通信協(xié)議細(xì)節(jié)》
《
Socket.IO介紹：支持WebSocket、用于WEB端的即時(shí)通訊的框架》
《
socket.io和websocket 之間是什么關(guān)系？有什么區(qū)別？》
有關(guān)SSE的詳細(xì)介紹文章請(qǐng)參見(jiàn)：《
SSE技術(shù)詳解：一種全新的HTML5服務(wù)器推送事件技術(shù)》
更多WEB端即時(shí)通訊文章請(qǐng)見(jiàn)：http://www.52im.net/forum.php?mod=collection&action=view&ctid=15概述
1996年IETF HTTP工作組發(fā)布了HTTP協(xié)議的1.0版本 ，到現(xiàn)在普遍使用的版本1.1，HTTP協(xié)議經(jīng)歷了17 年的發(fā)展。這種分布式、無(wú)狀態(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)歷了門(mén)戶(hù)網(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)。它一直保留著無(wú)狀態(tài)、請(qǐng)求/響應(yīng)模式，似乎從來(lái)沒(méi)意識(shí)到這應(yīng)該有所改變。
好在HTML5的時(shí)代已經(jīng)到來(lái)，為Web端即時(shí)通訊的實(shí)現(xiàn)帶來(lái)了WebSocket和SSE（Server-sent Events）兩種技術(shù)方案。
Ajax短輪詢(xún)：腳本發(fā)送的http請(qǐng)求
傳統(tǒng)的web應(yīng)用要想與服務(wù)器交互，必須提交一個(gè)表單（form），服務(wù)器接收并處理傳來(lái)的表單，然后返回全新的頁(yè)面，因?yàn)榍昂髢蓚€(gè)頁(yè)面的數(shù)據(jù)大部分都是相同的，這個(gè)過(guò)程傳輸了很多冗余的數(shù)據(jù)、浪費(fèi)了帶寬。于是Ajax技術(shù)便應(yīng)運(yùn)而生。
Ajax是Asynchronous JavaScript and XML的簡(jiǎn)稱(chēng)，由Jesse James Garrett 首先提出。這種技術(shù)開(kāi)創(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)使客戶(hù)端與服務(wù)器端傳輸數(shù)據(jù)少了很多，也快了很多，也滿(mǎn)足了以豐富用戶(hù)體驗(yàn)為特點(diǎn)的web2.0時(shí)代 初期發(fā)展的需要，但是慢慢地也暴露了他的弊端。比如無(wú)法滿(mǎn)足即時(shí)通信等富交互式應(yīng)用的實(shí)時(shí)更新數(shù)據(jù)的要求。這種瀏覽器端的小技術(shù)畢竟還是基于http協(xié)議，http協(xié)議要求的請(qǐng)求/響應(yīng)的模式也是無(wú)法改變的，除非http協(xié)議本身有所改變。
Comet：一種hack技術(shù)
以即時(shí)通信為代表的web應(yīng)用程序?qū)?shù)據(jù)的Low Latency要求，傳統(tǒng)的基于輪詢(xún)的方式已經(jīng)無(wú)法滿(mǎn)足，而且也會(huì)帶來(lái)不好的用戶(hù)體驗(yàn)。于是一種基于http長(zhǎng)連接的“服務(wù)器推”技術(shù)便被hack出來(lái)。這種技術(shù)被命名為
Comet，這個(gè)術(shù)語(yǔ)由Dojo Toolkit 的項(xiàng)目主管Alex Russell在博文
Comet: Low Latency Data for the Browser首次提出，并沿用下來(lái)。
其實(shí)，服務(wù)器推很早就存在了，在經(jīng)典的client/server模型中有廣泛使用，只是瀏覽器太懶了，并沒(méi)有對(duì)這種技術(shù)提供很好的支持。但是Ajax的出現(xiàn)使這種技術(shù)在瀏覽器上實(shí)現(xiàn)成為可能， google的gmail和gtalk的整合首先使用了這種技術(shù)。隨著一些關(guān)鍵問(wèn)題的解決（比如 IE 的加載顯示問(wèn)題），很快這種技術(shù)得到了認(rèn)可，目前已經(jīng)有很多成熟的開(kāi)源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則不同，客戶(hù)端與服務(wù)器端保持一個(gè)長(zhǎng)連接，只有客戶(hù)端需要的數(shù)據(jù)更新時(shí)，服務(wù)器才主動(dòng)將數(shù)據(jù)推送給客戶(hù)端。
Comet的實(shí)現(xiàn)主要有兩種方式，基于Ajax的長(zhǎng)輪詢(xún)（long-polling）方式和基于 Iframe 及 htmlfile 的流（http streaming）方式。
有關(guān)Comet技術(shù)的詳細(xì)介紹文章請(qǐng)參見(jiàn)：《
Comet技術(shù)詳解：基于HTTP長(zhǎng)連接的Web端實(shí)時(shí)通信技術(shù)》、《
WEB端即時(shí)通訊：HTTP長(zhǎng)連接、長(zhǎng)輪詢(xún)（long polling）詳解》、《
WEB端即時(shí)通訊：不用WebSocket也一樣能搞定消息的即時(shí)性》、《
開(kāi)源Comet服務(wù)器iComet：支持百萬(wàn)并發(fā)的Web端即時(shí)通訊方案》。
1基于Ajax的長(zhǎng)輪詢(xún)（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ù)一次性取回。
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ù)呢？可以通過(guò)在返回?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ì)顯示加載沒(méi)有完成，而且 IE 上方的圖標(biāo)會(huì)不停的轉(zhuǎn)動(dòng)，表示加載正在進(jìn)行。Google 的天才們使用一個(gè)稱(chēng)為“
htmlfile”的 ActiveX 解決了在 IE 中的加載顯示問(wèn)題，并將這種方法應(yīng)用到了 gmail+gtalk 產(chǎn)品中。
Websocket：未來(lái)的解決方案1
如果說(shuō)Ajax的出現(xiàn)是互聯(lián)網(wǎng)發(fā)展的必然，那么Comet技術(shù)的出現(xiàn)則更多透露出一種無(wú)奈，僅僅作為一種hack技術(shù)，因?yàn)闆](méi)有更好的解決方案。Comet解決的問(wèn)題應(yīng)該由誰(shuí)來(lái)解決才是合理的呢？瀏覽器，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ò)程，在關(guān)閉連接前也有一個(gè)Handshake（Closing Handshake）過(guò)程，建立連接之后，雙方即可雙向通信。
有關(guān)WebSocket的詳細(xì)介，請(qǐng)參見(jiàn)即時(shí)通訊網(wǎng)有關(guān)WebSocket的系列文章：《
WebSocket詳解（一）：初步認(rèn)識(shí)WebSocket技術(shù)》、《
WebSocket詳解（二）：技術(shù)原理、代碼演示和應(yīng)用案例》、《
WebSocket詳解（三）：深入WebSocket通信協(xié)議細(xì)節(jié)》。
從瀏覽器支持角度來(lái)看，WebSocket已經(jīng)近在眼前，但仍有一段較長(zhǎng)的路要走，特別是在中國(guó)這個(gè)IE6、7、8依然盛行的國(guó)家，舊版本瀏覽器的消亡需要很長(zhǎng)一段時(shí)間，在完全實(shí)現(xiàn)瀏覽器全兼容前，Comet技術(shù)可能仍然是最好的解決方案。不過(guò)，當(dāng)前也已存在一些比較成熟的封裝方案來(lái)解決這種兼容性限制，比如：開(kāi)源的Socket.io，詳見(jiàn)《
Socket.IO介紹：支持WebSocket、用于WEB端的即時(shí)通訊的框架》。
SSE：未來(lái)的解決方案2
SSE（Server-Sent Event，服務(wù)端推送事件）是一種允許服務(wù)端向客戶(hù)端推送新數(shù)據(jù)的HTML5技術(shù)。與由客戶(hù)端每隔幾秒從服務(wù)端輪詢(xún)拉取新數(shù)據(jù)相比，這是一種更優(yōu)的解決方案。
與WebSocket相比，它也能從服務(wù)端向客戶(hù)端推送數(shù)據(jù)。那如何決定你是用SSE還是WebSocket呢？概括來(lái)說(shuō)，WebSocket能做的，SSE也能做，反之亦然，但在完成某些任務(wù)方面，它們各有千秋。
WebSocket是一種更為復(fù)雜的服務(wù)端實(shí)現(xiàn)技術(shù)，但它是真正的雙向傳輸技術(shù)，既能從服務(wù)端向客戶(hù)端推送數(shù)據(jù)，也能從客戶(hù)端向服務(wù)端推送數(shù)據(jù)。
WebSocket和SSE的瀏覽器支持率差不多，大多數(shù)主流桌面瀏覽器兩者都支持。在Android 4.3以及更早的版本中，系統(tǒng)默認(rèn)瀏覽器兩者都不支持，F(xiàn)irefox和Chrome則完全支持；Android 4.4中，系統(tǒng)默認(rèn)瀏覽器兩者都支持；Safari從5.0開(kāi)始支持SSE（iOS系統(tǒng)從4.0開(kāi)始），但直到6.0才正確地支持WebSocket（6.0之前的Safari所實(shí)現(xiàn)的WebSocket協(xié)議存在安全問(wèn)題，所以一些主流瀏覽器已經(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ēng)為既存基礎(chǔ)設(shè)施優(yōu)勢(shì)。
SSE的第二個(gè)優(yōu)勢(shì)是服務(wù)端的簡(jiǎn)潔。相對(duì)而言，WebSocket則很復(fù)雜，不借助輔助類(lèi)庫(kù)基本搞不定（我試過(guò)，令人痛苦）。
因?yàn)镾SE能在現(xiàn)有的HTTP/HTTPS協(xié)議上運(yùn)作，所以它能直接運(yùn)行于現(xiàn)有的代理服務(wù)器和認(rèn)證技術(shù)。而對(duì)WebSocket而言，代理服務(wù)器需要做一些開(kāi)發(fā)（或其他工作）才能支持，在寫(xiě)這本書(shū)時(shí)，很多服務(wù)器還沒(méi)有（雖然這種狀況會(huì)改善）。SSE還有一個(gè)優(yōu)勢(shì)：它是一種文本協(xié)議，腳本調(diào)試非常容易。事實(shí)上，在本書(shū)中，我們會(huì)在開(kāi)發(fā)和測(cè)試時(shí)用curl，甚至直接在命令行中運(yùn)行后端腳本。
不過(guò)，這就引出了WebSocket相較SSE的一個(gè)潛在優(yōu)勢(shì)：WebSocket是二進(jìn)制協(xié)議，而SSE是文本協(xié)議（通常使用UTF-8編碼）。當(dāng)然，我們可以通過(guò)SSE連接傳輸二進(jìn)制數(shù)據(jù)：在SSE中，只有兩個(gè)具有特殊意義的字符，它們是CR和LF，而對(duì)它們進(jìn)行轉(zhuǎn)碼并不難。但用SSE傳輸二進(jìn)制數(shù)據(jù)時(shí)數(shù)據(jù)會(huì)變大，如果需要從服務(wù)端到客戶(hù)端傳輸大量的二進(jìn)制數(shù)據(jù)，最好還是用WebSocket。
WebSocket相較SSE最大的優(yōu)勢(shì)在于它是雙向交流的，這意味向服務(wù)端發(fā)送數(shù)據(jù)就像從服務(wù)端接收數(shù)據(jù)一樣簡(jiǎn)單。用SSE時(shí)，一般通過(guò)一個(gè)獨(dú)立的Ajax請(qǐng)求從客戶(hù)端向服務(wù)端傳送數(shù)據(jù)。相對(duì)于WebSocket，這樣使用Ajax會(huì)增加開(kāi)銷(xiāo)，但也就多一點(diǎn)點(diǎn)而已。如此一來(lái)，問(wè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ù)端向客戶(hù)端傳輸數(shù)據(jù)的性能如何？如果是文本數(shù)據(jù)而非二進(jìn)制數(shù)據(jù)（如前文所提到的），SSE和WebSocket沒(méi)什么區(qū)別。它們都用TCP/IP套接字，都是輕量級(jí)協(xié)議。延遲、帶寬、服務(wù)器負(fù)載等都沒(méi)有區(qū)別，除非……呃？除非什么？
當(dāng)你在享用SSE的既存基礎(chǔ)設(shè)施優(yōu)勢(shì)，并在客戶(hù)端和服務(wù)端腳本之間設(shè)了一個(gè)網(wǎng)絡(luò)服務(wù)器，區(qū)別就顯現(xiàn)出來(lái)了。一個(gè)SSE連接不僅使用一個(gè)套接字，還會(huì)占用一個(gè)Apache線(xiàn)程或進(jìn)程，如果用PHP，它會(huì)為這個(gè)連接專(zhuān)門(mén)創(chuàng)建一個(gè)PHP新實(shí)例。Apache和PHP會(huì)使用大量的內(nèi)存，這會(huì)限制服務(wù)器所能支持的并行連接數(shù)。所以，要做到用SSE在數(shù)據(jù)傳輸性能上和WebSocket完全一樣，需要寫(xiě)一個(gè)自己的后端服務(wù)器，當(dāng)然，那些在任何情況下都會(huì)用自己的服務(wù)器并使用Node.js的人，會(huì)覺(jué)得這有什么稀奇的。
說(shuō)一下WebSocket在舊版本瀏覽器上的兼容。當(dāng)前，大約超過(guò)2/3的瀏覽器支持這些新技術(shù)，移動(dòng)端瀏覽器的支持率會(huì)低一些。依慣例，每當(dāng)需要雙向套接字時(shí)，就會(huì)用到Flash，并且WebSocket的向后兼容通常是用Flash來(lái)做，這已經(jīng)相當(dāng)復(fù)雜了，如果瀏覽器上沒(méi)有Flash，情況更糟。概括來(lái)說(shuō)，WebSocket難兼容，SSE易兼容。
有關(guān)SSE的詳細(xì)介紹文章請(qǐng)參見(jiàn)：《
SSE技術(shù)詳解：一種全新的HTML5服務(wù)器推送事件技術(shù)》。
