作者:朱磊,單位:中國(guó)移動(dòng)智慧家庭運(yùn)營(yíng)中心成都業(yè)務(wù)支持中心
在WebSocket出現(xiàn)之前,一個(gè)Web應(yīng)用(即時(shí)聊天、多人協(xié)作)的客戶端和服務(wù)端之間常見的雙向數(shù)據(jù)交換方式有短輪詢、長(zhǎng)輪詢、SSE(Server-Sent Events,服務(wù)器發(fā)送事件)。這些方式在效率和網(wǎng)絡(luò)帶寬利用率方面存在諸多問題。WebSocket協(xié)議應(yīng)運(yùn)而生,對(duì)外提供了簡(jiǎn)單的雙向數(shù)據(jù)傳輸能力。
介紹?
WebSocket是一種在TCP連接上進(jìn)行全雙工通訊的網(wǎng)絡(luò)通信協(xié)議。在2009年誕生,于2011年被IETF(The Internet Engineering Task Force,國(guó)際互聯(lián)網(wǎng)工程任務(wù)組)定為標(biāo)準(zhǔn)并發(fā)布RFC 6455互聯(lián)網(wǎng)標(biāo)準(zhǔn)跟蹤文檔,2016發(fā)布了RFC7936文檔進(jìn)行補(bǔ)充。WebSocket API同時(shí)也被W3C定為標(biāo)準(zhǔn)。
WebSocket協(xié)議設(shè)計(jì)之初是為了取代HTTP形式的通信,因?yàn)镽FC6202中提到HTTP協(xié)議最初不是用來(lái)做雙向數(shù)據(jù)通信的。WebSocket協(xié)議并沒有完全舍棄HTTP,它基于HTTP基礎(chǔ)服務(wù)在現(xiàn)有環(huán)境中實(shí)現(xiàn)了雙向通信目標(biāo)。正如RFC 6455中說(shuō)的那樣,WebSocke的設(shè)計(jì)哲學(xué)是最小約束的框架,唯一的約束就是協(xié)議是基于幀而不是流,并且支持Unicode文本和二進(jìn)制幀兩者。
握手
WebSocket協(xié)議分為建連握手、消息傳輸和斷連握手三個(gè)部分,整體流程如下圖所示。
2.1 建連握手-客戶端
為了兼容HTTP服務(wù)器側(cè)的應(yīng)用程序和代理,客戶端的建連握手(包括通過代理或通過TLS加密隧道進(jìn)行的連接)是一個(gè)遵循RFC2616中定義的有效HTTP升級(jí)請(qǐng)求,客戶端連接握手請(qǐng)求header部分字段如下圖所示。此外,客戶端一旦發(fā)送了的連接握手就必須等待來(lái)自服務(wù)器的響應(yīng)。
- 請(qǐng)求URI
格式,ws-URI = "ws:" "http://" host [ ":" port ] path [ "?" query ]或者wss-URI = "wss:" "http://" host [ ":" port ] path [ "?" query ],任何無(wú)效值都會(huì)造成建連失敗
- 請(qǐng)求行
必須是GET方法,HTTP版本至少是1.1
- Upgrade
值必須是“websocket”,ASCII值,不區(qū)分大小寫
- Connection
值必須包含“Upgrade”,ASCII值,不區(qū)分大小寫
- Sec-WebSocket-Key
客戶端為本次建連隨機(jī)生成的16字節(jié)base64編碼的字符串
- Origin
源地址,瀏覽器客戶端必填,非瀏覽器客戶端選填
- Sec-WebSocket-Protocol
客戶端支持的一個(gè)或多個(gè)以逗號(hào)分隔的子協(xié)議,按優(yōu)先級(jí)排序
- Sec-WebSocket-Version
客戶端擬使用協(xié)議版本號(hào),值必須為13。歷史版本9、10、11和12不再作為有效值
- Sec-WebSocket-Extensions
客戶端擬使用協(xié)議擴(kuò)展。目前HyBi Working Group進(jìn)行了多路復(fù)用擴(kuò)展和壓縮擴(kuò)展,多路復(fù)用擴(kuò)展實(shí)現(xiàn)共享底層TCP連接。壓縮擴(kuò)展為WebSocket協(xié)議增加了壓縮功能,例如 x-webkit-deflate-frame
2.2 建連握手-服務(wù)端
當(dāng)客戶端與服務(wù)端建立WebSocket連接時(shí),服務(wù)端必須回復(fù)客戶端建連握手請(qǐng)求,握手回復(fù)header部分字段如下圖所示。
- 狀態(tài)行
HTTP/1.1 ?101 ?Switching Protocols,表示接受客戶端建連。若服務(wù)器想要停止處理客戶端的握手,可返回例如401這樣的錯(cuò)誤代碼的HTTP響應(yīng)
- Upgrade
值必須是“websocket”
- Connection
值必須包含“Upgrade”
- Sec-WebSocket-Accept
若服務(wù)端接受客戶端連接,生成該值。先將客戶端請(qǐng)求頭的 Sec-WebSocket-Key值與RFC4122文檔中定義的全局唯一標(biāo)識(shí)“258EAFA5-E914-47DA-95CA-C5AB0DC85B11”拼接,然后進(jìn)行SHA-1哈希再進(jìn)行base64-encoded得到該值
- Sec-WebSocket-Protocol
服務(wù)端擬使用的協(xié)議,該值從客戶端發(fā)送的Sec-WebSocket-Protocol中選擇,若服務(wù)端都不支持,值為空
- Sec-WebSocket-Extensions
服務(wù)端擬使用協(xié)議擴(kuò)展
2.3 斷接握手
客戶端和服務(wù)端都可以發(fā)送包含指定控制序列的控制幀(Close控制幀)以開始關(guān)閉握手。一方在接收到關(guān)閉控制幀時(shí),只需發(fā)送一個(gè)關(guān)閉幀作為響應(yīng),然后關(guān)閉連接。存在攔截代理等情況下,TCP關(guān)閉握手并不總是可靠的端到端握手,上述關(guān)閉握手過程旨在補(bǔ)充TCP關(guān)閉握手(FIN/ACK)
數(shù)據(jù)傳輸
客戶端一旦和服務(wù)端連接握手成功,雙方就可以開始數(shù)據(jù)傳輸了。這是一個(gè)雙向通信信道,在遵循RFC 6455規(guī)范中“消息”概念的基礎(chǔ)上,雙方均可以獨(dú)立地隨意發(fā)送數(shù)據(jù)。一條消息包含一個(gè)或者多個(gè)數(shù)據(jù)幀(不一定對(duì)應(yīng)于網(wǎng)絡(luò)層中的消息),Websocket幀格式如下圖所示。
3.1 幀結(jié)構(gòu)
- FIN
1位,表示是否是一條消息的最后一個(gè)分片。
- RSV1, RSV2, RSV3
1位,擴(kuò)展功能未使用的情況下默認(rèn)值為0。
- Opcode
4位,定義“Playload data”數(shù)據(jù)類型。
0(十進(jìn)制):連續(xù)幀
1:文本幀
2:二進(jìn)制幀
3-7:預(yù)留非控制幀
8:連接關(guān)閉幀
9:心跳ping幀
10:心跳pong幀
11-15:預(yù)留控制幀
- MASK
1位,是否屏蔽“Playload data”,1是,0否。
- Payload length
7位,或者7+16位,或者7+64位,表示Payload data的長(zhǎng)度。具體地,Payload length小于125,數(shù)據(jù)長(zhǎng)度用Payload length表示;Payload length等于126,數(shù)據(jù)長(zhǎng)度用Payload length后面16位表示;Payload length等于127,數(shù)據(jù)長(zhǎng)度用Payload length后面64位表示。
- Masking-key
32位,存放客戶端發(fā)送的掩碼。為了防止代理緩存污染攻擊,RFC6455中要求掩碼必須來(lái)自強(qiáng)大的熵源,不可被預(yù)測(cè)。常規(guī)算法以字節(jié)為步長(zhǎng)遍歷載荷數(shù)據(jù), 對(duì)于載荷數(shù)據(jù)的第i個(gè)字節(jié), 做i對(duì)4取模得到j(luò),掩碼覆蓋后的載荷數(shù)據(jù)的第i個(gè)字節(jié)的值為原第i個(gè)字節(jié)與Masking-Key的第j個(gè)字節(jié)做按位異或操作。
- Payload data
載荷數(shù)據(jù)分為擴(kuò)展數(shù)據(jù)和應(yīng)用數(shù)據(jù)兩種,擴(kuò)展數(shù)據(jù)在握手階段協(xié)商是否使用,應(yīng)用數(shù)據(jù)在擴(kuò)展數(shù)據(jù)之后。
3.2 控制幀
控制幀由Opcode值確定,協(xié)議當(dāng)前定義的控制幀的操作碼包括 0x8 (Close)、0x9(Ping)、和0xA(Pong)??刂茙仨氂幸粋€(gè)小于等于125字節(jié)的有效載荷長(zhǎng)度,對(duì)于Close控制幀有效載荷的前2個(gè)字節(jié)表示狀態(tài)碼,剩余字節(jié)表示關(guān)閉原因,如下圖所示。
3.3 消息分片
消息分片指將概念上的一條“消息”通過多個(gè)數(shù)據(jù)幀發(fā)送。消息分片允許發(fā)送未知大小的消息,而不必緩沖整條消息。同時(shí),消息分片結(jié)合多路復(fù)用協(xié)議的擴(kuò)展,可以分割消息為更小的分段以共享輸出通道。
協(xié)議中分片消息開始幀的FIN位為0,opcode位為非0表示該幀為某消息分片,中間幀F(xiàn)IN位為0,opcode位為0,最后通過FIN位為1,opcode為0標(biāo)識(shí)分片結(jié)束。協(xié)議要求分片數(shù)據(jù)幀按順序發(fā)送到另一端。
總結(jié)
WebSocke是設(shè)計(jì)在TCP層之上,不需要考慮數(shù)據(jù)長(zhǎng)度,數(shù)據(jù)粘包拆包。也能通過擴(kuò)展功能與HTTP/2多路復(fù)用結(jié)合,充分利用帶寬。開發(fā)者只需在服務(wù)端和客戶端代碼中按序處理消息分片邏輯。