WebSocket 服务器的工作原理，特性，应用场景

先给一个整体直觉：WebSocket 服务器 = 一种“长期在线的 HTTP 连接管理器 + 全双工消息管道”。它和传统 HTTP 最大的区别就是：连接一旦升级成功，就不再是“请求-响应一次就结束”，而是双方随时都能发消息，直到一方主动断开为止。

下面我分几块说：

• 工作原理：握手 → 升级协议 → 持续收发消息

• WebSocket 服务器的典型特性

• 常见应用场景（以及为什么要用它而不是轮询 / 长轮询）

一、WebSocket 服务器的工作原理

1. 从 HTTP 握手开始

WebSocket 设计时就是“复用 HTTP 端口”的，所以建立连接时走的是标准 HTTP 请求，只是加了一些特殊头，让服务器知道“我要升级为 WebSocket”。

典型握手（客户端 → 服务器）大概长这样：

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: https://example.com

服务器收到后如果接受升级，会返回：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

关键点：

• Upgrade: websocket / Connection: Upgrade：告诉对方“我们切换协议了，不再是普通 HTTP。”

• Sec-WebSocket-Key：客户端发一个随机 base64 字符串。

• 服务器用这个 Key + 固定 GUID 做一次 SHA1 → base64，得到 Sec-WebSocket-Accept，用来防止中间人假冒和一些误用场景。

一旦 101 返回成功，双方就不再说 HTTP，而是说 WebSocket 帧格式。

2. 协议升级后：长连接 + 全双工

从服务器视角看，升级成功后，做的事情和一个“长连接 TCP 服务器”很像：

1. 把这个 socket 从 HTTP 处理模块“移交”给 WebSocket 会话管理模块。

2. 为每个连接维护会话状态（用户 ID、房间、订阅主题等）。

3. 循环处理：

   • 解析客户端发来的 WebSocket 帧（opcode、fin、mask、payload 等）

   • 处理文本 / 二进制消息

   • 发送服务器主动推送的消息（比如广播、心跳、通知）

4. 连接断开时，清理资源，通知业务层（例如从聊天室移除、广播“用户下线”等）。

WebSocket 帧基本结构：

• FIN 位：是否是一个消息的最后一帧（支持拆包发送）。

• opcode：0x1 文本，0x2 二进制，0x8 关闭，0x9 ping，0xA pong 等。

• mask：客户端发送给服务器的帧必须带 mask（出于浏览器安全考虑）。

• payload length：数据长度，可变长编码。

• payload data：真正的业务数据（文本 / 二进制）。

服务器要做的是：

• 从 socket 中不断读取字节流。

• 组装成完整帧 → 还原 payload。

• 业务处理 →（可能）给一个 / 多个客户端发送新帧。