摘要：輪詢通過輪詢，瀏覽器定期發送請求并立即接收響應這項技術是瀏覽器首次嘗試傳遞實時信息。該協議由兩層組成記錄協議和握手協議。安全套接層及其繼任者傳輸層安全，是為網絡通信提供安全及數據完整性的一種安全協議。移除了開銷大幅度減輕了復雜度。

Web Sockets定義了一種在通過一個單一的 socket 在網絡上進行全雙工通訊的通道。它不僅僅是傳統的 HTTP 通訊的一個增量的提高，尤其對于實時、事件驅動的應用來說是一個飛躍。

HTML5 Web Sockets 相對于老的技術（在瀏覽器中模擬全雙工連接的復雜技術）有了如此巨大的提升，以致于谷歌的 Ian Hickson(HTML5 說明書的總編)說：

想閱讀更多優質文章請猛戳GitHub博客,一年百來篇優質文章等著你！

“將數據的千字節減少到2字節……并將延遲從150ms減少到50ms，這遠遠超過了邊際效應。”事實上，僅這兩個因素就足以讓谷歌對 Web Sockets 字產生濃厚的興趣。

讓我們來看看 HTML5 Web Sockets 是如何通過與傳統的解決方案進行比較，從而極大地減少不必要的網絡流量和延遲的

通常，當一個瀏覽器訪問一個網頁時，會向擁有這個頁面的服務器發送一個HTTP請求。Web 服務器接受這個請求并返回一個響應。

在許多情況下——例如，股票價格、新聞報道、機票銷售、交通模式、醫療設備讀數等等——瀏覽器渲染頁面時，響應可能已經過時，如果你想獲得最新的“實時”信息，你可以不斷手動刷新該頁面，但這顯然不是一個很好的解決方案。

當前嘗試提供實時 Web 應用程序其主要圍繞輪詢和其他服務器端推送技術，其中最引人注目的是 Comet，它會延遲完成 HTTP 響應以將消息傳遞到客戶端?；?Comet 的推送一般采用 JavaScript 實現并使用長連接或流等連接策略。

comet： 基于 HTTP 長連接的“服務器推”技術?；谶@種架構開發的應用中，服務器端會主動以異步的方式向客戶端程序推送數據，而不需要客戶端顯式的發出請求。Comet 架構非常適合事件驅動的 Web 應用，以及對交互性和實時性要求很強的應用，如股票交易行情分析、聊天室和 Web 版在線游戲等。

通過輪詢，瀏覽器定期發送 HTTP 請求并立即接收響應,這項技術是瀏覽器首次嘗試傳遞實時信息。顯然，如果消息傳遞的確切時間間隔已知，這是一個很好的解決方案，因為可以在服務器上先把需要發送的信息準備好之后在發送給客戶端。然而，實時數據通常是不可預測的，這必然造成許多不必要的請求，因此，在低頻率消息的情況下，許多連接被不必要地打開和關閉的。

長輪詢是讓服務器在接收到瀏覽器所送出 HTTP 請求后，服務器會等待一段時間，若在這段時間里面服務器有新的消息，它就會把最新的消息傳回給瀏覽器，如果等待的時間到了之后也沒有新的消息的話，就會送一個回應給瀏覽器，告知瀏覽器消息沒有更新。

雖然輪詢可以減少產生原本輪詢造成網絡帶寬浪費的情況，但是，如果在資料更新頻繁的狀況下，長時間輪詢不傳統比傳統的輪詢有效率，而且有時候資料量很大時，會造成連續的輪詢不斷產生，反而會更糟糕。

串流 (streaming) 是讓服務器在接收到瀏覽器所送出的 HTTP 請求后，立即產生一個回應瀏覽器的連接，并且讓這個連接持續一段時間不要中斷，而服務器在這段時間內如果有新的消息，就可以透過這個連接將消息馬上傳送給瀏覽器。

然而，由于流仍然封裝在 HTTP 中，介入的防火墻和代理服務器可能會選擇緩沖響應，從而增加消息傳遞的延遲。因此，如果檢測到緩沖代理服務器，流式 Comet 解決方案將退回到長輪詢?；蛘?，可以使用TLS (SSL)連接來防止響應被緩沖，但是這種情況下創建和銷毀每一個連接將消耗更多的可用的服務器資源。

TLS：安全傳輸層協議（TLS）用于在兩個通信應用程序之間提供保密性和數據完整性。 該協議由兩層組成： TLS 記錄協議（TLS Record）和 TLS 握手協議（TLS Handshake）。
SSL：SSL(Secure Sockets Layer 安全套接層),及其繼任者傳輸層安全（Transport Layer
Security，TLS）是為網絡通信提供安全及數據完整性的一種安全協議。TLS與SSL在傳輸層對網絡連接進行加密。

最后，所有這些提供實時數據的方法都會引入 HTTP 請求和響應報頭，這些報頭包含大量額外的、不必要的報頭數據，并會帶來延遲。

最重要的是，全雙工連接需要的不僅僅是從服務器到客戶端的下行連接。為了在半雙工HTTP上模擬全雙工通信，當今的許多解決方案使用兩個連接:一個用于下行，一個用于上行，這兩個連接的維護和協調在資源消耗方面引入了大量開銷，并增加了許多復雜性。

簡單地說，HTTP 不是為實時、全雙工通信而設計的，可以在下面的圖中看到，該圖展示了構建 Comet Web 應用(在半雙工的 HTTP 上使用訂閱模式實時獲取后端數據)的復雜性。

當試圖將 Comet 的解決方案擴充系統的規模時會變得更糟。在 HTTP 模擬全雙工的瀏覽器通訊易出錯、復雜而且復雜度無法降低。盡管最終用戶可能正在體驗類似于實時 Web應用程序的服務，但這種 “實時” 體驗的代價高得驚人。這個代價是，付出額外的延遲，不必要的網絡流量和 CPU性能的影響上。

在 HTML5 規范的通信部分中定義，HTML5 Web Sockets 代表了全雙工的網絡交互的下一個演變 —— 一個全雙工、雙向的通信通道，通過 Web 上的單個套接字進行操作。

HTML5 Web Sockets 提供了一個真正的標準，可以使用它來構建可擴展的實時 Web 應用程序。此外，由于它提供了瀏覽器本地的套接字，因此避免了 Comet 解決方案容易出現的許多問題。 Web Socket s移除了開銷大幅度減輕了復雜度。

為了建立WebSocket連接，客戶端和服務器在首次握手時從 HTTP 協議升級到 WebSocket 協議，如下圖所示:

示例1 - WebSocket握手(瀏覽器請求和服務器響應)

熟悉 HTTP 的可能會發現，這段類似 HTTP 協議的握手請求中，多了幾個東西：

Upgrade: websocket
Connection: Upgrade

這個就是 Websocket 的核心了，告訴 Apache 、 Nginx 等服務器：發起的是 Websocket協議，使用對應的Websocket協議處理，而不是使用 HTTP 協議。

一旦建立，WebSocket 數據幀可以在客戶端和服務器之間以全雙工模式來回發送。文本和二進制幀都可以發送全雙工，在同一時間向任意方向發送，數據的最小幀只有兩個字節。

在文本幀的情況下，每個幀以 0x00 元組開頭，以 0xFF 元組結束，中間包含 UTF-8 數據，WebSocket 文本幀使用終止符，而二進制幀使用長度前綴。

注意:盡管 Web Sockets 協議已經準備好支持各種客戶端集，但是它不能將原始二進制數據交付給 JavaScript，因為 JavaScript 不支持字節類型。因此，如果客戶端是 Javascript 的，二進制數據將被忽略 —— 但是可以把它發送給其它支持二進制的客戶端。

那么在非必要的網絡傳輸和延遲性上究竟減少了多少？讓比較一下長連接應用和 WebSocket 應用。

對于輪詢示例，我創建了一個簡單的 Web 應用程序，其中 Web 頁面使用傳統的發布/訂閱模型從RabbitMQ 消息隊列中獲取實時股票信息。

它通過輪詢駐留在 web 服務器上的 Java Servlet 來實現這一點。RabbitMQ 消息隊列從虛構的持續改變股票價格的股票價格服務接收數據。

Web 頁面連接并訂閱特定的股票通道(message broker上的主題)，并使用 XMLHttpReques t每秒輪詢更新一次。當接收到更新時，執行一些計算，股票數據顯示在一個表中，如下圖所示。

注意：后臺股票服務實際上每秒會產生大量股票價格更新，因此每秒輪詢一次實際上比使用Comet 長輪詢解決方案更為謹慎，后者會導致一系列持續輪詢，這里輪詢有效的節制了數據更新。

這一切看起來都很好，但從內部看，這個應用程序有一些嚴重的問題。在 Mozilla Firefox 中使用 Firebug（一個火狐插件——可以對網頁進行deb、跟蹤加載頁面和執行腳本的時間），可以看到 GET 請求每隔一秒就會連接服務器。打開Live HTTP Headers（另外一個火狐插件——可以顯示活躍 HTTP 頭傳輸）暴露了每一個連接上巨大數量的頭開銷（header overhead）。下面的例子展示了一個請求和響應的頭信息。

事例二：HTTP request header

事例三：HTTP response header

只是為了好玩，我數了數所有的字符。總的 HTT P請求和響應頭信息開銷包含 871 字節，甚至不包括任何數據 !當然，這只是一個示例，可以擁有少于 871 字節的頭數據，但是我也看到過頭數據超過 2000 字節的情況。

在這個示例應用程序中，典型股票標題信息僅僅20個字符長。正如所看到的，它實際上被過多的頭信息淹沒了，而頭信息甚至在一開始就不是必需的!

那么當你把這個應用部署到大用戶量的場景下會怎么樣？ 讓我們在三個不同的場景中對比與此輪詢應用程序關聯的 HTTP 請求和響應頭數據的網絡吞吐量。

場景一：每秒 1000 個客戶端輪詢，每秒的網絡流量是 6.6 M。

場景二：每秒 10000 個客戶端輪詢，每秒的網絡流量是 66 M。

場景三：每秒 100000 個客戶端輪詢，每秒的網絡流量是 660 M。

這是大量不必要的網絡吞吐量，要是我們能通過網絡得到必要的數據就好了，此時就可以使用 HTML5 Web Sockets!

我重新構建了應用程序以使用 HTML5 Web Sockets，在 Web 頁面中添加了一個事件處理程序來異步偵聽來來自于代理的股票更新信息。

。每一個信息都是一個WebSocket幀，只有兩個字節的開銷(而不是871字節)! 看看這如何影響我們的三個用例中的網絡吞吐量開銷。

場景一：每秒 1000 個客戶端輪詢，每秒的網絡流量是 0.015 M。

場景二：每秒 10000 個客戶端輪詢，每秒的網絡流量是 0.153 M。

場景三：每秒 100000 個客戶端輪詢，每秒的網絡流量是 .1526 M。

如下圖所示，與輪詢解決方案相比，HTML5 Web Sockets大大減少了不必要的網絡流量。

那么延遲的減多少呢? 請看下圖：

在上半部分，可以看到半雙工輪詢解決方案的延遲。在本例中，假設消息從服務器傳輸到瀏覽器需要50毫秒，那么輪詢應用程序將引入大量額外的延遲，因為在響應完成時必須將新請求發送到服務器。這個新請求需要另一個50ms，在此期間服務器不能向瀏覽器發送任何消息，從而導致額外的服務器內存消耗。

在圖的下半部分，可以看到 WebSocket 解決方案降低了延遲。一旦連接升級到 WebSocket，消息就可以在到達時從服務器流到瀏覽器。消息從服務器傳輸到瀏覽器仍然需要 50 毫秒，但是WebSocket 連接仍然打開，因此不需要向服務器發送另一個請求。

HTML5 Web Sockets 在實時網絡的擴展性上向前邁出了一大步。正如在本文中看到的， HTML5 Web Sockets可以提供 500：1 甚至 1000：1 的非必要HTTP頭信息傳輸的變少，以及 3：1 延遲性的降低。這不僅僅是個進步，它是巨大的一個飛躍!

原文：

http://www.websocket.org/quan...

你的點贊是我持續分享好東西的動力，歡迎點贊！

干貨系列文章匯總如下，覺得不錯點個Star，歡迎 加群 互相學習。

https://github.com/qq44924588...

我是小智，公眾號「大遷世界」作者，對前端技術保持學習愛好者。我會經常分享自己所學所看的干貨，在進階的路上，共勉！

關注公眾號，后臺回復福利，即可看到福利，你懂的。