iperf3 带宽性能测量工具

一、iPerf3 是干什么的

iPerf3 = 专业网络带宽与质量测试工具

它不是简单测速，而是可以测：

• 带宽（TCP / UDP）
• 丢包率
• 抖动（jitter）
• 重传（Retransmissions）
• 网络稳定性

👉 比 speedtest 更“工程级”

iPerf3 官方网站：https://software.es.net/iperf/
iPerf3 Github库：https://github.com/esnet/iperf

二、安装方法

1️⃣ Debian / Ubuntu
apt update
apt install -y iperf3

2️⃣ CentOS / RHEL
yum install -y epel-release
yum install -y iperf3 

3️⃣ windows
iPerf3 已编译版本：https://iperf.fr/iperf-download.php

三、使用演示

iPerf3 是 客户端 也是 服务端

服务端（Server）

iperf3 -p 5200 -s -i 1

命令拆解：
# -p 5200        使用 5200 端口（默认 5201）
# -s             以服务端模式运行（等待客户端连接）
# -i 1           每 1 秒输出一次统计信息

# 👉 运行方式：前台运行（占用当前终端，Ctrl+C 才会停止）

客户端（Client）

1️⃣ TCP 单线程 (应用层延迟测试)
iperf3 -c 192.168.1.1 -p 5200 -i 1 -t 15 -O 2 -V

命令拆解：
# -c             客户端模式
# -p 5200        指定服务端监听端口（默认 5201）
# -i 1           每 1 秒输出一次实时带宽
# -t 15          测试总时长 15 秒
# -O 2           前 2 秒为预热，不计入统计
# -V             输出更详细的 TCP/网络信息

测试方向说明
# 客户端（2.5Gbps） → 服务端（50M↑ / 340M↓）

作用：
# 单条 TCP 连接性能测试
# 模拟真实单线程应用（SSH / API / 单线程上传 / Web 请求）
# 验证链路基础质量与稳定性

适合场景：
# ✔ 判断线路是否稳定
# ✔ 检查是否存在丢包（Retr）
# ✔ 看单 TCP 流是否被限制
# ❌ 不用于跑满带宽（需要多线程）

核心理解：
# 👉 单线程测试看的不是“跑多快”，而是“能不能稳定跑”。

- - - - - - - - - - - - - - - - - - - - - - - - -
测试完成，结果汇总：
# [ ID]   统计周期        总转输数据量    平均传输速率   重传次数
# [  5] 0.00-15.00 sec  357 MBytes   200 Mbits/sec   0      sender  （发出去数据）
# [  5] 0.00-15.16 sec  361 MBytes   200 Mbits/sec          receiver（收到的数据）
# CPU 使用率： 客户端CPU 占用： local/sender 1.8% (0.3%u/1.6%s), 服务端CPU 占用：remote/receiver 21.3% (0.6%u/20.7%s)
# snd_tcp_congestion bbr   客户端：BBR（激进拉速）
# rcv_tcp_congestion cubic  服务端：CUBIC（保守）

结果解读：
# 单线程 TCP 测试结果约 200 Mbps，说明单条 TCP 流已经接近当前路径的自然拥塞窗口上限。
# 但链路本身非常稳定（Retr = 0），不存在丢包或明显拥塞。该结果属于“单流正常瓶颈”，
# 并不代表总带宽上限，实际带宽需依赖多线程测试验证。

2️⃣ TCP 多线程 (上行带宽测试)
iperf3 -c 192.168.1.1 -p 5200 -i 1 -t 15 -O 2 -V   -P 2

命令拆解：
# -P 2        使用 2 条并发 TCP 连接

测试方向说明
# 客户端（2.5Gbps） → 服务端（50M↑ / 340M↓）

作用：
# 用于判断 线路“真实可用带宽上限”

适合场景：
# ✔ 判断 VPS / 节点真实吞吐能力
# ✔ 判断是否能跑满带宽（对比 speedtest）
# ✔ 检测多流情况下是否稳定

核心理解：
# 👉 单流看“能不能跑”，多流看“能跑多满”。

- - - - - - - - - - - - - - - - - - - - - - - - -
测试完成，结果汇总：
# [ ID]   统计周期        总转输数据量    平均传输速率      重传次数
# [  5] 0.00-15.00 sec   307 MBytes   172 Mbits/sec     1210    sender
# [  5] 0.00-15.16 sec   311 MBytes   172 Mbits/sec             receiver
# [  7] 0.00-15.00 sec   308 MBytes   172 Mbits/sec     1311    sender
# [  7] 0.00-15.16 sec   312 MBytes   172 Mbits/sec             receiver
# [SUM] 0.00-15.00 sec   615 MBytes   344 Mbits/sec     2521    sender
# [SUM] 0.00-15.16 sec   622 MBytes   344 Mbits/sec             receiver
# CPU 使用率： 客户端CPU 占用：local/sender 2.6% (0.2%u/2.4%s), 服务端CPU 占用：remote/receiver 38.3% (2.2%u/36.2%s)
# snd_tcp_congestion bbr   客户端：BBR（激进拉速）
# rcv_tcp_congestion cubic  服务端：CUBIC（保守）


结果解读：
# 在 2 条并发 TCP 流情况下，每条线程平均约 172 Mbps + 172 Mbps，总带宽提升至约 344 Mbps，
# 链路吞吐提升至约 344 Mbps，基本达到服务端下行带宽上限，说明多流可以有效释放真实带宽。但同时
# 重传上升至 2521，表明链路在高压状态下存在一定拥塞或路径抖动，属于“带宽已跑满但稳定性开始消耗”的典型特征。