测试环境搭建：硬件选型与网络拓扑设计

吞吐测试这件事，说白了就是「用对的工具，在对的平台上，测对的数据」。我见过太多人拿着笔记本连个千兆交换机就开始跑 iperf，结果数据一塌糊涂还找不到原因。嗯，这里要明确一点：测试环境本身就是被测系统的一部分。

这一章，我们就把硬件选型、软件工具链和网络拓扑这三个环节拆开讲。我会结合自己踩过的坑，帮你搭一套「能复现、能对比、能说服人」的测试环境。

2.1 硬件选型：服务器、网卡、交换机

硬件选型有个基本原则：测试设备的性能上限，必须高于被测设备的上限。否则你测出来的瓶颈到底是 DUT 的，还是测试设备自己的？

2.1.1 服务器选型

我个人习惯把测试服务器分成两类：

做数据面测试时，CPU 的 NUMA 架构 很关键。我曾经在一台双路服务器上跑 100G 吞吐，结果死活跑不满，最后发现网卡插在了第二个 CPU 的 PCIe 槽上，而 iperf 进程绑在了第一个 CPU 的核上——跨 NUMA 访问，延迟直接翻倍。

2.1.2 网卡选型

网卡是吞吐测试的「咽喉」。选错了网卡，后面的调优全是白费。

我按速率和场景列个表：

你想想看，如果拿一块 PCIe 2.0 x1 的网卡去测 10G 吞吐，理论带宽只有 500 MB/s，怎么可能跑满？所以选网卡时，一定要算清楚 PCIe 带宽：

PCIe 3.0 x8 理论带宽 = 8 GT/s × 8 lanes × (128/130 编码效率) ≈ 7.88 GB/s
PCIe 4.0 x8 理论带宽 = 16 GT/s × 8 lanes × (128/130 编码效率) ≈ 15.75 GB/s

2.1.3 交换机选型

交换机在吞吐测试里扮演的角色很微妙——它要么是透明的，要么是瓶颈。我遇到过最离谱的一次，是客户用一台老旧的三层交换机做二层转发测试，结果交换机 CPU 被打满，丢包率超过 30%。

选型要点：

• 线速转发能力：交换容量必须 ≥ 所有端口速率之和 × 2（全双工）。比如 48 口 25G 交换机，交换容量至少 48 × 25 × 2 = 2.4 Tbps。
• 缓存大小：做吞吐测试时，交换机缓存太小会导致微突发丢包。我个人建议缓存 ≥ 9 MB 每端口。
• 流表规模：如果测试涉及 ACL 或 VXLAN 封装，流表至少要支持 32K 条。

2.2 软件工具链：iperf3、netperf、wrk

工具选对了，测试就成功了一半。我按测试类型把工具分个类：

2.2.1 iperf3 —— 吞吐测试的「瑞士军刀」

iperf3 是我用得最多的工具。它简单、稳定、跨平台。但很多人只用了它的默认参数，这其实浪费了它的能力。

我常用的测试命令模板：

# 服务端
iperf3 -s -p 5201 --one-off

# 客户端（单流 TCP 吞吐）
iperf3 -c 192.168.1.100 -p 5201 -t 30 -P 1 -w 256K -l 64K

# 客户端（多流 UDP 吞吐，模拟 VoIP）
iperf3 -c 192.168.1.100 -p 5201 -t 30 -u -b 100M -P 4 -l 1400

参数说明：

• -P：并行流数。单流测的是 TCP 窗口和 RTT 的极限，多流测的是网卡多队列和 CPU 多核的调度能力。
• -w：TCP 窗口大小。我建议设为 BDP（带宽 × 延迟）的 2 倍。比如 10Gbps、RTT 1ms，BDP = 10G × 0.001 = 10 Mb ≈ 1.25 MB，窗口设 2.5 MB 比较合理。
• -l：缓冲区大小。默认 128 KB 对大部分场景够用，但测小包吞吐时建议改小。

2.2.2 netperf —— 协议栈调优的「显微镜」

netperf 比 iperf3 更「底层」。它能测出 TCP 连接建立速率、单次事务延迟、以及协议栈内部的细微行为。我一般在做协议栈参数调优时才会用到它。

典型用法：

# 服务端
netserver -p 12865

# TCP 流吞吐测试
netperf -H 192.168.1.100 -p 12865 -l 30 -t TCP_STREAM -- -m 64K -s 256K

# TCP 请求/响应延迟测试（RR）
netperf -H 192.168.1.100 -p 12865 -l 30 -t TCP_RR -- -r 64,1024

这里 -t TCP_RR 测的是「请求-响应」延迟，对数据库、缓存这类短连接场景特别有参考价值。我调优 Redis 协议栈时，就是靠 netperf 的 RR 测试来验证参数效果的。

2.2.3 wrk —— HTTP 吞吐的「压力机」

wrk 是专门测 HTTP 的。它用 Lua 脚本做请求构造，支持 keep-alive 和 pipelining。我习惯用它来验证 Web 服务器的极限 QPS。

# 基础 GET 请求测试
wrk -t 12 -c 400 -d 30s --latency http://192.168.1.100:8080/index.html

# 带 Lua 脚本的 POST 测试
wrk -t 8 -c 200 -d 60s -s post.lua http://192.168.1.100:8080/api/v1/data

wrk 的 -c 参数控制并发连接数。注意，并发连接数不是越大越好。我曾经在 Nginx 上开 2000 个并发连接，结果 worker 连接数耗尽，大量请求被拒绝。一般建议并发数 ≤ 后端 worker 连接数 × worker 进程数。

2.3 网络拓扑设计

拓扑设计决定了测试结果的「可信度」。我见过最典型的错误，是把测试设备和被测设备串在一台交换机上，然后说「吞吐达标了」——其实瓶颈在交换机上。

我常用的三种拓扑：

2.3.1 背靠背直连拓扑

两台服务器用网线/光纤直连，中间不经过交换机。这是最干净的测试环境，适合验证网卡和协议栈的极限性能。

+-----------+          +-----------+
| 测试端 A  |----------| 测试端 B  |
| (iperf3)  |   DAC    | (iperf3)  |
+-----------+          +-----------+

适用场景： 网卡驱动调优、TCP 参数验证、DPDK 性能测试。

注意： 直连时两端 MTU 必须一致，否则会出现分片导致性能下降。

2.3.2 单跳交换机拓扑

两台服务器通过一台交换机互联。这是最常见的测试拓扑，适合验证网络设备的转发能力。

+-----------+     +-----------+     +-----------+
| 测试端 A  |-----| 交换机    |-----| 测试端 B  |
| (iperf3)  |     | (DUT)     |     | (iperf3)  |
+-----------+     +-----------+     +-----------+

适用场景： 交换机吞吐测试、ACL 性能验证、VXLAN 封装测试。

注意： 交换机端口必须配置为 无丢包模式（flow control off），否则测试结果会受 PFC 影响。

2.3.3 多跳复杂拓扑

模拟真实网络环境，包含多台交换机和路由器。这种拓扑我一般在做端到端性能验证时才会搭。

+-----------+     +-----------+     +-----------+     +-----------+
| 测试端 A  |-----| 交换机 1  |-----| 路由器    |-----| 交换机 2  |-----| 测试端 B  |
| (wrk)     |     | (接入层)  |     | (核心层)  |     | (汇聚层)  |     | (Nginx)   |
+-----------+     +-----------+     +-----------+     +-----------+     +-----------+

适用场景： 云平台网络性能验证、SDN 控制器性能测试、跨数据中心吞吐测试。

注意： 多跳拓扑中，每一跳的 MTU、QoS 策略、流表规则都必须记录清楚，否则出了问题根本没法排查。

2.4 本章知识体系总览

下面这张图把硬件选型、软件工具链和拓扑设计的关系串起来了。你可以把它当作搭建测试环境的「检查清单」。

这张图里，硬件选型是「底座」，软件工具链是「测量仪」，网络拓扑是「被测件的安装方式」。三者缺一不可。你搭建环境时，可以对照这张图逐项检查，确保每个环节都到位了再开始测试。