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

我們打開(kāi)百度首頁(yè)，進(jìn)一步查看header。

如圖，我們看到請(qǐng)求header中有一行：

Connection:keep-alive

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

但是！這只是個(gè)建議，服務(wù)器可能不支持，也可能忽略掉這個(gè)建議。也可能因?yàn)闀r(shí)間太久而直接斷開(kāi)TCP連接

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

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

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

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

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

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

場(chǎng)景再現(xiàn)：

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

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

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

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

場(chǎng)景再現(xiàn)：

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

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

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

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

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

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

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

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

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

如圖，我們?cè)谡?qǐng)求服務(wù)器的時(shí)候，發(fā)送了這樣的request header。

下面我們就一些比較重要的字段信息進(jìn)行說(shuō)明：

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

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

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

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

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

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

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

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

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

數(shù)據(jù)傳輸需要客戶(hù)端，沒(méi)什么好說(shuō)的了。

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

可以使用一些擴(kuò)展來(lái)實(shí)現(xiàn)websocket客戶(hù)端。如php的swoole、workerman。

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

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

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