iperf3 是常用的网络性能测试工具，可以测试：

• TCP 带宽
• UDP 带宽
• 丢包率
• 抖动
• 多连接并发
• 双向网络性能

典型使用场景：

客户端  <======== 网络 ========>  服务端
             iperf3

1. 安装 iperf3

Ubuntu / Debian

apt update
apt install -y iperf3

CentOS / Rocky Linux

dnf install -y iperf3

macOS

brew install iperf3

检查版本：

iperf3 --version

2. 启动服务端

在服务端执行：

iperf3 -s

默认监听：

TCP 5201

指定端口：

iperf3 -s -p 5202

后台运行：

iperf3 -s -D

如果有防火墙，需要开放端口：

ufw allow 5201/tcp

UDP 测试同样需要开放：

ufw allow 5201/udp

3. TCP 基础测试

客户端执行：

iperf3 -c 192.168.1.100

默认测试：

客户端 -> 服务端

持续 10 秒。

指定测试时间：

iperf3 -c 192.168.1.100 -t 30

每秒输出一次：

iperf3 -c 192.168.1.100 -i 1

4. 测试反向带宽

默认方向：

Client -> Server

增加：

-R

测试：

Server -> Client

例如：

iperf3 -c 192.168.1.100 -R

测试公网服务器时，建议正向和反向都跑一次：

iperf3 -c 1.2.3.4
iperf3 -c 1.2.3.4 -R

这样可以分别观察上传和下载能力。

5. 多线程测试

单连接可能无法跑满高带宽链路。

例如使用 4 个并发连接：

iperf3 -c 192.168.1.100 -P 4

8 个连接：

iperf3 -c 192.168.1.100 -P 8

常见测试方式：

iperf3 -c 192.168.1.100 -P 4 -t 30

适合测试：

• 千兆网络
• 跨公网链路
• 高延迟网络
• 单 TCP 流无法跑满的场景

6. UDP 测试

使用：

-u

开启 UDP 测试。

例如测试 100 Mbps：

iperf3 -c 192.168.1.100 \
  -u \
  -b 100M

测试 500 Mbps：

iperf3 -c 192.168.1.100 \
  -u \
  -b 500M \
  -t 30

UDP 重点关注：

Bitrate
Jitter
Lost/Total Datagrams

例如：

0.00-10.00 sec  119 MBytes  100 Mbits/sec
0.120 ms
15/85000 (0.018%)

主要指标：

实时音视频业务尤其需要关注：

丢包率 + Jitter

7. 测试不同 UDP 带宽

可以逐步增加：

iperf3 -c 192.168.1.100 -u -b 10M
iperf3 -c 192.168.1.100 -u -b 50M
iperf3 -c 192.168.1.100 -u -b 100M
iperf3 -c 192.168.1.100 -u -b 500M
iperf3 -c 192.168.1.100 -u -b 1G

观察什么时候开始明显出现：

丢包
Jitter 增加
实际吞吐下降

可以大致判断链路的稳定承载能力。

8. 指定客户端网卡/IP

服务器有多块网卡时，可以指定源 IP：

iperf3 -c 192.168.1.100 \
  -B 192.168.2.10

适合测试：

eth0
eth1
内网
公网
专线
VPN

分别对应的网络性能。

9. 指定端口

服务端：

iperf3 -s -p 6000

客户端：

iperf3 -c 192.168.1.100 -p 6000

10. JSON 输出

方便脚本采集：

iperf3 -c 192.168.1.100 -J

保存到文件：

iperf3 -c 192.168.1.100 -J > iperf.json

适合：

• 自动化监控
• 网络巡检
• Prometheus 数据采集
• CI 网络性能测试

11. 常用测试组合

TCP 单连接

iperf3 -c 192.168.1.100 -t 30

TCP 反向

iperf3 -c 192.168.1.100 -R -t 30

TCP 4 并发

iperf3 -c 192.168.1.100 -P 4 -t 30

TCP 8 并发

iperf3 -c 192.168.1.100 -P 8 -t 30

UDP 100M

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

UDP 500M

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

12. 推荐测试流程

测试一条网络链路时，可以依次执行：

# TCP 上传
iperf3 -c 192.168.1.100 -P 4 -t 30

# TCP 下载
iperf3 -c 192.168.1.100 -P 4 -R -t 30

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

# UDP 500M
iperf3 -c 192.168.1.100 -u -b 500M -t 30

重点观察：

TCP:
- Bandwidth
- Retr
- 上传/下载差异

UDP:
- Bitrate
- Jitter
- Packet Loss

13. TCP Retr 是什么

TCP 测试中经常看到：

Retr

表示：

TCP Retransmissions
TCP 重传次数

例如：

[SUM] 0.00-10.00 sec 1.08 GBytes 928 Mbits/sec 82 sender

其中：

82

表示发生了 82 次重传。

如果重传很多，可能存在：

• 网络丢包
• 链路拥塞
• 网卡错误
• MTU 问题
• Wi-Fi 干扰
• 中间设备性能不足

正常情况下：

Retr 越少越好

14. 注意事项

iperf3 测的是网络，不是磁盘

iperf3 数据主要在内存中生成：

Memory -> Network -> Memory

因此结果基本不受磁盘性能影响。

单线程跑不满不代表网络有问题

例如万兆网络：

iperf3 -c server

可能只能跑：

3~5 Gbps

但：

iperf3 -c server -P 8

可能可以达到：

9+ Gbps

需要结合：

RTT
TCP Window
CPU
单流性能

综合判断。

公网测试结果不等于运营商标称带宽

公网链路中还存在：

ISP
路由路径
跨网
跨省
跨境
拥塞
QoS

所以 iperf3 测到的是：

两台机器之间当前路径的实际性能

15. 常用参数速查

总结

日常测试网络性能，最常用的几个命令基本就是：

# TCP 上传
iperf3 -c SERVER -P 4

# TCP 下载
iperf3 -c SERVER -P 4 -R

# UDP
iperf3 -c SERVER -u -b 100M

# 长时间测试
iperf3 -c SERVER -P 4 -t 60

如果主要排查直播、音视频、VPN、跨公网链路，除了带宽，还要重点关注：

TCP Retr
UDP Packet Loss
UDP Jitter
上传与下载差异

使用 acme.sh 申请 Let's Encrypt ECC 证书

本文以 demo.example.com 为例，使用 acme.sh 申请 Let's Encrypt 的 ECC P-256 证书，并安装给nginx使用。

1. 安装 acme.sh

curl -sL https://get.acme.sh | sh -s email=example@gmail.com
source ~/.bashrc

这里的邮箱不需要校验真实性，符合邮箱规则即可

检查：

acme.sh --version

开启自动升级：

acme.sh --upgrade --auto-upgrade

设置 Let's Encrypt 为默认 CA：

acme.sh --set-default-ca --server letsencrypt

2. 申请 ECC 证书

申请前确保：

• demo.example.com 已解析到当前服务器
• 公网 TCP 80 端口可访问
• 80 端口未被 Nginx、Apache 等服务占用

检查：

dig +short demo.example.com
ss -lntp | grep ':80 '

申请 ECC P-256 证书：

acme.sh --issue \
  -d demo.example.com \
  --keylength ec-256 \
  --standalone

--standalone 会临时监听 80 端口完成 HTTP-01 验证。

3. 安装证书

mkdir -p /etc/nginx/ssl

安装：

acme.sh --install-cert \
  -d demo.example.com \
  --ecc \
  --key-file /etc/nginx/ssl/demo.example.com.key \
  --fullchain-file /etc/nginx/ssl/demo.example.com.pem \
  --reloadcmd "systemctl restart nginx"

最终生成：

/etc/nginx/ssl/demo.example.com.key
/etc/nginx/ssl/demo.example.com.pem

不建议让业务程序直接读取 ~/.acme.sh/ 目录中的证书，应统一通过 --install-cert 安装到业务目录。

4. 验证证书

查看本地证书：

openssl x509 \
  -in /etc/nginx/ssl/demo.example.com.pem \
  -noout \
  -subject \
  -issuer \
  -dates

查看线上实际使用的证书：

openssl s_client \
  -connect demo.example.com:443 \
  -servername demo.example.com \
  </dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -dates

5. 自动续期

安装 acme.sh 时会自动创建定时任务：

crontab -l

acme.sh 会定期检查证书，到期前自动续期。

因为设置了：

--reloadcmd "systemctl restart nginx"

证书续期成功后会自动重启 nginx，使新证书生效。

需要注意：使用 --standalone 时，后续自动续期仍然需要使用 80 端口。如果以后安装了 Nginx 并长期占用 80，建议改用 webroot 或 Nginx 验证方式。

适用场景

适用于：

• Shadowsocks / Trojan 等 TCP 代理
• 跨境网络
• 高 RTT 链路
• 长距离 TCP
• 高带宽、大文件传输
• 多 TCP Flow 代理服务器

推荐组合：

net.ipv4.tcp_fastopen = 3
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

三者作用不同：

TCP Fast Open
→ 减少 TCP 建连和首包延迟

BBR
→ 优化 TCP 拥塞控制，提高高 RTT 链路利用率

fq
→ Flow Queueing + Packet Pacing

TCP Fast Open

原理

普通 TCP：

SYN
↓
SYN/ACK
↓
ACK
↓
DATA

TFO 在满足条件时允许：

SYN + DATA
↓
SYN/ACK
↓
ACK

主要优化：

• 建连延迟
• 首包延迟
• 大量短连接

对长时间稳定传输的最终吞吐影响通常较小。

适用场景

收益较明显：

高 RTT
大量短连接
频繁建立 TCP
HTTP / API
代理请求

收益较低：

低 RTT
长连接
大文件已经进入稳态传输

含义

net.ipv4.tcp_fastopen = 3

含义：

1 = Client
2 = Server
3 = Client + Server

代理服务器通常同时存在入站和出站 TCP，所以使用 3。

BBR

原理

BBR 是 Linux TCP 拥塞控制算法，主要根据：

Bottleneck Bandwidth
+
RTT
+
Delivery Rate

估计链路容量，并控制：

cwnd
pacing_rate
发送节奏

相比主要依赖丢包反馈的传统算法，BBR 更适合：

• 高 RTT
• 高带宽
• 长距离 TCP
• 存在轻微随机丢包的网络

为什么高 RTT 更有价值

例如：

带宽 = 1 Gbps
RTT = 50 ms

BDP：

1 Gbps × 0.05s
≈ 6.25 MB

意味着链路上必须维持足够多的 In-flight Data 才能跑满。

高 RTT 环境下，如果拥塞窗口增长不足或丢包后下降过多，就容易出现：

线路 1 Gbps
实际单 TCP 只有 200 ~ 500 Mbps

BBR 的价值主要就在这里。

BBR 对代理服务器的作用

Shadowsocks / Trojan TCP 可以简化为：

Client
  ↓
TCP Connection 1
  ↓
Proxy Server
  ↓
TCP Connection 2
  ↓
Target

这其实是两段独立 TCP。

服务器上的 BBR：

只控制服务器自己发送出去的 TCP

因此通常对：

Server → Client

也就是下载方向，更容易观察到改善。

BBR 不优化 UDP

Linux：

net.ipv4.tcp_congestion_control = bbr

只作用于：

TCP

不会直接优化：

UDP
QUIC
HTTP/3
Shadowsocks UDP Relay

如果 UDP / QUIC 性能差，应重点检查：

丢包
RTT
抖动
MTU
Socket Buffer
线路 QoS
应用层拥塞控制

fq

推荐：

net.core.default_qdisc = fq

主要提供：

Flow Queueing
Packet Pacing
多 Flow 调度

对代理服务器大量 TCP Flow 比较适合。

常用组合：

fq + BBR

TCP 优化配置

检查系统是否支持 BBR

查看当前可用的 TCP 拥塞控制算法：

sysctl net.ipv4.tcp_available_congestion_control

正常情况下应包含：

bbr

例如：

net.ipv4.tcp_available_congestion_control = reno cubic bbr

如果没有 bbr，尝试加载模块：

sudo modprobe tcp_bbr

再次检查：

sysctl net.ipv4.tcp_available_congestion_control

如果仍然没有 bbr，说明当前内核没有提供可用的 BBR，不建议继续配置：

net.ipv4.tcp_congestion_control = bbr

配置 TCP Fast Open + fq + BBR

创建配置文件：

sudo nano /etc/sysctl.d/99-network-tuning.conf

写入：

# TCP Fast Open
net.ipv4.tcp_fastopen = 3

# Queue Discipline
net.core.default_qdisc = fq

# TCP Congestion Control
net.ipv4.tcp_congestion_control = bbr

应用配置：

sudo sysctl --system

验证配置

检查：

sysctl net.ipv4.tcp_fastopen
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc
sysctl net.ipv4.tcp_available_congestion_control

期望：

net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq

并且：

net.ipv4.tcp_available_congestion_control

中包含：

bbr

进一步检查真实 TCP Connection：

ss -tin

重点关注：

bbr
rtt
cwnd
retrans
delivery_rate
pacing_rate

其中：

rtt
→ 当前往返延迟

cwnd
→ 拥塞窗口

retrans
→ TCP 重传

delivery_rate
→ 实际交付速率

pacing_rate
→ 当前发送节奏

场景建议

国内低 RTT

例如：

RTT < 10 ms
低丢包
低抖动

建议：

TFO：可以开
BBR：可以开，但收益通常有限

更应该关注：

CPU
NIC
MTU
代理程序
线路带宽

跨境 / 高 RTT

例如：

RTT 30 ~ 150 ms
200 Mbps ~ 1 Gbps+
存在随机丢包或抖动

推荐：

net.ipv4.tcp_fastopen = 3
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

这类场景最值得测试 BBR。

常见问题

Q1：开启 BBR 后一定会更快吗？

不一定。

BBR 无法解决：

运营商限速
线路物理瓶颈
CPU 满载
NIC 上限
目标服务器限速
严重物理丢包

如果 CUBIC 已经接近跑满线路，切换 BBR 可能几乎没有变化。

Q2：TFO 能提高大文件下载速度吗？

通常不会明显提高稳态吞吐。

TFO主要优化：

建连
首包
短连接

大文件稳定传输阶段主要取决于：

BBR / CUBIC
RTT
丢包
TCP Window
线路带宽

Q3：为什么开启 BBR 后 iperf3 没变化？

常见原因：

RTT 很低
线路本来已经跑满
原来的 CUBIC 已经足够
CPU 或带宽已经成为瓶颈

结合：

iperf3
ss -tin

一起判断。

Q4：BBR 对 QUIC 有作用吗？

没有直接作用。

因为：

QUIC
↓
UDP

QUIC 的拥塞控制通常由应用自己实现。

Q5：设置 tcp_fastopen=3 就一定使用 TFO 吗？

不一定。

它只代表：

Linux 内核允许使用 TFO

实际是否生效还取决于：

客户端
服务端应用
TFO Cookie
NAT
防火墙
中间网络

Q6：需要升级到 BBRv3 吗？

一般不需要。

生产环境优先使用：

发行版稳定内核自带 BBR

如果评估 BBRv3，应做完整 A/B 测试，至少比较：

吞吐
平均 RTT
P95 / P99 RTT
重传率
丢包
CPU
SoftIRQ

确认稳定收益后再考虑使用。

最终建议

普通跨境代理服务器可以直接使用：

net.ipv4.tcp_fastopen = 3
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

记住：

TFO
→ 优化建连和首包

BBR
→ 优化 TCP 拥塞控制

fq
→ Flow Queueing + Packet Pacing

iperf3 + ss -tin
→ 验证是否真的有收益