内网带宽与质量测速是什么
迁移或扩容之前先量真实可用带宽，比看标称值靠谱。iperf3 是最常用的打流工具：服务端以 iperf3 -s 常驻监听 5201，客户端用 -c 指定目标地址发流。关键在怎么测才算数：单流只反映单个 TCP 连接的吞吐，多流（-P）才能压满链路；-R 反向测试检验下行方向；-u 切到 UDP 模式才能看到丢包与抖动。测之前还要确认两侧 CPU 空闲，否则量到的是 CPU 上限而不是网络上限。
基本信息
| 适用平台 | Linux、macOS、Windows（iperf3，需两端版本相近） |
|---|---|
| 场景 | 内网与专线带宽验收、链路质量评估 |
| 组合命令 | iperf3 -s 与 -c -P -R -u |
| 默认端口 | 5201（TCP 与 UDP 相同） |
| 关键指标 | 吞吐速率、TCP 重传、UDP 丢包率与抖动 |
| 前提 | 两侧防火墙放行 5201，两端都能运行 iperf3 |
典型使用场景
- 新购专线或云内网交付验收，确认实测吞吐是否接近标称带宽。
- 上线大流量业务前评估链路余量，避免上线后才发现瓶颈。
- 排查「链路看着正常但应用传输慢」，用多流与反向测试定位限制点。
- 更换交换机、网卡或升级链路后做前后对比。
- 验证限速或 QoS 策略是否按预期生效。
标准测试流程
标准测试流程
# 服务端（A 机）
iperf3 -s # 前台监听 5201
iperf3 -s -D # 以守护进程方式运行
# 客户端（B 机）
iperf3 -c 10.0.0.5 -t 10 # 单流上行测 10 秒
iperf3 -c 10.0.0.5 -t 10 -P 4 # 4 条并行流，更容易压满链路
iperf3 -c 10.0.0.5 -t 10 -P 4 -R # 反向测试，衡量下行
iperf3 -c 10.0.0.5 -u -b 500M -t 10 # UDP 模式，看丢包与抖动
iperf3 -c 10.0.0.5 -t 30 -i 5 -P 8 # 每 5 秒输出中间结果结果逐项读法
| 指标 | 含义 | 判断要点 |
|---|---|---|
| Bitrate | 吞吐速率 | 多流总吞吐才代表链路能力 |
| Retr | TCP 重传次数 | 持续增长说明有丢包或链路质量问题 |
| Jitter | UDP 抖动 | 实时业务关注，一般要求毫秒级 |
| Lost 丢包率 | UDP 丢包 | 有丢包会明显影响实时语音视频体验 |
| Sender 与 Receiver | 两侧统计速率 | 两侧差异大时注意方向与瓶颈位置 |
| 端口 5201 | 默认监听端口 | 被防火墙拦掉是最常见的测不了原因 |
单流吞吐受 TCP 窗口、往返时延与单核 CPU 限制，往往远低于链路容量。判断链路能力要看多流结果（-P 4 以上），单流数据只适合用来对比应用的实际体验。
UDP 模式必须显式指定 -b 目标速率：不指定时默认速率很低，既测不出上限，还可能让人误判链路只有这么点能力。测试速率要略高于预期带宽，才能看出丢包拐点。
测完记得关掉临时启动的服务端进程与临时放行的端口，长期开着既占端口，也留下一个未授权打流的入口。