RFC 6455 WebSocket协议

websocket握手

客户端发送

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

服务端返回

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

• Sec-WebSocket-Protocol  可以用来指定子协议

握手协议服务端需要校验

1. 请求方法必须是GET，而且http版本至少为1.1
2. 请求头部必须要host，upgrade（值必须为websocket），Connection（值必须为Upgrade），Sec-WebSocket-Key（值为随机生成的16字节随机数通过base64编码得到的），Sec-WebSocket-Version（值必须为13）
3. 请求头部可能包含Sec-WebSocket-Protocol  用来指定子协议。该值形式为用逗号分割的按权重排序的子协议列表。
4. 请求头部可能包含Sec-WebSocket-Extensions。

握手协议客户端需要校验

1. 判断状态码，收到401状态码可能需要验证，收到3xx需要重定向
2. 返回头部必须包含Upgrade且值必须为websocket
3. 返回头部必须包含Connection且值必须为Upgrade
4. 返回头部必须包含Sec-WebSocket-Accept且值为 base64(sha1（Sec-WebSocket-Key+“258EAFA5-E914-47DA-95CA-C5AB0DC85B11”)）
5. 若返回头部包含Sec-WebSocket-Extensions，则需确保其值在客户端请求头部中包含
6. 若返回头部包含Sec-WebSocket-Protocol，则需确保其值在客户端请求头部中包含

数据帧格式

      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 ...                |
     +---------------------------------------------------------------+

字段含义 位数(bit)FIN表示这是消息的最后一个片段。第一个片段也有可能是最后一个片段1RSV1，RSV2，RSV3必须设置为0，除非扩展了非0值含义的扩展。如果收到了一个非0值但是没有扩展任何非0值的含义，接收终端必须断开WebSocket连接。每个1 bitOpcode

定义“有效负载数据”的解释。如果收到一个未知的操作码，接收终端必须断开WebSocket连接

4Mask​ mask标志位，定义“有效负载数据”是否添加掩码。如果设置为1，那么掩码的键值存在于Masking-Key中，根据5.3节描述，这个一般用于解码“有效负载数据”。所有的从客户端发送到服务端的帧都需要设置这个bit位为1。1Payload length

以字节为单位的“有效负载数据”长度，根据不同的情况分为以下几种

7 bits, 7+16 bits, or 7+64 bitsMasking-Key所有从客户端发往服务端的数据帧都已经与一个包含在这一帧中的32 bit的掩码进行过了运算。如果mask标志位（1 bit）为1，那么这个字段存在，如果标志位为0，那么这个字段不存在0 or 4 bytesPayload data

“有效负载数据”是指“扩展数据”和“应用数据”。

(x+y) bytes

客户端掩码算法

掩码、反掩码操作都采用如下算法：

j = i MOD 4

transformed-octet-i = original-octet-i XOR masking-key-octet-j

解释一下：

• _1）_original-octet-i：为原始数据的第 i 字节；
• _2）_transformed-octet-i：为转换后的数据的第 i 字节；
• _3）_masking-key-octet-j：为 mask key 第 j 字节。

状态码

当关闭一个连接时（如：在开始握手已经完成后，发送一个关闭帧），终端可能会说明关闭的原因。终端的这个原因的描述和终端应该采取的行动，在这个文档中都没有说明。这个文档提前定义了一些可能用于扩展、框架和终端应用的状态码和状态码范围。这些状态码和任何有关联的的文本消息在关闭帧中都是可选的

分片

一个分片的消息由起始帧（FIN为0，opcode非0），若干（0个或多个）帧（FIN为0，opcode为0），结束帧（FIN为1，opcode为0）。

参考网站

• https://www.rfc-editor.org/rfc/rfc6455
• https://juejin.cn/post/6844903779192569869