摘要：當數(shù)據(jù)發(fā)生變化，便將數(shù)據(jù)發(fā)送給。與網(wǎng)絡應用中，兩個應用程序同時需要向對方發(fā)送消息的能力即全雙工通信，所利用到的技術就是，其能夠提供端對端的通信。其不僅支持，還支持許多種輪詢機制以及其他實時通信方式，并封裝了通用的接口。

最近小組在做一個智慧交通的項目，其中有個 “分享屏幕” 的功能，即一個 client 能夠將自己當前的頁面分享到另外一個 client，針對這個需求，我們利用了 WebSocket 技術，具體說是 Socket.IO。

提到 WebSocket，我首先會想到 “及時通訊” 和 “推送” 這類詞。在 WebSocket 以前，很多網(wǎng)站通過其他方式來推送信息，下面我們先看看以前的推送方式，這樣，有比較才能看出 WebSocket 的優(yōu)勢。

這種方式下，client 每隔一段時間都會向 server 發(fā)送 http 請求，服務器收到請求后，將最新的數(shù)據(jù)發(fā)回給 client。一開始必須通過提交表單的形式，這樣的后果就是傳輸很多冗余的數(shù)據(jù)，浪費了帶寬。后來 Ajax 出現(xiàn)，減少了傳輸數(shù)據(jù)量。

如圖所示，在 client 向 server 發(fā)送一個請求活動結束后，server 中的數(shù)據(jù)發(fā)生了改變，所以 client 向 server 發(fā)送的第二次請求中，server 會將最新的數(shù)據(jù)返回給 client。

但這種方式也存在弊端。比如在某個時間段 server 沒有更新數(shù)據(jù)，但 client 仍然每隔一段時間發(fā)送請求來詢問，所以這段時間內(nèi)的詢問都是無效的，這樣浪費了網(wǎng)絡帶寬。將發(fā)送請求的間隔時間加大會緩解這種浪費，但如果 server 更新數(shù)據(jù)很快時，這樣又不能滿足數(shù)據(jù)的實時性。

鑒于（短）輪詢的弊端，一種基于 HTTP 長連接的 “服務器推” 的技術被 hack 了出來，這種技術被命名為 Comet。其與（短）輪詢主要區(qū)別就是，在輪詢方式下，要想取得數(shù)據(jù)，必須首先發(fā)送請求，在實時性要求較高的情況下，只能增加向 server 請求的頻率；而 Comet 則不同，client 與 server 端保持一個長連接，只有數(shù)據(jù)發(fā)生改變時，server 才主動將數(shù)據(jù)推送給 client。Comet 又可以被細分為兩種實現(xiàn)方式，一種是長輪詢機制，一種是流技術。

client 向 server 發(fā)出請求，server 接收到請求后，server 并不一定立即發(fā)送回應給 client，而是看數(shù)據(jù)是否更新，如果數(shù)據(jù)已經(jīng)更新了的話，那就立即將數(shù)據(jù)返回給 client；但如果數(shù)據(jù)沒有更新，那就把這個請求保持住，等待有新的數(shù)據(jù)到來時，才將數(shù)據(jù)返回給 client。

當然了，如果 server 的數(shù)據(jù)長時間沒有更新，一段時間后，請求便會超時，client 收到超時信息后，再立即發(fā)送一個新的請求給 server。

如圖所示，在長輪詢機制下，client 向 server 發(fā)送了請求后，server會等數(shù)據(jù)更新完才會將數(shù)據(jù)返回，而不是像（短）輪詢一樣不管數(shù)據(jù)有沒有更新然后立即返回。

這種方式也有弊端。當 server 向 client 發(fā)送數(shù)據(jù)后，必須等待下一次請求才能將新的數(shù)據(jù)發(fā)送出去，這樣 client 接收到新數(shù)據(jù)的間隔最短時間便是 2 * RTT（往返時間），這樣便無法應對 server 端數(shù)據(jù)更新頻率較快的情況。

流技術基于 Iframe。Iframe 是 HTML 標記，這個標記的 src 屬性會保持對指定 server 的長連接請求，server 就可以不斷地向 client 返回數(shù)據(jù)。

可以看出，流技術與長輪詢的區(qū)別是長輪詢本質(zhì)上還是一種輪詢方式，只不過連接的時間有所增加，想要向 server 獲取新的數(shù)據(jù)，client 只能一遍遍的發(fā)送請求；而流技術是一直保持連接，不需要 client 請求，當數(shù)據(jù)發(fā)生改變時，server 自動的將數(shù)據(jù)發(fā)送給 client。

如圖所示，client 與 server 建立連接之后，便不會斷開。當數(shù)據(jù)發(fā)生變化，server 便將數(shù)據(jù)發(fā)送給 client。

但這種方式有一個明顯的不足之處，網(wǎng)頁會一直顯示未加載完成的狀態(tài)，雖然我沒有強迫癥，但這點還是難以忍受。

寫到現(xiàn)在，大家會發(fā)現(xiàn)，前人推出那么多的解決方案，想要解決的唯一的問題便是怎么讓 server 將最新的數(shù)據(jù)以最快的速度發(fā)送給 client。但 HTTP 是個懶惰的協(xié)議，server 只有收到請求才會做出回應，否則什么事都不干。因此，為了徹底解決這個 server 主動向 client 發(fā)送數(shù)據(jù)的問題，W3C 在 HTML5 中提供了一種 client 與 server 間進行全雙工通訊的網(wǎng)絡技術 WebSocket。WebSocket 是一個全新的、獨立的協(xié)議，基于 TCP 協(xié)議，與 HTTP 協(xié)議兼容卻不會融入 HTTP 協(xié)議，僅僅作為 HTML5 的一部分。

那 WebSocket 與 HTTP 什么關系呢？簡單來說，WebSocket 是一種協(xié)議，是一種與 HTTP 同等的網(wǎng)絡協(xié)議，兩者都是應用層協(xié)議，都基于 TCP 協(xié)議。但是 WebSocket 是一種雙向通信協(xié)議，在建立連接之后，WebSocket 的 server 與 client 都能主動向對方發(fā)送或接收數(shù)據(jù)。同時，WebSocket 在建立連接時需要借助 HTTP 協(xié)議，連接建立好了之后 client 與 server 之間的雙向通信就與 HTTP 無關了。

相比于傳統(tǒng) HTTP 的每次“請求-應答”都要 client 與 server 建立連接的模式，WebSocket 是一種長連接的模式。具體什么意思呢？就是一旦 WebSocket 連接建立后，除非 client 或者 server 中有一端主動斷開連接，否則每次數(shù)據(jù)傳輸之前都不需要 HTTP 那樣請求數(shù)據(jù)。從上面的圖可以看出，client 第一次需要與 server 建立連接，當 server 確認連接之后，兩者便一直處于連接狀態(tài)。直到一方斷開連接，WebSocket 連接才斷開。

下面我們從報文層面談一下 WebSocket 與 HTTP 的差異。

首先，client 發(fā)起 WebSocket 連接，報文類似于 HTTP，但主要有幾點不一樣的地方：

"Upgrade: websocket"： 表明這是一個 WebSocket 類型請求，意在告訴 server 需要將通信協(xié)議切換到 WebSocket

"Sec-WebSocket-Key: *": 是 client 發(fā)送的一個 base64 編碼的密文，要求 server 必須返回一個對應加密的 "Sec-WebSocket-Accept" 應答，否則 client 會拋出 "Error during WebSocket handshake" 錯誤，并關閉連接

server 收到報文后，如果支持 WebSocket 協(xié)議，那么就會將自己的通信協(xié)議切換到 WebSocket，返回以下信息：

"HTTP/1.1 101 WebSocket Protocol Handshake"：返回的狀態(tài)碼為 101，表示同意 client 的協(xié)議轉換請求

"Upgrade: websocket"

"Connection: Upgrade"

"Sec-WebSocket-Accept: *"

...

以上都是利用 HTTP 協(xié)議完成的。這樣，經(jīng)過“請求-相應”的過程， server 與 client 的 WebSocket 連接握手成功，后續(xù)便可以進行 TCP 通訊了，也就沒有 HTTP 什么事了?？梢圆殚哤ebSocket 協(xié)議棧了解 WebSocket 的 client 與 server 更詳細的交互數(shù)據(jù)格式。

網(wǎng)絡應用中，兩個應用程序同時需要向對方發(fā)送消息的能力（即全雙工通信），所利用到的技術就是 socket，其能夠提供端對端的通信。對于程序員而言，其需要在 A 端創(chuàng)建一個 socket 實例，并為這個實例提供其所要連接的 B 端的 IP 地址和端口號，而在 B 端創(chuàng)建另一個 socket 實例，并且綁定本地端口號來進行監(jiān)聽。當 A 和 B 建立連接后，雙方就建立了一個端對端的 TCP 連接，從而可以進行雙向通信。

WebSocekt 是 HTML5 規(guī)范中的一部分，其借鑒了 socket 的思想，為 client 和 server 之間提供了類似的雙向通信機制。同時，WebSocket 又是一種新的應用層協(xié)議，包含一套標準的 API；而 socket 并不是一個協(xié)議，而是一組接口，其主要方便大家直接使用更底層的協(xié)議（比如 TCP 或 UDP）

Socket.IO 是一個封裝了 Websocket、基于 Node 的 JavaScript 框架，包含 client 的 JavaScript 和 server 的 Node。其屏蔽了所有底層細節(jié)，讓頂層調(diào)用非常簡單。

另外，Socket.IO 還有一個非常重要的好處。其不僅支持 WebSocket，還支持許多種輪詢機制以及其他實時通信方式，并封裝了通用的接口。這些方式包含 Adobe Flash Socket、Ajax 長輪詢、Ajax multipart streaming 、持久 Iframe、JSONP 輪詢等。換句話說，當 Socket.IO 檢測到當前環(huán)境不支持 WebSocket 時，能夠自動地選擇最佳的方式來實現(xiàn)網(wǎng)絡的實時通信。

參考：

Web端即時通訊技術盤點：短輪詢、Comet、Websocket、SSE

微信公眾號： 【龍果】 --- 《WebSocket --web持久連接神器》

WebSocket詳解（一）：初步認識WebSocket技術

Socket 與 WebSocket

Differences between socket.io and websockets