tcpdump 抓包与 Wireshark 分析实战指南

实际项目中，我们常常会遇到各种扑朔迷离的网络通信问题。在 VoIP、SIP 语音呼叫或 WebRTC 音视频对讲中，对端提示“未检测到按键（DTMF）”或出现音频卡顿、杂音，难以确认 RTP/UDP 报文是否完整到达。面对自研的私有二进制协议或 IoT 设备通信，抓不到明文日志，无法排查报文字段对齐问题。

在这些场景下，应用层日志可能会滞后或失真，但操作系统网卡上流转的真实原始数据包绝不会说谎。

为了高效排查上述问题，我们可以在服务器或设备端使用 tcpdump 快速截获网络原始报文并保存为 .pcap 文件；将 .pcap 拉取到本地电脑后，借助 Wireshark 进行可视化分析。

tcpdump

启动抓包的标准命令：

sudo tcpdump -ni any -s 0 -w d-2026.pcap

各个参数的含义与考量：

• sudo：抓包需要操作底层的 Raw Socket，必须具备 root 权限；
• -n：关闭 IP 到主机名的逆向 DNS 解析。如果不加，在高网络吞吐下可能因等待 DNS 响应而产生严重卡顿乃至丢包；
• -i any：-i 指定网卡，any 代表捕获所有可用网卡（物理网卡、虚拟网卡以及本地回环 lo）；
• -s 0：-s（snapshot length）指定捕获的包字节上限，设为 0 代表抓取完整数据包，保证应用层 Payload（如 HTTP、JSON 内容）不被截断；
• -w d-2026.pcap：将原始报文二进制数据输出到指定文件，方便后续导出并在 Wireshark 中进行可视化分析。

需要注意Linux设备上的root权限与写入路径（如 /data/local/tmp）。

Wireshark几种常见的过滤

用 Display Filter 快速过滤

ip.src（源 IP 过滤）

用于仅筛选指定发送方 IP 发出的数据包。在多人并发请求或服务器流量庞杂时，能迅速定位特定客户端的请求行为。
例如查看来自10.10.10.1的

ip.src == 10.10.10.1

ip.dst（目的 IP）

只看发往某 IP 的包（目的 IP）
例如查看发往10.10.10.2的

ip.dst == 10.10.10.2

ip.addr

看本机与该 IP 之间的完整收发往返交互
例如

ip.addr == 10.10.22.1

按网段过滤

支持 CIDR 掩码过滤，例如查看来自某个子网的所有包：

# 过滤来自 10.10.10.0/24 子网的所有源包
ip.src == 10.10.10.0/24

• /24（相当于子网掩码 255.255.255.0）：前 24 位为网络位，涵盖 10.10.10.0 ~ 10.10.10.255 共 256 个地址。
• /16（相当于子网掩码 255.255.0.0）：涵盖 10.10.0.0 ~ 10.10.255.255（常用在公司大内网或 Kubernetes Pod 网络）。

rtpevent（RTP Event / DTMF 按键事件过滤）

rtpevent 是音视频通信与网络电话（VoIP / SIP / WebRTC）排障中非常关键的过滤器。它遵循 RFC 2833 / RFC 4733 协议，专门用于捕获传输中的电话按键事件（DTMF 双音多频）。

背景与应用场景：
在电话客服、语音导航（IVR，如“按 1 转人工，按 # 号键确认”）或对讲呼叫场景中，按键音如果直接走 Opus/G.711 等音频编码压缩容易失真变形，因此系统会将按键单独打包成特殊的 RTP Event 数据包传输。

rtpevent

过滤具体按键

比如只想看是否收到了按下数字 1 的事件（0-9 对应按键 0~9，10 为 *，11 为 #）：

rtpevent.event_id == 1

只看按键结束帧（判断有效按键）

用户长按一个键时会持续发送多个持续帧，最后会连续发几个标志位 End of Event 为 1 的结束确认包。排查按键是否被识别完整时很常用：

rtpevent.end_of_event == 1

排查丢键问题

结合 rtpevent 观察 RTP 包的 Sequence Number（序列号）是否连续，能迅速定位“为什么系统提示没按键”是因为网络抖动丢包还是客户端未触发。