tcpdump 不直接显示吞吐量，但通过分段抓包（SYN、HTTP响应、重传）结合 nethogs/iftop/ss 定位瓶颈层级，并用 Wireshark 分析耗时与重传，可精准识别网络路径异常。
tcpdump 本身不直接显示吞吐量数值，但它是定位吞吐异常波动根源的关键工具——关键在于“抓对包”和“看对阶段”。需结合其他命令初步判断瓶颈层级后，再用 tcpdump 聚焦验证。
先缩小范围：确认是否真由网络路径导致
吞吐波动未必是网络问题。先快速排除常见干扰：
- 用 nethogs -t 查进程级实时带宽，确认是否有 rsync、备份脚本或日志同步等后台任务周期性占满出口
- 用 iftop -P 看端口维度流量，识别是否某个服务（如 API 端口）突发大量连接或大包传输
- 执行 ss -tan state established | wc -l 和 ss -s，检查 ESTABLISHED 连接数是否远超正常水平，TIME-WAIT 是否堆积严重
- 若发现某连接的 Recv-Q 持续 > 0，说明应用读取慢，瓶颈在用户态，tcpdump 抓包意义有限，应转向应用日志和 strace
抓包重点：聚焦 TCP 关键耗时环节
不要全量抓包，按典型请求链路分段分析：
- 抓握手阶段：tcpdump -i eth0 -nn -s 0 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn' -w syn.pcap —— 观察 SYN → SYN-ACK 时间，若明显增长（如从 1ms 升至 200ms），说明链路基础延迟或中间设备（防火墙、负载均衡）处理变慢
- 抓首字节响应：tcpdump -i eth0 -nn -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)>2)) != 0)' -w http_resp.pcap —— 过滤含 HTTP 响应体的数据包，配合 Wireshark 的 “Time since request” 功能，看服务端生成首字节是否延迟
- 抓重传与乱序：tcpdump -i eth0 -nn -s 0 'tcp[tcpflags] & tcp-rst or tcp[tcpflags] & tcp-ack and (tcp[12:1] & 0xf) > 5' -w retrans.pcap —— 捕获 RST 包及窗口大于 5 的 ACK（常伴随重传），重传段数突增直接指向路径丢包
配合统计命令交叉验证丢包点
tcpdump 发现重传后，必须定位丢包发生在哪一层：
- 查网卡底层错误：ip -s link show eth0 | grep -A 5 "RX\|TX"，关注 rx_missed（Ring Buffer 溢出）、rx_errors（物理层错误）是否持续上升
- 查队列丢弃：tc -s qdisc show dev eth0，若 dropped 字段非零且随时间增加，说明本地出口 qdisc 饱和，是拥塞信号，需调优或限速
- 查协议栈重传：netstat -s | grep -i "segments retransmited"，对比 tcpdump 中重传次数，若远高于抓包数，说明重传发生在更早阶段（如应用发包后内核未及时发出）
分析技巧：用 Wireshark 快速提取关键指标
将 pcap 文件导入 Wireshark 后，不用逐包翻看：
- 右键任意 HTTP 请求包 → Follow → HTTP Stream，自动关联请求与响应，顶部显示三阶段耗时：TCP 握手、首字节响应、传输完成
- 过滤表达式输入 tcp.analysis.retransmission，高亮所有重传包，观察是否集中于某 IP 或端口
- 使用 Statistics → IO Graphs，设置 Y 轴为 Packets/sec，X 轴为时间，叠加吞吐波动曲线，直观比对丢包峰值与业务波动是否同步
