本文來自“糊糊糊糊糊了”的分享，原題《實時消息推送整理》，有優(yōu)化和改動。

1、寫在前面

對Web端即時通訊技術(shù)熟悉的開發(fā)者來說，我們回顧網(wǎng)頁端IM的底層通信技術(shù)，從短輪詢、長輪詢，到后來的SSE以及WebSocket，使用門檻越來越低（早期的長輪詢Comet這類技術(shù)實際屬于hack手段，使用門檻并不低），技術(shù)手段越來越先進，網(wǎng)頁端即時通訊技術(shù)的體驗也因此越來越好。

但上周在編輯《IM掃碼登錄技術(shù)專題》系列文章第3篇的時候忽然想到，之前的這些所謂的網(wǎng)頁端即時通訊“老技術(shù)”相對于當紅的WebSocket，并非毫無用武之地。就拿IM里的掃碼登錄功能來說，用短輪詢技術(shù)就非常合適，完全沒必要大炮打蚊子上WebSocket。

所以，很多時候沒必要盲目追求新技術(shù)，相對應(yīng)用場景來說適合的才是最好的。對于即時通訊網(wǎng)的im和消息推送這類即時通訊技術(shù)開發(fā)者來說，掌握WebSocket固然很重要，但了解短輪詢、長輪詢等這些所謂的Web端即時通訊“老技術(shù)”仍然大有裨益，這也正是整理分享本文的重要原因。

學習交流：

- 即時通訊/推送技術(shù)開發(fā)交流5群：215477170?[推薦]

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK

（本文同步發(fā)布于：http://www.52im.net/thread-3555-1-1.html）

2、推薦閱讀

[1]?新手入門貼：史上最全Web端即時通訊技術(shù)原理詳解

[2]?詳解Web端通信方式的演進：從Ajax、JSONP 到 SSE、Websocket

[3]?Web端即時通訊技術(shù)盤點：短輪詢、Comet、Websocket、SSE

3、正文引言

對于IM/消息推送這類即時通訊系統(tǒng)而言，系統(tǒng)的關(guān)鍵就是“實時通信”能力。

從表面意思上來看，“實時通信”指的是：

• 1）客戶端能隨時主動發(fā)送數(shù)據(jù)給服務(wù)端；

• 2）當客戶端關(guān)注的內(nèi)容在發(fā)生改變時，服務(wù)器能夠?qū)崟r地通知客戶端。

類比于傳統(tǒng)的C/S請求模型，“實時通信”時客戶端不需要主觀地發(fā)送請求去獲取自己關(guān)心的內(nèi)容，而是由服務(wù)器端進行“推送”。

注意：上面的“推送”二字打了引號，實際上現(xiàn)有的幾種技術(shù)實現(xiàn)方式中，并不是服務(wù)器端真正主動地推送，而是通過一定的手段營造了一種“實時通信”的假象。

就目前現(xiàn)有的幾種技術(shù)而言，主要有以下幾類：

• 1）客戶端輪詢：傳統(tǒng)意義上的短輪詢（Short Polling）；

• 2）服務(wù)器端輪詢：長輪詢（Long Polling）；

• 3）單向服務(wù)器推送：Server-Sent Events（SSE）；

• 4）全雙工通信：WebSocket。

以下正文將針對這幾種技術(shù)方案，為你一一解惑。

4、本文配套Demo和代碼

為了幫助讀者更好的理解本文內(nèi)容，筆者專門寫了一個較完整的Demo，Demo會以一個簡易聊天室的例子來分別通過上述的四種技術(shù)方式實現(xiàn)（代碼存在些許bug，主要是為了做演示用，別介意）。

完整Demo源碼打包下載：

（請從同步鏈接附件中下載：http://www.52im.net/thread-3555-1-1.html）

Demo的運行效果（動圖）：

有興趣可以自行下載研究學習。

5、理解短輪詢（Short Polling）

短輪詢的實現(xiàn)原理：

• 1）客戶端向服務(wù)器端發(fā)送一個請求，服務(wù)器返回數(shù)據(jù)，然后客戶端根據(jù)服務(wù)器端返回的數(shù)據(jù)進行處理；

• 2）客戶端繼續(xù)向服務(wù)器端發(fā)送請求，繼續(xù)重復(fù)以上的步驟，如果不想給服務(wù)器端太大的壓力，一般情況下會設(shè)置一個請求的時間間隔。

邏輯如下圖所示：

使用短輪詢的優(yōu)點：基礎(chǔ)不需要額外的開發(fā)成本，請求數(shù)據(jù)，解析數(shù)據(jù)，作出響應(yīng)，僅此而已，然后不斷重復(fù)。

缺點也顯而易見：

• 1）不斷的發(fā)送和關(guān)閉請求，對服務(wù)器的壓力會比較大，因為本身開啟Http連接就是一件比較耗資源的事情；

• 2）輪詢的時間間隔不好控制。如果要求的實時性比較高，顯然使用短輪詢會有明顯的短板，如果設(shè)置interval的間隔過長，會導(dǎo)致消息延遲，而如果太短，會對服務(wù)器產(chǎn)生壓力。

短輪詢客戶的代碼實現(xiàn)（片段節(jié)選）：

var ShortPollingNotification = {

??datasInterval: null,

??subscribe: function() {

????this.datasInterval = setInterval(function() {

??????Request.getDatas().then(function(res) {

????????window.ChatroomDOM.renderData(res);

??????});

????}, TIMEOUT);

????return this.unsubscribe;

??},

??unsubscribe: function() {

????this.datasInterval && clearInterval(this.datasInterval);

??}

}

PS：完整代碼，請見本文“4、本文配套Demo和代碼”一節(jié)。

對應(yīng)本文配套Demo的運行效果如下（動圖）：

下面是對應(yīng)的請求，注意左下角的請求數(shù)量一直在變化：

在上圖中，每隔1s就會發(fā)送一個請求，看起來效果還不錯，但是如果將timeout的值設(shè)置成5s，效果將大打折扣。如下圖所示。

將timeout值設(shè)置成5s時的Demo運行效果（動圖）：

8、什么是WebSocket

8.1 基本介紹

PS：本小節(jié)內(nèi)容引用自《Web端即時通訊實踐干貨：如何讓WebSocket斷網(wǎng)重連更快速？》一文的“3、快速了解WebSocket”。

WebSocket誕生于2008年，在2011年成為國際標準，現(xiàn)在所有的瀏覽器都已支持（詳見《新手快速入門：WebSocket簡明教程》）。它是一種全新的應(yīng)用層協(xié)議，是專門為web客戶端和服務(wù)端設(shè)計的真正的全雙工通信協(xié)議，可以類比HTTP協(xié)議來了解websocket協(xié)議。

（圖片引用自《WebSocket詳解（四）：刨根問底HTTP與WebSocket的關(guān)系(上篇)》）

它們的不同點：

• 1）HTTP的協(xié)議標識符是http，WebSocket的是ws；

• 2）HTTP請求只能由客戶端發(fā)起，服務(wù)器無法主動向客戶端推送消息，而WebSocket可以；

• 3）HTTP請求有同源限制，不同源之間通信需要跨域，而WebSocket沒有同源限制。

它們的相同點：

• 1）都是應(yīng)用層的通信協(xié)議；

• 2）默認端口一樣，都是80或443；

• 3）都可以用于瀏覽器和服務(wù)器間的通信；

• 4）都基于TCP協(xié)議。

兩者和TCP的關(guān)系圖：

（圖片引用自《新手快速入門：WebSocket簡明教程》）

有關(guān)Http和WebSocket的關(guān)系，可以詳讀：

《WebSocket詳解（四）：刨根問底HTTP與WebSocket的關(guān)系(上篇)》

《WebSocket詳解（五）：刨根問底HTTP與WebSocket的關(guān)系(下篇)》

有關(guān)WebSocket和Socket的關(guān)系，可以詳讀：《WebSocket詳解（六）：刨根問底WebSocket與Socket的關(guān)系》.

8.2 技術(shù)特征

WebSocket技術(shù)特征總結(jié)下就是：

• 1）可雙向通信，設(shè)計的目的主要是為了減少傳統(tǒng)輪詢時http連接數(shù)量的開銷；

• 2）建立在TCP協(xié)議之上，握手階段采用 HTTP 協(xié)議，因此握手時不容易屏蔽，能通過各種 HTTP 代理服務(wù)器；

• 3）與HTTP兼容性良好，同樣可以使用80和443端口；

• 4）沒有同源限制，客戶端可以與任意服務(wù)器通信；

• 5）可以發(fā)送文本，也可以發(fā)送二進制數(shù)據(jù)；

• 6）協(xié)議標識符是ws（如果加密，則為wss），服務(wù)器網(wǎng)址就是 URL.

WebSocket的技術(shù)原理如下圖所示：

關(guān)于WebSocket API方面的知識，這里不再作講解，可以自己查閱：https://developer.mozilla.org/en-US/docs/Web/API/WebSocket

8.3 瀏覽器兼容性

WebSocket兼容性良好，基本支持所有現(xiàn)代瀏覽器。

（上圖來自：https://caniuse.com/mdn-api_websocket）

8.4 代碼實現(xiàn)

筆者這里采用的是socket.io，是基于WebSocket的封裝，提供了客戶端以及服務(wù)器端的支持。

// 客戶端

var WebsocketNotification = {

??// ...

??subscribe: function(args) {

????var connector = args[1];

????this.socket = io();

????this.socket.emit('register', connector);

????this.socket.on('register done', function() {

??????window.ChatroomDOM.renderAfterRegister();

????});

????this.socket.on('data', function(res) {

??????window.ChatroomDOM.renderData(res);

????});

????this.socket.on('disconnect', function() {

??????window.ChatroomDOM.renderAfterLogout();

????});

??}

??// ...

}

?

// 服務(wù)器端

var io = socketIo(httpServer);

io.on('connection', (socket) => {

??socket.on('register', function(connector) {

????chatRoom.onConnect(connector);

????io.emit('register done');

????var data = chatRoom.getDatas();

????io.emit('data', { data });

??});

??socket.on('chat', function(message) {

????chatRoom.receive(message);

????var data = chatRoom.getDatas();

????io.emit('data', { data });

??});

});

PS：完整代碼，請見本文“4、本文配套Demo和代碼”一節(jié)。

響應(yīng)格式如下：

8.5 深入學習

隨著HTML5的普及率越來越高，WebSocket的應(yīng)用也越來越普及，關(guān)于WebSocket的學習資料網(wǎng)上很容易找到，限于篇幅本文就不深入展開這個話題。

如果想進一步深入學習WebSocket的方方面面，以下文章值得一讀：

《新手快速入門：WebSocket簡明教程》

《WebSocket詳解（一）：初步認識WebSocket技術(shù)》

《WebSocket詳解（二）：技術(shù)原理、代碼演示和應(yīng)用案例》

《WebSocket詳解（三）：深入WebSocket通信協(xié)議細節(jié)》

《WebSocket詳解（四）：刨根問底HTTP與WebSocket的關(guān)系(上篇)》

《WebSocket詳解（五）：刨根問底HTTP與WebSocket的關(guān)系(下篇)》

《WebSocket詳解（六）：刨根問底WebSocket與Socket的關(guān)系》

《理論聯(lián)系實際：從零理解WebSocket的通信原理、協(xié)議格式、安全性》

《微信小程序中如何使用WebSocket實現(xiàn)長連接(含完整源碼)》

《八問WebSocket協(xié)議：為你快速解答WebSocket熱門疑問》

《Web端即時通訊實踐干貨：如何讓你的WebSocket斷網(wǎng)重連更快速？》

《WebSocket從入門到精通，半小時就夠！》

《WebSocket硬核入門：200行代碼，教你徒手擼一個WebSocket服務(wù)器》

《長連接網(wǎng)關(guān)技術(shù)專題(四)：愛奇藝WebSocket實時推送網(wǎng)關(guān)技術(shù)實踐》

9、本文小結(jié)

短輪詢、長輪詢實現(xiàn)成本相對比較簡單，適用于一些實時性要求不高的消息推送，在實時性要求高的場景下，會存在延遲以及會給服務(wù)器帶來更大的壓力。

SSE只能是服務(wù)器端推送消息，因此對于不需要雙向通信的項目比較適用。

WebSocket目前而言實現(xiàn)成本相對較低，適合于雙工通信，對于多人在線，要求實時性較高的項目比較實用。

本文已同步發(fā)布于“即時通訊技術(shù)圈”公眾號。

▲ 本文在公眾號上的鏈接是：點此進入。同步發(fā)布鏈接是：http://www.52im.net/thread-3555-1-1.html