websocket协议详解

10000001 00010001

最后一帧 text帧

不掩码 有效数据17字节

• FIN：1 bit
  表示这是不是消息的最后一帧。第一帧也有可能是最后一帧。 %x0： 还有后续帧 %x1：最后一帧

• RSV1、RSV2、RSV3：1 bit 总3字节
  扩展字段，除非一个扩展经过协商赋予了非零值的某种含义，否则必须为0

• opcode：4 bit
  解释 payload data 的类型，如果收到识别不了的opcode，直接断开。分类值如下： %x0：连续的帧

  %x1：text帧

  %x2：binary帧

  %x3 - 7：为非控制帧而预留的

  %x8：关闭握手帧

  %x9：ping帧

  %xA：pong帧

  %xB - F：为非控制帧而预留的

0x605090：10000001
// 第1部分: 1, FIN数据
// 第2部分: 000, RSV1/RSV2/RSV3数据
// 第3部分: 0001, opcode数据text帧

• MASK：1 bit
  标识 Payload data 是否经过掩码处理，如果是 1，Masking-key域的数据即为掩码密钥，用于解码Payload data。协议规定客户端数据需要进行掩码处理，所以此位为1

• Payload len：7 bit | 7+16 bit | 7+64 bit
  表示了 “有效负荷数据 Payload data”，以字节为单位：

  如果是 0~125，那么就直接表示了 payload 长度

  如果是 126，那么 先存储 0x7E（=126）接下来的两个字节表示的 16位无符号整型数的值就是 payload 长度

  如果是 127，那么 先存储 0x7E（=126）接下来的八个字节表示的 64位无符号整型数的值就是 payload 长度

• Masking-key：0 | 4 bytes 掩码密钥，所有从客户端发送到服务端的帧都包含一个 32bits 的掩码（如果mask被设置成1），否则为0。一旦掩码被设置，所有接收到的 payload data 都必须与该值以一种算法做异或运算来获取真实值。
  ws协议中，数据掩码的作用是增强协议的安全性。但数据掩码并不是为了保护数据本身，因为算法本身是公开的，运算也不复杂。除了加密通道本身，似乎没有太多有效的保护通信安全的办法，那么为什么还要引入掩码计算呢，除了增加计算机器的运算量外似乎并没有太多的收益（这也是不少同学疑惑的点）
  答案还是两个字：安全。但并不是为了防止数据泄密，而是为了防止早期版本的协议中存在的代理缓存污染攻击（proxy cache poisoning attacks）等问题

• Payload data：(x+y) bytes
  它是 Extension data 和 Application data 数据的总和，但是一般扩展数据为空。

• Extension data：x bytes
  除非扩展被定义，否则就是0

• Application data：y bytes
  占据 Extension data 后面的所有空间

结束 81 7e(126) 00 9b(155)

10000001 01111110 00000000 10011011

相关资料：
https://blog.csdn.net/tianshi0007/article/details/52698374
https://blog.csdn.net/yangzai187/article/details/93862980 掩码处理方式
https://blog.csdn.net/lzf200906306/article/details/119252046 websocket