1、前言
iperf3 是网络工程级工具，用来测试 TCP / UDP 在当前 RTT 与丢包条件下的吞吐上限。
用此工具可以测试这条链路能不能稳定吃饱带宽，但是指标并不能反映在网页浏览和观看视频，因为测试模型是基于单一流，而往往在日常中我们面对的是碎片化的混合流量形态，我们要面对的是带宽 + 延迟 + 丢包 + 抖动 + 并发连接 + 协议行为 + 服务器质量 + 运营商策略的多重拷打
2、iperf3 的基本使用方式
1. 基本模型
- Server：被测端
- Client：本地
# VPS
iperf3 -s
# 本地
iperf3 -c VPS_IP
2. 测试下行
iperf3 -c VPS_IP -R
-R = Reverse 表示 VPS → 本地
3. 并发参数
-P N
- 先测单流 (
-P 1)：作为基准，了解单个 TCP 流的性能。 - 逐步增加 (
-P)：从-P 4或-P 8开始，然后尝试-P 16、-P 32。 - 观察吞吐量变化：
- 吞吐量显著增加：继续增加并发数。
- 吞吐量达到平台或下降：说明已达瓶颈（网络带宽、VPS/客户端 CPU 等），此时的并发数是合适的。
- 重要提示：始终使用足够长的测试时间 (
-t至少 30 秒)，确保 TCP 慢启动完成。
| RTT | 推荐并发 |
|---|---|
| < 50 ms | 2–4 |
| 50–100 ms | 4–8 |
| > 100 ms | 8–16 |
4. 测试时间
-t 20
# 或
-t 30
在高 RTT 场景下，测试时间如果选择太短：
- TCP 慢启动（Slow Start）机制未充分发挥：TCP 协议（iperf3 默认使用 TCP 进行带宽测试）在建立连接后会经历一个“慢启动”阶段。在这个阶段，发送方会逐渐增加发送数据的速率，而不是一开始就以最大速度发送。在高 RTT 环境下，每个数据包发送和接收确认（ACK）所需的时间更长，这意味着 TCP 需要更多的时间才能从慢启动阶段逐渐“加速”到网络的实际最大吞吐量。如果
-t参数过小，测试可能会在连接达到其最大潜在吞吐量之前就结束，导致测试结果远低于实际可达到的带宽。- 例如，NVIDIA 建议测试持续足够长的时间，或者使用
-O标志在收集结果前等待 2 秒，以确保 TCP 慢启动完成。
- 例如，NVIDIA 建议测试持续足够长的时间，或者使用
- 测量结果不准确且偏低：由于 TCP 连接没有足够的时间达到稳定状态和最大传输速率，测试报告的带宽值将不准确，通常会显著低于 VPS 实际提供的下行带宽。测试时间过短（例如小于 5 秒）可能会因为测试结束时仍有数据在传输中而受到显著影响。
- TCP 窗口大小优化受限：TCP 窗口大小决定了在等待确认之前可以传输多少字节的数据。在高 RTT 链路中，为了充分利用带宽，需要一个较大的 TCP 窗口来保证有足够多的数据在“飞行中”。如果测试时间过短，TCP 可能没有足够的时间来协商和扩大其发送/接收窗口到最佳大小，从而限制了吞吐量。
- 数据传输量有限：在测试时间内，由于上述原因，实际传输的数据总量会非常有限，这使得基于少量数据计算出的平均带宽更不稳定和不可靠。
在高 RTT 环境下，为确保 iperf3 测试结果的准确性，强烈建议使用足够长的测试时间。通常建议将 -t 参数设置为至少 30 秒，以便让 TCP 充分完成慢启动，并使连接有机会达到稳定状态，从而获得更接近真实网络性能的测量结果。
5. 推荐通用测速模板
iperf3 -c VPS_IP -R -P 8 -t 20
3、iperf3 输出结果如何看
典型输出：
[SUM] 0.00-20.01 sec 315 MBytes 132 Mbits/sec receiver
只需要关注 4 个关键点。
1️、[SUM] receiver（最终结论）
真实可用下行带宽
判断标准（以 VPS 上行为上限）：
| 利用率 | 结论 |
|---|---|
| ≥ 85% | 网络非常好 |
| 60–85% | 可用 |
| < 50% | 有明显问题 |
| < 20% | 不建议使用 |
2、 sender vs receiver（是否在路上丢包）
sender ≈ receiver
sender ≫ receiver
后者说明 严重丢包 / QoS / 限速
3️、Retr（重传）的正确理解
Retr 不能单独看数字大小，必须结合 RTT 与吞吐。
4、可接受的 Retr 场景
- RTT < 60 ms
- 多并发
- 吞吐接近带宽上限
- sender ≈ receiver
👉 对体验 无明显影响
5、危险的 Retr 场景
- RTT > 100 ms
- 吞吐很低
- sender ≫ receiver
👉 TCP 被反复打断，链路不可用
4️、逐秒速率特征
坏迹象：
2 Mbps → 4 Mbps → 6 Mbps → 卡住
说明：
- TCP 慢启动反复失败
- 拥塞窗口（cwnd）长不起来
4、最重要的网络计算公式
1、带宽-时延积（BDP）
BDP = 带宽 × RTT
示例：
100 Mbps × 200 ms
= 100 Mbit/s × 0.2 s
= 20 Mbit ≈ 2.5 MB
含义：
TCP 至少需要 2.5 MB 在“路上飞行”才能跑满这条链路
2️、TCP 吞吐近似关系
吞吐 ≈ 窗口 / RTT × f(丢包)
结论：
- RTT 越大，先天不利
- RTT + 丢包 = 吞吐灾难
3️、 为什么 RTT × 丢包 是“杀手组合”
- 每次丢包 → cwnd 减半
- cwnd 恢复 ≥ 1 RTT
| RTT | 恢复时间 |
|---|---|
| 200 ms | 0.2 秒 |
| 44 ms | 0.044 秒 |
👉 这解释了 高 RTT VPS 即使 RTT 稳定，视频仍然卡
5、如何用 iperf3 判断网络好坏
- RTT < 80 ms
[SUM] receiver≥ 85% 带宽- sender ≈ receiver
- 并发增加后吞吐收敛
- 视频 / 下载体验流畅
- RTT > 150 ms
- iperf3 吞吐 < 20 Mbps
- Retr 爆炸
- sender ≫ receiver
- 视频缓冲、降清晰度
👉 直接放弃，不值得调参数
6、结论
- RTT 稳定 ≠ 网络好
- 高 RTT + 丢包 = 一切实时应用的噩梦
- 低 RTT 即使有一定重传，也能被 TCP 快速消化
- iperf3 是筛 VPS / 判断网络路径价值的“第一道门槛”
RTT 决定上限丢包决定生死