websocket同http和https一樣，屬於tcp基礎上的應用層的協議；因此其必然也是存在三次握手四次揮手的過程
一般來說，我們使用的http協議只能由客戶端發起請求，而服務端無法直接主動進行資料推送，這就導致了如果服務端有持續的變化(如聊天室)而客戶端獲取起來較為複雜(如實時性和服務端壓力等)。因此，websocket協議便應運而生
對於websocket協議來說，客戶端和服務端都可以主動推送訊息，其中訊息內容可以時文字也可以是二進位制資料。而且沒有同源策略的限制，也不存在跨域問題
websocket協議的表示符號時ws(ws:像https一樣，如果加密的話，識別符號就是wxs
1）tcp協議的三次握手四次揮手的過程必然存在
2）websocket協議本身的握手環節
3）websocket協議握手成功之後的收發資料環節
握手環節：驗證服務端是否支援websocket協議
1）建立連線，瀏覽器連線服務端，建立連線成功
2）瀏覽器生成乙個隨機字串，瀏覽器存乙份該隨機字串，同時發乙份給服務端（基於http協議發到服務端，會把該字串放在http請求頭里發給服務端）
3）服務端收到隨機字串之後，讓它跟魔法字串（magic string，全球公認的固定字串）拼接，然後再通過sha1演算法進行加密然後再通過base64編碼後，生成密文
4）服務端將密文返回給瀏覽器（該密文無法反解）
5）瀏覽器也將本地存的隨機字串與magic string進行拼接並加密編碼之後得到乙個密文
6）瀏覽器將服務端發來的密文與本地的密文進行對比、校驗，若通過，則說明兩端用的同乙個magic string，即用的同一種加密手段，即可以判定服務端支援websocket協議，握手成功；若校驗不通過，則代表服務端不支援websocket協議，握手失敗
收發資料環節：資料是加密的
1）瀏覽器將資料加密發往客戶端
2）服務端接收到資料之後進行的解密（解密是全球公認的）
a) 拿到第2個位元組（8位），取其後7位(即前兩個位元組的10-16位)，也就是資料的前9位都不要，我們取到的7位稱之為payload length（7位最大值是127）；
b) 服務端對payload length的值進行判斷：
1> 若payload length = 127：
再往後讀8個位元組(即64bit/位)，也就是說前10個位元組(8+2)是資料頭，後面才是資料
2> 若payload length = 126：
再往後讀2個位元組(即16bit/位)，也就是說前4個位元組(2+2)是資料頭，後面才是資料部分
3> 若payload length <= 125：
不往後讀，前面2個位元組就是資料頭，後面都是資料部分
3）通過b解密過程獲取資料，但是該資料也不是明文的，還需要再解密
a) 獲取到資料部分後，再往後讀4個位元組，該4個位元組稱之為masking key，剩下部分是真正的資料；
b) 讓masking key與資料的每乙個位元組進行位運算(與或運算)，運算完之後就獲取到了最終的資料(具體過程可見官網)
Websocket原理概述
html5提供了websocket來支援瀏覽器與伺服器的全雙工通訊。websocket在tcp之上定義了幀協議，從而能夠支援雙向的通訊。由於websocket本質上是乙個基於tcp的協議，在建立websocket連線前，瀏覽器或者其他客戶端需要向伺服器發起請求，伺服器解析請求後產生應答資訊返回給客戶...
websocket的通訊原理
1.websocket和http一樣是一種通訊協議，是html5的一種新的協議。2.既然有了http協議了，為什麼還會有websocket呢？是因為是為了彌補http的單向請求的缺陷的 http的請求只能由客戶端發起 建立在tcp協議之上，伺服器端的實現比較容易 2.和http協議有著良好的相容性，...
websocket原理與聊天功能
前段時間剛好要做乙個小型的網頁版聊天室，需求是用電腦完成語音通話 前面部落格有 傳送 文字 檔案什麼的。這就涉及到的網頁套接字，在這裡就不得不說一下的的websocket的原理 首先，可將網頁套接字是html5出的東西 協議 也可以理解的websocket的是乙個新協議，跟http協議基本沒有關係，...