📚 课程目录第4章网络监控工具

网络监控工具：使用 ping、traceroute、iperf、netstat 等工具诊断

核心原理：从连通性到性能的分层诊断

网络故障诊断不能靠猜，而应遵循“由近及远、由连通到性能、由数据面到控制面”的递进逻辑。ping、traceroute、iperf、netstat 这四类工具恰好覆盖了不同层次的检测需求，组合使用才能精准定位瓶颈。

ping（ICMP Echo）：验证三层连通性与 RTT 时延，判断目标是否可达、是否存在丢包。
traceroute（UDP/ICMP 探测）：逐跳显示路径上的路由器，定位时延突增或丢包发生的具体节点。
iperf（TCP/UDP 流量生成）：主动灌入流量，测量实际带宽、重传率与抖动，区分“链路容量不足”与“协议栈低效”。
netstat（内核网络状态）：查看本机连接表、端口监听、重传队列与套接字缓冲区，判断是否为本地资源瓶颈。

四者关系可概括为：ping 探活 → traceroute 定位路径 → iperf 压测容量 → netstat 核查本地状态。若 ping 通但 iperf 带宽不达标，问题往往在 TCP 参数或中间设备限速；若 ping 丢包而 traceroute 显示某跳时延飙升，则需关注物理链路或队列拥塞。

诊断顺序建议：先做 100 个 ICMP 包的丢包率测试（ping -c 100），再做 10 秒 iperf 双向测试，最后用 netstat -s 查看重传统计。三步即可区分“链路坏”“路径堵”“主机弱”三类根因。

方法流程：四步定位网络瓶颈

以一个典型的“服务器到存储阵列”场景为例，假设业务反馈读写延迟从 1ms 恶化到 20ms，按以下流程操作：

第一步：ping 探活与基线测试
```
ping -c 100 -i 0.2 10.0.0.8   # 发送 100 个包，间隔 200ms
# 观察：packet loss 0%，min/avg/max = 0.3/0.5/1.2 ms
```
若丢包率 > 0.1% 或 RTT 抖动超过 2ms，说明物理链路或交换机端口存在异常。

第二步：traceroute 定位路径节点

traceroute -n -T -p 443 10.0.0.8   # TCP 模式穿透防火墙
# 输出示例：
#  1  10.0.0.1    0.4 ms
#  2  192.168.1.1  3.2 ms
#  3  10.0.0.8    18.5 ms   <-- 时延在此跳突增

若第 2 跳到第 3 跳时延从 3ms 跳到 18ms，说明瓶颈在接入交换机到存储阵列之间的链路或存储网卡。

第三步：iperf 双向带宽压测
```
# 在存储端启动服务
iperf3 -s -p 5201
# 在服务器端发起测试
iperf3 -c 10.0.0.8 -t 10 -i 1 -P 4
iperf3 -c 10.0.0.8 -t 10 -i 1 -R   # 反向测试
```
重点关注 retr（重传）列。若带宽只有 2Gbps（万兆网卡预期 9.4Gbps）且重传率高，则可能是 MTU 不一致或网卡 offload 设置错误。
第四步：netstat 核查本地状态
```
netstat -s | grep -E "retransmit|listen|overflow"
netstat -an | grep 5201   # 确认连接建立
ss -ti state established   # 查看发送/接收队列
```
若 TCPLostRetransmit 或 ListenOverflows 数值持续增长，说明应用程序 accept 队列不足或内核缓冲区过小。

案例实战：一次典型的 RoCEv2 性能劣化排查

某数据中心使用 RoCEv2 承载分布式存储流量，业务反馈跨机柜读写延迟从 80μs 升至 800μs。按照上述流程诊断：

步骤	工具	关键输出	结论
1	ping -c 1000	丢包 0.3%，RTT 抖动 ±50μs	链路存在轻微拥塞
2	traceroute --udp -p 4791	第 4 跳（TOR 交换机）时延 +200μs	交换机队列缓冲不足
3	iperf3 -u -b 8G -t 30	UDP 丢包率 2.1%，抖动 180μs	确认 PFC 流控未生效
4	netstat -s \| grep Congestion	ECN 标记包数量暴增 50 倍	交换机 WRED 丢弃导致重传

最终定位为 TOR 交换机上 RoCEv2 的 PFC 优先级队列配置错误，导致突发流量触发丢包。调整 qos buffer 参数并启用 ECN 后，延迟恢复至 90μs。

误区与复盘：工具使用中的常见陷阱

误区一：ping 通就认为网络没问题
ICMP 流量通常被交换机设置为低优先级，且不经过 RDMA 的数据路径。实际业务流量（尤其是 RoCEv2）可能因 PFC 死锁或 ECN 标记而严重丢包，但 ping 依然表现正常。必须用 iperf 或专用 RoCE 测试工具（如 qperf）验证真实数据面。

误区二：traceroute 看到星号就断定故障
很多核心路由器不响应 UDP 探测或 ICMP 超时消息，星号可能只是设备策略限制，而非链路中断。应改用 traceroute -T -p 80（TCP 模式）或 -I（ICMP 模式）交叉验证，并结合两端 iperf 结果综合判断。

  复盘要点：
  先看丢包，再看时延：丢包会导致 TCP 重传，重传造成的时延假象会误导排查方向。
双向测试不可省略：RoCEv2 的 PFC 死锁往往只影响一个方向，iperf 必须加 -R 参数。
netstat 要结合时间点：单独看绝对值无意义，需在故障发生时抓取 netstat -s 并与正常基线对比。
工具版本一致性：iperf2 与 iperf3 的线程模型不同，对比结果时必须使用相同版本和参数。

网络监控工具的价值不在于单个命令的输出，而在于将多个工具的数据交叉印证。ping 负责探活，traceroute 负责画路径，iperf 负责压容量，netstat 负责查本地——四者形成闭环，才能从“通不通”深入到“快不快”“稳不稳”。在 RDMA 场景中，还需额外关注 PFC 计数器、ECN 标记和 RoCE 网卡丢包统计，这些信息往往比传统工具更能揭示无损网络的真实健康状态。