一、引言在实时 Web 应用普及的当下WebSocket 早已取代传统轮询成为在线聊天、行情推送、直播弹幕、协同编辑等场景的主流通信方案。与基于请求 - 响应模型的 HTTP 不同WebSocket 支持全双工长连接数据传输格式更灵活这也给数据采集、接口调试、逆向分析带来了全新的挑战。本文将从协议底层原理出发系统讲解 WebSocket 数据抓取的核心逻辑结合浏览器工具、代理软件、Python 脚本三类主流方案覆盖从基础抓包到进阶对抗的完整实践路径帮助开发者与安全分析人员掌握实时通信数据的采集方法。二、WebSocket 协议核心原理2.1 与 HTTP 的本质区别HTTP 是半双工的请求 - 响应协议每次交互都由客户端主动发起服务端无法主动推送数据而 WebSocket 是全双工协议一次握手后即可建立持久连接客户端与服务端可双向、异步发送数据无需重复建立 TCP 连接开销远低于 HTTP 长轮询。表格特性HTTP/1.1 长轮询WebSocket通信模式客户端请求→服务端响应双向全双工连接状态每次请求独立短连接复用持久长连接数据开销每次携带完整 HTTP 头帧头仅 2-14 字节实时性依赖轮询间隔延迟高毫秒级实时推送2.2 握手流程基于 HTTP 的协议升级WebSocket 的建立并非凭空生成而是依托 HTTP 协议完成握手升级这也是它能兼容现有网络基础设施代理、防火墙的核心原因。完整握手流程如下客户端发起 HTTP GET 请求携带升级标识头httpGET /ws/connect HTTP/1.1 Host: example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ Sec-WebSocket-Version: 13其中Sec-WebSocket-Key是客户端随机生成的 Base64 字符串用于服务端校验握手合法性。服务端返回 101 Switching Protocols 响应完成协议切换httpHTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbKxOoSec-WebSocket-Accept由服务端将客户端 Key 与固定 GUID 拼接后做 SHA1 哈希再 Base64 编码生成用于确认双方均认可协议升级。握手完成后TCP 连接保持后续数据不再以 HTTP 报文传输而是采用 WebSocket 数据帧格式。2.3 数据帧结构WebSocket 传输的最小单位是帧Frame一条完整消息可由一个或多个帧组成。标准帧结构如下plaintext0 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 len126/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 | --------------------------------- - - - - - - - - - - - - - - 核心字段含义FIN1bit标识是否为消息的最后一帧1 表示消息结束Opcode4bit帧类型常见值0x0延续帧分片消息的后续帧0x1文本帧UTF-8 编码0x2二进制帧ProtoBuf、自定义协议等0x8连接关闭帧0x9心跳 Ping 帧0xA心跳 Pong 帧MASK1bit标识 payload 是否被掩码加密客户端发往服务端的帧必须掩码服务端发往客户端的帧无需掩码Payload len数据长度7/16/64 位变长编码Masking-key32 位掩码密钥仅客户端帧存在用于异或解密 payload三、WebSocket 数据抓取的核心原理所有 WebSocket 抓包方案本质上都遵循中间人MITM思路核心是在通信链路中插入代理节点捕获并解析双向传输的帧数据。根据加密类型不同实现难度有显著差异3.1 明文 WS 抓取对于ws://开头的未加密连接数据在 TCP 层直接以明文帧传输只需通过网卡抓包如 Wireshark或端口代理即可直接捕获并解析帧内容无需额外处理。3.2 加密 WSS 抓取当前绝大多数生产环境使用wss://WebSocket over TLS数据在 TLS 加密通道内传输普通网卡抓包只能看到密文。此时必须通过SSL 证书信任实现中间人解密代理工具生成自签名根证书用户在客户端浏览器、系统信任该证书客户端与代理建立 TLS 连接代理与服务端建立独立 TLS 连接代理完成双向 TLS 解密与重加密中间获取明文 WebSocket 帧解析帧结构提取文本 / 二进制 payload 内容3.3 与 HTTP 抓包的核心差异HTTP 抓包只需处理请求 - 响应对而 WebSocket 是流式长连接需持续监听双向帧流HTTP 报文边界清晰WebSocket 存在消息分片、帧拼接问题WebSocket 存在心跳帧、控制帧需过滤非业务数据二进制帧需额外做协议反序列化无法直接读取四、主流抓取方案与实践步骤4.1 方案一浏览器开发者工具最便捷对于浏览器端的 WebSocket 通信Chrome/Edge 自带的 DevTools 是门槛最低的抓取方案无需安装额外软件。操作步骤打开目标网页按 F12 启动开发者工具切换到 Network 面板在筛选栏选择WSWebSocket过滤器刷新页面触发连接建立点击对应的 WebSocket 连接条目切换到Messages标签页即可查看双向传输的所有消息绿色箭头为客户端发送灰色箭头为服务端推送支持单条消息查看原始内容、复制数据也可右键保存全部 HAR 文件做后续分析适用场景前端调试、快速分析业务消息格式、定位通信时序问题缺点是无法自动化、不支持非浏览器客户端。4.2 方案二代理工具跨应用通用Charles、Fiddler、Proxyman 等主流 HTTP 代理工具均原生支持 WebSocket 抓包适合抓取 APP、桌面客户端等非浏览器场景的通信数据。以 Charles 为例的实践流程配置 Charles 代理端口将客户端设备代理指向 Charles 地址安装并信任 Charles 根证书确保 HTTPS 解密生效客户端发起 WebSocket 连接后Charles 会自动识别并在WebSocket分类下展示连接双击连接进入消息面板可实时查看双向文本消息支持时间戳、十六进制查看支持断点修改、重发 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_openon_open, on_messageon_message, on_erroron_error, on_closeon_close ) # run_forever 自动处理重连、ping/pong心跳 ws.run_forever(ping_interval30, ping_timeout10)路线 2被动代理拦截mitmproxy当握手参数存在动态签名、加密逻辑复杂难以逆向时可通过 mitmproxy 搭建本地代理拦截真实客户端的 WebSocket 流量无需破解客户端逻辑即可获取明文数据。自定义拦截脚本示例ws_intercept.pypython运行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, errorsignore) 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(fWebSocket连接关闭共传输{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 接口普遍存在反爬措施常见对抗点握手参数签名Sec-WebSocket-Protocol、自定义 Header、URL 参数携带动态签名需逆向签名算法或通过代理拦截获取有效握手参数消息体加密业务数据做 AES/RSA 加密后再封装进 WebSocket 帧需从客户端代码中提取密钥与加密逻辑频率与行为校验服务端检测消息发送频率、订阅顺序、交互逻辑异常需严格模拟真实客户端的行为时序SSL PinningAPP 端锁定服务端证书导致代理无法解密需通过 Frida Hook、Xposed 模块等方式绕过证书校验5.4 分片消息处理当单条消息体积过大时WebSocket 会拆分为多个延续帧传输抓取时需根据 FIN 位判断消息边界将多帧 payload 拼接后再做业务解析避免单帧解析导致的数据不完整。六、合规与风险提示WebSocket 数据抓取与普通爬虫一样需严格遵守法律法规与平台规则仅可抓取公开可访问的非敏感数据禁止窃取用户隐私、商业机密等未授权信息不得绕过平台安全机制、破坏服务端正常运行高频采集可能构成对计算机信息系统的非法侵入抓取的数据不得用于二次售卖、非法牟利等商业用途遵守目标平台的《用户协议》《robots 协议》避免引发民事侵权甚至刑事风险七、总结WebSocket 抓取的核心本质是对长连接帧流的拦截与解析从便捷的浏览器工具到自动化的脚本方案不同场景对应不同的技术选型。基础场景下代理工具即可满足需求复杂的生产级采集则需要结合协议逆向、加密破解、反爬对抗等综合能力。在实际实践中建议优先通过浏览器与代理工具完成协议分析明确消息格式与业务逻辑后再选择主动模拟或被动拦截的方案实现自动化采集同时始终坚守合规边界合理使用技术能力。