2. 测试环境搭建：硬件选型、软件栈与网络拓扑设计
做通信系统性能测试，环境搭建是地基。地基没打好，后面测出来的数据全是废的。我见过太多团队，花大价钱买了服务器，结果网卡选错了，线缆没配好，最后跑出来的延迟数据根本没法看。今天咱们就把这块掰开揉碎了讲清楚。
2.1 硬件选型：服务器、网卡与线缆
2.1.1 服务器选型
服务器选型，说白了就是看你的测试场景。我个人习惯把服务器分成三类：
- 控制节点：负责管理测试流程，不需要太强，4核8G就够了
- 流量发生器：这是核心，CPU要强，内存要大，PCIe通道要够
- 被测设备：根据实际业务场景来，但建议和线上保持一致
嗯，这里要注意一个坑。很多人觉得CPU核数越多越好，其实不然。通信测试里，单核性能往往比核数更重要。为什么？因为很多协议栈是单线程处理的，你核再多，单核跑不动也是白搭。
我的推荐配置（流量发生器）：
- CPU：Intel Xeon Gold 6xxx系列，主频3.0GHz以上
- 内存：64GB起步，DDR4 3200MHz
- PCIe：至少2条x16插槽，支持Gen4
- 硬盘：NVMe SSD，500GB以上
2.1.2 网卡选型
网卡是通信测试的咽喉。我曾经在一个项目中，用了某品牌的消费级网卡，结果小包性能惨不忍睹。后来换了Intel X710，问题迎刃而解。
选网卡，主要看三个指标：
| 指标 | 说明 | 推荐值 |
|---|---|---|
| 端口速率 | 单端口能跑多快 | 25Gbps或100Gbps |
| 队列数 | 支持多少RSS队列 | ≥16 |
| 卸载功能 | TSO/GRO/LRO等 | 全支持 |
小技巧：如果你测的是小包（64字节），建议用Mellanox ConnectX系列。我在实际测试中发现，它在小包场景下比Intel的网卡能多跑20%的吞吐量。
2.1.3 线缆选择
线缆这事，很多人不重视。我见过有人用3米的DAC线缆跑100G，结果误码率居高不下。线缆选型其实很简单：
- 短距离（≤5米）：DAC直连铜缆，成本低，延迟小
- 中距离（5-30米）：AOC有源光缆，抗干扰好
- 长距离（≥30米）：光模块+光纤，灵活部署
避坑指南：我曾经在测试25G网络时，用了劣质的SFP+线缆，结果丢包率高达0.1%。后来换了原厂线缆，丢包率直接降到0.001%以下。线缆这东西，真不能省。
2.2 软件栈：操作系统、驱动与测试工具
2.2.1 操作系统选型
操作系统这块，我的建议很明确：用Linux，别折腾Windows。具体用哪个发行版？
- CentOS/RHEL 7.x：稳定，适合生产环境
- Ubuntu 20.04 LTS：驱动支持好，社区活跃
- DPDK专用系统：如果做高性能测试，建议用FreeBSD或定制Linux
我个人习惯用Ubuntu 20.04。为什么？因为它的内核版本够新，对25G/100G网卡的支持很完善。而且遇到问题，网上资料多，不用自己瞎琢磨。
2.2.2 驱动与固件
驱动这事，我吃过不少亏。有一次测试100G网卡，性能死活上不去，折腾了两天。最后发现是固件版本太旧，升级后直接翻倍。
驱动安装的几个要点：
- 用厂商官方驱动，别用内核自带的
- 固件必须升级到最新，尤其是新网卡
- 检查驱动参数，比如Ring Buffer大小、中断合并等
驱动参数示例（Intel i40e）：
# 设置Ring Buffer为4096
ethtool -G eth0 rx 4096 tx 4096
# 关闭中断合并（低延迟场景）
ethtool -C eth0 rx-usecs 0 tx-usecs 0
# 开启RSS多队列
ethtool -L eth0 combined 162.2.3 测试工具选型
测试工具这块，我按场景分类推荐：
| 场景 | 推荐工具 | 说明 |
|---|---|---|
| 吞吐量测试 | iperf3 / iperf2 | iperf3适合单流，iperf2适合多流 |
| 延迟测试 | ping / sockperf | sockperf精度更高，支持ns级 |
| 丢包测试 | mtr / netperf | mtr能看路径丢包，netperf能压测 |
| DPDK测试 | testpmd / pktgen-dpdk | testpmd做转发，pktgen做发包 |
我的经验：别只用一个工具。比如测吞吐量，先用iperf3跑单流，再用iperf2跑多流，最后用netperf验证。三个工具结果一致，数据才可信。
2.3 网络拓扑设计
网络拓扑设计，说白了就是怎么把设备连起来。我见过最蠢的设计，是把流量发生器和被测设备放在同一个交换机下，结果测出来的延迟数据全是交换机的转发延迟。
2.3.1 基础拓扑：直连模式
最简单的拓扑，就是两台服务器直连。适合做：
- 网卡性能测试
- 驱动稳定性测试
- 协议栈基准测试
直连模式的好处是排除了中间设备的影响，测出来的数据最干净。但要注意，线缆长度不能超过规范，否则信号衰减会影响结果。
2.3.2 标准拓扑：三层架构
如果模拟真实网络环境，我建议用三层架构：
- 接入层：流量发生器，模拟用户端
- 汇聚层：被测设备（交换机/路由器）
- 核心层：流量接收器，模拟服务器端
拓扑设计原则：
- 流量发生器和接收器用同一型号服务器，避免硬件差异
- 所有链路速率保持一致，别出现25G接10G的情况
- 预留管理口，方便远程调试
2.3.3 高级拓扑：环形与Mesh
如果你测的是SDN或数据中心网络，环形和Mesh拓扑更合适。我曾在某云厂商的数据中心测试中，用了4台交换机构建Full-Mesh拓扑，专门验证ECMP负载均衡的效果。
这种拓扑的难点在于配置复杂，但能暴露很多隐藏问题。比如，我曾经在环形拓扑中发现，某个厂商的交换机在STP收敛时，丢包时间长达30秒——这在生产环境中是不可接受的。
2.4 知识体系总览
下面这张图，是我做测试环境搭建时的心法。你照着这个框架走，基本不会出大问题。
2.5 环境验证清单
环境搭好了，别急着跑测试。先做一轮验证，确保所有组件都正常工作。这是我个人的检查清单：
- 物理层验证：用ethtool检查链路状态，确认速率和双工模式正确
- 驱动层验证：检查驱动版本，确认Ring Buffer、RSS等参数已设置
- 网络层验证：ping通对端，确认MTU设置正确（建议用9000字节）
- 性能基线验证：用iperf3跑一次简单测试，确认吞吐量达到预期
避坑指南：我曾经在验证环节偷懒，直接跳过了MTU检查。结果测试时发现大包性能异常，查了半天才发现是MTU不匹配。从那以后，我每次搭环境都会跑一遍完整的验证清单，一个环节都不跳过。
好了，测试环境搭建这块就讲到这里。记住一句话：环境搭得好，测试事半功倍；环境搭得差，数据全是垃圾。下一章咱们聊测试用例设计，到时候我会分享一些压箱底的测试场景设计思路。