摘要：握手客戶端向服務(wù)端發(fā)起連接請求如圖，我們在請求服務(wù)器的時候，發(fā)送了這樣的。如圖下面解釋下字段的含義協(xié)議升級成功服務(wù)端處理之后的協(xié)議版本號協(xié)議升級為至此，握手成功下面就盡情的傳輸數(shù)據(jù)吧數(shù)據(jù)傳輸數(shù)據(jù)傳輸需要客戶端，沒什么好說的了。

我們打開百度首頁，進一步查看header。

如圖，我們看到請求header中有一行：

Connection:keep-alive

keep-alive是通知服務(wù)器，在這個HTTP Request/Responset結(jié)束后，不要立即斷開TCP連接（注意是TCP連接，和HTTP沒有關(guān)系），后面的HTTP Request仍然可以通過這個TCP連接繼續(xù)傳送。

但是！這只是個建議，服務(wù)器可能不支持，也可能忽略掉這個建議。也可能因為時間太久而直接斷開TCP連接

通俗點解釋就是：keep-alive只是通知服務(wù)器，您先別掛，一會兒可能還有活兒，至于它掛不掛還是看它心情。

所以,keep-alive只是客戶端建議的一種復(fù)用TCP連接的方式，至于服務(wù)器支持不支持，就由不得客戶端了。

keep-alive是http協(xié)議中的一部分，也即客戶端可以主動的發(fā)起request到服務(wù)器，服務(wù)器只能被動的response給客戶端。

我要想實現(xiàn)服務(wù)器主動的push消息給客戶端，keep-alive是無能無力的。

long long ago~ 服務(wù)器端要想主動的push消息給客戶端(比如網(wǎng)頁聊天室消息的即時收發(fā))，這是不可能滴。
但是，我可以使用ajax輪詢、long poll 技術(shù)造一個服務(wù)端給客戶端主動push消息的假象。

ajax輪詢的原理非常簡單，讓瀏覽器隔個幾秒就發(fā)送一次請求，詢問服務(wù)器是否有新信息。

場景再現(xiàn)：

客戶端：啦啦啦，有沒有新信息(Request)
服務(wù)端：沒有（Response）
客戶端：啦啦啦，有沒有新信息(Request)
服務(wù)端：沒有。。（Response）
客戶端：啦啦啦，有沒有新信息(Request)
服務(wù)端：你好煩啊，沒有啊。。（Response）
客戶端：啦啦啦，有沒有新消息（Request）
服務(wù)端：好啦好啦，有啦給你。（Response）
客戶端：啦啦啦，有沒有新消息（Request）
服務(wù)端：。。。。。沒。。。。沒。。。沒有（Response） ---- loop

但是這樣，有沒有發(fā)現(xiàn)，大大增加了服務(wù)端的負載，并且速度還慢。

long poll和ajax差不多，原理都是采用輪詢的方式。只不過long poll是采取的阻塞的方式去輪詢。
也即客戶端發(fā)起一個請求連接，這個連接會阻塞住，直到服務(wù)端有了消息，才會response給客戶端。

注：阻塞、非阻塞的理解，請參考我之前的文章：nginx、swoole高并發(fā)原理初探

場景再現(xiàn)：

客戶端：啦啦啦，有沒有新信息，沒有的話就等有了才返回給我吧（Request）
服務(wù)端：額。。 等待到有消息的時候。。來 給你（Response）
客戶端：啦啦啦，有沒有新信息，沒有的話就等有了才返回給我吧（Request） -loop

long pull 雖然降低了服務(wù)器的負載，但是需要服務(wù)器有很高的并發(fā)能力才可以。
而目前處理高并發(fā)的模型基本都是異步非阻塞的模型(比如nginx)。

既想阻塞，又想高并發(fā)，幾乎不可能。

ajax輪詢、long poll技術(shù)雖然都能實現(xiàn)服務(wù)端消息的實時通知，但是各有缺點，都不是根本的解決辦法。
計算機界急需一種新的技術(shù)去處理這些需求~

既然ajax輪詢、long poll都不怎么樣。我們發(fā)明一種新的協(xié)議吧！

Websocket協(xié)議解決了服務(wù)器與客戶端全雙工通信的問題。

注:什么是單工、半雙工、全工通信？
信息只能單向傳送為單工；
信息能雙向傳送但不能同時雙向傳送稱為半雙工；
信息能夠同時雙向傳送則稱為全雙工。

wensocket協(xié)議包含兩部分:一部分是“握手”，一部分是“數(shù)據(jù)傳輸”。
為了便于演示，我們采用swoole建立一個websocket服務(wù)器來演示。

①客戶端向服務(wù)端發(fā)起連接請求

如圖，我們在請求服務(wù)器的時候，發(fā)送了這樣的request header。

下面我們就一些比較重要的字段信息進行說明：

Connection:Upgrade #通知服務(wù)器協(xié)議升級
Upgrade:websocket  #協(xié)議升級為websocket協(xié)議
Host:0.0.0.0:9501  #升級協(xié)議的服務(wù)主機:端口地址
Sec-WebSocket-Key:K8o1cNIxO2pR6inTIDBSgg== #傳輸給服務(wù)器的key
Sec-WebSocket-Version:13 #websocket協(xié)議版本13

Sec-WebSocket-Key有什么用呢？
客戶端將這個key發(fā)送給服務(wù)器，服務(wù)器將這個key進行處理，將處理后的key返回給客戶端，客戶端根據(jù)這個key是否正確來判斷是否建立連接。

②：服務(wù)端返回握手應(yīng)答

如圖，我們看到websocket協(xié)議狀態(tài)碼是101.

101表示協(xié)議切換成功。

我們查看websocket的response header。如圖：

下面解釋下reponse header字段的含義

Connection:Upgrade #協(xié)議升級成功
Sec-WebSocket-Accept:GnoYH/ip/ZMh+a5rX5P/YR6e68g= #服務(wù)端處理之后的key
Sec-WebSocket-Version:13#websocket 協(xié)議版本號
Upgrade:websocket#協(xié)議升級為websocket

至此，websocket握手成功！下面就盡情的傳輸數(shù)據(jù)吧！

數(shù)據(jù)傳輸需要客戶端，沒什么好說的了。

Chrome/Firefox/高版本IE/Safari等瀏覽器內(nèi)置了JS語言的WebSocket客戶端

可以使用一些擴展來實現(xiàn)websocket客戶端。如php的swoole、workerman。

注意：非WebSocket客戶端不能與WebSocket服務(wù)器通信

Websocket協(xié)議之握手連接
WebSocket 是什么原理？為什么可以實現(xiàn)持久連接？

更多精彩，請關(guān)注公眾號“聊聊代碼”，讓我們一起聊聊“左手代碼右手詩”的事兒。