📚 课程目录第3章丢包率度量方法

丢包率度量方法：ping、traceroute、iperf 实战归纳

做网络的人，谁没被丢包折磨过？我记得刚入行那会儿，遇到用户说“卡”，我二话不说就敲个 ping，看个两屏没丢包就回复“网络正常”。现在想想真脸疼。丢包率这玩意儿，光用 ping 看是不够的，不同工具测出来的结果可能完全不一样。

这一章我就把平时最常用的三把刀——ping、traceroute、iperf——拿出来掰开揉碎讲。每种工具测什么、怎么测、数据怎么看、有什么坑，我都会结合自己踩过的坑来说。

重要提醒： 别只盯着丢包率百分比。连续丢包模式、丢包位置、是否受QoS影响，都比单纯一个数字有价值。我见过太多人只看 ping 的结果就下结论，结果被坑得很惨。

1. ping - 最直接的丢包探针

说到丢包，大部分人第一个想到的就是 ping。它基于 ICMP Echo 请求，简单粗暴。但你真的会用吗？

我的基本用法：

# Linux 下，发送 100 个包，间隔 0.1 秒，大包测MTU问题  
ping -c 100 -i 0.1 -s 1472 10.0.0.1

输出里面看「packet loss」这一行。举个例子：

--- 10.0.0.1 ping statistics ---
100 packets transmitted, 98 received, 2% packet loss

2% 算不算高？要看场景。语音视频 1% 就可能卡，文件传输 5% 可能还能接受。但注意，这里统计的是整体丢包率，不反映丢包分布。

个人经验： 我曾遇到一个 case：ping 对端丢包 1%，但业务却经常断连。后来发现丢包是连续发生的（连续6个包全丢），TCP 重传超时直接断链。所以不要只看平均百分比，要看丢包模式。可以用 ping -f（flood模式）测连续丢包，不过千万别在生产环境用。

几个关键参数，我用表格整理一下：

参数	作用	我的推荐值
-c	发送包数	至少 100，越多越稳定
-i	发送间隔（秒）	0.01~0.1，短时间测压力
-s	payload 大小	默认 56，测MTU时设 1472
-W	超时时间（秒）	5，别设太长
-f	flood 模式	慎用，只在实验室用

避坑指南： 我曾经用默认 ping 测阿里云 ECS，发现偶尔丢包 0.5%，吓得差点重启。后来才发现是 ICMP 限速，换成 ping -c 1000 -i 0.01 反而没问题。记住，很多云平台对 ICMP 做了限速，丢包不一定是网络问题。

2. traceroute - 定位丢包节点

ping 能告诉我们有没有丢包，但在哪里丢的？那就得上 traceroute。它通过逐步增大 TTL 来探测每一跳的路由器。

我的常用命令：

# 用 ICMP 模式（避免被 UDP 防火墙拦截）
traceroute -n -I -q 3 10.0.0.1

注意我加了 -I，用 ICMP Echo 代替默认的 UDP。为什么？很多网络设备会丢弃 UDP 高端口包，导致你看到全是 * * *，但其实 ICMP 是通的。

怎么看结果？ 看每一跳的延迟和丢包。比如：

 1  192.168.1.1  1.2 ms  1.0 ms  1.1 ms
 2  10.0.0.254  2.3 ms  2.5 ms  *      ← 丢了一个包
 3  10.0.0.1    5.0 ms  5.1 ms  4.9 ms

第2跳丢了一个包（第三组探测超时），但整体链路还是通的。如果某一跳连续丢包 >20%，那它就是瓶颈。

个人经验： 有一次用户投诉访问某国外站点慢，traceroute 看到在国外某节点丢包 50%。我跟对方运营商报障，对方回复“我们统计不丢包”。后来发现是路径不对称——去程走 A 路由器，回程走 B 路由器，而 B 路由器超载。traceroute 只测了去程，所以单看不够。建议结合 traceroute -R（记录路由）或者两端同时测。

各模式对比：

模式	默认端口	通过防火墙概率	我的选型
UDP（默认）	33434+	低，容易被拦截	不推荐
ICMP (-I)	无	中，某些设备限速	首选
TCP (-T)	80/443 可指定	高，模拟真实流量	生产环境首选

  关键点： traceroute 的星号不一定代表丢包。可能是路由器没回 ICMP TTL 超时，也可能是 QoS 限速。我通常在目标端同时用 tcpdump 抓包确认。

3. iperf - 压力下的丢包率

ping 和 traceroute 都是轻量探测，但真实业务流量下丢包率可能完全不同。为什么？因为缓冲区。空闲时路由器缓存够用，一旦跑满带宽，缓存丢包才会暴露。

我的 UDP 测试命令（iperf3）：

# 服务端（目标）
iperf3 -s

# 客户端（发流端）
iperf3 -c 10.0.0.1 -u -b 100M -l 1400 -t 60

-b 100M 表示以 100Mbps 速率发送 UDP 流。注意 iperf 默认是 TCP，必须加 -u 才是 UDP。

输出看什么？ 重点关注这几行：

[ ID] Interval       Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]  0.00-60.00  sec   713 MBytes   99.8 Mbits/sec  0.025 ms  0/510115 (0%)

[  5]  0.00-60.00  sec   713 MBytes   99.8 Mbits/sec  0.025 ms  0/510115 (0%)

[  5] Sent 510115 datagrams

Lost/Total 后面的百分比就是 UDP 丢包率。Jitter（抖动）也很关键，语音视频对抖动敏感。

个人经验： 某次在 10G 链路测试，iperf UDP 跑 2Gbps 就丢包 5%，但链路利用率才 20%。折腾了半天，最后发现是网卡中断合并（coalescing） 没关，导致小包堆积。关掉 ethtool -C eth0 rx-usecs 0 后就好了。iperf 能暴露这类隐含问题，ping 测不出来。

关键参数速查：

参数	作用	推荐值
-b	目标带宽	链路带宽的 80%~95%
-l	payload 大小	接近 MTU（1400 安全）
-t	测试时长	30~120 秒
--get-server-output	获取服务端统计	建议加上，看双向丢包

警告： iperf UDP 测试要小心带宽打爆。我曾有一次不小心把 -b 设成 1G，而链路实际只有 100M，结果把交换机缓存打满了，导致同链路上的其他业务全部丢包。建议先在低带宽下测试，逐步增加。另外，一定要确认服务端 iperf 进程已经启动，否则测试会失败。

4. 工具选择策略与决策流程

三个工具各有侧重。我画了一张图，帮你快速决策：

这张图展示了我的推荐路径：先用 ping 确认有没有丢包，如果有就 traceroute 定位节点，最后用 iperf 模拟真实压力验证。如果 ping 没丢包但业务慢，别犹豫，直接上 iperf UDP 压力测试。

  对比总结：
  ping：快速、轻量，但易受 ICMP 限速影响，不能反映真实业务流丢包。
traceroute：定位到节点级别，但只有去程信息，且星号可能误判。
iperf：模拟真实负载，暴露缓存和限速问题，但需要双向部署且注意别打爆链路。

5. 注意事项与避坑指南

双向路径不对称：traceroute 只测去程，丢包可能发生在回程。我曾在跨运营商场景中，去程正常，回程在某台设备上丢包 30%。解决方法：在两端同时做 traceroute，或者用 mtr 工具结合看。
QoS 队列影响：有些设备会优先处理控制面流量（如 ICMP），导致 ping 不丢包但业务丢包。我遇到过一个交换机，ICMP 被放在 High 队列，而业务流量在 Default 队列被 tail drop。
采样周期：短时间测试不可靠。我建议 ping 至少 1000 个包，iperf 至少跑 30 秒，traceroute 每跳测 3~5 次。
防火墙策略：很多防火墙默认丢弃 ICMP，或者对 UDP 高端口限速。我曾经在客户环境里用 ping 什么都正常，但业务全丢，后来发现是防火墙把业务端口限速了。用 iperf TCP 才测出来。

经典事故： 有一回我远程帮同事排查丢包，他 ping 网关丢包 0.1%，我让他 traceroute 看每跳，结果全是 * * *。我以为网络断了，他说不对，网页能打开。后来发现他 traceroute 用的 UDP 模式，而核心路由器正好把 UDP 高端口全 drop 了。换成 traceroute -I 就好了。所以记住：工具的参数选择可能颠覆你的判断。

好了，这三种工具怎么用、怎么看、怎么避坑，基本都讲清楚了。下次你遇到丢包投诉，别再只敲个 ping 就交差了。先快速 ping 摸底，再 traceroute 定位，最后 iperf 做压力验证——这套组合拳下来，绝大多数丢包根因都能揪出来。