4. 测量工具部署：iPerf3、Ping、Traceroute、MTR的安装与基础使用
好，咱们进入实战环节。前面讲了那么多理论，什么SLA指标、测量模型，说白了，最后都得靠工具落地。你想想看，没有趁手的家伙事儿，怎么去跟运营商掰扯“这条链路丢包了”？
我个人习惯，在接手一条新专线时，第一件事不是看配置，而是先把这四把“刀”磨好。iPerf3、Ping、Traceroute、MTR，各有各的脾气，也各有各的用处。今天我就带你挨个儿过一遍，怎么装、怎么用、怎么避坑。
4.1 为什么是这四件套？
你可能觉得，Ping不是系统自带的吗？还用专门讲？嗯，这里要注意，自带的Ping功能太弱了。咱们做SLA保障，要的是能定量分析、能持续监控、能快速定位的工具。
- Ping：最基础的连通性测试，看延迟和丢包。但它的精度有限，数据包小，测不出大压力下的表现。
- iPerf3：这才是核心。它能模拟真实的业务流量，测出链路的极限带宽、抖动和丢包率。我在项目中遇到过，Ping着全通，但一跑iPerf3就现原形，原来是运营商的带宽限速没给够。
- Traceroute：路径探测。告诉你数据包从你家到对端，走了哪些“路口”。哪一跳延迟高了，一目了然。
- MTR：这是Ping和Traceroute的合体进化版。它能持续追踪路径上的每一跳，同时统计丢包和延迟。我排查故障时，90%的情况都是先跑MTR。
核心逻辑：Ping做“体检”，iPerf3做“压力测试”，Traceroute看“路线图”，MTR做“实时路况监控”。四者缺一不可。
4.2 iPerf3：专线带宽的“照妖镜”
先讲iPerf3，因为它最重要。很多运维兄弟习惯用Ping测链路，但Ping包太小，根本压不出问题。iPerf3能模拟大流量，把链路的真实底裤都扒出来。
4.2.1 安装
安装很简单，几乎主流系统都支持。
# CentOS / RHEL
yum install iperf3 -y
# Ubuntu / Debian
apt-get install iperf3 -y
# macOS (用Homebrew)
brew install iperf3
# Windows
# 去官网下载.exe文件，或者用scoop: scoop install iperf3我的习惯：在服务器端和客户端都装上。别只装一端，有时候问题出在客户端机器性能不够，压不满带宽。
4.2.2 基础使用
iPerf3是C/S架构。先启动服务端，再跑客户端。
服务端（对端机房）：
iperf3 -s -p 5201客户端（本地）：
iperf3 -c 对端IP -p 5201 -t 30 -P 4参数说明：
-c：客户端模式，后面跟服务器IP-p：端口，默认5201-t：测试时长，单位秒。我一般跑30秒以上，太短了数据不准确-P：并行线程数。专线带宽大时，单线程可能压不满，我习惯用4或8
输出结果里，重点关注 Bitrate（带宽）和 Retr（重传数）。重传数高，说明链路有丢包或拥塞。
我曾经踩过的坑：有一次测一条100M专线，iPerf3结果只有50M。我查了半天，最后发现是客户端网卡协商成了百兆半双工。所以，测之前先检查两端网卡速率：ethtool eth0。
4.2.3 双向测试
专线很多时候是上下行不对称的。我建议做双向测试：
# 先测下行（从服务端到客户端）
iperf3 -c 对端IP -t 30
# 再测上行（从客户端到服务端），加 -R 参数
iperf3 -c 对端IP -t 30 -R你想想看，如果下行100M，上行只有20M，那视频会议肯定卡。这就是SLA里要明确上下行带宽的原因。
4.3 Ping：最熟悉的陌生人
Ping大家都会，但做SLA测量时，有几个参数必须用对。
4.3.1 高级Ping用法
# Linux 下持续ping，并记录时间戳
ping -D -c 1000 对端IP | tee ping_result.txt
# 指定包大小，模拟大包延迟（比如1500字节）
ping -s 1472 -c 100 对端IP
# Windows 下持续ping
ping -t 对端IP关键点：
- 默认Ping包只有56字节，太小了。我测专线时，习惯用
-s 1472（加上IP头正好1500，模拟真实MTU）。 - 连续Ping至少1000个包，才能统计出有意义的丢包率。Ping 4个包就说链路没问题？那是自欺欺人。
避坑指南：我曾经遇到一个案例，Ping大包全丢，小包正常。最后发现是中间某个交换机MTU设置成了1500，但专线封装MPLS后实际MTU只有1460。所以，Ping大包能帮你发现MTU问题。
4.4 Traceroute：看清你的数据走了哪条路
专线出问题，很多时候是中间路由跳了。Traceroute就是用来查这个的。
4.4.1 安装与使用
# Linux
traceroute 对端IP
# Windows (命令叫 tracert)
tracert 对端IP
# macOS
traceroute 对端IP输出结果里，每一行代表一跳。重点关注：
- 延迟突然飙升：比如第5跳是10ms，第6跳变成100ms，那问题很可能出在第5跳到第6跳之间。
- 星号（* * *）：表示那一跳没回应。不一定就是故障，可能是路由器禁用了ICMP。但如果连续多跳都星号，那链路可能断了。
我的经验：Traceroute默认用UDP包，有些运营商会拦截。我习惯加 -I 参数改用ICMP包，穿透性更好：traceroute -I 对端IP。
4.5 MTR：我的故障排查首选
MTR是我最依赖的工具。它把Ping和Traceroute结合起来，持续探测每一跳，并统计丢包和延迟。你想想看，一条命令跑几分钟，就能拿到整条路径的健康报告。
4.5.1 安装
# CentOS
yum install mtr -y
# Ubuntu
apt-get install mtr -y
# macOS
brew install mtr
# Windows
# 用WinMTR，图形界面，很好用4.5.2 基础使用
# 实时模式，持续追踪
mtr 对端IP
# 只跑10个包，然后出报告（适合脚本调用）
mtr -r -c 10 对端IP
# 报告模式，显示更详细
mtr -r -c 100 --report-wide 对端IP输出结果解读：
| 列名 | 含义 | 重点关注 |
|---|---|---|
| Loss% | 丢包率 | 任何非0的丢包都要警惕 |
| Snt | 已发送包数 | 至少100个才有统计意义 |
| Last | 最后一个包的延迟 | 看瞬时值 |
| Avg | 平均延迟 | SLA里通常看这个 |
| Best/Worst | 最好/最差延迟 | 抖动大说明链路不稳定 |
| StDev | 延迟标准差 | 越大说明抖动越厉害 |
我曾经犯过的错：刚开始用MTR时，看到最后一跳有丢包，就以为是专线问题。后来才发现，最后一跳是目标服务器，它可能因为自身负载高而丢包。正确的做法是：看中间跳的丢包。如果中间跳都正常，只有最后一跳丢，那问题大概率在服务器端。
4.5.3 实战技巧：如何判断问题点
假设MTR结果如下：
1. 192.168.1.1 0.0% 100 0.5 0.4 0.3 0.6 0.1
2. 10.0.0.1 0.0% 100 1.2 1.1 0.9 1.5 0.2
3. 172.16.0.1 5.0% 100 20.0 25.0 18.0 30.0 3.0
4. 对端IP 5.0% 100 20.5 25.5 18.5 31.0 3.1看到了吗？第3跳开始丢包，延迟也飙升。那问题就出在第2跳到第3跳之间。直接找运营商，告诉他们“我在第3跳（172.16.0.1）看到丢包了”，他们就能快速定位。
总结一下：MTR的核心理念是“路径+统计”。它告诉你问题在哪一跳，以及有多严重。这是做SLA保障时，跟运营商扯皮的最有力证据。
好了，工具都装好了，基础用法也过了一遍。下一节咱们就拿着这些工具，去实战演练一下，看看怎么用它们来验证SLA指标。记住，工具是死的，人是活的。多跑、多看、多总结，你也能成为专线保障的老手。