摘要：輪詢(xún)通過(guò)輪詢(xún)，瀏覽器定期發(fā)送請(qǐng)求并立即接收響應(yīng)這項(xiàng)技術(shù)是瀏覽器首次嘗試傳遞實(shí)時(shí)信息。該協(xié)議由兩層組成記錄協(xié)議和握手協(xié)議。安全套接層及其繼任者傳輸層安全，是為網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議。移除了開(kāi)銷(xiāo)大幅度減輕了復(fù)雜度。

Web Sockets定義了一種在通過(guò)一個(gè)單一的 socket 在網(wǎng)絡(luò)上進(jìn)行全雙工通訊的通道。它不僅僅是傳統(tǒng)的 HTTP 通訊的一個(gè)增量的提高，尤其對(duì)于實(shí)時(shí)、事件驅(qū)動(dòng)的應(yīng)用來(lái)說(shuō)是一個(gè)飛躍。

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

想閱讀更多優(yōu)質(zhì)文章請(qǐng)猛戳GitHub博客,一年百來(lái)篇優(yōu)質(zhì)文章等著你！

“將數(shù)據(jù)的千字節(jié)減少到2字節(jié)……并將延遲從150ms減少到50ms，這遠(yuǎn)遠(yuǎn)超過(guò)了邊際效應(yīng)?！笔聦?shí)上，僅這兩個(gè)因素就足以讓谷歌對(duì) Web Sockets 字產(chǎn)生濃厚的興趣。

讓我們來(lái)看看 HTML5 Web Sockets 是如何通過(guò)與傳統(tǒng)的解決方案進(jìn)行比較，從而極大地減少不必要的網(wǎng)絡(luò)流量和延遲的

通常，當(dāng)一個(gè)瀏覽器訪問(wèn)一個(gè)網(wǎng)頁(yè)時(shí)，會(huì)向擁有這個(gè)頁(yè)面的服務(wù)器發(fā)送一個(gè)HTTP請(qǐng)求。Web 服務(wù)器接受這個(gè)請(qǐng)求并返回一個(gè)響應(yīng)。

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

當(dāng)前嘗試提供實(shí)時(shí) Web 應(yīng)用程序其主要圍繞輪詢(xún)和其他服務(wù)器端推送技術(shù)，其中最引人注目的是 Comet，它會(huì)延遲完成 HTTP 響應(yīng)以將消息傳遞到客戶(hù)端?；?Comet 的推送一般采用 JavaScript 實(shí)現(xiàn)并使用長(zhǎng)連接或流等連接策略。

comet： 基于 HTTP 長(zhǎng)連接的“服務(wù)器推”技術(shù)?；谶@種架構(gòu)開(kāi)發(fā)的應(yīng)用中，服務(wù)器端會(huì)主動(dòng)以異步的方式向客戶(hù)端程序推送數(shù)據(jù)，而不需要客戶(hù)端顯式的發(fā)出請(qǐng)求。Comet 架構(gòu)非常適合事件驅(qū)動(dòng)的 Web 應(yīng)用，以及對(duì)交互性和實(shí)時(shí)性要求很強(qiáng)的應(yīng)用，如股票交易行情分析、聊天室和 Web 版在線游戲等。

通過(guò)輪詢(xún)，瀏覽器定期發(fā)送 HTTP 請(qǐng)求并立即接收響應(yīng),這項(xiàng)技術(shù)是瀏覽器首次嘗試傳遞實(shí)時(shí)信息。顯然，如果消息傳遞的確切時(shí)間間隔已知，這是一個(gè)很好的解決方案，因?yàn)榭梢栽诜?wù)器上先把需要發(fā)送的信息準(zhǔn)備好之后在發(fā)送給客戶(hù)端。然而，實(shí)時(shí)數(shù)據(jù)通常是不可預(yù)測(cè)的，這必然造成許多不必要的請(qǐng)求，因此，在低頻率消息的情況下，許多連接被不必要地打開(kāi)和關(guān)閉的。

長(zhǎng)輪詢(xún)是讓服務(wù)器在接收到瀏覽器所送出 HTTP 請(qǐng)求后，服務(wù)器會(huì)等待一段時(shí)間，若在這段時(shí)間里面服務(wù)器有新的消息，它就會(huì)把最新的消息傳回給瀏覽器，如果等待的時(shí)間到了之后也沒(méi)有新的消息的話，就會(huì)送一個(gè)回應(yīng)給瀏覽器，告知瀏覽器消息沒(méi)有更新。

雖然輪詢(xún)可以減少產(chǎn)生原本輪詢(xún)?cè)斐删W(wǎng)絡(luò)帶寬浪費(fèi)的情況，但是，如果在資料更新頻繁的狀況下，長(zhǎng)時(shí)間輪詢(xún)不傳統(tǒng)比傳統(tǒng)的輪詢(xún)有效率，而且有時(shí)候資料量很大時(shí)，會(huì)造成連續(xù)的輪詢(xún)不斷產(chǎn)生，反而會(huì)更糟糕。

串流 (streaming) 是讓服務(wù)器在接收到瀏覽器所送出的 HTTP 請(qǐng)求后，立即產(chǎn)生一個(gè)回應(yīng)瀏覽器的連接，并且讓這個(gè)連接持續(xù)一段時(shí)間不要中斷，而服務(wù)器在這段時(shí)間內(nèi)如果有新的消息，就可以透過(guò)這個(gè)連接將消息馬上傳送給瀏覽器。

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

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

最后，所有這些提供實(shí)時(shí)數(shù)據(jù)的方法都會(huì)引入 HTTP 請(qǐng)求和響應(yīng)報(bào)頭，這些報(bào)頭包含大量額外的、不必要的報(bào)頭數(shù)據(jù)，并會(huì)帶來(lái)延遲。

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

簡(jiǎn)單地說(shuō)，HTTP 不是為實(shí)時(shí)、全雙工通信而設(shè)計(jì)的，可以在下面的圖中看到，該圖展示了構(gòu)建 Comet Web 應(yīng)用(在半雙工的 HTTP 上使用訂閱模式實(shí)時(shí)獲取后端數(shù)據(jù))的復(fù)雜性。

當(dāng)試圖將 Comet 的解決方案擴(kuò)充系統(tǒng)的規(guī)模時(shí)會(huì)變得更糟。在 HTTP 模擬全雙工的瀏覽器通訊易出錯(cuò)、復(fù)雜而且復(fù)雜度無(wú)法降低。盡管最終用戶(hù)可能正在體驗(yàn)類(lèi)似于實(shí)時(shí) Web應(yīng)用程序的服務(wù)，但這種 “實(shí)時(shí)” 體驗(yàn)的代價(jià)高得驚人。這個(gè)代價(jià)是，付出額外的延遲，不必要的網(wǎng)絡(luò)流量和 CPU性能的影響上。

在 HTML5 規(guī)范的通信部分中定義，HTML5 Web Sockets 代表了全雙工的網(wǎng)絡(luò)交互的下一個(gè)演變 —— 一個(gè)全雙工、雙向的通信通道，通過(guò) Web 上的單個(gè)套接字進(jìn)行操作。

HTML5 Web Sockets 提供了一個(gè)真正的標(biāo)準(zhǔn)，可以使用它來(lái)構(gòu)建可擴(kuò)展的實(shí)時(shí) Web 應(yīng)用程序。此外，由于它提供了瀏覽器本地的套接字，因此避免了 Comet 解決方案容易出現(xiàn)的許多問(wèn)題。 Web Socket s移除了開(kāi)銷(xiāo)大幅度減輕了復(fù)雜度。

為了建立WebSocket連接，客戶(hù)端和服務(wù)器在首次握手時(shí)從 HTTP 協(xié)議升級(jí)到 WebSocket 協(xié)議，如下圖所示:

示例1 - WebSocket握手(瀏覽器請(qǐng)求和服務(wù)器響應(yīng))

熟悉 HTTP 的可能會(huì)發(fā)現(xiàn)，這段類(lèi)似 HTTP 協(xié)議的握手請(qǐng)求中，多了幾個(gè)東西：

Upgrade: websocket
Connection: Upgrade

這個(gè)就是 Websocket 的核心了，告訴 Apache 、 Nginx 等服務(wù)器：發(fā)起的是 Websocket協(xié)議，使用對(duì)應(yīng)的Websocket協(xié)議處理，而不是使用 HTTP 協(xié)議。

一旦建立，WebSocket 數(shù)據(jù)幀可以在客戶(hù)端和服務(wù)器之間以全雙工模式來(lái)回發(fā)送。文本和二進(jìn)制幀都可以發(fā)送全雙工，在同一時(shí)間向任意方向發(fā)送，數(shù)據(jù)的最小幀只有兩個(gè)字節(jié)。

在文本幀的情況下，每個(gè)幀以 0x00 元組開(kāi)頭，以 0xFF 元組結(jié)束，中間包含 UTF-8 數(shù)據(jù)，WebSocket 文本幀使用終止符，而二進(jìn)制幀使用長(zhǎng)度前綴。

注意:盡管 Web Sockets 協(xié)議已經(jīng)準(zhǔn)備好支持各種客戶(hù)端集，但是它不能將原始二進(jìn)制數(shù)據(jù)交付給 JavaScript，因?yàn)?JavaScript 不支持字節(jié)類(lèi)型。因此，如果客戶(hù)端是 Javascript 的，二進(jìn)制數(shù)據(jù)將被忽略 —— 但是可以把它發(fā)送給其它支持二進(jìn)制的客戶(hù)端。

那么在非必要的網(wǎng)絡(luò)傳輸和延遲性上究竟減少了多少？讓比較一下長(zhǎng)連接應(yīng)用和 WebSocket 應(yīng)用。

對(duì)于輪詢(xún)示例，我創(chuàng)建了一個(gè)簡(jiǎn)單的 Web 應(yīng)用程序，其中 Web 頁(yè)面使用傳統(tǒng)的發(fā)布/訂閱模型從RabbitMQ 消息隊(duì)列中獲取實(shí)時(shí)股票信息。

它通過(guò)輪詢(xún)駐留在 web 服務(wù)器上的 Java Servlet 來(lái)實(shí)現(xiàn)這一點(diǎn)。RabbitMQ 消息隊(duì)列從虛構(gòu)的持續(xù)改變股票價(jià)格的股票價(jià)格服務(wù)接收數(shù)據(jù)。

Web 頁(yè)面連接并訂閱特定的股票通道(message broker上的主題)，并使用 XMLHttpReques t每秒輪詢(xún)更新一次。當(dāng)接收到更新時(shí)，執(zhí)行一些計(jì)算，股票數(shù)據(jù)顯示在一個(gè)表中，如下圖所示。

注意：后臺(tái)股票服務(wù)實(shí)際上每秒會(huì)產(chǎn)生大量股票價(jià)格更新，因此每秒輪詢(xún)一次實(shí)際上比使用Comet 長(zhǎng)輪詢(xún)解決方案更為謹(jǐn)慎，后者會(huì)導(dǎo)致一系列持續(xù)輪詢(xún)，這里輪詢(xún)有效的節(jié)制了數(shù)據(jù)更新。

這一切看起來(lái)都很好，但從內(nèi)部看，這個(gè)應(yīng)用程序有一些嚴(yán)重的問(wèn)題。在 Mozilla Firefox 中使用 Firebug（一個(gè)火狐插件——可以對(duì)網(wǎng)頁(yè)進(jìn)行deb、跟蹤加載頁(yè)面和執(zhí)行腳本的時(shí)間），可以看到 GET 請(qǐng)求每隔一秒就會(huì)連接服務(wù)器。打開(kāi)Live HTTP Headers（另外一個(gè)火狐插件——可以顯示活躍 HTTP 頭傳輸）暴露了每一個(gè)連接上巨大數(shù)量的頭開(kāi)銷(xiāo)（header overhead）。下面的例子展示了一個(gè)請(qǐng)求和響應(yīng)的頭信息。

事例二：HTTP request header

事例三：HTTP response header

只是為了好玩，我數(shù)了數(shù)所有的字符?？偟?HTT P請(qǐng)求和響應(yīng)頭信息開(kāi)銷(xiāo)包含 871 字節(jié)，甚至不包括任何數(shù)據(jù) !當(dāng)然，這只是一個(gè)示例，可以擁有少于 871 字節(jié)的頭數(shù)據(jù)，但是我也看到過(guò)頭數(shù)據(jù)超過(guò) 2000 字節(jié)的情況。

在這個(gè)示例應(yīng)用程序中，典型股票標(biāo)題信息僅僅20個(gè)字符長(zhǎng)。正如所看到的，它實(shí)際上被過(guò)多的頭信息淹沒(méi)了，而頭信息甚至在一開(kāi)始就不是必需的!

那么當(dāng)你把這個(gè)應(yīng)用部署到大用戶(hù)量的場(chǎng)景下會(huì)怎么樣？ 讓我們?cè)谌齻€(gè)不同的場(chǎng)景中對(duì)比與此輪詢(xún)應(yīng)用程序關(guān)聯(lián)的 HTTP 請(qǐng)求和響應(yīng)頭數(shù)據(jù)的網(wǎng)絡(luò)吞吐量。

場(chǎng)景一：每秒 1000 個(gè)客戶(hù)端輪詢(xún)，每秒的網(wǎng)絡(luò)流量是 6.6 M。

場(chǎng)景二：每秒 10000 個(gè)客戶(hù)端輪詢(xún)，每秒的網(wǎng)絡(luò)流量是 66 M。

場(chǎng)景三：每秒 100000 個(gè)客戶(hù)端輪詢(xún)，每秒的網(wǎng)絡(luò)流量是 660 M。

這是大量不必要的網(wǎng)絡(luò)吞吐量，要是我們能通過(guò)網(wǎng)絡(luò)得到必要的數(shù)據(jù)就好了，此時(shí)就可以使用 HTML5 Web Sockets!

我重新構(gòu)建了應(yīng)用程序以使用 HTML5 Web Sockets，在 Web 頁(yè)面中添加了一個(gè)事件處理程序來(lái)異步偵聽(tīng)來(lái)來(lái)自于代理的股票更新信息。

。每一個(gè)信息都是一個(gè)WebSocket幀，只有兩個(gè)字節(jié)的開(kāi)銷(xiāo)(而不是871字節(jié))! 看看這如何影響我們的三個(gè)用例中的網(wǎng)絡(luò)吞吐量開(kāi)銷(xiāo)。

場(chǎng)景一：每秒 1000 個(gè)客戶(hù)端輪詢(xún)，每秒的網(wǎng)絡(luò)流量是 0.015 M。

場(chǎng)景二：每秒 10000 個(gè)客戶(hù)端輪詢(xún)，每秒的網(wǎng)絡(luò)流量是 0.153 M。

場(chǎng)景三：每秒 100000 個(gè)客戶(hù)端輪詢(xún)，每秒的網(wǎng)絡(luò)流量是 .1526 M。

如下圖所示，與輪詢(xún)解決方案相比，HTML5 Web Sockets大大減少了不必要的網(wǎng)絡(luò)流量。

那么延遲的減多少呢? 請(qǐng)看下圖：

在上半部分，可以看到半雙工輪詢(xún)解決方案的延遲。在本例中，假設(shè)消息從服務(wù)器傳輸?shù)綖g覽器需要50毫秒，那么輪詢(xún)應(yīng)用程序?qū)⒁氪罅款~外的延遲，因?yàn)樵陧憫?yīng)完成時(shí)必須將新請(qǐng)求發(fā)送到服務(wù)器。這個(gè)新請(qǐng)求需要另一個(gè)50ms，在此期間服務(wù)器不能向?yàn)g覽器發(fā)送任何消息，從而導(dǎo)致額外的服務(wù)器內(nèi)存消耗。

在圖的下半部分，可以看到 WebSocket 解決方案降低了延遲。一旦連接升級(jí)到 WebSocket，消息就可以在到達(dá)時(shí)從服務(wù)器流到瀏覽器。消息從服務(wù)器傳輸?shù)綖g覽器仍然需要 50 毫秒，但是WebSocket 連接仍然打開(kāi)，因此不需要向服務(wù)器發(fā)送另一個(gè)請(qǐng)求。

HTML5 Web Sockets 在實(shí)時(shí)網(wǎng)絡(luò)的擴(kuò)展性上向前邁出了一大步。正如在本文中看到的， HTML5 Web Sockets可以提供 500：1 甚至 1000：1 的非必要HTTP頭信息傳輸?shù)淖兩伲约?3：1 延遲性的降低。這不僅僅是個(gè)進(jìn)步，它是巨大的一個(gè)飛躍!

原文：

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

你的點(diǎn)贊是我持續(xù)分享好東西的動(dòng)力，歡迎點(diǎn)贊！

干貨系列文章匯總?cè)缦?，覺(jué)得不錯(cuò)點(diǎn)個(gè)Star，歡迎 加群 互相學(xué)習(xí)。

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

我是小智，公眾號(hào)「大遷世界」作者，對(duì)前端技術(shù)保持學(xué)習(xí)愛(ài)好者。我會(huì)經(jīng)常分享自己所學(xué)所看的干貨，在進(jìn)階的路上，共勉！

關(guān)注公眾號(hào)，后臺(tái)回復(fù)福利，即可看到福利，你懂的。