ifstat可高频采样捕获瞬时流量尖峰：用ifstat -t 0.5 20每500ms采样一次并记录时间戳，再通过awk分析相邻行差值；默认KB/s单位易误读，建议加-b以字节/秒输出，避免与比特混淆。
怎么用 ifstat 抓住瞬时流量尖峰
ifstat 是唯一能稳定捕获“突发”这种短时高值的命令行工具，因为它输出的是离散时间点的速率快照，不像 nload 或 iftop 那样平滑或带缓冲。关键不是看单次输出，而是靠高频采样+人工/脚本识别跳变。
- 用
ifstat 0.5 10每 500ms 采一次、共 10 次，比默认 1s 更容易暴露TX或RX的突增（比如从 200KB/s 突跳到 8MB/s） - 加
-t输出时间戳：ifstat -t 0.5 20 | tee /tmp/traffic.log，后续可用awk扫描相邻行差值 - 别依赖
ifstat -e查错误——它只显示累计错误计数，无法反映突发丢包；真要定位丢包时刻，得结合ip -s -h link show dev eth0对比前后dropped增量 - 注意单位：默认是 KB/s，突发流量常达 MB/s 级，建议加
-b以字节/秒输出，避免误读为 bit（ifstat -b 0.5）
iftop -P 怎么过滤出端口级突发连接
iftop 本身不标“突发”，但它的实时刷新机制天然适合捕捉短连接爆发——比如某 IP 突然在几秒内建立大量 HTTP 连接并快速传输数据。关键是禁用聚合、锁定端口维度。
- 必须加
-P（大写 P），否则它默认按主机对聚合，会把多个端口流量合并，掩盖单端口突发 - 配合
-n（禁 DNS）和-B（字节单位），执行sudo iftop -i eth0 -P -n -B，界面里每行就是一个src:port → dst:port连接 - 观察右侧三列速率：
2s、10s、40s平均值——如果2s明显高于后两者（比如 5MB/s vs 200KB/s），就是典型突发 - 按
l键可临时过滤，输入:80或192.168.1.100快速聚焦目标，避免被其他连接干扰判断
为什么 ip -s link 不适合查突发，但能验证后果
ip -s link 的统计是内核累积值，没有时间分辨率，不能告诉你“哪一秒爆了”，但它能告诉你突发是否造成了链路层损伤——这才是排查的根本依据。
- 执行
ip -s -h link show dev eth0两次，间隔 2 秒，重点对比RX下的packets和errors增量：若packets增长极小但errors上升，说明突发导致网卡或驱动处理不过来，开始丢帧 -
TX下的dropped值增长，不是网络丢包，而是内核发送队列满被迫丢弃——这直接指向宿主机负载过高或网桥配置过小（如 Docker 容器场景） -
carrier非零意味着物理链路反复断连，常见于网线松动或交换机端口震荡，此时任何“突发”都是假象，实际是链路不稳定造成的重传假高峰 - 切记：
ip -s link的bytes是协议栈入口计数，不含 TCP 重传，所以看到突发流量远小于应用层日志记录量，大概率是重传导致
用 nload 看突发容易误判的两个细节
nload 的图表看着直观，但它的内部采样逻辑和显示缓冲会让真实突发被“抹平”或“延迟呈现”，直接盯着屏幕看峰值极易误判。
- 默认刷新间隔是 1000ms，但图表实际显示的是该周期内的平均速率——一个持续 200ms 的 10MB/s 尖峰，在图表上只会显示成约 2MB/s 的柱状图，数值严重偏低
- 界面顶部的
peak值是历史最大瞬时速率，但它只更新不重置，一旦触发过一次高峰，后续长时间都显示这个旧值，无法反映当前是否仍在突发 - 若真要用 nload 辅助判断，必须加
-t 200（200ms 刷新）并紧盯curr（当前速率）栏，而不是依赖图表或peak字段 - 它不区分方向细节：入向突发和出向突发在同一个柱子里混合显示，而很多问题（如 SYN Flood 攻击）只体现在
RX，这时候必须切回ifstat或iftop
真实环境里，“突发”从来不是孤立指标——它要么是业务请求激增（需查应用日志），要么是异常行为（需结合进程级工具如 nethogs），要么是底层链路问题（得看 ethtool 和 dmesg）。盯住工具输出的数字只是第一步，关键要明白每个数字背后对应哪一层的决策或故障。
