摘要：流控制通常就是在客戶端的頁面使用一個隱藏的窗口向服務端發出一個長連接的請求。和長鏈接以上幾種服務器推的技術中長輪詢和流控制其實都是基于長鏈接來實現的，也就是中所謂的。通信協議于年被定為標準，并被所補充規范。

node websocket socket.io

我們平常開發的大部分web頁面都是主動‘拉’的形式，如果需要更新頁面內容，則需要“刷新”一個，但Slack工具卻能主動收到信息，好像服務端能主動給客戶端推送信息，請研究一下這是怎么實現的。

websocket是HTML5中新引進的一種 協議 ，它是一種協議就像(HTTP,FTP在tcp/ip協議棧中屬于應用層)而不是簡單的一個函數。它本身及基于TCP協議的一種新的協議。

websocket是基于web的實時性而產生的，說到這里就不得不要追溯一下web的歷史了，在2005年(也就是ajax還沒誕生)以前，我們如果想要在一個頁面顯示顯示不同的內容，或者說頁面內跳轉，只能是通過點擊然后路由跳轉，在ajax誕生之后，網頁開始變得動態了。但是所有的HTTP通信還都是由客戶端控制的，這就要需要長連接，定期輪詢或者長輪詢，來和服務器溝通來更新數據。

定期輪詢(ajax輪詢)：瀏覽器在特定的時間給服務器發送請求，查看服務器是否有信息數據。

優點：后端程序編寫比較容易。
缺點：請求中有大半是無用，浪費帶寬和服務器資源。
實例：適于小型應用。

長輪詢：其實和上面的原理差不多，是對ajax輪詢進行了改進和提高。客戶端和服務端建立連接之后，一直保持通信(阻塞模式)，如果服務器沒有新消息就一直保持通信，直到服務器有新的消息，然后返回給客戶端，客戶端與服務器斷開連接，此時客戶端可以繼續和服務器進行連接。

優點：在無消息的情況下不會頻繁的請求，耗費資源小。
缺點：服務器hold連接會消耗資源，返回數據順序無保證，難于管理維護。
實例：舊的 WebQQ、Hi網頁版、Facebook IM。

流控制：通常就是在客戶端的頁面使用一個隱藏的窗口向服務端發出一個長連接的請求。服務器端接到這個請求后作出回應并不斷更新連接狀態以保證客戶端和服務 器端的連接不過期。通過這種機制可以將服務器端的信息源源不斷地推向客戶端。比如在頁面里嵌入一個隱蔵iframe，將這個隱蔵iframe的src屬性設為對一個長連接的請求或是采用xhr請求，服務器端就能源源不斷地往客戶端輸入數據。

SSE，Comet,使用長鏈接進行通訊。

優點：消息即時到達，不發無用請求；管理起來也相對方便。
缺點：服務器維護一個長連接會增加開銷。
實例：Gmail聊天

Flash Socket：在頁面中內嵌入一個使用了Socket類的 Flash 程序JavaScript通過調用此Flash程序提供的Socket接口與服務器端的Socket接口進行通信，JavaScript在收到服務器端傳送的信息后控制頁面的顯示。

優點：實現真正的即時通信，而不是偽即時。
缺點：客戶端必須安裝Flash插件；非HTTP協議，無法自動穿越防火墻。
實例：網絡互動游戲。

以上幾種服務器“推”的技術中：長輪詢和流控制其實都是基于長鏈接來實現的，也就是 http1.1 中所謂的 keep-alive。在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲。

HTTP是無狀態的，也就是說，瀏覽器和服務器每進行一次HTTP操作，就建立一次連接，但任務結束就中斷連接。如果客戶端瀏覽器訪問的某個HTML或其他類型的Web頁中包含有其他的Web資源，如JavaScript文件、圖像文件、CSS文件等；當瀏覽器每遇到這樣一個Web資源，就會建立一個HTTP會話

HTTP1.1和HTTP1.0相比較而言，最大的區別就是HTTP1.1默認支持持久連接(最新的 http1.0 可以顯示的指定 keep-alive)，但還是無狀態的，或者說是不可以信任的。

在向客戶發送所請求文件的同時，服務器并沒有存儲關于該客戶的任何狀態信息。即便某個客戶在幾秒鐘內再次請求同一個對象，服務器也不會響應說:自己剛剛給它發送了這個對象。相反，服務器重新發送這個對象，因為它已經徹底忘記早先做過什么。既然HTTP服務器不維護客戶的狀態信息，我們于是 說HTTP是一個無狀態的協議(stateless protocol)。

基于http協議的長連接減少了請求,減少了建立連接的時間,但是每次交互都是由客戶端發起的,客戶端發送消息,服務端才能返回客戶端消息。因為客戶端也不知道服務端什么時候會把結果準備好，所以客戶端的很多請求是多余的,僅是維持一個心跳,浪費了帶寬。

WebSocket 協議在2008年誕生，2011年成為國際標準。所有瀏覽器都已經支持了。WebSocket通信協議于2011年被IETF定為標準RFC 6455，并被RFC7936所補充規范。

關于HTML5的故事很多人都是知道的，w3c放棄了HTML，然后有一群人（也有說是這些人供職的公司，不過官方的文檔上是說的個人）創立了WHATWG組織來推動HTML語言的繼續發展，同時，他們還發展了很多關于Web的技術標準，這些標準不斷地被官方所接受。WebSocket就屬于WHATWG發布的Web Application的一部分（即HTML5）的產物。

它的最大特點就是，服務器可以主動向客戶端推送信息，客戶端也可以主動向服務器發送信息，是真正的雙向平等對話，屬于服務器推送技術的一種。

建立在 TCP 協議之上，服務器端的實現比較容易。

與 HTTP 協議有著良好的兼容性。默認端口也是80和443，并且握手階段采用 HTTP 協議，因此握手時不容易屏蔽，能通過各種 HTTP 代理服務器。

數據格式比較輕量，性能開銷小，通信高效。

可以發送文本，也可以發送二進制數據。

沒有同源限制，客戶端可以與任意服務器通信。

協議標識符是ws（如果加密，則為wss），服務器網址就是 URL。

其中 Upgrade: websocket Connection: Upgrade 告訴服務器我們發起的是一個 WebSocket 請求。Sec-WebSocket-Key 是一個 Base64encode 的值，這個是瀏覽器隨機生成的，驗證服務器是不是真的是Websocket助理。
然后，Sec_WebSocket-Protocol 是一個用戶定義的字符串，用來區分同URL下，不同的服務所需要的協議。
最后，Sec-WebSocket-Version 是告訴服務器所使用的WebsocketDraft（協議版本）。

詳細接口文檔：MDN WebSocket

創建對象：
var ws = new WebSocket(url,name);
url為WebSocket服務器的地址，name為發起握手的協議名稱，為可選擇項。

發送文本消息：
ws.send(msg);
msg為文本消息，對于其他類型的可以通過二進制形式發送。

接收消息：
ws.onmessage = (function(){...})();

錯誤處理：
ws.onerror = (function(){...})();

關閉連接：
ws.close();

我們借助這個測試接口 wss://echo.websocket.org 來做一個小demo。

公用html（下面的代碼基本也是這個結構）:

客戶端簡單例子
這里我們走Kaazing WebSocket為我們提供的接口，這個接口將完整返回我們所發送的數據。
狀態：
返回數據：

發送
關閉

JS：

var show = document.getElementById("state"),
    msg  = document.getElementById("msg"),
    st   = document.getElementById("sendText"),
    sb   = document.getElementById("sendBtn");

if ("WebSocket" in window) {
  var ws = new WebSocket("wss://echo.websocket.org");

  ws.onopen = function(e) { 
    show.innerText = "WebSocket連接成功～";
    ws.send("Hello WebSockets!");
  };

  ws.onmessage = function(e) {
    msg.innerText = e.data;
  };

  ws.onclose = function(e) {
      show.innerText = "WebSocket連接關閉～";
  }

  sb.addEventListener("click",function(){
      ws.send(st.value);
  })

}else{
  alert("你的瀏覽器不支持WebSocket");
}

nodejs-websocket是一個nodeJs的模塊，我們可以用它來輕易地為我們之前的代碼多帶帶搭建一個WebSocket的nodeJs服務端。

yarn add nodejs-websocket

var ws = require("nodejs-websocket")

// Scream server example: "hi" -> "HI!!!"
var server = ws.createServer(function (conn) {
    console.log("New connection")
    conn.on("text", function (str) {
        console.log("Received "+str)
        conn.sendText(str.toUpperCase()+"!!!")
    })
    conn.on("close", function (code, reason) {
        console.log("Connection closed")
    })
}).listen(8001)

在某種程度上，socket.io就是websocket，其實socket.io與websocket不是一回事，而且websocket可以說是socket.io的一個子集，socket.io的底層實現其實有5種方式，websocket只是其中一種，只不過在默認的情況下，我們建立的socket.io連接，底層也是調用websocket的實例。當我們io.connect()建立一個socket連接的時候，返回的是namespace實例，namespace實例中有個socket實例，當新建一個連接，或者發送一條消息的時候，namespace->socket->transport->websocket(xhrpolling...)，其實發送一條消息真正的發送者還是底層的websocket或是xhrpolling或其他的幾種，而socket.io只是一個組織者，當我們需要建立連接的時候，它自己會在其內部挑選一種連接方式，然后實現連接。

Socket.io都實現了Polling中的那些通信機制呢？

Adobe? Flash? Socket

AJAX long polling

AJAX multipart streaming

Forever Iframe

JSONP Polling

應用層的協議，WebSocket在現代的軟件開發中被越來越多的實踐，和HTTP有一些相似的地方，而且有人也會把WebSocket和Socket混為一談，那么他們之間到底有什么異同呢？

我們先看兩個協議的截圖來領會下。

相同點

都是基于TCP的應用層協議。

都使用Request/Response模型進行連接的建立。

在連接的建立過程中對錯誤的處理方式相同，在這個階段WS可能返回和HTTP相同的返回碼。

都可以在網絡中傳輸數據。

不同點

WS使用HTTP來建立連接，但是定義了一系列新的header域，這些域在HTTP中并不會使用。

WS的連接不能通過中間人來轉發，它必須是一個直接連接。

WS連接建立之后，通信雙方都可以在任何時刻向另一方發送數據。

WS連接建立之后，數據的傳輸使用幀來傳遞，不再需要Request消息。

WS的數據幀有序。

其實就像Java和JavaScript一樣，WebSocket和Socket并沒有太大的關系。

Socket可以有很多意思，和IT較相關的本意大致是指在端到端的一個連接中，這兩個端叫做Socket。對于IT從業者來說，它往往指的是TCP/IP網絡環境中的兩個連接端，大多數的API提供者（如操作系統，JDK）往往會提供基于這種概念的接口，所以對于開發者來說也往往是在說一種編程概念。同時，操作系統中進程間通信也有Socket的概念，但這個Socket就不是基于網絡傳輸層的協議了。

Socket 其實并不是一個協議。它工作在 OSI 模型會話層（第5層），是為了方便大家直接使用更底層協議（一般是 TCP 或 UDP ）而存在的一個抽象層。

Socket是應用層與TCP/IP協議族通信的中間軟件抽象層，它是一組接口。在設計模式中，Socket其實就是一個門面模式，它把復雜的TCP/IP協議族隱藏在Socket接口后面，對用戶來說，一組簡單的接口就是全部，讓Socket去組織數據，以符合指定的協議。

主機 A 的應用程序要能和主機 B 的應用程序通信，必須通過 Socket 建立連接，而建立 Socket 連接必須需要底層 TCP/IP 協議來建立 TCP 連接。建立 TCP 連接需要底層 IP 協議來尋址網絡中的主機。我們知道網絡層使用的 IP 協議可以幫助我們根據 IP 地址來找到目標主機，但是一臺主機上可能運行著多個應用程序，如何才能與指定的應用程序通信就要通過 TCP 或 UPD 的地址也就是端口號來指定。這樣就可以通過一個 Socket 實例唯一代表一個主機上的一個應用程序的通信鏈路了。

而 WebSocket 則不同，它是一個完整的 應用層協議，包含一套標準的 API 。

所以，從使用上來說，WebSocket 更易用，而 Socket 更靈活。

websocket api在瀏覽器端的廣泛實現似乎只是一個時間問題了, 值得注意的是服務器端沒有標準的api, 各個實現都有自己的一套api, 并且tcp也沒有類似的提案, 所以使用websocket開發服務器端有一定的風險.可能會被鎖定在某個平臺上或者將來被迫升級。

本文相關的Demo已經放在作者的Github上：小樓蘭的github