WebSocket簡介及原理

WebSocket簡介

Web系統的應用有時客戶端須要實時的得到服務器消息，但默認HTTP協議只支持請求響應模式，這樣作能夠簡化Web服務器，減小服務器的負擔，加快響應速度，由於服務器不須要與客戶端長時間創建一個通訊連接，但不容易直接完成實時的消息推送功能，如聊天室、後臺信息提示、實時更新數據等功能，但經過polling、Long polling、長鏈接、Flash Socket可完成該功能須要。

Polling：客戶端定時向服務器發送Ajax請求，服務器接到請求後立刻返回響應信息並關閉鏈接。 優勢：後端程序編寫比較容易。 缺點：請求中有大半是無用，浪費帶寬和服務器資源。 實例：適於小型應用。

Long-Polling：客戶端向服務器發送Ajax請求，服務器接到請求後hold住鏈接，直到有新消息才返回響應信息並關閉 鏈接，客戶端處理完響應信息後再向服務器發送新的請求。 優勢：在無消息的狀況下不會頻繁的請求，耗費資小。 缺點：服務器hold鏈接會消耗資源， 返回數據順序無保證，難於管理維護。

長鏈接：在頁面裏嵌入一個隱蔵iframe，將這個隱蔵iframe的src屬性設爲對一個長鏈接的請求或是採 用xhr請求，服務器端就能源源不斷地往客戶端輸入數據。 優勢：消息即時到達，不發無用請求；管理起來也相對便。 缺點：服務器維護一個長鏈接會增 加開銷。 實例：Gmail聊天

基於 Flash，AdobeFlash 經過本身的 Socket 實現完成數據交換，再利用 Flash 暴露出相應的接口爲 JavaScript 調用，從而達到實時傳輸目的。此方式比輪詢要高效，且由於 Flash 安裝率高，應用場景比較普遍，但在移動互聯網終端上 Flash 的支持並很差。IOS 系統中沒有 Flash 的存在，在 Android 中雖然有 Flash 的支持，但實際的使用效果差強人意，且對移動設備的硬件配置要求較高。2012 年 Adobe 官方宣佈再也不支持 Android4.1+系統，宣告了 Flash 在移動終端上的死亡。

傳統 Web 模式在處理高併發及實時性需求的時候，會遇到難以逾越的瓶頸，咱們須要一種高效節能的雙向通訊機制來保證數據的實時傳輸。在此背景下，基於 HTML5 規範的、有 Web TCP 之稱的 WebSocket 應運而生。 早期 HTML5 並無造成業界統一的規範，各個瀏覽器和應用服務器廠商有着各異的相似實現，如 IBM 的 MQTT，Comet 開源框架等，直到 2014 年，HTML5 在 IBM、微軟、Google 等巨頭的推進和協做下終於塵埃落地，正式從草案落實爲實際標準規範，各個應用服務器及瀏覽器廠商逐步開始統一，在 JavaEE7 中也實現了 WebSocket 協議，從而不管是客戶端仍是服務端的 WebSocket 都已完備，讀者能夠查閱HTML5 規範，熟悉新的 HTML 協議規範及 WebSocket 支持。 WebSocket是HTML5開始提供的一種瀏覽器與服務器間進行全雙工通信的網絡技術。依靠這種技術能夠實現客戶端和服務器端的長鏈接，雙向實時通訊。它的特色是以事件驅動的、異步的、使用ws或者wss協議的客戶端socket可以實現真正意義上的推送功能。

HTML5 WebSockets解決了諸如代理和防火牆等網絡危害，能夠經過任何鏈接進行流式傳輸，而且經過單一鏈接支持上游和下游通訊的能力，基於HTML5 WebSockets的應用程序對服務器的負擔下降，從而容許現有的機器支持 更多的併發鏈接。 下圖顯示了基本的基於WebSocket的架構，其中瀏覽器使用WebSocket鏈接進行全雙工，與遠程主機的直接通訊。

WebSocket 是一種全新的協議，不屬於http無狀態協議，協議名爲"ws"，這意味着一個websocket鏈接地址會是這樣的寫 法：ws://localhost:8080/webSocketServer。ws不是http，因此傳統的web服務器不必定支持，須要服務器與瀏覽 器同時支持， WebSocket才能正常運行，目前的支持還不廣泛，須要特別的web服務器和現代的瀏覽器。一下是瀏覽器對WebSocket支持狀況：

WebSocket原理

WebSocket協議被設計更好適用於現有網絡基礎。做爲這一設計原則的一部分，該協議規範定義了WebSocket鏈接開始它的生命週期做爲一個HTTP鏈接，保證向後兼容性。從HTTP到WebSocket協議轉換是指創建了WebSocket握手。

在客戶端，new WebSocket 實例化一個新的 WebSocket 客戶端對象，WebSocket 客戶端對象會自動解析並識別爲 WebSocket 請求，從而鏈接服務端端口，執行雙方握手過程，客戶端發送數據格式相似：

能夠看到，客戶端發起的 WebSocket 鏈接報文相似傳統 HTTP 報文，」Upgrade：websocket」參數值代表這是 WebSocket 類型請求，「Sec-WebSocket-Key」是 WebSocket 客戶端發送的一個 base64 編碼的密文，要求服務端必須返回一個對應加密的「Sec-WebSocket-Accept」應答，不然客戶端會拋出「Error during WebSocket handshake」錯誤，並關閉鏈接。服務端收到報文後返回的數據格式相似：

「Sec-WebSocket-Accept」的值是服務端採用與客戶端一致的密鑰計算出來後返回客戶端的,「HTTP/1.1 101 Switching Protocols」表示服務端接受 WebSocket 協議的客戶端鏈接，通過這樣的請求-響應處理後，客戶端服務端的 WebSocket 鏈接握手成功, 後續就能夠進行 TCP 通信了。讀者能夠查閱WebSocket 協議棧瞭解 WebSocket 客戶端和服務端更詳細的交互數據格式。

WebSocket有兩種實現方式，請看下節。