tcpdump 抓包后的流量统计与分析流程设计-linux运维-PHP中文网

tcpdump流量分析需先精准抓包、导出pcap、再分层统计：链路层含mac头，网络层算ip总长，传输层提取tcp payload；结合wireshark过滤、tcp流追踪、io图及时序分析定位业务瓶颈，并与/proc/uid_stat交叉验证偏差。

tcpdump 抓包后的流量统计与分析流程设计

tcpdump 抓包后的流量统计与分析，核心在于“先抓准、再导出、后分层处理”。它不是一次性操作，而是围绕目标（比如某 App 的真实上传量、某接口的响应延迟、某 IP 的异常连接频次）设计的一套闭环流程。关键不在命令多复杂，而在每一步是否服务于明确的验证目的。

抓包前必须锁定目标维度，避免数据冗余或遗漏：

指定接口：用 tcpdump -D 查看可用接口（如 wlan0、rmnet0、any），Android 设备常用 any 或具体蜂窝/ Wi-Fi 接口；
限制捕获长度：加 -s 0 确保抓全包（尤其对 HTTPS 或大 payload 场景）；
直接写文件：务必用 -w capture.pcap 保存为标准 PCAP 格式，不建议实时打印分析；
合理过滤：例如只抓某 App 的流量，可结合其通信 IP 或端口（如 host 192.168.1.100 and port 8080），或按协议（tcp port 443）缩小范围。

PCAP 文件本身不含“应用层流量”概念，需按协议栈层级分别计算：

链路层帧大小：Wireshark 中 Statistics → Protocol Hierarchy，查看 Ethernet 层总字节数（含 MAC 头、FCS）；
网络层 IP 包大小：筛选 IPv4 流量，Sum column → Length 列求和（即 IP Total Length 字段之和）；
传输层有效载荷：对 TCP/UDP 流，用 Follow TCP Stream → Save As，提取 payload 字节数，或用 tshark 命令：
tshark -r capture.pcap -T fields -e tcp.len | awk '{sum += $1} END {print sum}'；
注意：同一笔 HTTP 请求，在不同层级统计结果可能相差 20%~40%，因含 TCP/IP 头、TLS 加密开销、重传包等。

单纯看总量不够，要回溯到业务动作：

在 Wireshark 中使用显示过滤器定位关键会话，例如：http.request.method == "POST" && http.host contains "api.example.com"；
右键数据包 → Follow → TCP Stream，查看完整请求-响应交互，确认是否分块传输、有无 304 缓存、是否遭遇服务端超时；
用 Time Column + IO Graph（Statistics → IO Graph）观察流量时间分布，识别突发上传、长连接空闲、心跳间隔异常等模式；
检查 Expert Info（Analyze → Expert Info）汇总重传、重复 ACK、零窗口等异常事件，辅助判断是网络问题还是应用逻辑缺陷。

抓包结果需与 Android 本地统计比对，才能确认偏差来源：

读取 /proc/uid_stat/[UID]/tcp_rcv 和 tcp_snd，获取内核记录的该 UID 收发字节数；
对比 Wireshark 统计的 IP 层收发总量，若差异显著（如 >15%），需检查是否含 ICMP/ARP/广播包、是否漏抓某些接口（如 rmnet_data0）、或是否存在内核 bypass 流量（如某些厂商定制 socket 实现）；
若 App 使用 UDP 或 QUIC，tcpdump 默认不捕获 UDP payload（除非加 -A/-X），而 /proc/uid_stat 会统计，此时需额外过滤 udp 并启用 -A 查看内容。