3、测试工具选型：iperf3 详解、ping 与 traceroute、mtr 综合测试、wrk 与 httping、自定义测试脚本框架

做网络加速器测试，工具选不对，后面全白费。我见过太多人拿着一个 ping 结果就下结论，结果上线后被打脸。这一章，我把压箱底的工具清单和用法都摊开来讲。

3.1 iperf3 详解：带宽测试的黄金标准

iperf3 是我最常用的工具，没有之一。它专门用来测量网络的最大带宽。说白了，就是看你的管道到底有多粗。

核心用法

服务端启动很简单：

iperf3 -s -p 5201

客户端连上去测：

iperf3 -c 192.168.1.100 -p 5201 -t 30 -P 4

这里 -t 30 表示测30秒，-P 4 表示开4个并行流。我个人习惯至少测60秒，数据更稳。

反向测试

加速器往往上下行不对称。用 -R 参数可以测反向：

iperf3 -c 192.168.1.100 -R -t 30

我在项目中遇到过，某加速器下行能跑满500M，上行却只有30M。如果不做反向测试，根本发现不了这个坑。

UDP 测试

很多加速器对 UDP 支持很差。用 -u 参数测一下：

iperf3 -c 192.168.1.100 -u -b 100M -t 30

看丢包率和抖动。如果丢包超过1%，那这个加速器基本废了。

参数	作用	我的建议
-P	并行流数	先试4，再试8，看拐点
-t	测试时长	至少30秒，推荐60秒
-R	反向测试	必做，别偷懒
-u	UDP模式	加速器必测项

3.2 ping 与 traceroute：基础但别小看

ping 太基础了，但很多人用错了。它测的是延迟和丢包，不是带宽。

ping 的正确姿势

ping -c 100 -i 0.2 8.8.8.8

发100个包，间隔0.2秒。这样能看出延迟的波动范围。我曾经遇到一个加速器，平均延迟50ms，但最大延迟跳到800ms。这种波动对游戏体验是毁灭性的。

traceroute 看路径

加速器到底走了哪条路？traceroute 告诉你：

traceroute -n 8.8.8.8

用 -n 参数不解析域名，速度快很多。看每一跳的延迟，如果某跳突然飙升，那就是瓶颈。

3.3 mtr 综合测试：把 ping 和 traceroute 合二为一

mtr 是我最爱的排障工具。它把 ping 和 traceroute 结合起来，持续探测每一跳的丢包和延迟。

mtr -r -c 100 8.8.8.8

-r 表示报告模式，-c 100 发100个包。输出结果里，Loss% 列是关键。如果中间某跳丢包超过5%，但最终节点丢包为0，那中间跳的丢包可能是正常的（优先级问题）。

如果最终节点也有丢包，那问题就严重了。我遇到过一家加速器，宣传说零丢包，mtr 一跑，最后一跳丢包3%。对方还嘴硬，我把报告甩过去，立马没声了。

3.4 wrk 与 httping：应用层性能测试

带宽和延迟测完了，还得看应用层的表现。毕竟用户用的是 HTTP 服务，不是 iperf。

wrk 压测 HTTP

wrk -t12 -c400 -d30s http://target.com

12个线程，400个并发连接，持续30秒。看 Requests/sec 和 Latency。我一般会对比直连和走加速器的结果。如果加速器反而更慢，那要它何用？

httping 测延迟

httping 比 ping 更贴近真实场景，它发的是 HTTP 请求：

httping -c 100 -g http://target.com

测的是完整的 HTTP 往返时间。对于网页加速器来说，这个指标比 ICMP ping 更有参考价值。

3.5 自定义测试脚本框架：把一切自动化

手动测试太累了。我写了一个脚本框架，把上面所有工具串起来。核心思路是：一次配置，多次运行，自动出报告。

框架结构

test_framework/
├── config.yaml        # 测试配置
├── run_tests.sh       # 主执行脚本
├── modules/
│   ├── iperf_test.sh
│   ├── ping_test.sh
│   ├── mtr_test.sh
│   └── http_test.sh
└── reports/
    └── report_$(date).md

核心脚本片段

#!/bin/bash
# run_tests.sh - 自动化测试执行器

source modules/iperf_test.sh
source modules/ping_test.sh
source modules/mtr_test.sh
source modules/http_test.sh

echo "开始测试..."
run_iperf_test
run_ping_test
run_mtr_test
run_http_test
echo "测试完成，报告已生成"

每个模块独立，可以单独跑，也可以全量跑。我习惯把结果输出成 Markdown 格式，方便归档和分享。

嗯，工具选型就这些。记住一个原则：不要迷信单一指标。带宽高不代表延迟低，延迟低不代表不丢包。只有组合测试，才能还原真实场景。