4. 测试环境搭建：硬件选型与软件工具链
吞吐测试不是光靠软件就能搞定的事。硬件选错了，工具再牛也白搭。我见过不少团队，上来就装 iperf3 开测，结果发现网卡丢包、交换机背板跑不满，折腾半天才发现是硬件瓶颈。说白了，测试环境搭建是整场实验的底座，底座不稳，数据全是废的。
这一节，咱们把硬件选型和软件工具链拆开讲。我会结合自己踩过的坑，告诉你哪些参数必须盯死，哪些配置可以偷懒。
4.1 硬件选型：网卡、交换机、线缆
硬件选型的核心就一句话：被测链路不能成为瓶颈。你测的是网络性能，不是硬件性能。所以网卡、交换机、线缆的规格，必须至少比被测链路高一个等级。
4.1.1 网卡选型
网卡是数据进出的第一道门。我个人习惯，测试环境优先用 Intel 或 Mellanox 的服务器级网卡。消费级网卡（比如板载 Realtek）在中断处理、队列深度、驱动稳定性上差太多，测出来的数据波动很大。
| 参数 | 推荐规格 | 说明 |
|---|---|---|
| 接口速率 | 10GbE / 25GbE / 40GbE | 至少比被测链路高 1 倍，避免网卡成为瓶颈 |
| PCIe 通道 | PCIe 3.0 x8 或更高 | 10GbE 需要约 10 GT/s 带宽，x8 是安全线 |
| 队列数 | ≥ 8 队列 | 多队列配合 RSS，能充分利用多核 CPU |
| 卸载功能 | TSO / GRO / LRO | 减少 CPU 开销，提升吞吐上限 |
| 驱动成熟度 | 主流厂商（Intel / Mellanox） | 驱动 bug 会导致测试结果异常，我踩过这个坑 |
4.1.2 交换机选型
交换机是测试环境的“十字路口”。如果交换机背板带宽不够，或者缓存太小，测试结果会严重失真。我建议，测试环境尽量用无阻塞架构的交换机，也就是背板带宽 ≥ 所有端口速率之和。
举个例子：一台 48 口 10GbE 交换机，背板带宽至少需要 48 × 10 Gbps × 2（全双工）= 960 Gbps。低于这个数，就是有阻塞架构，不适合做吞吐测试。
| 参数 | 推荐规格 | 说明 |
|---|---|---|
| 背板带宽 | ≥ 端口数 × 速率 × 2 | 无阻塞架构的基本要求 |
| 缓存大小 | ≥ 4 MB 每端口 | 缓存太小会导致突发流量丢包 |
| 流控支持 | IEEE 802.3x（Pause Frame） | 测试 TCP 时建议关闭，避免干扰结果 |
| 端口类型 | SFP+ / SFP28 / QSFP+ | 根据网卡接口匹配，避免转接损耗 |
4.1.3 线缆选型
线缆是最容易被忽视的环节。很多人觉得“线嘛，能通就行”。但线缆的质量直接影响信号完整性和误码率。我遇到过好几次，换一根线，吞吐从 9.8 Gbps 掉到 7.2 Gbps，就是因为线缆衰减太大。
- 短距离（≤ 7 米）：用 DAC 铜缆，成本低、延迟小、即插即用。
- 中距离（7 ~ 30 米）：用多模光纤 + SR 光模块，10GbE 用 OM3，25GbE 用 OM4。
- 长距离（≥ 30 米）：用单模光纤 + LR 光模块，注意光模块的发射功率和接收灵敏度。
4.2 软件工具链：iperf3、netperf、wrk
硬件搭好了，接下来就是软件工具。工具选对了，测试效率翻倍。我常用的三件套是：iperf3 做基础吞吐测试，netperf 做协议栈细粒度分析，wrk 做 HTTP 层面的性能评估。各有各的用处，别指望一把锤子敲所有钉子。
4.2.1 iperf3：吞吐测试的瑞士军刀
iperf3 是我用得最多的工具。它简单、稳定、跨平台。基本用法就两行命令：
# 服务端（接收端）
iperf3 -s -p 5201
# 客户端（发送端）
iperf3 -c 192.168.1.100 -p 5201 -t 30 -P 4参数说明：
-t 30：测试时长 30 秒，我一般跑 60 秒以上，避免冷启动影响。-P 4：并行流数，用于测试多流场景。注意，并行流数不要超过 CPU 核心数，否则会引入调度开销。-R：反向测试，测下行带宽。-u：UDP 模式，测 UDP 吞吐和丢包率。
-w 256K 调整 TCP 窗口大小。默认窗口可能太小，导致吞吐上不去。我一般从 256K 开始试，逐步增大，直到吞吐不再增长为止。
4.2.2 netperf：协议栈的显微镜
netperf 比 iperf3 更“细”。它能测 TCP 的请求/响应延迟、连接建立速率、以及不同消息大小下的吞吐。如果你怀疑协议栈有问题，netperf 是首选。
# 服务端
netserver -p 12865
# 客户端：TCP 流测试
netperf -H 192.168.1.100 -p 12865 -l 60 -t TCP_STREAM
# 客户端：TCP 请求/响应测试（RR）
netperf -H 192.168.1.100 -p 12865 -l 60 -t TCP_RR -- -r 64,1024参数说明：
-t TCP_STREAM：流吞吐测试，类似 iperf3。-t TCP_RR：请求/响应测试，测的是事务处理能力（TPS）。-r 64,1024：请求 64 字节，响应 1024 字节。模拟小请求大响应的场景。
4.2.3 wrk：HTTP 层的压力测试
wrk 是 HTTP 层面的吞吐测试工具。它用多线程 + epoll 实现高并发，适合测 Web 服务器、反向代理、API 网关的性能。
# 基本用法
wrk -t12 -c400 -d30s http://192.168.1.100:8080/index.html
# 带脚本的复杂测试
wrk -t4 -c200 -d60s -s post.lua http://192.168.1.100:8080/api参数说明：
-t12：12 个线程。线程数一般设为 CPU 核心数的 2~3 倍。-c400：400 个并发连接。注意，并发连接数不是越大越好，超过某个阈值后，吞吐反而会下降。-d30s：测试时长 30 秒。-s post.lua：加载 Lua 脚本，用于自定义请求体、Header、认证等。
Connection: close。否则 wrk 会复用连接，测出来的结果偏乐观。
4.3 工具链对比与选型建议
三个工具各有侧重，我整理了一张对比表，方便你快速决策：
| 工具 | 测试层级 | 核心指标 | 适用场景 |
|---|---|---|---|
| iperf3 | 传输层（TCP/UDP） | 带宽、丢包率、抖动 | 基础吞吐验证、链路质量评估 |
| netperf | 传输层 + 应用层 | TPS、延迟、连接速率 | 协议栈调优、中间件性能分析 |
| wrk | 应用层（HTTP） | QPS、延迟分布、错误率 | Web 服务器、API 网关、反向代理 |
我的建议是：先用 iperf3 确认链路没问题，再用 netperf 挖协议栈细节，最后用 wrk 压应用层。三层验证下来，性能瓶颈基本无处可藏。
4.4 测试环境拓扑图
下面这张图，展示了典型的吞吐测试环境拓扑。我把它画成 SVG，方便你直接嵌入文档。
这张图里，客户端和服务端通过交换机直连。交换机配置为无阻塞模式，流控关闭。线缆根据距离选择 DAC 或光纤。工具链按 iperf3 → netperf → wrk 的顺序逐层测试。嗯，这个拓扑我用了好几年，基本没出过问题。
4.5 环境验证清单
硬件和工具都准备好了，别急着开测。先跑一遍验证清单，确保环境没问题：
- 链路协商检查：用
ethtool eth0确认速率和双工模式。我遇到过协商成 1 Gbps 的情况，结果是线缆问题。 - 中断亲和性：用
cat /proc/interrupts查看网卡中断是否均匀分布在多个 CPU 核心上。如果不均匀，手动设置irqbalance或绑定中断。 - 防火墙关闭：测试期间关闭 iptables / firewalld，避免额外开销。
- CPU 频率锁定：用
cpupower frequency-set -g performance锁定 CPU 频率，避免频率波动影响结果。 - 基线测试：先用 iperf3 跑一次单流 TCP 测试，确认吞吐在预期范围内。如果偏差超过 10%，排查硬件或配置问题。
iperf3 -c <server> -t 5 -P 1 做一次快速“嗅探”，确认链路通且速率正常。然后再跑正式的长时测试。这样能避免浪费大量时间在无效测试上。
环境搭建这块，说复杂也复杂，说简单也简单。核心就一句话：让被测链路成为唯一的变量。硬件选型、工具配置、环境验证，都是围绕这句话展开的。你按这个思路走，测试结果的可信度会高很多。