文章介绍
WebSocket 是一种在单个 TCP 连接上进行全双工通信的协议，它的出现使客户端和服务器之间的数据交换变得更加简单。WebSocket 通常被应用在实时性要求较高的场景，例如赛事数据、股票证券、网页聊天和在线绘图等。
WebSocekt 与 HTTP 协议完全不同，但同样被广泛应用。无论是后端开发者、前端开发者、爬虫工程师或者信息安全工作者，都应该掌握 WebSocekt 协议的知识。
在本篇文章中，你将收获如下知识：
- 读懂 WebSocket 协议规范文档 RFC6455
- WebSocket 与 HTTP 的关系
- 数据帧格式及字段含义
- 客户端与服务端交互流程
- 客户端与服务端如何保持连接
- 何时断开连接
本篇文章适用于互联网领域的开发者和产品经理
开始
WebSocket 是一种在单个 TCP 连接上进行全双工通信的协议。WebSocket 通信协议于 2011 年被 IETF 定为标准 RFC6455，并由 RFC7936 补充规范。看到这里，很多读者会有疑问：什么是 RFC？
RFC 是一系列以编号排定的文件，它由一系列草案和标准组成。几乎所有互联网通信协议均记录在 RFC 中，例如 HTTP 协议标准、本篇介绍的 WebSocket 协议标准、Base64 编码规范等。除此之外，RFC 还加入了许多论题。在本篇 Chat 中，我们对 WebSocekt 的学习和讨论将基于 RFC6455。
WebSocket 协议的来源
在 WebSocket 协议出现以前，网站通常使用轮询来实现类似“数据实时更新”这样的效果。要注意的是，这里的“数据实时更新”是带有引号的，这表示并不是真正意义上的数据实时更新。轮询指的是在特定的时间间隔内，由客户端主动向服务端发起 HTTP 请求，以确认是否有新数据的行为。下图描述了轮询的过程：
首先，客户端会向服务端发出一个 HTTP 请求，这个请求的意图就是向服务器询问“大哥，有新数据吗？”。服务器在接收到请求后，根据实际情况（有数据或无数据）做出响应：
- 有数据，我发给你；
- 无数据，你待会再问；
这种一问一答的方式有着明显的缺点，即浏览器需要不断的向服务器发出请求。由于 HTTP 请求包含较长的头部信息（例如 User-Agent、Referer 和 Host 等），其中真正有效的数据可能只是很小的一部分，所以这样会浪费很多的带宽资源。
比轮询更好的“数据实时更新”手段是 Comet。这种技术可以实现双向通信，但依然需要反复发出请求。而且在 Comet 中，采用的是 HTTP 长连接，这同样会消耗服务器资源。在这种情况下，HTML5 定义了更节省资源，且能够让双端稳定实时通信的 WebSocket 协议。在 WebSocket 协议下，客户端和服务端只需要完成一次握手，就直接可以创建持久性的连接，并进行双向数据传输。下图描述了 WebSocket 协议中，双端通信的过程：
WebSocket 的优点
相对于 HTTP 协议来说，WebSocket 具有开销少、实时性高、支持二进制消息传输、支持扩展和更好的压缩等优点。这些优点如下所述：
较少的开销
WebSocket 只需要一次握手，在每次传输数据时只传输数据帧即可。而 HTTP 协议下，每次请求都需要携带完整的请求头信息，例如 User-Agent、Referer 和 Host 等。所以 WebSocket 的开销相对于 HTTP 来说会少很多。
更强的实时性
由于协议是全双工的，所以服务器可以随时主动给客户端下发数据。相对于一问一答的 HTTP 来说，WebSocket 协议下的数据传输的延迟明显更少。
支持二进制消息传输
WebSocket 定义了二进制帧，可以更轻松地处理二进制内容。
支持扩展
开发者可以扩展协议，或者实现部分自定义的子协议。
更好的压缩
Websocket 在适当的扩展支持下，可以沿用之前内容的上下文。这样在传递类似结构的数据时，可以显著地提高压缩率。
WebSocket 协议规范
WebSocket 是一个通信协议，该协议的规范与标准均记录在 RFC6455 中。协议共有 14 个部分，但与协议规范相关的只有 11 个部分：
- 介绍
- 术语和其他约定
- WebSocket URI
- 握手规范
- 数据帧
- 发送和接收数据
- 关闭连接
- 错误处理
- 扩展
- 通信安全
- 注意事项
而与本篇 Chat 相关的为 4、5、6、7 部分的内容，这些也是 WebSocket 中较为重要的内容。接下来，我们就来学习这些知识。
双端交互流程
客户端与服务端连接成功之前，使用的通信协议是 HTTP。连接成功后，使用的才是 WebSocket 协议。下图描述了双端交互的流程：
首先，客户端向服务端发出一个 HTTP 请求，请求中携带了服务端规定的信息，并在信息中表明希望将协议升级为 WebSocket。这个请求被称为升级请求，双端升级协议的整个过程叫做握手。然后服务端验证客户端发送的信息，如果符合规范则将协议替换成 WebSocket，并将升级成功的信息响应给客户端。最后，双方就可以基于 WebSocket 协议互相推送信息了。现在，我们需要学习的第一个知识点就是握手。
双端握手
我们先来看看 RFC6455 对客户端握手的规定，原文锚点链接为 Opening Handshak。此段原文如下：
The opening handshake is intended to be compatible with HTTP-based server-side software and intermediaries, so that a single port can be used by both HTTP clients talking to that server and WebSocket clients talking to that server. To this end, the WebSocket client's handshake is an HTTP Upgrade request: 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 In compliance with [RFC2616], header fields in the handshake may be sent by the client in any order, so the order in which different header fields are received is not significant.
原文表明，握手时使用的并不是 WebSocekt 协议，而是 HTTP 协议，握手时发出的请求叫做升级请求。客户端在握手阶段通过 Connection 和 Upgrade 头域及对应的值告知服务端，要求将当前通信协议升级为指定协议，此处指定的是 WebSocket 协议。其他头域名及值的作用如下：
GET /chat HTTP/1.1表明本次请求基于 HTTP/1.1，请求方式为GET；Sec-WebSocket-Protocol用于指定子协议；Sec-WebSocket-Version表明协议版本，要求双端版本一致。当前 WebSocekt 协议版本默认为13；Origin表明请求来自于哪个站点；Host表明目标主机；Sec-WebSocket-Key用于防止攻击者恶意欺骗服务端；
也就是说，握手时客户端只需要按照上述规定向服务端发出一个 HTTP 请求即可。
服务端收到客户端发起的请求后，按照 RFC6455 的约定验证请求信息。验证通过就代表握手成功，此时服务端应当按照约定将以下内容响应给客户端：
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
服务端会给出代表连接结果的响应状态码，101 状态码表示表示本次请求成功且得到服务端的正确处理。Connection 和 Upgrade 表示已经切换成 websocket 协议。Sec-WebSocket-Accept 则是经过服务器确认，并且加密过后的 Sec-WebSocket-Key，这个值根据客户端发送的 Sec-WebSocket-Key 生成。Sec-WebSocket-Protocol 表明双端约定的子协议。
这样，客户端与服务端就完成了握手操作。双端达成一致，通信协议将由 HTTP 协议切换成 WebSocket 协议。
发送和接收数据
双方握手成功，并确定协议后，就可以互相发送信息了。客户端和服务端互发消息与我们平时在社交应用中互发消息类似，例如：
client: Hello, Server boy.
server: Hello, Client Man.
当然，这里的 Hello, Server boy 和 Hello, Client Man 是有助于我们理解的比喻。实际上，WebSocket 协议的中的数据传输格式并不是这样直接呈现的。
数据帧
WebSocket 双端传输的是一个个数据帧，数据帧的约定原文如下：
In the WebSocket Protocol, data is transmitted using a sequence of frames. To avoid confusing network intermediaries (such as intercepting proxies) and for security reasons that are further discussed in Section 10.3, a client MUST mask all frames that it sends to the server (see Section 5.3 for further details). (Note that masking is done whether or not the WebSocket Protocol is running over TLS.) The server MUST close the connection upon receiving a frame that is not masked. In this case, a server MAY send a Close frame with a status code of 1002 (protocol error) as defined in Section 7.4.1. A server MUST NOT mask any frames that it sends to the client. A client MUST close a connection if it detects a masked frame. In this case, it MAY use the status code 1002 (protocol error) as defined in Section 7.4.1. (These rules might be relaxed in a future specification.)
The base framing protocol defines a frame type with an opcode, a payload length, and designated locations for "Extension data" and "Application data", which together define the "Payload data". Certain bits and opcodes are reserved for future expansion of the
protocol.
A data frame MAY be transmitted by either the client or the server at any time after opening handshake completion and before that endpoint has sent a Close frame (Section 5.5.1).
原文表明，协议中约定数据传输时并不是使用 Unicode 编码，而是使用数据帧（Frame）。下图描述了数据帧的组成：
数据帧由几个部分组成：FIN、RSV1、RSV2、RSV3、opcode、MASK、Payload length、Payload Data、和 Masking-key。下面，我们来了解一下数据帧组件的大体含义或作用。
FIN
占 1 bit，其值为 0 或 1，值对应的含义如下：
0：不是消息的最后一个分片；
1：是消息的最后一个分片；
RSV1 RSV2 RSV3
均占 1 bit，一般情况下值为 0。当客户端、服务端协商采用 WebSocket 扩展时，这三个标志位可以非 0，且值的含义由扩展进行定义。如果出现非零的值，但并没有采用 WebSocket 扩展，则连接出错。
Opcode
占 4 bit，其值可以是 %x0、%x1、%x2、%x3~7、%x8、%x9、%xA 和 %xB~F 中的任何一个。值对应的含义如下：
%x0：表示一个延续帧。当 Opcode 为 0 时，表示本次数据传输采用了数据分片，当前收到的数据帧为其中一个数据分片；
%x1：表示这是一个文本帧（text frame）；
%x2：表示这是一个二进制帧（binary frame）；
%x3-7：保留的操作代码，用于后续定义的非控制帧；
%x8：表示连接断开，是一个控制帧；
%x9：表示这是一个心跳请求（ping）；
%xA：表示这是一个心跳响应（pong）；
%xB-F：保留的操作代码，用于后续定义的控制帧；
Mask
占 1 bit，其值为 0 或 1。值 0 表示要对数据进行掩码异或操作，反之亦然。
Payload length
占 7 bit 或 7+16 bit 或 7+64 bit，表示数据的长度，其值可以是0~127 中的任何一个数。值对应的含义如下：
0~126：数据的长度等于该值；
126：后续 2 个字节代表一个 16 位的无符号整数，该无符号整数的值为数据的长度；
127：后续 8 个字节代表一个 64 位的无符号整数（最高位为 0），该无符号整数的值为数据的长度。
掩码
掩码的作用并不是为了防止数据泄密，而是为了防止早期版本的协议中存在的代理缓存污染攻击（proxy cache poisoning attacks）问题。这里要注意的是从客户端向服务端发送数据时，需要对数据进行掩码操作；从服务端向客户端发送数据时，不需要对数据进行掩码操作。
如果服务端接收到的数据没有进行过掩码操作，服务端需要断开连接。如果Mask是1，那么在Masking-key中会定义一个掩码键（masking key），并用这个掩码键来对数据载荷进行反掩码。
所有客户端发送到服务端的数据帧，Mask都是1。
掩码算法：按位做循环异或运算，先对该位的索引取模来获得 Masking-key 中对应的值 x，然后对该位与 x 做异或，从而得到真实的 byte 数据。
Making-key
占 0 或 4 bytes，其值为 0 或 1。值对应的含义如下：
0：没有 Masking-key；
1：有 Masking-key；
Payload Data
双端接收到数据帧之后，可以根据上述几个数据帧组件的值对 Payload Data 进行处理或直接提取数据。
数据收发流程
在了解到 WebSocket 传输的数据帧格式后，我们再来学习数据收发的流程。
在双端建立 WebSocket 连接后，任何一端都可以给另一端发送消息，这里的消息指的就是数据帧。但平时我们输入或输出的信息都是“明文”，所以在消息发送前需要将“明文”通过一定的方法转换成数据帧。而在接收端，拿到数据帧后需要按照一定的规则将数据帧转换为”明文“。下图描述了双端收发 Hello, world 的主要流程：
保持连接和关闭连接
WebSocket 双端的连接可以保持长期不断开，但实际应用中却不会这么做。如果保持所有连接不断开，但连接中有很多不活跃的成员，那么就会造成严重的资源浪费。
服务端如何判断客户端是否活跃呢？
服务端会定期给所有的客户端发送一个 opcode 为 %x9 的数据帧，这个数据帧被称为 Ping 帧。客户端在收到 Ping 帧时，必须回复一个 opcode 为 %xA 的数据帧（又称为 Pong 帧），否则服务端就可以主动断开连接。
反之，如果服务端在发送 Ping 帧后能够得到客户端 Pong 帧的回应，就代表这个客户端是活跃的，不要断开连接。
如果需要关闭连接，那么一端向另一端发送 opcode 为 %x8 的数据帧即可，这个数据帧被称为关闭帧。
实际代码解读-Python
上面所述均为 RFC6455 中约定的 WebSocket 协议规范。在学习完理论知识后，我们可以通过一些示例（代码伪代码）来加深对上述知识的理解。
Echo Test 是 websocket.org 提供的一个测试平台，开发者可以用它测试与 WebSocket 相关的连接、消息发送和消息接收等功能。下面的代码演示也将基于 Echo Test。
客户端握手
上面提到过，客户端向服务端发出升级请求时，请求头如下：
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
对应的 Python 代码如下：
import requests
url = 'http://echo.websocket.org/?encoding=text'
header = {
"Host": "echo.websocket.org",
"Upgrade": "websocket",
"Connection": "Upgrade",
"Sec-WebSocket-Key": "9GxOnSwEuBNbLeBwiltymg==",
"Origin": "http://www.websocket.or",
"Sec-WebSocket-Protocol": "chat, superchat",
"Sec-WebSocket-Version": "13"
}
resp = requests.get(url, headers=header)
print(resp.status_code)
代码运行后返回的结果为 101，这说明上方代码完成了升级请求的工作。
数据转换为数据帧
数据转换为数据帧涉及到很多知识，同时需要运行完整的 WebSocket 客户端。本篇 Chat 不演示完整的代码结构，仅讲解对应的代码逻辑。完整的 WebSocket 客户端可在 Github 上克隆我编写的开源的库：aiowebsocekt。
克隆到本地后打开 freams.py ，这就是负责数据帧的转换处理的主要文件。
首先看 write() 方法，发送端发送数据时，数据会经过该方法。write() 方法的完整代码如下：
async def write(self, fin, code, message, mask=True, rsv1=0, rsv2=0, rsv3=0): """Converting messages to data frames and sending them. Client data frames must be masked,so mask is True. """ head1, head2 = self.pack_message(fin, code, mask, rsv1, rsv2, rsv3) output = io.BytesIO() length = len(message) if length < 126: output.write(pack('!BB', head1, head2 | length)) elif length < 2**16: output.write(pack('!BBH', head1, head2 | 126, length)) elif length < 2**64: output.write(pack('!BBQ', head1, head2 | 127, length)) else: raise ValueError('Message is too long') if mask: # pack mask mask_bits = pack('!I', random.getrandbits(32)) output.write(mask_bits) message = self.message_mask(message, mask_bits) output.write(message) self.writer.write(output.getvalue())
首先，调用 pack_message() 方法构造数据帧中的 FIN、Opcode、RSV1、RSV2、RSV3。然后根据消息的长度构造数据帧中的 Payload length。接着根据发送端是客户端或服务端对数据进行掩码。最后将数据放到数据帧中，并将数据帧发送给接收端。这里用到的 pack_message() 方法代码如下：
@staticmethod
def pack_message(fin, code, mask, rsv1=0, rsv2=0, rsv3=0):
"""Converting message into data frames
conversion rule reference document:
https://tools.ietf.org/html/rfc6455#section-5.2
"""
head1 = (
(0b10000000 if fin else 0)
| (0b01000000 if rsv1 else 0)
| (0b00100000 if rsv2 else 0)
| (0b00010000 if rsv3 else 0)
| code
)
head2 = 0b10000000 if mask else 0 # Whether to mask or not
return head1, head2
用于执行掩码操作的 message_mask() 方法代码如下：
@staticmethod
def message_mask(message: bytes, mask):
if len(mask) != 4:
raise FrameError("The 'mask' must contain 4 bytes")
return bytes(b ^ m for b, m in zip(message, cycle(mask)))
以上就是数据转换为数据帧并发送给接收端的主要代码。
数据帧转换为数据
同样是 freams.py 文件，这次我们来看 read() 方法。接收端接收数据后，数据会经过该方法。read() 方法的完整代码如下：
async def read(self, text=False, mask=False, maxsize=None):
"""return information about message
"""
fin, code, rsv1, rsv2, rsv3, message = await self.unpack_frame(mask, maxsize)
await self.extra_operation(code, message) # 根据操作码决定后续操作
if any([rsv1, rsv2, rsv3]):
logging.warning('RSV not 0')
if not fin:
logging.warning('Fragmented control frame:Not FIN')
if code is DataFrames.binary.value and text:
if isinstance(message, bytes):
message = message.decode()
if code is DataFrames.text.value and not text:
if isinstance(message, str):
message = message.encode()
return message
首先，调用 unpack_frame() 方法从数据帧中提取出 FIN、Opcode、RSV1、RSV2、RSV3 和 Payload Data（代码中是 message）。然后根据 Opcode 决定后续的操作，例如提取数据、关闭连接、发送 Ping 帧或 Pong 帧等。
unpack_frame() 方法的完整代码如下：
async def unpack_frame(self, mask=False, maxsize=None):
reader = self.reader.readexactly
frame_header = await reader(2)
head1, head2 = unpack('!BB', frame_header)
fin = True if head1 & 0b10000000 else False
rsv1 = True if head1 & 0b01000000 else False
rsv2 = True if head1 & 0b00100000 else False
rsv3 = True if head1 & 0b00010000 else False
code = head1 & 0b00001111
if (True if head2 & 0b10000000 else False) != mask:
raise FrameError("Incorrect masking")
length = head2 & 0b01111111
if length == 126:
message = await reader(2)
length, = unpack('!H', message)
elif length == 127:
message = await reader(8)
length, = unpack('!Q', message)
if maxsize and length > maxsize:
raise FrameError("Message length is too long)".format(length, maxsize))
if mask:
mask_bits = await reader(4)
message = self.message_mask(message, mask_bits) if mask else await reader(length)
return fin, code, rsv1, rsv2, rsv3, message
从数据帧中提取 FIN、RSV1、Opcode 和 Payload Data（代码中是 message） 等组件时，使用的是按位与运算。接着根据是否掩码调用 message_mask() 方法，最后将得到的组件返回给调用方。
总结
本篇 Chat 我们了解了 WebSocekt 协议的来源，并讨论了它的优点。然后解读 RFC6455 中对 WebSocket 的约定，了解到双端交互流程、保持连接和关闭连接方面的知识。最后学习到如何将 WebSocket 协议转换为具体的代码。
WebSocket 有几个关键点：握手、数据与数据帧的转换、保持连接的 Ping 帧和 Pong 帧、主动关闭连接的关闭帧。希望大家在看过本篇 Chat 后，能够对 WebSocket 协议有一个全新的认识。
原文：https://juejin.im/post/5d4cbc0cf265da038f47fa37