WebSocket协议

image.png

参考

• WebSocket协议分析及实现
• WebSocket 是什么原理？为什么可以实现持久连接？
• RFC6455

协议格式

  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)     |
 | |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. 数据帧格式详解

   1. FIN：1 个比特。
      如果是 1，表示这是消息（message）的最后一个分片（fragment），如果是 0，表示不是是 消息（message）的最后一个 分片（fragment）。

   2. RSV1, RSV2, RSV3：各占 1 个比特。
      一般情况下全为 0。当客户端、服务端协商采用 WebSocket 扩展时，这三个标志位可以非 0，且值的含义由扩展进行定义。如果出现非零的值，且并没有采用 WebSocket 扩展，连接出错。

   3. Opcode: 4 个比特。
      操作代码，Opcode 的值决定了应该如何解析后续的 数据载荷（data payload）。如果操作代码是不认识的，那么接收端应该 断开连接（fail the connection）。可选的操作代码如下：

      • 0：表示一个延续帧。当 Opcode 为 0 时，表示本次数据传输采用了数据分片，当前收到的数据帧为其中一个数据分片。
      • 1：表示这是一个文本帧（frame）
      • 2：表示这是一个二进制帧（frame）
      • 3-7：保留的操作代码，用于后续定义的非控制帧。
      • 8：表示连接断开。
      • 9：表示这是一个 ping 操作。
      • A：表示这是一个 pong 操作。
      • B-F：保留的操作代码，用于后续定义的控制帧。

   4. Mask: 1 个比特。
      表示是否要对数据载荷进行掩码操作。从客户端向服务端发送数据时，需要对数据进行掩码操作；从服务端向客户端发送数据时，不需要对数据进行掩码操作。
      如果服务端接收到的数据没有进行过掩码操作，服务端需要断开连接。
      如果 Mask 是 1，那么在 Masking-key 中会定义一个 掩码键（masking key），并用这个掩码键来对数据载荷进行反掩码。所有客户端发送到服务端的数据帧，Mask 都是 1。

   5. Payload length：数据载荷的长度
      单位是字节。为 7 位，或 7+16 位，或 1+64 位。
      假设数 Payload length === x，如果

      • x 为 0~126：数据的长度为 x 字节。
      • x 为 126：后续 2 个字节代表一个 16 位的无符号整数，该无符号整数的值为数据的长度。
      • x 为 127：后续 8 个字节代表一个 64 位的无符号整数（最高位为 0），该无符号整数的值为数据的长度。

      此外，如果 payload length 占用了多个字节的话，payload length 的二进制表达采用 网络序（big endian，重要的位在前）。

   6. Masking-key：0 或 4 字节（32 位）
      所有从客户端传送到服务端的数据帧，数据载荷都进行了掩码操作，Mask 为 1，且携带了 4 字节的 Masking-key。如果 Mask 为 0，则没有 Masking-key。
      备注：载荷数据的长度，不包括 mask key 的长度。

   7. Payload data：(x+y) 字节
      载荷数据：包括了扩展数据、应用数据。其中，扩展数据 x 字节，应用数据 y 字节。

      • 扩展数据：
        如果没有协商使用扩展的话，扩展数据数据为 0 字节。所有的扩展都必须声明扩展数据的长度，或者可以如何计算出扩展数据的长度。此外，扩展如何使用必须在握手阶段就协商好。如果扩展数据存在，那么载荷数据长度必须将扩展数据的长度包含在内。
      • 应用数据：
        任意的应用数据，在扩展数据之后（如果存在扩展数据），占据了数据帧剩余的位置。载荷数据长度 减去 扩展数据长度，就得到应用数据的长度。