网络编程：WebSocket协议浅析

最新推荐文章于 2023-05-16 21:12:06 发布

晓衡的成长日记

最新推荐文章于 2023-05-16 21:12:06 发布

阅读量137

点赞数

欢迎关注colinsusie的微信公众号，colinsusie就是之前的colin大神哦！继续向colinsusie学习网络协议！

前言

当前好多手游都要求支持全平台，即要支持IOS和Android，也要支持原生App和H5，这让游戏的研发门槛越来越高。服务器这一端相对好一点，但也要考虑不同平台的通讯协议差异。综合各个平台的差异，只有HTTP和WebSocket是全平台支持的。HTTP适合于短连接的游戏，WebSocket则常用在长连接，通信比较频繁的游戏，比如像一些RPG，回合制，对战类的等等。

这一篇就来讲讲WebSocket协议的内容。

握手阶段

WebSocket以一个HTTP的请求和响应来进行握手，客户端请求的文本大概是这样：

GET / HTTP/1.1	
Host: example.com:8000	
Upgrade: websocket	
Connection: Upgrade	
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==	
Sec-WebSocket-Version: 13

请求方法必须是GET，协议必须是1.1以上，请求路径没有强制要求，这里是/
Upgrade 必须是websocket，Connection必须是Upgrade
Sec-WebSocket-Version 为WebSocket版本号，当然是13
Sec-WebSocket-Key 是客户端发来的一个Key，看下面响应描述。

服务器响应的文本为：

HTTP/1.1 101 Switching Protocols	
Upgrade: websocket	
Connection: Upgrade	
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

响应码必须是101，表示Switching Protocols
Upgrade和Connection与上面一样
Sec-WebSocket-Accept根据上面请求的Sec-WebSocket-Key算出来的，它的算法是：Sec-WebSocket-Key + 258EAFA5-E914-47DA-95CA-C5AB0DC85B11，然后计算出这个字符串的SHA-1哈希值，最后用base64得到结果。

响应完之后，握手完成，接下来就可以交换数据帧。

数据帧格式

每一个数据帧都包含帧头+有效数据，帧头的格式如下（注意字节顺序都是网络字节序）：

0                   1                   2                   3	
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1	
+-+-+-+-+-------+-+-------------+-------------------------------+	
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |	
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |	
|N|V|V|V|       |S|             |   (if payload len==126/127)   |	
| |1|2|3|       |K|             |                               |	
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +	
|     Extended payload length continued, if payload len == 127  |	
+ - - - - - - - - - - - - - - - +-------------------------------+	
|                               |Masking-key, if MASK set to 1  |	
+-------------------------------+-------------------------------+	
| Masking-key (continued)       |          Payload Data         |	
+-------------------------------- - - - - - - - - - - - - - - - +	
:                     Payload Data continued ...                :	
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +	
|                     Payload Data continued ...                |	
+---------------------------------------------------------------+

协议的大概内容是：

第1位FIN表示该帧是否为连续帧(即需要多个帧才能组成完整有效数据)，如果为1表示单独帧，如果为0表示连续帧。我觉得这个有点过度设计了，连续帧应该由应用层自己解决，并且一个帧可以表示的长度是很长的，完全没必要设计这个连接帧。
RSV1~RSV3 这3位未用，默认为0。
opcode 为操作码，占4位，这个会决定该帧的类型，后面描述。
MASK 为掩码标志，占1位，如果为1，有效数据需要和Masking-key进行异或才得到原始数据，后面描述。
Payload len，Extended payload length 用于描述有效数据的大小，这个长度是动态的，后面描述。
Masking-key和MASK位结合，如果MASK为1，这个才会存在，否则不存在。
后面就是上层应用的有效数据。

MASK数据

如果MASK位为1，那么Masking-key这4个字节就存在，用于和Playload data进行解码，才能得到原始的数据，解码的伪代码如下：

var DECODED = "";	
for (var i = 0; i &lt; PayloadData.length; i++) {	
    DECODED[i] = PayloadData[i] ^ MaskKey[i % 4];	
}

这其实就是一种异或加密，客户端发过来的数据规定必须要加密。服务器可以根据需要自己决定。

Payload Data的长度

帧头有一块内容用来表示有效数据的大小，这一块内容是动态长度的，它是这样计算有效数据大小的：

先读7位(Payload len)，如果其值小于126，那么有效数据的长度就是它的值。
如果等于126，还要再读16位，这16位的值就是有效数据的长度。
如果等于127，还要再读64位，这64位的值就是有效数据的长度。

操作码

操作码分为两种，一种是数据类型，一种是控制码，描述如下：

0x1 表示内容是文本数据，并且总是以utf-8编码。
0x2 表示内容是二进制数据。
0x9 是一个控制帧，叫PING帧。
0xA 是一个控制帧，叫PONG帧，服务器收PING帧到后必须回应一个PONG帧，这其实就是一种心跳机制，且PING和PONG可以带有效数据，数据长度必须小于等125，即可以用前面的7位表示。
0x8 是一个控制帧，叫关闭帧，告诉对端我要关闭了，关闭帧可以带有效数据，其中前面2个字节是关闭码，后面跟着utf-8的判断原因文本。。
0x0 是一个控制帧，叫连续帧，假设连续帧有3帧，下面3帧的信息可以描述opcode和FIN怎么组合的： Client:FIN=0,opcode=0x1,msg="and a"Client:FIN=0,opcode=0x0,msg="happy new"Client:FIN=1,opcode=0x0,msg="c" 最后收到的信息就是: anda happynewhappynew

断开挥手阶段

开始断开前，一端需要发送一个关闭控制帧。
另一端收到关闭帧后，需要发送一个关闭帧作为响应。
两端都发送并收到关闭帧后，就可以正常断开连接。

这个断开挥手阶段一直不大明白，TCP已经有断开过程了，WebSocket为什么还要自己设计一套挥手的过程，如果两端主动关闭，那么两端的TCP都会处于TIME_WAIT状态，这样会有什么好处呢？查看过几个实现，一般都是发送关闭帧后自己立即断开连接，并没有遵循WebSocket的协议说明等对端返回关闭帧才关闭。这个有人理解的话，欢迎告知。

关于WebSocket更详细的协议说明，请查看RFC6455