tcpdump 本身无法直接统计内核或网卡层的丢包率，但可以通过增大抓包缓冲区避免抓包工具自身丢包，并结合系统指标与 Wireshark 分析重传来间接定位。适用于排查 UDP 业务丢包或 TCP 重传问题，风险在于高吞吐场景下若缓冲区不足会导致抓包结果不可信。

命令速用版

以下命令用于捕获特定端口流量并尽量减少抓包工具自身的丢包风险，适用于 Linux 环境。

# 增大缓冲区至 4MB，禁用解析，捕获 eth0 接口 UDP 5060 端口流量
tcpdump -i eth0 -B 4096 -nn -s 128 udp port 5060 -w capture.pcap

# 抓包结束后检查是否有抓包工具自身丢包
tcpdump -r capture.pcap 2>&1 | grep "packets dropped"

若 grep 结果为非 0，说明 tcpdump 已漏抓，结果不可信，需进一步增大 -B 值或减小 -s 值。

为什么会这样

tcpdump 显示 dropped by kernel 通常指抓包缓冲区溢出，而非网卡物理丢包。tcpdump 通过 libcap 从内核复制数据包，若应用层读取速度慢于内核收包速度，sock 接收缓冲区填满后会丢弃副本，计数显示为 dropped by kernel。这不代表网络链路丢包，而是监控工具性能瓶颈。真实网络丢包需查看内核网络栈统计指标或应用层反馈。

分步处理

按照以下顺序排查，确保每一步都有明确的验证结果和风险边界。

步骤 1：确保抓包工具不丢包

适用场景：高吞吐流量监控。操作动作：添加 -B 参数增大操作系统捕获缓冲区，添加 -n 禁用 DNS 解析减少开销。验证结果：tcpdump 结束统计中 dropped by kernel 为 0。风险边界：-B 过大会占用过多内存，建议从 4096 (4MB) 开始调整。

步骤 2：采集系统级 UDP 丢包指标

适用场景：UDP 业务丢包定位。操作动作：实时监控 /proc/net/snmp 中 Udp 行数据。验证结果：对比 InDatagrams 增量与抓包计数，若前者远大于后者，说明丢包发生在 tcpdump 之前（网卡驱动、防火墙、内核早期丢弃）。风险边界：需关注 RcvbufErrors（套接字缓冲区满）和 NoPorts（端口无监听）。

步骤 3：分析捕获文件定位业务丢包

适用场景：TCP 重传或 UDP 序列缺失。操作动作：将 pcap 文件导入 Wireshark，过滤 tcp.analysis.lost_segment 或检查 UDP 载荷序列号。验证结果：发现重传包或序列号不连续。风险边界：仅靠 tcpdump 看到的包不等于应用成功读取，需结合应用日志确认 recv() 状态。

怎么验证是否生效

检查 tcpdump 退出时的统计信息，确保 captured 加上 dropped by kernel 等于 received by filter。查看 /proc/net/snmp 中 Udp 行的 InErrors 和 RcvbufErrors 是否在业务高峰期持续增长。在 Wireshark 中统计 TCP 重传率，若重传率低于 1% 通常视为网络链路正常，高于此值需排查链路拥塞或接收端处理慢。

常见坑

默认 snaplen 可能截断数据包，导致无法分析完整协议头，建议 UDP 至少 -s 128，TCP 含 SACK 选项时需更大。未禁用 DNS 解析会导致抓包性能下降，高负载下加剧丢包，务必加 -nn 参数。将数据包输出到文件比实时打印更可靠，避免终端 I/O 阻塞影响抓包。

常见问题

tcpdump 显示 dropped by kernel 是什么意思？

指抓包缓冲区满导致 libcap 丢弃副本，非网卡物理丢包。需增大 -B 参数或优化过滤条件。

如何确认 UDP 业务丢包？

结合应用层序列号或 RTP seq 分析，tcpdump 无法直接统计 UDP 丢包率。

抓包影响服务器性能吗？

高吞吐下会占用 CPU 和内存，建议限流抓包或离线分析，避免长时间全量抓包。

参考来源

• Linux 环境下利用 tcpdump 监控 UDP 特定端口报文丢失方案
• tcpdump 丢包问题分析
• tcpdump 丢包分析
• 如何使用 tcpdump 抓取并分析 Linux 网络报文数据包
• TCPDump 实际抓包案例及故障分析