有了 HTTP 協(xié)議，為什么還需要 Websocket？
WebSocket 是一種基于 TCP 連接上進(jìn)行全雙工通信的協(xié)議，相對于 HTTP 這種非持久的協(xié)議來說，WebSocket 是一個持久化網(wǎng)絡(luò)通信的協(xié)議。
它不僅可以實(shí)現(xiàn)客戶端請求服務(wù)器，同時可以允許服務(wù)端主動向客戶端推送數(shù)據(jù)。在 WebSocket API 中，客戶端和服務(wù)器只需要完成一次握手，兩者之間就直接可以創(chuàng)建持久性的連接，并進(jìn)行雙向數(shù)據(jù)傳輸。
為什么需要 WebSocket
在 Web 應(yīng)用架構(gòu)中，連接由 HTTP/1.0 和 HTTP/1.1 處理。HTTP 是客戶端/服務(wù)器模式中 請求一響應(yīng) 所用的協(xié)議，在這種模式中，客戶端(一般是瀏覽器)向服務(wù)器提交 HTTP 請求，服務(wù)器響應(yīng)請求的資源(例如 HTML 頁面)。
HTTP 是無狀態(tài)的，也就是說，它將每個請求當(dāng)成唯一和獨(dú)立的。無狀態(tài)協(xié)議具有一些優(yōu)勢，例如，服務(wù)器不需要保存有關(guān)會話的信息，從而不需要存儲數(shù)據(jù)。但是，這也意味著在每次 HTTP 請求和響應(yīng)中都會發(fā)送關(guān)于請求的冗余信息，比如使用 Cookie 進(jìn)行用戶狀態(tài)的驗(yàn)證。
隨著客戶端和服務(wù)器之間交互的增加，HTTP 協(xié)議在客戶端和服務(wù)器之間通信所需要的信息量快速增加。
從根本上講，HTTP 還是 半雙工 的協(xié)議，也就是說，在同一時刻信息的流向只能單向的：客戶端向服務(wù)器發(fā)送請求(單向)，然后服務(wù)器響應(yīng)請求(單向)。半雙工方式的通信效率是非常低的。
同時 HTTP 協(xié)議有一個缺陷：通信只能由客戶端發(fā)起。
這種單向請求的特點(diǎn)，注定了如果服務(wù)器有狀態(tài)變化，是無法主動通知客戶端的。
為了能夠及時的獲取服務(wù)器的變化，我們嘗試過各種各樣的方式：
- 輪詢(polling)：每隔一段時間，就發(fā)出一個請求，了解服務(wù)器有沒有新的信息。不精準(zhǔn)，有延時，大量無效數(shù)據(jù)交換。
- 長輪詢( long polling)：客戶端向服務(wù)器請求信息，并在設(shè)定的時間段內(nèi)保持連接。直到服務(wù)器有新消息響應(yīng)，或者連接超時，這種技術(shù)常常稱作“掛起GET”或“擱置POST”。占用服務(wù)器資源，相對輪詢并沒有優(yōu)勢，沒有標(biāo)準(zhǔn)化。
- 流化技術(shù)：在流化技術(shù)中，客戶端發(fā)送一個請求，服務(wù)器發(fā)送并維護(hù)一個持續(xù)更新和保持打開(可以是無限或者規(guī)定的時間段)的開放響應(yīng)。每當(dāng)服務(wù)器有需要交付給客戶端的信息時，它就更新響應(yīng)。服務(wù)器從不發(fā)出完成 HTTP 響應(yīng)。代理和防火墻可能緩存響應(yīng)，導(dǎo)致信息交付的延遲增加。
上述方法提供了近乎實(shí)時的通信，但是它們也涉及 HTTP 請求和響應(yīng)首標(biāo)，包含了許多附加和不必要的首標(biāo)數(shù)據(jù)與延遲。此外，在每一種情況下，客戶端都必須等待請求返回，才能發(fā)出后續(xù)的請求，而這顯著地增加了延退。同時也極大地增加了服務(wù)器的壓力。
什么是 WebSocket
而 Websocket 是一種自然的全雙工、雙向、單套接字連接，解決了 HTTP 協(xié)議中不適合于實(shí)時通信的問題。2008 年被提出，2011 年成為國際標(biāo)準(zhǔn)。
Websocket 協(xié)議能夠通過 Web 進(jìn)行客戶端和服務(wù)器之間的全雙工通信，并支持二進(jìn)制數(shù)據(jù)和文本字符串的傳輸。
這個協(xié)議由開始的握手和之后的基本消息框架組成，是建立在 TCP 協(xié)議上的。相比于 HTTP 協(xié)議，Websocket 鏈接一旦建立，即可進(jìn)行雙向的實(shí)時通信。
其特點(diǎn)包括：
(1)建立在 TCP 協(xié)議之上，服務(wù)器端的實(shí)現(xiàn)比較容易。
(2)與 HTTP 協(xié)議有著良好的兼容性。默認(rèn)端口也是 80 和 443，并且握手階段采用 HTTP 協(xié)議，因此握手時不容易屏蔽，能通過各種 HTTP 代理服務(wù)器。
(3)數(shù)據(jù)格式比較輕量，性能開銷小，通信高效。
(4)可以發(fā)送文本，也可以發(fā)送二進(jìn)制數(shù)據(jù)。
(5)沒有同源限制，客戶端可以與任意服務(wù)器通信。
相似技術(shù)
Server-sent Events(SSE)：
https://www.ruanyifeng.com/blog/2017/05/server-sent_events.html
https://www.cnblogs.com/goloving/p/9196066.html
SPDY (讀作“SPeeDY”)：已不再維護(hù)，由 HTTP/2 取代
https://baike.baidu.com/item/SPDY/3399551#7
WebRTC
https://baike.baidu.com/item/WebRTC/5522744
通信原理
WebSocket 鏈接是如何建立的?
前面說過，WebSocket 在握手階段采用的是 HTTP 協(xié)議，Websocket 借用了 HTTP 的一部分協(xié)議來完成一次握手。(HTTP的三次握手，此處只完成一次)
HTTP 請求與響應(yīng)首部
WebSocket 請求與響應(yīng)首部
鏈接通信模擬
HTTP 輪詢
首先是 ajax 輪詢，其原理非常簡單，讓瀏覽器隔個幾秒就發(fā)送一次請求，詢問服務(wù)器是否有新信息。
場景再現(xiàn)：
- 客戶端：啦啦啦，有沒有新信息(Request)
- 服務(wù)端：沒有(Request)
- 客戶端：啦啦啦，有沒有新信息(Request)
- 服務(wù)端：沒有。。(Response)
- 客戶端：啦啦啦，有沒有新信息(Request)
- 服務(wù)端：你好煩啊，沒有啊。。(Response)
- 客戶端：啦啦啦，有沒有新消息(Request)
- 服務(wù)端：好啦好啦，有啦給你 ' 西嶺真帥' 。(Response)
- 客戶端：啦啦啦，有沒有新消息(Request)
- 服務(wù)端：。。。沒。。。。沒。。沒有
從上面可以看出，輪詢其實(shí)就是在不斷地建立HTTP連接，然后等待服務(wù)端處理，可以體現(xiàn) HTTP 協(xié)議的另外一個特點(diǎn)，被動性。同時，http 的每一次請求與響應(yīng)結(jié)束后，服務(wù)器將客戶端信息全部丟棄，下次請求，必須攜帶身份信息(cookie)，無狀態(tài)性。
WebSocket
客戶端通過 http(騎馬)帶著信請求服務(wù)器，但同時，攜帶了 Upgrade:websocket 和Connection:Upgrade(兩根管子)，服務(wù)器如果支持 WebSocket 協(xié)議(有兩根管子的接口)，使用 Websocket 協(xié)議返回可用信息(丟棄馬匹)，此后信息的傳遞，均使用這兩個管子，除非有一方人為的將管子切斷。若服務(wù)器不支持，客戶端請求鏈接失敗，返回錯誤信息。
Websocket 的出現(xiàn)，干凈利落的解決了這些問題。
所以上面的情景可以做如下修改。
- 客戶端：啦啦啦，我要建立 Websocket 協(xié)議，需要的服務(wù)：chat，Websocket協(xié)議版本：13(HTTP Request)
- 服務(wù)端：ok，確認(rèn)，已升級為 Websocket協(xié)議(HTTP Protocols Switched)
- 客戶端：麻煩你有信息的時候推送給我噢。。
- 服務(wù)端：ok，有的時候會告訴你的。
- 客戶端：balabala開始斗圖balabala
- 服務(wù)端：蒼*空bala
- 客戶端：流鼻血了，我擦……
- 服務(wù)端：哈哈哈牛XX啊哈哈哈哈
- 服務(wù)端：笑死我了哈哈
本文轉(zhuǎn)載自微信公眾號「勾勾的前端世界」
