? 之前在用 Charles 抓取游戲數(shù)據(jù)包的時(shí)候遇到的縮寫為“ws”的協(xié)議，一查是 WebSocket 協(xié)議，之前沒(méi)有接觸過(guò)，于是小小地學(xué)習(xí)了一下。
一、簡(jiǎn)介/與 HTTP 協(xié)議的聯(lián)系
? WebSocekt 是 HTML5 開(kāi)始提供的一種在單個(gè) TCP 連接上進(jìn)行全雙工通訊的協(xié)議。按照個(gè)人理解，就是 HTTP 協(xié)議為了支持長(zhǎng)連接所產(chǎn)生的一個(gè)“補(bǔ)丁”，但并不完全相等。
? 在 HTTP 協(xié)議中，連接（Connection）的生命周期由請(qǐng)求（Request）和響應(yīng)（Response）界定（HTTP1.0）。在 HTTP1.1 中則進(jìn)行了改進(jìn)，由多個(gè)請(qǐng)求（Request）和響應(yīng)（Response）來(lái)達(dá)到近似 keep-alive 的狀態(tài)，但是?Request 和?Response 總是一一對(duì)應(yīng)的，而且 Response 是被動(dòng)的，不能主動(dòng)發(fā)起。而達(dá)到持久連接（keep-alive），常用的方法是輪詢與長(zhǎng)輪詢，但二者都需要浪費(fèi)很多的 HTTP 資源，請(qǐng)求的數(shù)量較大。
?而 WebSocket 則優(yōu)化了這一問(wèn)題。首先，建立了 WebSocket 后，服務(wù)器不必在收到瀏覽器（客戶端）的 Request 后才能發(fā)送消息給瀏覽器（客戶端），即服務(wù)器有自己的“主動(dòng)權(quán)”來(lái)決定何時(shí)發(fā)送消息。這種方式使得只需要經(jīng)過(guò)一次 HTTP 請(qǐng)求，就可以做到持久連接（keep-alive）。簡(jiǎn)單來(lái)說(shuō)，就是有了信息就會(huì)通知，而不是周期性地詢問(wèn)是否有信息。
二、握手流程
? 為了建立一個(gè) WebSocket 連接，瀏覽器（客戶端）發(fā)送一個(gè) WebSocket 握手 Request，作為回應(yīng)，服務(wù)器回復(fù)一個(gè) WebSocket 握手 Response，如下面例子（摘自 Wikipedia）：
? 客戶端 Request：
GET/chatHTTP/1.1
Host:server.example.com
Upgrade:websocket
Connection:Upgrade
Sec-WebSocket-Key:x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol:chat, superchat
Sec-WebSocket-Version:13
Origin:http://example.com
? 以下字段表面發(fā)起的是 WebSocket 協(xié)議，而不是 HTTP ：
Upgrade:websocket
Connection:Upgrade
? Sec-WebSocket-Key 主要是防止未授權(quán)的跨域腳本攻擊（簡(jiǎn)單來(lái)說(shuō)就是驗(yàn)證身份用），Sec-WebSocket-Protocol 則是自定義字符串，用來(lái)告知所需服務(wù)，Sec-WebSocket-Version 即是協(xié)議版本。
Sec-WebSocket-Key:x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol:chat, superchat
Sec-WebSocket-Version:13
? 服務(wù)器 Response：
HTTP/1.1101Switching Protocols
Upgrade:websocket
Connection:Upgrade
Sec-WebSocket-Accept:HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol:chat
? 依然是固定的，用來(lái)回應(yīng)身份驗(yàn)證，和告知協(xié)議切換（Upgrade）。
? 握手完成后，就可以按前文所說(shuō)的進(jìn)行持久連接通信了。
三、WebSocket的缺陷
? 瀏覽器兼容問(wèn)題、開(kāi)發(fā)成本的提高以及新的協(xié)議生態(tài)不成熟是主要缺陷，且服務(wù)器長(zhǎng)時(shí)間維護(hù)持久連接需要很大的成本。
? 另外，WebSocket 在用于雙向傳輸、推送消息方面能夠做到靈活、簡(jiǎn)便、高效，但在普通的 Request - Response 過(guò)程中并沒(méi)有太大用武之地，比起普通的 HTTP 請(qǐng)求來(lái)反倒麻煩了許多，甚至更為低效。
