摘要:握手客戶端向服務端發起連接請求如圖,我們在請求服務器的時候,發送了這樣的。如圖下面解釋下字段的含義協議升級成功服務端處理之后的協議版本號協議升級為至此,握手成功下面就盡情的傳輸數據吧數據傳輸數據傳輸需要客戶端,沒什么好說的了。
一、閱前熱身 什么是keep-alive 1、keep-alive只是客戶端的一種建議
我們打開百度首頁,進一步查看header。
如圖,我們看到請求header中有一行:
Connection:keep-alive
keep-alive是通知服務器,在這個HTTP Request/Responset結束后,不要立即斷開TCP連接(注意是TCP連接,和HTTP沒有關系),后面的HTTP Request仍然可以通過這個TCP連接繼續傳送。
但是!這只是個建議,服務器可能不支持,也可能忽略掉這個建議。也可能因為時間太久而直接斷開TCP連接
通俗點解釋就是:keep-alive只是通知服務器,您先別掛,一會兒可能還有活兒,至于它掛不掛還是看它心情。
所以,keep-alive只是客戶端建議的一種復用TCP連接的方式,至于服務器支持不支持,就由不得客戶端了。
2、keep-alive只是http協議中的一部分keep-alive是http協議中的一部分,也即客戶端可以主動的發起request到服務器,服務器只能被動的response給客戶端。
二、服務器的消息如何發給客戶端我要想實現服務器主動的push消息給客戶端,keep-alive是無能無力的。
long long ago~ 服務器端要想主動的push消息給客戶端(比如網頁聊天室消息的即時收發),這是不可能滴。
但是,我可以使用ajax輪詢、long poll 技術造一個服務端給客戶端主動push消息的假象。
ajax輪詢的原理非常簡單,讓瀏覽器隔個幾秒就發送一次請求,詢問服務器是否有新信息。
場景再現:
客戶端:啦啦啦,有沒有新信息(Request) 服務端:沒有(Response) 客戶端:啦啦啦,有沒有新信息(Request) 服務端:沒有。。(Response) 客戶端:啦啦啦,有沒有新信息(Request) 服務端:你好煩啊,沒有啊。。(Response) 客戶端:啦啦啦,有沒有新消息(Request) 服務端:好啦好啦,有啦給你。(Response) 客戶端:啦啦啦,有沒有新消息(Request) 服務端:。。。。。沒。。。。沒。。。沒有(Response) ---- loop
但是這樣,有沒有發現,大大增加了服務端的負載,并且速度還慢。
②:什么是long poll?long poll和ajax差不多,原理都是采用輪詢的方式。只不過long poll是采取的阻塞的方式去輪詢。
也即客戶端發起一個請求連接,這個連接會阻塞住,直到服務端有了消息,才會response給客戶端。
注:阻塞、非阻塞的理解,請參考我之前的文章:nginx、swoole高并發原理初探
場景再現:
客戶端:啦啦啦,有沒有新信息,沒有的話就等有了才返回給我吧(Request) 服務端:額。。 等待到有消息的時候。。來 給你(Response) 客戶端:啦啦啦,有沒有新信息,沒有的話就等有了才返回給我吧(Request) -loop
long pull 雖然降低了服務器的負載,但是需要服務器有很高的并發能力才可以。
而目前處理高并發的模型基本都是異步非阻塞的模型(比如nginx)。
既想阻塞,又想高并發,幾乎不可能。
③:總結ajax輪詢、long poll技術雖然都能實現服務端消息的實時通知,但是各有缺點,都不是根本的解決辦法。
計算機界急需一種新的技術去處理這些需求~
既然ajax輪詢、long poll都不怎么樣。我們發明一種新的協議吧!
Websocket協議解決了服務器與客戶端全雙工通信的問題。
注:什么是單工、半雙工、全工通信?
信息只能單向傳送為單工;
信息能雙向傳送但不能同時雙向傳送稱為半雙工;
信息能夠同時雙向傳送則稱為全雙工。
wensocket協議包含兩部分:一部分是“握手”,一部分是“數據傳輸”。
為了便于演示,我們采用swoole建立一個websocket服務器來演示。
①客戶端向服務端發起連接請求
如圖,我們在請求服務器的時候,發送了這樣的request header。
下面我們就一些比較重要的字段信息進行說明:
Connection:Upgrade #通知服務器協議升級 Upgrade:websocket #協議升級為websocket協議 Host:0.0.0.0:9501 #升級協議的服務主機:端口地址 Sec-WebSocket-Key:K8o1cNIxO2pR6inTIDBSgg== #傳輸給服務器的key Sec-WebSocket-Version:13 #websocket協議版本13
Sec-WebSocket-Key有什么用呢?
客戶端將這個key發送給服務器,服務器將這個key進行處理,將處理后的key返回給客戶端,客戶端根據這個key是否正確來判斷是否建立連接。
②:服務端返回握手應答
如圖,我們看到websocket協議狀態碼是101.
101表示協議切換成功。
我們查看websocket的response header。如圖:
下面解釋下reponse header字段的含義
Connection:Upgrade #協議升級成功 Sec-WebSocket-Accept:GnoYH/ip/ZMh+a5rX5P/YR6e68g= #服務端處理之后的key Sec-WebSocket-Version:13#websocket 協議版本號 Upgrade:websocket#協議升級為websocket
至此,websocket握手成功!下面就盡情的傳輸數據吧!
2、數據傳輸數據傳輸需要客戶端,沒什么好說的了。
Chrome/Firefox/高版本IE/Safari等瀏覽器內置了JS語言的WebSocket客戶端
可以使用一些擴展來實現websocket客戶端。如php的swoole、workerman。
四、參考文章注意:非WebSocket客戶端不能與WebSocket服務器通信
Websocket協議之握手連接
WebSocket 是什么原理?為什么可以實現持久連接?
更多精彩,請關注公眾號“聊聊代碼”,讓我們一起聊聊“左手代碼右手詩”的事兒。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/22081.html
摘要:面向消息的簡單文本協議。為提供了備選方案。但無論哪種場景,對于實際應用來說,這種通信形式層級過低。協議,來為瀏覽器和間的通信增加適當的消息語義。協議解決了瀏覽器發起請求以及服務器響應請求的細節,假設協議并不存在,只能使用套接字來編寫應用。 最近有項目需求要用到websocket,剛開始以為很簡單,但是隨著遇到問題,深入了解,才知道websocket并不是想象中的那么簡單,這篇文章主要是...
摘要:面向消息的簡單文本協議。為提供了備選方案。但無論哪種場景,對于實際應用來說,這種通信形式層級過低。協議,來為瀏覽器和間的通信增加適當的消息語義。協議解決了瀏覽器發起請求以及服務器響應請求的細節,假設協議并不存在,只能使用套接字來編寫應用。 最近有項目需求要用到websocket,剛開始以為很簡單,但是隨著遇到問題,深入了解,才知道websocket并不是想象中的那么簡單,這篇文章主要是...
摘要:面向消息的簡單文本協議。為提供了備選方案。但無論哪種場景,對于實際應用來說,這種通信形式層級過低。協議,來為瀏覽器和間的通信增加適當的消息語義。協議解決了瀏覽器發起請求以及服務器響應請求的細節,假設協議并不存在,只能使用套接字來編寫應用。 最近有項目需求要用到websocket,剛開始以為很簡單,但是隨著遇到問題,深入了解,才知道websocket并不是想象中的那么簡單,這篇文章主要是...
閱讀 4122·2022-09-16 13:49
閱讀 1398·2021-11-22 15:12
閱讀 1519·2021-09-09 09:33
閱讀 1039·2019-08-30 13:15
閱讀 1720·2019-08-29 15:30
閱讀 654·2019-08-27 10:52
閱讀 2643·2019-08-26 17:41
閱讀 1896·2019-08-26 12:11