网络吞吐波动剧烈本质是单位时间有效传输数据量忽高忽低，需区分链路层丢包、协议栈处理不稳或应用读写滞后；应依次排查端口流量、进程带宽占用、TCP队列堆积、网卡错误计数、重传激增及抓包分析耗时分布。
网络吞吐波动剧烈，本质是单位时间有效传输的数据量忽高忽低，不是“跑不满带宽”，而是“跑得断断续续”。关键要分清：是链路层真丢包？还是本机协议栈处理不稳？抑或应用读写跟不上？不能只盯着 iftop 的瞬时数字看。
查实时带宽占用与进程行为
先排除“被自己人抢光”的可能：
- 用 iftop -P 查端口级流量，确认是否有某个连接（如 rsync、日志推送、监控心跳）周期性爆发，压占出口；
- 用 nethogs 按进程查看上下行速率，重点盯住非业务进程——比如 backup-agent 每分钟拉一次全量数据，就会造成规律性吞吐凹坑；
- 若波动周期固定（如每60秒一次），配合 vnstat -l 看分钟级汇总，比实时工具更能识别节奏性行为。
看 TCP 连接队列是否堆积
吞吐不稳常源于连接内部卡顿，而非整体带宽不足：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 运行 ss -tan state established | wc -l，检查活跃连接数是否远超预期（Web服务几百连接却显示上万，说明连接释放慢或慢客户端拖累）；
- 对目标连接执行 ss -i dst IP:PORT，重点关注 Recv-Q 和 Send-Q： • Recv-Q > 0 持续存在 → 应用读取太慢，内核缓冲区积压； • Send-Q 长期非零 → 对端 ACK 延迟或路径拥塞，发送被阻塞；
- 这两个字段持续非零，会直接压制吞吐稳定性，且 ping 看不出异常。
验底层丢包与驱动层异常
跳过猜测，直查硬件和驱动是否掉链子：
- 执行 ip -s link show eth0（替换为实际网卡），检查 rx_missed_errors、tx_dropped、rx_errors 是否随时间增长——持续上升说明 ring buffer 溢出、驱动 bug 或物理链路不稳；
- 运行 tc -s qdisc show dev eth0，关注 dropped 字段。非零且递增 → 本地出口队列饱和，是典型拥塞信号；
- 查 netstat -s | grep -i "retransmitted"，重传段数短时激增，表明路径中存在丢包，需结合 mtr --tcp -P 443 目标域名 定位具体跳点。
抓包分析关键路径耗时
用 tcpdump + Wireshark 做精细拆解，避免泛泛而谈“网络慢”：
- 在业务请求期间抓包：tcpdump -i eth0 'host TARGET_IP and port PORT' -w debug.pcap -c 1000；
- Wireshark 中打开，右键 HTTP 包 → Follow → HTTP Stream，自动关联请求与响应；
- 重点看三个耗时：SYN 建立时间、首字节响应（TTFB）、后续数据包到达间隔。若数据包呈“一簇一簇”到达（非均匀分布），大概率是中断集中导致的批量处理效应。
