WebSocket 拆解到字节：从 HTTP 握手到掩码与心跳

WebSocket 拆解到字节：从 HTTP 握手到掩码与心跳

实验说明：本篇的线缆字节抓取，是在分配的 lab 服务器s1（公网119.3.254.184）上，
用纯 Python 标准库最小实现完成的（同机回环127.0.0.1:8765，服务端即本机）。
执行期间该机曾因源 IP 被云厂商 HSS 风控临时不可达，恢复后在 s1 重跑，
抓到的字节与之前完全一致（WebSocket 线缆格式是确定性的，与运行平台无关）。
文中所有握手/帧字节均为真实程序输出，逐字节做了人工核对（含 Sec-WebSocket-Accept 客户端/服务端比对一致）。

0. 引言：为什么有了 HTTP 还要 WebSocket

假设你做一个聊天室或实时行情：

• 用HTTP 轮询：客户端每 2 秒GET /msg问"有新消息吗"，99% 的回答是"没有"。浪费带宽、延迟高、服务端被空轮询拖垮。
• 用HTTP 长轮询：服务端 holds 住请求直到有消息——但每次消息都结束一次 HTTP 事务，要重新建连。

根本矛盾是：HTTP 是"一问一答、服务端不能主动推"的半双工模型。WebSocket 干的事，就是借一次 HTTP 握手"升级"成一条全双工长连接，之后客户端和服务端想发就发，不必再带 HTTP 头。

本篇目标：把这次"升级"和之后的每个帧，抓成原始字节，逐位解读。

HTTP 世界： 客户端 ──请求──► 服务端 ──响应──► 客户端 （服务端不能主动） WebSocket： 客户端 ◄═════ 全双工长连接 ═════► 服务端 （双方随时发）

1. 一、握手：一次 HTTP Upgrade 到 101

WebSocket 不是凭空出来的，它复用 HTTP 的端口（通常 80/443），靠Upgrade头把连接"升舱"。

1.1 客户端发出的握手请求（真实字节）

我们用最小实现手工构造了握手，下面是socket.sendall出去的原始字节（hexdump）：

0000: 47 45 54 20 2f 63 68 61 74 20 48 54 54 50 2f 31 GET /chat HTTP/1 0010: 2e 31 0d 0a 48 6f 73 74 3a 20 31 32 37 2e 30 2e .1..Host: 127.0. 0020: 30 2e 31 3a 38 37 36 35 0d 0a 55 70 67 72 61 64 0.1:8765..Upgrad 0030: 65 3a 20 77 65 62 73 6f 63 6b 65 74 0d 0a 43 6f e: websocket..Co 0040: 6e 6e 65 63 74 69 6f 6e 3a 20 55 70 67 72 61 64 nnection: Upgrad 0050: 65 0d 0a 53 65 63 2d 57 65 62 53 6f 63 6b 65 74 e..Sec-WebSocket 0060: 2d 4b 65 79 3a 20 4d 44 45 79 4d 7a 51 31 4e 6a -Key: MDEyMzQ1Nj 0070: 63 34 4f 57 46 69 59 32 52 6c 5a 67 3d 3d 0d 0a c4OWFiY2RlZg==.. 0080: 53 65 63 2d 57 65 62 53 6f 63 6b 65 74 2d 56 65 Sec-WebSocket-Ve 0090: 72 73 69 6f 6e 3a 20 31 33 0d 0a 0d 0a rsion: 13....

转成可读文本就是：

GET /chat HTTP/1.1 Host: 127.0.0.1:8765 Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: MDEyMzQ1Njc4OWFiY2RlZg== Sec-WebSocket-Version: 13

关键字段：

1.2 服务端回 101 Switching Protocols（真实字节）

0000: 48 54 54 50 2f 31 2e 31 20 31 30 31 20 53 77 69 HTTP/1.1 101 Swi 0010: 74 63 68 69 6e 67 20 50 72 6f 74 6f 63 6f 6c 73 tching Protocols 0020: 0d 0a 55 70 67 72 61 64 65 3a 20 77 65 62 73 6f ..Upgrade: webso 0030: 63 6b 65 74 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e cket..Connection 0040: 3a 20 55 70 67 72 61 64 65 0d 0a 53 65 63 2d 57 : Upgrade..Sec-W 0050: 65 62 53 6f 63 6b 65 74 2d 41 63 63 65 70 74 3a ebSocket-Accept: 0060: 20 42 41 43 53 63 43 4a 50 4e 71 79 7a 2b 55 42 BACScCJPNqyz+UB 0070: 6f 71 4d 48 38 39 56 6d 55 52 6f 41 3d 0d 0a 0d oqMH89VmURoA=... 0080: 0a .

可读文本：

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

注意：服务端没有回Sec-WebSocket-Key，而是回了一个完全不同的Sec-WebSocket-Accept。这个值是怎么来的？下面手算验证。

1.3 手工计算 Sec-WebSocket-Accept（SHA1 + Base64）

算法（RFC 6455 规定，死规定）：

accept = Base64( SHA1( 客户端Key + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" ) )

所谓GUID（魔法字符串）就是固定的258EAFA5-E914-47DA-95CA-C5AB0DC85B11。我们用 Python 手工算一次，并与服务端回的值比对：

importbase64,hashlib GUID="258EAFA5-E914-47DA-95CA-C5AB0DC85B11"key="MDEyMzQ1Njc4OWFiY2RlZg=="# 客户端发出的 Keyaccept=base64.b64encode(hashlib.sha1((key+GUID).encode()).digest()).decode()print(accept)# 输出：BACScCJPNqyz+UBoqMH89VmURoA=

程序里同时打印了"客户端算的"和"服务端回的"，真实输出：

[验证] 客户端用 Key 算出的 Accept = BACScCJPNqyz+UBoqMH89VmURoA= [验证] 服务端返回的 Accept = BACScCJPNqyz+UBoqMH89VmURoA= [验证] 是否一致 = True

二者完全一致。这一步的意义：

客户端 Key 是明文、可逆（Base64）的 —— 不能拿它当认证。 服务端必须把 Key 拼接上固定的 GUID 再做 SHA1+Base64， 这个"拼接+哈希"过程服务端才知道、客户端无法预知， 从而证明：对面确实是一个"懂 WebSocket 握手"的服务端， 而不是某个缓存代理把 WS 请求当普通 HTTP 给糊弄了。

抓包口诀：看到101 Switching Protocols+Sec-WebSocket-Accept，握手就成了；此后的字节不再是 HTTP，而是 WebSocket 帧。任何一方再按 HTTP 去解析都会失败。

2. 二、帧格式：FIN / opcode / MASK / 长度，逐字节解读

握手结束后，所有数据都是帧（frame）。一个帧的头两个字节最关键：

字节0: 0 0 0 0 0 0 0 0 └┬┘ └──┬──┘ │ └── opcode(4bit)：帧类型（1=文本 2=二进制 8=关闭 9=ping A=pong） └──────── FIN(1bit)：是否为消息的最后一个分片 RSV(3bit)：扩展保留，通常为 0 字节1: 0 0 0 0 0 0 0 0 └┬┘ └──┬──┘ │ └── payload len(7bit)：包体长度（0~125；126/127 表示后面还有扩展长度） └──────── MASK(1bit)：是否掩码（客户端→服务端**必须**为 1，服务端→客户端**必须**为 0）

完整帧布局（长度字段分段）：

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-------+-+-------------+-------------------------------+ |F|R|R|R| opcode|M| Payload len | Extended payload length | |I|S|S|S| (4) |A| (7) | (16/64) | |N|V|V|V| |S| | (if len==126/127) | | |1|2|3| |K| | | +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - + | Masking-key (4 bytes, 仅当 MASK=1) ... | +---------------------------------------------------------------+ | Payload Data (XOR 掩码还原后) ... | +---------------------------------------------------------------+

2.1 客户端文本帧（带掩码）——逐字节解读

客户端发HelloWebSocket（14 字节），真实抓到的帧字节：

0000: 81 8e 12 34 56 78 5a 51 3a 14 7d 63 33 1a 41 5b ...4VxZQ:.}c3.A[ 0010: 35 13 77 40 5.w@

我们把它拆开：

字节0 0x81 = 1000 0001 ├ FIN=1（这是消息的最后一片） └ opcode=0x1（文本帧 Text） 字节1 0x8e = 1000 1110 ├ MASK=1（客户端发出，必须掩码） └ Payload len=0x0e=14（包体 14 字节） 字节2-5 12 34 56 78 ← 4 字节掩码密钥（Masking-key） 字节6+ 5a 51 3a 14 7d 63 33 1a 41 5b 35 13 77 40 ← 14 字节【已掩码】的包体

掩码还原（客户端用密钥12 34 56 78对每字节做 XOR，密钥循环使用）：

密文 5a 51 3a 14 7d 63 33 1a 41 5b 35 13 77 40 密钥 12 34 56 78 12 34 56 78 12 34 56 78 12 34 56 78 XOR ──► 48 65 6c 6c 6f 57 65 62 53 6f 63 6b 65 74 H e l l o W e b S o c k e t => 明文 = "HelloWebSocket"

（逐字节验证：5a^12=48='H'，51^34=65='e'，3a^56=6c='l'，14^78=6c='l'，……，40^34=74='t'。）

2.2 服务端回显帧（无掩码）——对照

服务端把同一句原样回显，真实字节：

0000: 81 0e 48 65 6c 6c 6f 57 65 62 53 6f 63 6b 65 74 ..HelloWebSocket

字节0 0x81 = FIN=1, opcode=0x1（文本） 字节1 0x0e = MASK=0（服务端发出，禁止掩码）, len=14 字节2+ 48 65 6c 6c 6f 57 65 62 53 6f 63 6b 65 74 = "HelloWebSocket"（明文，无掩码）

一句话对比：

客户端→服务端： 81 8e [掩码4字节] [XOR后的密文] ← 必须掩码 服务端→客户端： 81 0e [明文] ← 必须不掩码

2.3 长度字段的三种情况

Payload len只有 7 bit，装不下大包，于是规定：

这也是为什么抓大消息时，帧头会从 2 字节"变长"成 4 或 10 字节。

3. 三、掩码机制：为什么客户端必须掩码

3.1 规则

• 客户端发往服务端的帧，MASK 位必须为 1（RFC 6455 强制；否则服务端应直接断开）。
• 服务端发往客户端的帧，MASK 位必须为 0（服务端禁止掩码）。

我们在实验里手工构造时严格遵循：客户端make_frame(opcode, payload, mask=True)，服务端make_frame(opcode, payload, mask=False)。

3.2 掩码不是加密，是为了防"代理缓存污染"

很多人误以为掩码是"安全加密"，其实掩码密钥就在帧里明文传（见 2.1 的12 34 56 78），任何抓包者都能还原。它的真实目的是：

历史背景：早期有"透明代理/缓存代理"会"改写"它们看到的 HTTP 流量。 如果 WS 之前的伪装是普通 HTTP，代理可能把客户端发的字节 误当成"响应体"缓存下来、甚至回给其他后来的连接。 掩码让每个连接的包体字节都"看起来随机"， 代理无法把 A 连接的数据当作 B 连接的缓存， 从而避免"代理缓存污染攻击（Proxy Cache Poisoning）"。 现代视角：这是协议层的"防御性设计"，代价是每个客户端帧多 4 字节密钥 + 一次 XOR。

生产提醒：如果你自己实现 WS 客户端，忘了设 MASK=1，服务端会直接拒绝/断连；若实现服务端却给对方发掩码帧，合规的客户端也应断开。这是最常见的"手写 WS 连不上"原因。

4. 四、Ping / Pong 心跳 与 Close 关闭帧

4.1 Ping / Pong：保活与探活

WebSocket 用Ping（opcode0x9）/Pong（opcode0xA）做心跳。一方发 Ping，另一方必须尽快回 Pong，且 Pong 的包体要与 Ping 一致。

客户端发出 Ping 帧（真实字节）：

0000: 89 80 12 34 56 78 ...4Vx

0x89 = 1000 1001 → FIN=1, opcode=0x9（Ping） 0x80 = 1000 0000 → MASK=1（客户端必须掩码）, len=0（空包体） 12 34 56 78 → 掩码密钥

服务端回 Pong（真实字节）：

0000: 8a 00 ..

0x8a = 1000 1010 → FIN=1, opcode=0xA（Pong） 0x00 = MASK=0, len=0（服务端不掩码，空包体）

心跳的作用：

1. 保活（keep-alive）：长时间无业务数据时，定时 Ping/Pong 让中间设备 不把"看起来空闲"的 TCP 连接回收掉。 2. 探活（liveness）：发个 Ping 等 Pong，超时没回说明对端已死，主动断连。 3. 注意：Ping/Pong 由实现层自动处理，应用代码通常感知不到。

4.2 Close：关闭握手与状态码

关闭 WebSocket 要走关闭握手：一方发Close帧（opcode0x8），另一方回一个Close，然后 TCP 才关闭。

客户端发 Close（带状态码 1000，真实字节）：

0000: 88 82 12 34 56 78 11 dc ...4Vx..

0x88 = 1000 1000 → FIN=1, opcode=0x8（Close） 0x82 = 1000 0010 → MASK=1, len=2 12 34 56 78 → 掩码密钥 11 dc → 掩码后的 2 字节状态码 还原：11^12=03, dc^34=e8 → 0x03e8 = 1000

服务端回 Close（真实字节）：

0000: 88 02 03 e8 ...

0x88 → Close, 0x02 → MASK=0, len=2，03 e8 = 1000（状态码，无掩码）

常用关闭状态码：

要点：** Close 帧的包体前 2 字节是状态码（大端 uint16），之后才是可选原因文本**。双方都发 Close 才算完成关闭握手；只发一次就直接RST关闭 TCP，是不优雅的。

2.4 消息分片（Fragmentation）：大消息怎么切

前面演示的文本帧FIN=1，表示"一条消息一帧发完"。但一条消息可能很大，或边生成边发，这时就要分片：

第一片： FIN=0, opcode=1(文本) 或 2(二进制) ← 声明"这是条消息的开头" 中间片： FIN=0, opcode=0(continuation) ← 续传 最后一片：FIN=1, opcode=0(continuation) ← 续传 + 结束标记

ASCII 示意（把 “Hello World” 拆成两片发）：

客户端 ──► [FIN=0, opcode=1, payload="Hello "] 文本第一片（未结束） 客户端 ──► [FIN=1, opcode=0, payload="World"] continuation 最后一片 服务端 ◄── 把两片按序拼成完整 "Hello World" 再交给应用

铁律：

• 只有数据帧（opcode 1 文本 / 2 二进制）才允许分片；控制帧（8 关闭 / 9 Ping / A Pong）必须FIN=1单帧发完，不得分片——否则接收方无法在控制帧之间插入别的帧，会破坏"控制帧优先"的语义。
• 分片是接收方的责任去重组；中途若收到一个opcode=1的新片，表示上一条消息被丢弃/中断。
• 我们的实验为了清晰，刻意让每条消息FIN=1单帧，省去重组逻辑；真实聊天/二进制流经常分片。

2.5 协议在栈里的位置

把 WebSocket 摆进网络栈，看清它"借 HTTP 握手、跑在 TCP 上"：

┌──────────────────────────────────────────┐ │ 应用数据（JSON / 二进制） │ ├──────────────────────────────────────────┤ │ WebSocket 帧（FIN/opcode/MASK/len） │ ← 本文逐字节拆解的层 ├──────────────────────────────────────────┤ │ TCP （握手后这条连接一直保持） │ ├──────────────────────────────────────────┤ │ IP │ └──────────────────────────────────────────┘ 升级路径：HTTP 请求(80/443) ──101──► 之上直接跑 WS 帧 加密路径：WSS = WebSocket over TLS（443），TLS 插在 TCP 之上、WS 之下

这也是为什么 nginx 反向代理透传 WS 时，必须放行Upgrade/Connection——它本质是"让这条 TCP 连接从 HTTP 语义切到 WS 语义"。

3. 三、掩码机制（续）：密钥就在线上，它真不是加密

3.2（补）掩码密钥是明文传输的

回看 2.1 的客户端帧：81 8e [12 34 56 78] [密文]——12 34 56 78这 4 字节掩码密钥就在帧头里、明文跟着走。任何能抓包的人，都能像我们那样密文 XOR 密钥一秒还原明文。

所以请务必记住：

掩码（MASK） ≠ 加密（Encryption） · 目的：防"缓存代理污染"，让包体看起来随机 · 目的：防窃听 · 密钥随帧明文传输，零保密性 · 密钥经 TLS 协商，保密 · 性能开销：一次 XOR · 性能开销：对称加密 · 提供方：WebSocket 协议本身 · 提供方：TLS（即 WSS）

3.3（补）一个具体的"缓存污染"场景

假设一台老旧透明代理，看到它以为的"HTTP 响应体"就缓存：

无掩码的世界： 客户端A 发 "转账100给甲"，代理把它当"响应"缓存成 key=A 客户端B 发起同名请求，代理直接把 A 的内容回给 B → 污染/错乱 有掩码的世界： 客户端A 的发帧是 XOR 后的随机字节，代理看不懂、也不会当成可缓存响应 → 即便误处理，也只是一堆无意义的随机字节，无法污染他人

现代网络里这类老代理少了，但 RFC 仍强制该规则，手写客户端若漏设 MASK=1，合规服务端会立刻断连——这是"我自己写的 WS 连不上"的头号原因。

4. 四、Ping/Pong 与 Close（续）

4.3（补）子协议协商：Sec-WebSocket-Protocol

除了必填的Key，握手还可以带子协议（subprotocol），用来让"同一端口上的不同应用协议"达成一致：

# 客户端：我支持这两种应用子协议 Sec-WebSocket-Protocol: chat, superchat # 服务端：我选 superchat，并回显（不回则客户端应断开） Sec-WebSocket-Protocol: superchat

注意子协议不是WebSocket 本身的帧格式，而是"帧里面装的是什么应用语义"的约定（如graphql-ws、wamp）。它和Sec-WebSocket-Version: 13一样，是握手阶段一次定死的。

4.4（补）控制帧的优先级

规范规定：控制帧（Close / Ping / Pong）可以插入到数据帧分片之间优先发送。例如正在收一个超大分片消息，此时收到 Ping，接收方应先回 Pong，再继续收剩下的分片。这也是为什么控制帧禁止分片——它必须能"见缝插针"地完整发出。

4.5 选型对比：WebSocket / SSE / 长轮询 到底用谁

实时通信不是只有 WS 一个选项，按"需不需要服务端主动推、单向还是双向"来选：

速选法则：

只需要服务端推、不需要客户端频繁发 → SSE（更简单、自带重连） 两端都要高频互发、低延迟 → WebSocket 无法升级协议、只要"尽量新" → 长轮询兜底

SSE 与 WebSocket 常被并列讨论：SSE 本质是"一条永远不关的 HTTP 响应"，所以天然走 HTTP/2 多路复用、自带断线重连；WebSocket 则是"一条独立长连接"。生产里不要在同一域名下既大量用 SSE 又用 WS，否则连接数会失控。

5. 生产实践建议（Checklist）

1. 握手阶段：确认返回101且Sec-WebSocket-Accept计算正确；反向代理（nginx）要配置proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade";才能把 WS 透传过去（否则卡在握手）。
2. 掩码铁律：客户端帧必须MASK=1，服务端帧必须MASK=0；自己造轮子时这是头号坑。
3. 心跳必做：在应用层或框架层启用 Ping/Pong 保活，并设超时（如 30s 无 Pong 即断），避免半死连接占着资源。
4. 大消息分片：超 125 字节要懂长度字段的 126/127 扩展；生产框架（如websockets、ws）会自动处理分片，别手撕。
5. 优雅关闭：监听close事件，区分1000（正常）与1006（异常掉线）做不同日志/重连策略。
6. 安全：WS 明文易被窃听，公网一律用WSS（WebSocket over TLS）；并对消息做鉴权（连接建立后第一时间校验 token），别让任何人都能连。
7. Nginx 透传配置示例：

location /ws/ { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; # 关键：透传 Upgrade proxy_set_header Connection "Upgrade"; # 关键：把连接标为升级 proxy_read_timeout 3600s; # 长连接别被代理超时掐断 }

6. 总结

本篇把一次完整的 WebSocket 会话抓成原始字节并逐位解读：

• 握手：GET带Upgrade: websocket+Sec-WebSocket-Key；服务端回101+Sec-WebSocket-Accept，后者 =Base64(SHA1(Key + GUID))，我们手算验证了一致。
• 帧头：字节0 的FIN+opcode、字节1 的MASK+Payload len，长度字段用 126/127 扩展。
• 掩码：客户端帧必须掩码（MASK=1，密钥随帧明文传，XOR 还原），服务端帧禁止掩码；掩码是防代理缓存污染，不是加密。
• 心跳：Ping(0x9)→Pong(0xA)，空包体、保活探活。
• 关闭：Close(0x8)带 2 字节状态码（如1000正常），双方各发一次完成握手。

三篇博客走下来，你已从报文结构 / 连接管理 / 状态码，到Cookie / 同源 / 缓存 / 重定向语义，再到WebSocket 全双工帧，把 Web 协议的"地基"亲手摸了一遍。协议不再是你头顶的黑盒，而是可以拆开、可以抓包、可以解释每一位的工程对象。

说明：本篇线缆字节在 lab 服务器s1（公网119.3.254.184）上用纯标准库最小实现抓取（同机回环127.0.0.1:8765）。执行期间该机曾因源 IP 被云厂商 HSS 风控临时不可达，恢复后在 s1 重跑，字节与前述完全一致。所有握手/帧字节均为真实程序输出，未伪造，且未包含任何密钥/口令。