详解websocket与http与TCP/IP的三角恋

HTTP协议是一个工作在应用层的协议，它是建立在TCP之上的一个协议。

关于WebSocket，官方的解释可能会让人有些困惑，但仔细阅读官方文档后我发现，WebSocket并不是我们通常理解的基于TCP或UDP协议的套接字，而是一个基于TCP的应用层协议，与HTTP协议工作在计算机网络的同一层。

实际上，WebSocket在TCP的基础上增加了一个协议。这个协议与TCP协议非常相似，也需要握手、挥手，发送大数据时也需要分包，并且按位进行标识。需要再次强调的是，它并不是套接字！它工作在应用层，而不是传输层。

1. WebSocket的数据帧格式如下：

• FIN：1个bit位，用来标记当前数据帧是否为最后一个数据帧。因为一个消息可能会分成多个数据帧传递，如果只需要一个数据帧，则第一个数据帧也是最后一个。

• RSV1, RSV2, RSV3：这三个分别占用一个bit位，根据RFC的介绍，这三个bit位用于扩展目的，如果没有扩展需求，则设置为0。

• Opcode：操作码，占用4个bit位，即一个16进制数。它用于描述要传递的数据的类型或用途，只能取以下值：

• 0x0：表示当前数据帧为分片的数据帧，即当一个消息需要分成多个数据帧传输时，需要将Opcode设置为0x0。

• 0x1：表示当前数据帧传递的内容是文本。

• 0x2：表示当前数据帧传递的是二进制内容，不要转换成字符串。

• 0x8：表示请求关闭连接。

• 0x9：表示Ping请求。

• 0xA：表示Pong数据包，当收到Ping请求时自动回复一个Pong。
  目前协议中只规定了以上这些值，0x3~0x7和0xB~0xF都是预留作为其他用途。

• MASK：占用一个bit位，用于标识数据是否使用掩码。根据RFC的说明，服务端发送给客户端的数据帧不能使用掩码，而客户端发送给服务端的数据帧必须使用掩码。如果一个帧的数据使用了掩码，则Masking-key部分必须是一个32位的掩码，用于服务端解码数据。

• Payload len：数据的长度，默认占用7个bit位。如果数据长度小于125个字节（注意：是字节），则使用默认的7个bit位标识数据长度。如果数据长度为126个字节，则使用相邻的2个字节保存一个16位的无符号整数作为数据长度。如果数据长度大于126个字节，则使用相邻的8个字节保存一个64位的无符号整数作为数据长度。

• Masking-key：数据掩码，如果MASK设置为0，则可以省略该部分。如果MASK设置为1，则Masking-key为一个32位的掩码，用于解码客户端发送给服务端的数据帧。

• Payload data：该部分是帧真正要发送的数据，可以是任意长度。

1. WebSocket握手：

建立TCP连接后，开始建立WebSocket连接。如前所述，WebSocket连接只需一次成功握手即可建立。握手过程如下图所示（图片来自互联网）：

1) 首先，客户端会发送一个握手包。这里体现了WebSocket与HTTP协议的联系，握手包的报文格式必须符合HTTP报文格式的规范。

2) 服务端验证客户端的握手包是否符合规范后，也会发送一个握手包给客户端。格式如下：

3) 客户端收到服务端的握手包后，验证报文格式是否符合规范，并按照第2步同样的方式计算Sec-WebSocket-Accept，并与服务端握手包中的值进行比对。

如果任何一步验证不通过，则无法建立WebSocket连接。

参考：