2、测试环境搭建：服务器端配置、客户端配置、网络拓扑与工具链
环境搭建这事，说简单也简单，说复杂能折腾你一整天。我刚开始做 QUIC 吞吐测试时，以为配个服务器、装个客户端就能跑，结果被各种内核参数和防火墙坑了整整一个下午。今天我把踩过的坑和经验一起梳理出来，你照着搭，基本一次过。
2.1 服务器端配置
服务器是测试的起点。我个人习惯用 Linux 服务器，Ubuntu 22.04 LTS 或 CentOS Stream 9 都行。QUIC 依赖 UDP，所以内核参数得调一调。
核心配置清单：
- 操作系统：Ubuntu 22.04 LTS / CentOS Stream 9
- 内核参数：开启 BBR 拥塞控制，调整 UDP 缓冲区大小
- QUIC 实现：选用
quiche或lsquic，我推荐quiche，社区活跃、文档全 - 防火墙：开放 UDP 443 或自定义端口
具体操作，我直接贴一段我常用的配置脚本：
# 开启 BBR
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
# 调整 UDP 缓冲区（单位：字节）
echo "net.core.rmem_max=26214400" >> /etc/sysctl.conf
echo "net.core.wmem_max=26214400" >> /etc/sysctl.conf
# 应用配置
sysctl -p
# 安装 quiche 依赖
apt update && apt install -y cargo cmake libssl-dev
# 编译 quiche
git clone https://github.com/cloudflare/quiche.git
cd quiche
cargo build --release
注意： 我曾经在 CentOS 上忘记关闭 SELinux，结果 QUIC 连接一直建立失败。排查了半天才发现是 SELinux 拦截了 UDP 包。建议测试环境直接 setenforce 0，生产环境再按需配置。
2.2 客户端配置
客户端这边，我一般用两台机器：一台跑测试工具，一台跑监控。测试工具我推荐 h2load 或 quic-perf。h2load 支持 HTTP/3，能直接压 QUIC 服务。
客户端的关键参数：
| 参数 | 推荐值 | 说明 |
|---|---|---|
--workers |
4~8 | 并发工作线程数，根据 CPU 核数调整 |
--connections |
100~500 | 并发连接数，测试吞吐时建议从 100 起步 |
--duration |
60s | 测试时长，太短数据不稳定，太长浪费时间 |
--udp-buffer |
65536 | UDP 接收缓冲区，避免丢包 |
举个例子，我常用的压测命令：
h2load -n 100000 --workers 4 --connections 200 --duration 60 \
--udp-buffer 65536 https://your-quic-server.com:4433/path
嗯，这里要注意：QUIC 的 0-RTT 握手在首次连接时用不上，所以第一次压测结果会偏低。我习惯先跑一次预热，等连接池建立后再正式测试。
2.3 网络拓扑
网络拓扑直接影响测试结果。你想想看，如果中间有 NAT 或防火墙，QUIC 的 UDP 包可能被分片或丢弃。我建议用直连拓扑，避免干扰。
我的经验： 在实验室环境，我通常把服务器和客户端放在同一个二层网络，中间只接一台交换机。这样能排除路由器和防火墙的干扰，测出来的数据更干净。
下面这张图是我常用的测试拓扑：
为什么强调直连？因为 QUIC 对丢包非常敏感。我曾经在跨公网测试时，中间经过三层 NAT，结果吞吐直接掉了 40%。后来换成二层直连，数据才恢复正常。
2.4 工具链
工具链选对了，事半功倍。我整理了一份常用工具清单：
| 工具 | 用途 | 备注 |
|---|---|---|
| h2load | HTTP/3 压测 | 支持 QUIC 和 HTTP/3，输出吞吐、延迟、连接数 |
| quic-perf | QUIC 专用性能测试 | 轻量级，适合快速验证 |
| tcpdump | 抓包分析 | 抓 UDP 包，配合 Wireshark 分析 QUIC 帧 |
| iftop | 实时带宽监控 | 看瞬时吞吐，方便定位瓶颈 |
| perf | CPU 性能分析 | 看 QUIC 处理是否吃满 CPU |
一个小技巧： 我习惯在压测时同时跑 tcpdump -i eth0 udp port 4433 -w quic_test.pcap，等测试结束后用 Wireshark 分析 QUIC 的帧结构。这样能直观看到丢包、重传和 RTT 变化，比只看吞吐数字更有说服力。
2.5 环境验证
配置完别急着跑大测试。先做一次快速验证：
- 检查 UDP 端口是否可达：
nc -uvz server-ip 4433 - 测试 QUIC 握手：用
quiche-client发一个简单请求 - 确认 BBR 生效：
sysctl net.ipv4.tcp_congestion_control返回bbr
我遇到过最坑的事：服务器端 BBR 没生效，结果 QUIC 的拥塞控制退化成 CUBIC，吞吐直接腰斩。所以这一步千万别省。