一、前言

上一篇??WebSocket實戰(zhàn)之一?講了WebSocket一個極簡例子和基礎的API的介紹，這一篇來分析一下WebSocket的協(xié)議，學習網絡協(xié)議最好的方式就是抓包分析一下什么就都明白了。

二、WebSocket協(xié)議

本想盜一張網絡圖，后來想想不太好，還是自己畫了一張。

1、WebSocket握手

WebSocket握手是用一個特殊的HTTP請求和響應來完成，客戶端握手請求頭會攜帶Upgrade:websocket，表示請求將協(xié)議升級為WebSocket協(xié)議。

響應碼 101 表示同意將協(xié)議進行升級，Sec-WebSocket-Accept是從請求的Sec-WebSocket-key繼承而來，包含一個特殊的響應值，必須和客戶端預期精確匹配才能握手成功。Sec-WebSocket-Accept=Base64(SHA1(Sec-WebSocket-key+KEY_SUFFIX))。

2、發(fā)送數(shù)據(jù)

WebSocket握手成功連接打開后，客戶端和服務端就可以在任何時候相互發(fā)送數(shù)據(jù)，在昨天簡單例子中客戶端open事件加上發(fā)送信息，在瀏覽器可以看到發(fā)送的消息和接收到的消息。這就是和HTTP最本質的區(qū)別，只要握手完成后無論哪一端想發(fā)送數(shù)據(jù)就發(fā)送，而不是像HTTP那樣服務端一定要等客戶端的請求然后做出響應。

將前一節(jié)例子客戶端也改成每隔5秒發(fā)送一條數(shù)據(jù)。

在瀏覽器控制臺Message標簽可以查看Send（向上箭頭）和Receive（向下箭頭）的數(shù)據(jù)，全雙工相互發(fā)送。

3、關閉握手

終止連接的端點發(fā)送一個數(shù)字代碼以及關閉原因字符串，關閉握手能正常關閉連接，使應用程序可以區(qū)分出是有意關閉還是意外終止連接。

三、抓包分析

IP:115.192.133.59 WebSocket客戶端

IP:172.16.79.224? ?WebSocket服務端（內網IP）

為了便于查看數(shù)據(jù)包內容，代碼稍微調整，將客戶端服務端持續(xù)發(fā)送數(shù)據(jù)去掉

服務端改為接連發(fā)送三條數(shù)據(jù)

客戶端改為不發(fā)送消息，而只在收到消息后關閉websocket

1、【1、2、3】開始三個包就是普通的TCP三次握手。

2、【4】第4個包是請求頭攜帶了Upgrade:websocket的普通HTTP請求。

3、【5】服務端一個TCP響應包，【6】服務端一個HTTP響應包，101 Switching Protocols告訴客戶端協(xié)議進行升級。

4、【7、8、9】第7、8、9個包，服務端向客戶端以WebSocket協(xié)議發(fā)送了三個包，WebSocket以幀格式發(fā)送消息內容

• Fin：1位，用來表明這是一個消息的最后的消息片斷，當然第一個消息片斷也可能是最后的一個消息片斷.

• RSV1, RSV2, RSV3: 分別都是1位，如果雙方之間沒有約定自定義協(xié)議，那么這幾位的值都必須為0,否則必須斷掉WebSocket連接.

• Opcode:4位操作碼，定義有效負載數(shù)據(jù)，如果收到了一個未知的操作碼，連接也必須斷掉，以下是定義的操作碼.

• Payload length: 傳輸數(shù)據(jù)的長度，以字節(jié)的形式表示.

• Payload data: 負載數(shù)據(jù),這一幀里傳的數(shù)據(jù)是 【b】.

5、【10、11、12、13】客戶端向服務端發(fā)送4個TCP應答包，應該是對收到消息的一個應答

6、【14】客戶端調用close方法關閉websocket連接，可以看到在關閉之前服務端包已經發(fā)出來了。

7、【15】服務端對客戶端的close進行了應答，關閉了連接。

8、【16、17、18、19、20】 TCP的4次揮手，另外一個包沒搞清楚是做什么的。

四、總結

WebSocket是基于TCP的，與HTTP同樣也是應用層協(xié)議，但WebSocket的首次握手是依賴于HTTP協(xié)議，握手成功協(xié)議升級為WebSocket，然后就是長連接可以相互一直發(fā)送消息而不再是HTTP的那種請求/響應機制，另外可以看到客戶端的端口在開始隨機用了一個值是52914后，在關閉之前一直會用同一端口，這樣才能找得到，IP用來找機器，端口用來找應用。

注：下一篇再介紹一下心跳機制以及斷開重連機制。