摘要：是個不太干凈協(xié)議。目前此協(xié)議的受眾的也不僅僅是開發(fā)者。借助協(xié)議進行握手，握手成功后，就會變身為通道，從此與不再相見。如此操作，可以盡量避免普通請求被誤認為協(xié)議。它包含四個事件和兩個動作發(fā)送和關閉。有類似協(xié)議的幀格式，在此不做過多解釋。

WebSocket是一種比較新的協(xié)議，它是伴隨著html5規(guī)范而生的，雖然還比較年輕，但大多主流瀏覽器都已經(jīng)支持。它使用方面、應用廣泛，已經(jīng)滲透到前后端開發(fā)的各種場景中。

對http一問一答中二式流程的不滿，催生了支持雙向通信的WebSocket誕生。WebSocket是個不太干凈協(xié)議。

不是。目前此協(xié)議的受眾的也不僅僅是web開發(fā)者。

WebSocket只是一種協(xié)議，它和http協(xié)議一樣，使用類似okhttp的組件，可以在任何地方進行調(diào)用，甚至可以借助WebSocket實現(xiàn)RPC框架。

WebSocket和http一樣，都是處于OSI模型中的最高層：應用層。
WebSocket借助http協(xié)議進行握手，握手成功后，就會變身為TCP通道，從此與http不再相見。

使用netstat或者ss，能夠看到對應的連接，它與處于抽象層的socket，在外觀上沒有區(qū)別。

長輪詢，就是客戶端發(fā)送一個請求，服務端將一直在這個連接上等待（當然有一個超長的超時時間），直到有數(shù)據(jù)才返回，它依然是一個一問一答的模式。比如著名的comted。

WebSocket在握手成功后，就是全雙工的TCP通道，數(shù)據(jù)可以主動從服務端發(fā)送到客戶端，處于鏈接兩端的應用沒有任何區(qū)別。

WebSocket創(chuàng)建的連接和Http的長連接是不一樣的。由于Http長連接底層依然是Http協(xié)議，所以它還是一問一答，只是Hold住了一條命長點的連接而已。

長輪詢和Http長連接是阻塞的I/O，但WebSocket可以是非阻塞的（具體是多路復用）。

WebSocket的連接創(chuàng)建是借助Http協(xié)議進行的。這樣設計主要是考慮兼容性，在瀏覽器中就可以很方便的發(fā)起請求，看起來比較具有迷惑性。

下圖是一個典型的由瀏覽器發(fā)起的ws請求，可以看到和http請求長的是非常相似的。但是，它只是請求階段長得像而已：

請求的地址，一般是：ws://***，或者是使用了SSL/TLS加密的安全協(xié)議wss:，用來標識是WebSocket請求。

1、 首先，通過Http頭里面的Upgrade域，請求進行協(xié)議轉換。如果服務端支持的話，就可以切換到WebSocket協(xié)議。簡單點講：連接已經(jīng)在那了，通過握手切換成ws協(xié)議，就是切換了連接的一個狀態(tài)而已。

1、Connection域可以認為是與Upgrade域配對的頭信息。像nginx等代理服務器，是要先處理Connection，然后再發(fā)起協(xié)議轉換的。

Sec-WebSocket-Key 是隨機的字符串，服務器端會用這些數(shù)據(jù)來構造出一個 SHA-1 的信息摘要。如此操作，可以盡量避免普通 HTTP 請求被誤認為 WebSocket 協(xié)議。

其他的，像Sec-WebSocket*字樣的頭信息，表明了客戶端支持的子協(xié)議以及其他信息。像loT中很流行的mqtt，就可以作為WebSocket的子協(xié)議。

使用javascript，可以很容易連接一個WebSocket服務端。

WebSocket是通過事件通知的方式運行的。它包含四個事件和兩個動作（發(fā)送和關閉）。

WebSocket的事件

數(shù)據(jù)可直接通過Socket.send()方法進行傳輸。

通過chrome的Inspect->Network->WS，可以看到頁面上的WebSocket連接。如圖Opcode為2，表明它是一個二進制幀。

WebSocket有類似tcp協(xié)議的幀格式，在此不做過多解釋。

參考：(https://tools.ietf.org/html/r...

心跳對應的ping、pong操作，opcode分別是0x9、0xA。收到心跳的一方需要自行更新心跳的更新時間。同使用Netty，我們到底在開發(fā)些什么？介紹的類似，在一些移動環(huán)境中，需要更加智能的控制心跳。

nginx官網(wǎng)已經(jīng)給出了例子。主要是Upgrade和Connection頭的設置。

map $http_upgrade $connection_upgrade {
    default upgrade;
    "" close;
}

location /chat/ {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
}

需要注意的是，nginx做負載均衡，不需要配置ip_hash等參數(shù)，nginx天然支持。由于ip_hash僅使用ip地址的前三個數(shù)字做hash，還有可能造成服務端的不均衡。

可以實現(xiàn)javax.WebSocket下的包，簡單的實現(xiàn)ws服務端。目前基本可以通過注解的方式去編寫代碼，比如ServerEndpoint。

推薦使用基于netty的netty-socketio進行服務端的編寫。由于使用的是netty，所以能夠在多個層面進行切入，獲取一些統(tǒng)計數(shù)據(jù)，執(zhí)行一些控制指令。socketio是一套解決方案，它有多個語言的客戶端，并處理了市面上大多數(shù)的兼容問題。

保持一個長連接，當服務端游新的消息，能夠實時的推送到使用方。像知乎的點贊通知、評論等，都可以使用WebSocket通信。

某些使用H5的客戶端，為了簡化開發(fā)，也會使用WebSocket進行消息的通知，由于它是實時推送的，會有更好的用戶體驗。

一些次優(yōu)級別的數(shù)據(jù)，比如行為日志、trace、異常執(zhí)棧收集等，都可以開辟專門的WebSocket通道進行傳輸。這能夠增加信息的集中度，并能及時的針對用戶的行為進行合適的配置推送。由于大多數(shù)瀏覽器內(nèi)核都支持，它將使客戶端APM編程模型變得簡單。

雖然使用Fiddler、Charles等能夠抓到很多WebSocket包。但如果同時開啟SSL，傳輸加密后的二進制數(shù)據(jù)，會大幅增加破解的成本，會安全的多。

這個...由于是雙工長連接，服務端完全可以推送一些鉤子命令，甚至直接是代碼，在客戶端進行執(zhí)行。比如截個屏，錄個音，種個小馬。用戶只要通過了授權申請，剩下的就隨你發(fā)揮了。

支付寶偷偷調(diào)用你的相機給你拍照的梗，我是相信的。

想當年，cometd的出現(xiàn)，驚為天人，振奮了很久。但技術日新月異，cometd已經(jīng)衰老，而Socket.io得到了快速發(fā)展。WebSocket經(jīng)過一段時間的混沌期，規(guī)范已經(jīng)越來越完善，使用也越來越方便，不需要再處理那么多的兼容。

但它的本質，還是新瓶裝舊酒，換湯不換藥。WebSocket的發(fā)展得益于HTML5規(guī)范的制定。規(guī)范的意義，就是約束廠商們天馬行空的實現(xiàn)，以及指明發(fā)展的方向。

這當然有典型的反例，那就是ie?，F(xiàn)在，只有一群公認的**，還堅持在用。