websocket原理

摘抄並用於自查

 

1. WebSocket 與 HTTP

　　websocket 協議在 2008 年誕生，2011年成爲國際標準。如今全部瀏覽器都已經支持了。Websocket 的最大特色是，服務器能夠主動向客戶端推送消息，客戶端也能夠主動向服務器發送消息，是真正的雙向平等對話。

　　HTTP 有 1.1 和 1.0 只說，也就是所謂的 keep-alive，把多個 HTTP 請求合併爲一個，可是 Websocket 實際上是一個新協議，跟 HTTP 協議基本沒有關係，只是爲了兼容現有瀏覽器，因此在握手階段使用了 HTTP。

　　下面偷一張圖說明 HTTP 和 Websocket 的主要區別：

 

Websocket 的其餘特色：

• 創建在 TCP 協議之上，服務端的實現比較容易。
• 與 HTTP 協議有着良好的兼容性。默認端口也是 80 和 443，而且握手階段採用 HTTP 協議，所以握手時不容易被屏蔽，能經過各類 HTTP 代理服務器。
• 數據格式比較輕量，性能開銷小，通訊高效。
• 能夠發送文本，也能夠發送二進制數據。
• 沒有同源限制，客戶端能夠與任意服務器通訊。
• 協議標識符是 ws （若是加密，則爲 wss），服務器網址就是 URL。

 

2. WebSocket 是什麼樣的協議，具體有什麼優勢

　　首先，WebSocket 是一個持久化的協議，相對於 HTTP 這種非持久的協議來講。

　　HTTP 的生命週期經過 Request 來界定，也就是一個 Request 一個 Response，那麼在 HTTP1.0 中，此次 HTTP 請求就結束了。

 

　　在 HTTP1.1 中有改進，使得有一個 keep-alive，也就是說，在一個 HTTP 鏈接中，能夠發送多個 Request，接收多個 Response。可是，Request = Response，在 HTTP 中永遠是一個 Request 對應一個 Response。並且這個 Response 也是被動的，不能主動發起。

 

　　WebSocket 是基於 HTTP 協議，借用 HTTP 協議完成一部分握手。

 

　　下面一個典型的 WebSocket 握手

　　GET /chat HTTP/1.1

　　Host: server.xxx.com

　　Upgrade:websocket

　　Connection:Upgrade

　　Sec-WebSocket-Key: xxxxxxx

　　Sec-WebSocket-Protacal:chat, superchat

　　Sec-WebSocket-Version:13

　　Origin: http://xxx.com

 

　　這段相比 HTTP 協議的握手請求，多了 Upgrade 和 Connection。這個就是 WebSocket 的核心了，告訴 Apache、Nginx 等服務器：我發起的請求要用 WebSocket 協議，須要對應的處理。

 

　　Sec-WebSocket-Key: xxxx

　　Sec-WebSocket-Protocol:chat, superchat

　　Sec-WebSocket-Version:13

 

　　首先，Sec-WebSocket-Key 是一個 Base64 encode 的值，這個是瀏覽器隨機生成的，驗證是不是能夠處理 WebSocket 服務的。

　　而後， Sec-WebSocket-Protocol 是一個用戶自定義的字符串，用來區分同 URL 下，不一樣的服務所須要的協議。

　　最後，Sec-WebSocket-Version 是高速服務器所使用的 WebSocket 的協議版本。在最初的時候 WebSocket 協議有不少種，各瀏覽器都不一樣，如今你們都使用同一版本。

 

　　而後服務器會返回下列東西，表示已經接受到請求，成功創建 WebSocket。

　　HTTP/1.1 101 Switching Protocols

　　Upgrade: websocket

　　Connection: Upgrade

　　Sec-WebSocket-Accept:xxxxxxxx

　　Sec-WebSocket-Protocol:chat

　　這裏就是 HTTP 最後負責的區域，告訴客戶，已經成功切換協議。

　　Sec-WebSocket-Protocol 是通過服務器確認，而且加密事後的 Sec-WebSocket-key 。

　　Sec-WebSocket-Protocol 表示最終使用的協議、

　　至此，HTTP 已經完成了它全部的工做，接下來就是徹底按照 WebSocket 協議進行了。

 

3. WebSocket 的做用

 

　　前奏

　　ajax 輪詢：其原理是，讓瀏覽器每隔幾秒就發送一次請求，詢問服務器是否有新的信息

　　long poll：其原理和 ajax 輪詢差很少，都是採用輪詢的方式，不過採起的是阻塞模型（一直打電話，沒收到就不掛電話），也就是說，客戶端發起請求後，若是沒消息，就一直不返回 Response 給客戶端。直到有消息才返回，返回完以後，客戶端再次創建鏈接，周而復始。

　　從上面能夠看出其實這兩種方式，都是在不斷地創建 HTTP 鏈接，而後等待服務端處理，能夠體現 HTTP 協議的另一個特色，被動性。

 

　　從上面很容易看出，無論怎麼樣，上面兩種都是很是消耗資源的。ajax 輪詢須要服務器有很快的處理速度和資源。long poll 須要有很高的併發，也就是說同時接待客戶的能力。

 

　　主題

　　經過上面這兩個例子，咱們能夠看出，這兩種方式都不是最好的方式，須要不少資源。一種須要更快的速度，一種須要更多併發，這兩種都會致使性能需求愈來愈高。

　　還有，HTTP 是一個無狀態協議。通俗就是，服務器天天要處理的請求不少，不會記得上次處理的你的請求參數和內容。

　　因此在這種狀況下出現了 WebSocket。他解決了 HTTP 的這幾個難題。首先，被動性，當服務器完成協議升級後，服務端就能夠主動推送消息給客戶端。只須要通過一次 HTTP 請求，就能夠作到源源不斷的信息傳送了。

 

https://www.cnblogs.com/nnngu/p/9347635.html