websocket的官方文档为rfc(request for comments)，是网络协议的规范文档。它包含了许多计算机世界的核心知识
除了这里的websocket，它里边还包含我们熟知的http,tcp等协议的解析。
websocket协议对应的编号是rfc 6455
websocket协议格式解析
由图可知，websocket的报文格式可以分为七大部分，分别是1bite的FIN标志位，3bite的RSV保留位，4bite的Opcode，1bite的mask标志位，7/7+16/7+64bite的payloadLen，可选字段masking-key，可选字段payload。
下边具体解释下：
-
FIN标志位：此标志位用于指示当前的帧是消息的最后一个分段。
websocket支持将长消息切割成若干帧发送，切分后，前边的帧的FIN字段均为0，最后一个帧的FIN为1。
当消息没有分段时，这个帧便包含所有信息，FIN标志位为1.【1bite】
-
RSV1~3：这是三个保留位。一般情况下为全0。
当客户端、服务端协商采用websocket扩展时，这三个标志位可以非0，且值的含义由扩展进行定义。
如果出现非0值但并未采用websocket扩展，连接出错。【3bite】
-
Opcode:操作码。用于指示帧类型。【4bite】
它决定了如何解析后续的数据载荷部分，如果操作码是不认识的，接收端应该断开连接。可选的操作码如下：
%x0：表示一个延续帧。当Opcode为0时，表示本次数据传输采用了数据分片，当前收到的数据帧为其中一个数据分片。 %x1：表示这是一个文本帧（frame） %x2：表示这是一个二进制帧（frame） %x3-7：保留的操作代码，用于后续定义的非控制帧。 %x8：表示连接断开。 %x9：表示这是一个ping操作。 %xA：表示这是一个pong操作。 %xB-F：保留的操作代码，用于后续定义的控制帧。其中注意websocket既可以传输文本数据，也可以传输二进制数据
-
Mask标志位：指示帧的payload是否需要使用掩码覆盖。【1bite】
RFC6455规定，当且仅当由客户端向服务端发送的帧需要覆盖。
掩码覆盖的作用：解决“缓冲区溢出”（忽略）
当mask为1，但服务端接收的数据没有进行过掩码操作，服务端需要断开连接
-
payload length:7位/7+16位（64k）/7+64位（超级大），单位是字节
模式区分：
①当7bite的payloadlength<126，此时为模式1
② 7bite的payloadlength=126，16bite生效为模式2
③ 7bite的payloadlength=126，64bite生效为模式3
-
masking-key与mask值有关，当mask为0时，没有masking-key，为1时，有4B的masking-key
-
payload-data:长度可变。包含扩展数据（x字节）和应用数据（y字节）
如果通信双方约定使用了websocket扩展，则扩展数据也存放于此。并声明扩展长度。
如果没有约定使用，则扩展数据为0字节。
其中最重要的便是Opcode、payload length(三种模式)，payload data
参考
引用
引用
官方
