一、引言

在实时 Web 应用普及的当下，WebSocket 早已取代传统轮询，成为在线聊天、行情推送、直播弹幕、协同编辑等场景的主流通信方案。与基于请求 - 响应模型的 HTTP 不同，WebSocket 支持全双工长连接，数据传输格式更灵活，这也给数据采集、接口调试、逆向分析带来了全新的挑战。

本文将从协议底层原理出发，系统讲解 WebSocket 数据抓取的核心逻辑，结合浏览器工具、代理软件、Python 脚本三类主流方案，覆盖从基础抓包到进阶对抗的完整实践路径，帮助开发者与安全分析人员掌握实时通信数据的采集方法。

二、WebSocket 协议核心原理

2.1 与 HTTP 的本质区别

HTTP 是半双工的请求 - 响应协议，每次交互都由客户端主动发起，服务端无法主动推送数据；而 WebSocket 是全双工协议，一次握手后即可建立持久连接，客户端与服务端可双向、异步发送数据，无需重复建立 TCP 连接，开销远低于 HTTP 长轮询。

表格

2.2 握手流程：基于 HTTP 的协议升级

WebSocket 的建立并非凭空生成，而是依托 HTTP 协议完成握手升级，这也是它能兼容现有网络基础设施（代理、防火墙）的核心原因。

完整握手流程如下：

1. 客户端发起 HTTP GET 请求，携带升级标识头：

   http

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

   其中Sec-WebSocket-Key是客户端随机生成的 Base64 字符串，用于服务端校验握手合法性。

2. 服务端返回 101 Switching Protocols 响应，完成协议切换：

   http

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

   Sec-WebSocket-Accept由服务端将客户端 Key 与固定 GUID 拼接后做 SHA1 哈希再 Base64 编码生成，用于确认双方均认可协议升级。

3. 握手完成后，TCP 连接保持，后续数据不再以 HTTP 报文传输，而是采用 WebSocket 数据帧格式。

2.3 数据帧结构

WebSocket 传输的最小单位是帧（Frame），一条完整消息可由一个或多个帧组成。标准帧结构如下：

plaintext

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 payload len==126/127) | | |1|2|3| |K| | | +-+-+-+-+-------+-+-------------+-------------------------------+ | Extended payload length continued, if payload len == 127 | +-------------------------------+-------------------------------+ | |Masking-key, if MASK set to 1 | +-------------------------------+-------------------------------+ | Masking-key (continued) | Payload Data | +--------------------------------- - - - - - - - - - - - - - - +

核心字段含义：

• FIN（1bit）：标识是否为消息的最后一帧，1 表示消息结束
• Opcode（4bit）：帧类型，常见值：
  • 0x0：延续帧（分片消息的后续帧）
  • 0x1：文本帧（UTF-8 编码）
  • 0x2：二进制帧（ProtoBuf、自定义协议等）
  • 0x8：连接关闭帧
  • 0x9：心跳 Ping 帧
  • 0xA：心跳 Pong 帧
• MASK（1bit）：标识 payload 是否被掩码加密，客户端发往服务端的帧必须掩码，服务端发往客户端的帧无需掩码
• Payload len：数据长度，7/16/64 位变长编码
• Masking-key：32 位掩码密钥，仅客户端帧存在，用于异或解密 payload

三、WebSocket 数据抓取的核心原理

所有 WebSocket 抓包方案本质上都遵循中间人（MITM）思路，核心是在通信链路中插入代理节点，捕获并解析双向传输的帧数据。根据加密类型不同，实现难度有显著差异：

3.1 明文 WS 抓取

对于ws://开头的未加密连接，数据在 TCP 层直接以明文帧传输，只需通过网卡抓包（如 Wireshark）或端口代理即可直接捕获并解析帧内容，无需额外处理。

3.2 加密 WSS 抓取

当前绝大多数生产环境使用wss://（WebSocket over TLS），数据在 TLS 加密通道内传输，普通网卡抓包只能看到密文。此时必须通过SSL 证书信任实现中间人解密：

1. 代理工具生成自签名根证书，用户在客户端（浏览器、系统）信任该证书
2. 客户端与代理建立 TLS 连接，代理与服务端建立独立 TLS 连接
3. 代理完成双向 TLS 解密与重加密，中间获取明文 WebSocket 帧
4. 解析帧结构，提取文本 / 二进制 payload 内容

3.3 与 HTTP 抓包的核心差异

• HTTP 抓包只需处理请求 - 响应对，而 WebSocket 是流式长连接，需持续监听双向帧流
• HTTP 报文边界清晰，WebSocket 存在消息分片、帧拼接问题
• WebSocket 存在心跳帧、控制帧，需过滤非业务数据
• 二进制帧需额外做协议反序列化，无法直接读取

四、主流抓取方案与实践步骤

4.1 方案一：浏览器开发者工具（最便捷）

对于浏览器端的 WebSocket 通信，Chrome/Edge 自带的 DevTools 是门槛最低的抓取方案，无需安装额外软件。

操作步骤：

1. 打开目标网页，按 F12 启动开发者工具，切换到 Network 面板
2. 在筛选栏选择WS（WebSocket）过滤器，刷新页面触发连接建立
3. 点击对应的 WebSocket 连接条目，切换到Messages标签页
4. 即可查看双向传输的所有消息，绿色箭头为客户端发送，灰色箭头为服务端推送
5. 支持单条消息查看原始内容、复制数据，也可右键保存全部 HAR 文件做后续分析

适用场景：前端调试、快速分析业务消息格式、定位通信时序问题；缺点是无法自动化、不支持非浏览器客户端。

4.2 方案二：代理工具（跨应用通用）

Charles、Fiddler、Proxyman 等主流 HTTP 代理工具均原生支持 WebSocket 抓包，适合抓取 APP、桌面客户端等非浏览器场景的通信数据。

以 Charles 为例的实践流程：

1. 配置 Charles 代理端口，将客户端设备代理指向 Charles 地址
2. 安装并信任 Charles 根证书，确保 HTTPS 解密生效
3. 客户端发起 WebSocket 连接后，Charles 会自动识别并在WebSocket分类下展示连接
4. 双击连接进入消息面板，可实时查看双向文本消息，支持时间戳、十六进制查看
5. 支持断点修改、重发 WebSocket 帧，可用于接口测试与参数篡改

注意事项：

• 若客户端做了 SSL Pinning（证书锁定），代理工具无法解密 WSS 流量，需先绕过证书校验
• 二进制格式消息在代理工具中仅显示原始字节，需导出后做反序列化处理

4.3 方案三：Python 脚本化抓取（自动化采集）

对于需要批量采集、持续监听、自动化处理的场景，Python 生态提供了成熟的工具链，分为主动连接模拟和被动代理拦截两种路线。

路线 1：主动连接模拟（websocket-client）

通过逆向分析握手参数与消息格式，直接用代码模拟客户端建立 WebSocket 连接，接收服务端推送数据，适合明确业务逻辑后的稳定采集。

示例代码：

python

运行

import websocket import json import time def on_message(ws, message): """接收服务端消息回调""" try: data = json.loads(message) print(f"收到消息: {data}") # 可在此处做数据持久化、业务处理 except: print(f"原始二进制/非JSON消息: {len(message)}字节") def on_open(ws): """连接建立后回调，发送鉴权与订阅指令""" auth_msg = { "type": "auth", "token": "your_token_here", "timestamp": int(time.time()) } ws.send(json.dumps(auth_msg)) # 订阅业务频道 subscribe_msg = {"type": "subscribe", "channel": "market_btc_usdt"} ws.send(json.dumps(subscribe_msg)) print("连接建立，已发送订阅指令") def on_error(ws, error): print(f"连接错误: {error}") def on_close(ws, close_status_code, close_msg): print(f"连接关闭: {close_status_code} - {close_msg}") if __name__ == "__main__": # 开启心跳自动响应，避免连接被断开 ws = websocket.WebSocketApp( "wss://example.com/ws/endpoint", on_open=on_open, on_message=on_message, on_error=on_error, on_close=on_close ) # run_forever 自动处理重连、ping/pong心跳 ws.run_forever(ping_interval=30, ping_timeout=10)

路线 2：被动代理拦截（mitmproxy）

当握手参数存在动态签名、加密逻辑复杂难以逆向时，可通过 mitmproxy 搭建本地代理，拦截真实客户端的 WebSocket 流量，无需破解客户端逻辑即可获取明文数据。

自定义拦截脚本示例（ws_intercept.py）：

python

运行

from mitmproxy import ctx from mitmproxy.websocket import WebSocketMessage def websocket_message(flow): """WebSocket 消息拦截钩子""" # 获取WebSocket流对象 ws_flow = flow.websocket if not ws_flow.messages: return # 获取最新一条消息 msg: WebSocketMessage = ws_flow.messages[-1] # 区分消息方向 direction = "客户端→服务端" if msg.from_client else "服务端→客户端" # 处理文本消息 if msg.type == "text": content = msg.content.decode("utf-8", errors="ignore") ctx.log.info(f"[{direction}] 文本消息: {content[:200]}") # 可写入文件、转发到数据库等 # 处理二进制消息 elif msg.type == "binary": ctx.log.info(f"[{direction}] 二进制消息: {len(msg.content)}字节") # 可保存原始字节做后续ProtoBuf解析 def websocket_start(flow): """WebSocket 连接建立钩子""" ctx.log.info(f"新WebSocket连接建立: {flow.request.url}") def websocket_end(flow): """WebSocket 连接关闭钩子""" ctx.log.info(f"WebSocket连接关闭，共传输{len(flow.websocket.messages)}条消息")

启动命令：

bash

运行

mitmdump -s ws_intercept.py -p 8080

将客户端代理设置为本地 8080 端口并信任 mitmproxy 证书，即可自动拦截所有 WSS/Ws 流量。

五、进阶难点与对抗方案

5.1 二进制消息反序列化

大量高性能场景使用 ProtoBuf、MessagePack 或自定义二进制协议传输数据，抓包后仅能获取原始字节，需做反序列化解析：

• ProtoBuf 消息：通过逆向客户端 JS/APP 代码提取.proto定义文件，使用protobuf库编译后反序列化
• MessagePack：直接使用msgpack-python库解码，无需额外定义
• 自定义协议：根据字段偏移量、大小端序手动拆解字节流，结合业务逻辑逆向字段含义

5.2 心跳保活与连接维持

WebSocket 长连接极易因网络波动、服务端超时被断开，稳定采集需处理：

• 自动响应服务端 Ping 帧，客户端主动按间隔发送心跳
• 实现断线重连机制，重连后恢复订阅状态
• 记录消息序号，重连后补发缺失数据，避免消息丢失

5.3 鉴权与反爬对抗

生产环境的 WebSocket 接口普遍存在反爬措施，常见对抗点：

1. 握手参数签名：Sec-WebSocket-Protocol、自定义 Header、URL 参数携带动态签名，需逆向签名算法，或通过代理拦截获取有效握手参数
2. 消息体加密：业务数据做 AES/RSA 加密后再封装进 WebSocket 帧，需从客户端代码中提取密钥与加密逻辑
3. 频率与行为校验：服务端检测消息发送频率、订阅顺序、交互逻辑异常，需严格模拟真实客户端的行为时序
4. SSL Pinning：APP 端锁定服务端证书，导致代理无法解密，需通过 Frida Hook、Xposed 模块等方式绕过证书校验

5.4 分片消息处理

当单条消息体积过大时，WebSocket 会拆分为多个延续帧传输，抓取时需根据 FIN 位判断消息边界，将多帧 payload 拼接后再做业务解析，避免单帧解析导致的数据不完整。

六、合规与风险提示

WebSocket 数据抓取与普通爬虫一样，需严格遵守法律法规与平台规则：

1. 仅可抓取公开可访问的非敏感数据，禁止窃取用户隐私、商业机密等未授权信息
2. 不得绕过平台安全机制、破坏服务端正常运行，高频采集可能构成对计算机信息系统的非法侵入
3. 抓取的数据不得用于二次售卖、非法牟利等商业用途
4. 遵守目标平台的《用户协议》《robots 协议》，避免引发民事侵权甚至刑事风险

七、总结

WebSocket 抓取的核心本质是对长连接帧流的拦截与解析，从便捷的浏览器工具到自动化的脚本方案，不同场景对应不同的技术选型。基础场景下代理工具即可满足需求，复杂的生产级采集则需要结合协议逆向、加密破解、反爬对抗等综合能力。

在实际实践中，建议优先通过浏览器与代理工具完成协议分析，明确消息格式与业务逻辑后，再选择主动模拟或被动拦截的方案实现自动化采集，同时始终坚守合规边界，合理使用技术能力。