WhatsApp抓包分析

1. 引言

WhatsApp 是当前主流的端到端加密（E2EE）即时通信系统，其通信协议基于 TLS、QUIC 以及未公开私有协议实现。由于应用层 Payload 与实时信令均经过加密保护，因此无法像传统明文协议一样直接解析消息内容、信令字段及协议结构。本文并不尝试对 WhatsApp 私有协议进行逆向，而是采用网络行为分析的方法，通过 Wireshark 抓包、差分操作等方式，对 WhatsApp的抓包进行分析与推断。

分析重点包括：

• 连接与传输层分析
• 心跳周期观察
• 聊天消息状态机分析
• 通话分析

2. 连接与传输层分析

2.1 操作步骤

1.开启 Wireshark 抓包；

2.冷启动 WhatsApp；

3.执行多种典型业务操作，包括：

• 查看用户 Profile；
• 查看群组与频道信息；
• 修改群设置；
• 发送文本消息；
• 标星消息；
• 发送图片与文件；
• 拨打语音/视频通话；

4.记录不同操作下的连接变化、流量模式及协议特征。

2.2 过程分析

• WhatsApp 已大量使用 QUIC

  证据：大量Protocol = QUIC，web.whatsapp.com，static.whatsapp.net，media-sin2-3.cdn.whatsapp.net，pps.whatsapp.net都出现：QUIC Initial

• 存在明显"长连接复用"特征

  web.whatsapp.com 在整个抓包过程中持续存在 QUIC 连接，但并未出现传统 HTTP/1.1 场景下大量短生命周期 TCP/TLS 握手。这说明 WhatsApp Web 更倾向于基于 HTTP/2 / HTTP/3 的长连接复用机制，而非"一请求一连接"的传统模式。

• 存在"不同业务域名拆分"

  实时核心：web.whatsapp.com

  静态资源： static.whatsapp.net

  媒体 CDN：media-sinx-x.cdn.whatsapp.net

  图片/头像：pps.whatsapp.net

因为在抓包中可以观察到，WhatsApp Web 的流量在同一 443 端口上同时承载了 HTTP/2 请求（如 /ajax/）与长连接通信（WebSocket / 可能的 QUIC/UDP 连接），且不同功能域名（如 web.whatsapp.com、pps.whatsapp.net、media-sinx-x.cdn.whatsapp.net）在连接建立阶段均携带不同的 TLS SNI 信息。因此可以推测：其服务端在 TLS 握手阶段基于 SNI 对流量进行分流，将 HTTP API 请求、实时信令通道以及媒体资源访问路由到不同的后端集群或不同协议栈（HTTP/2 RPC 服务与长连接/QUIC 通道），从而实现统一入口下的多通道通信架构。

2.3 结论推断

WhatsApp Web 已广泛使用 QUIC（HTTP/3）及 HTTP/2 长连接机制，通信呈现明显的连接复用与多路复用特征。在抓包中可观察到多个业务域名均存在 QUIC Initial 报文，表明其已在 UDP/443 上建立基于 QUIC 的传输通道。同时，整个通信过程中未观察到传统 HTTP/1.1 场景下大量短连接与频繁 TLS 重建的特征，说明其 HTTP API 已从"一请求一连接"模式演进为基于 HTTP/2 / HTTP/3 的长连接复用模型。

综合分析可推断：

1. WhatsApp Web 已大规模采用 QUIC（HTTP/3）作为核心传输机制；
2. HTTP API 与实时通信均依赖长连接与多路复用通道；
3. 不同业务域名通过 TLS SNI 进行连接级路由分发（域名维度分流）；
4. 整体通信架构已演进为 HTTP/2 + HTTP/3（QUIC）统一承载的现代长连接体系。

备注：

1、尝试了Wireshark + SSLKEYLOGFILE方法（原理：把 TLS 会话密钥从浏览器进程导出，让 Wireshark 具备解密能力）和 使用 Fidder Anywhere抓包依旧无法观察到语义化业务 HttpAPI（如 getXXXInfo）调用，推测WhatsApp为基于统一 RPC Endpoint 的 HTTP/2 请求模型（Fidder抓到的几乎为统一的：Post /ajax/bootloader-endpoint）；

2、ChatGPT根据抓包信息及人机讨论给出的WhatsApp组网方式推断图（供参考）：

3. 心跳周期分析

3.1 操作步骤

1. 启动 WhatsApp；
2. 开启 Wireshark 抓包；
3. 不进行任何操作抓包2000秒以上；

3.2 过程分析

1、长连接IP地址定位

通过wireshark中的conversations的统计发现：其中57.144.187.32的持续时间是528，其他2个IP时间持续时间很少；结合57.144.187.32 IP归属查询结果为：新加坡/Facebook Inc，因此确认当前QUIC长连接的IP地址为：57.144.187.32

2、WireShark IO Graphs图表统计找发包规律

从 I/O Graph 可以观察到，在约 244、546、853、1151、1446、1748、2050 秒附近存在规律性的发包波峰。

备注：以上时间点均通过UI自带功能手工测量读取（例如：上图中横轴小圆点位置时间为52s）；

差值明细：

546  - 244  = 302
853  - 546  = 307
1151 - 853  = 298
1446 - 1151 = 295
1748 - 1446 = 302
2050 - 1748 = 302

在真实网络环境里 ±5s 已经可以认为是"稳定周期"，在互联网系统里300秒一个极经典的值，常见于：

类型	常见周期
NAT mapping refresh	30~300s
Session refresh	300s
Token validation	300s
IM heartbeat	240~300s
Edge keepalive	300s
Idle timeout prevention	300s

3.3 结论推断

在约 2300 秒持续抓包中，观察到全局流量存在稳定约 300 秒周期的网络行为，结合 QUIC 长连接、小包持续交换及周期性突发流量特征，推测该行为可能与 session maintenance、keepalive 或应用层心跳机制有关。

备注：

在现代 IM 架构中，心跳机制通常与客户端类型强绑定，不同端（PC、Mobile、Web）由于操作系统后台限制、网络稳定性及功耗约束差异，往往采用不同的心跳策略。PC 端通常具备更稳定的长连接环境，心跳周期相对更长且更稳定；而移动端则受限于省电与后台调度机制，心跳更倾向于自适应与动态调整。Web 端则进一步受浏览器生命周期限制，心跳策略通常依赖底层 WebSocket/QUIC 连接状态管理。因此，工业级 IM 系统一般不会采用统一固定心跳周期，而是采用基于客户端类型与连接状态的分层自适应保活机制。

4. 聊天分析

4.1 操作步骤

1. 启动whatsApp；
2. 开启抓包，找到whatsApp服务端IP（找IP方法参考前述章节相关描述），并以此作为过滤条件；
3. 进行多条文本消息发送；

4.2 过程分析

4.2.1 接收方不在线（单钩未达）

上图中带底色区域为 3 次文本消息发送过程中产生的流量增长区间。从抓包结果可观察到，在每次消息发送过程中，均存在如下稳定通信模式：

1.客户端首先向服务端发送一条较大的 TLS Application Data；

2.服务端向客户端返回一条固定长度（144B）的 TLS Application Data；

结合时间顺序与通信方向分析，该行为特征符合典型即时通信系统中的"消息发送（Send）→ 服务端确认（ServerACK）"交互模型。

进一步观察发现，服务端返回的 TLS Application Data 长度均稳定为 144B。由于即时通信系统中的 ACK 类消息通常仅包含 messageId、状态码、时间戳等固定长度字段，因此其加密后的 TLS Record 长度亦表现出较强一致性。基于此，可推断该固定长度报文属于消息发送后的服务端业务确认报文。此外，由于实验场景中接收方处于离线状态，抓包过程中未观察到后续 Deliver/DeliverACK 或 Read/ReadACK 相关流量符合预期。推测在接收方离线场景下，可将消息发送状态机抽象为：

Send → SendACK

备注：

因SendACK约 144 字节显著高于 MQTT 等轻量发布确认协议的典型控制报文开销范围（约 20--40 字节），结合 TLS 记录层额外开销有限，该差异更可能来源于业务层状态字段的携带。由此可推测 WhatsApp 私有协议在控制面设计上相较 MQTT 更为复杂。

4.2.2 接收方在线未读（双钩送达未读）

上图中带底色区域为消息接收方移动端在线时 2 次文本消息发送过程中产生的流量增长区间。从抓包结果可观察到，在每次消息发送过程中，均存在如下稳定通信模式：

1.客户端首先向服务端发送一条较大的 TLS Application Data；

2.服务端向客户端返回一条固定长度（144B）的 TLS Application Data；

3.服务端会继续向客户端下发一条中等长度的 TLS Application Data（约137B）。

4.客户端会返回一条长度相对较小且稳定的 TLS Application Data（约134B）。

根据前述分析1，2为send，sendAck；之后成对的包长度均稳定为 137B，134B，由于即时通信系统中的 msgDeliver/msgDeliverAck 字段和值长度一般固定，因此推测在接收方在线未读场景下，可将消息发送状态机抽象为：

Send → SendACK →Deliver→ DeliverACK

此外，由于实验场景中接收方消息未读，抓包过程中未观察到后续 Read/ReadACK 相关流量符合预期。

备注：
接收方PC+手机多端在线抓包对比

上图中带底色区域为消息接收方手机&PC均在线时 2 次文本消息发送过程中产生的流量增长区间。对比：接收方手机1端在线的抓包正多出一对TLS Application Data，符合多出一对PC端送达的Deliver & DeliverAck的预期；

4.2.3 接收方在线已读（双钩送达已读）

客户端操作步骤：

1. 发送方发1条文本消息，接收方1端在线；
2. 发送方UI显示双钩以达之后接收方查看消息；
3. 上述步骤重复2次；

上图中带底色区域为消息接收方移动端在线场景下，2 次文本消息发送及后续消息读取过程中产生的流量增长区间。从抓包结果可观察到，在每次消息发送过程中，均存在如下稳定通信模式：

1.客户端首先向服务端发送一条较大的 TLS Application Data；

2.服务端向客户端返回一条固定长度（144B）的 TLS Application Data；

3.服务端继续向客户端下发一条中等长度的 TLS Application Data（约137B）；

4.客户端返回一条长度相对较小且稳定的 TLS Application Data（约134B）。

此外，在接收方实际查看消息后，还可额外观察到一组新的双向交互：

5.服务端向客户端下发一条新的 TLS Application Data（第1条消息约216B，第2条消息约139B）；

6.客户端随后返回一条长度稳定的 TLS Application Data（约136B）。

根据前述分析，第1、2阶段分别对应 Send 与 SendACK。随后出现的 137B / 134B 稳定双向交互，在两次实验中均保持一致，且与接收方在线未读状态严格对应。由于即时通信系统中的 msgDeliver / msgDeliverAck 类状态字段通常具有固定结构与固定长度，因此可推测该阶段对应消息送达状态同步过程，即：

Send → SendACK → Deliver → DeliverACK

进一步地，在接收方实际查看消息后，抓包中稳定出现额外一组新的双向交互（216B/136B 或 139B/136B），且该交互仅在消息被读取后触发。因此可进一步推测该阶段与消息已读状态同步相关，对应：

Read → ReadACK

综上，在当前实验场景下，可将 WhatsApp 消息发送状态机抽象为：

Send → SendACK → Deliver → DeliverACK → Read → ReadACK

5. 通话分析

5.1 操作步骤

1. 开启抓包，并根据IP过滤；
2. 被叫不在线前提下，主叫发起通话，振铃一段时间之后主叫取消通话；

5.2 分析推论

1. 抓包数据较多且无明显规律性，无法精确建立网络包与应用层动作的一一映射；
2. 通话建立阶段出现连续大包突发（在约 4.18 秒附近出现），说明服务端在通话建立阶段，向客户端集中同步了大量会话相关状态数据。该行为明显不同于传统 HTTP API 的单次请求/响应模式，更接近：长连接实时信令同步，因此推论WhatsApp音视频通话控制高度依赖长连接实时信令。

6. 推论总结

由于 WhatsApp 采用 E2EE（端到端加密）、私有协议以及 TLS/QUIC 等加密传输机制，无法通过网络抓包直接获取明文业务字段及协议语义，因此本文仅能基于客户端网络行为、报文长度特征、通信时序及状态变化进行推断分析。相关结论属于行为级推测，可能与实际协议实现存在偏差，仅供参考，主要推论总结如下：

• WhatsApp 已大规模采用 QUIC（HTTP/3）作为核心传输机制，不同业务域名通过 TLS SNI 进行连接级路由分发；
• WhatsApp 私有协议在控制面设计上相较 MQTT 更为复杂，并非典型轻量 Pub/Sub ACK 模型；
• WhatsApp 客户端保活心跳周期约为 300 秒；
• WhatsApp 消息状态机： Send → SendACK →Deliver→ DeliverACK → Read->ReadACK；
• WhatsApp 音视频通话控制更可能依赖基于长连接的实时信令机制，而非传统 HTTP Request/Response 模型。