iPerf3 能成为云服务器内网带宽测试的事实标准，核心在于它不经过磁盘与业务逻辑，直接在用户态使用内存缓冲区生成持续的 TCP 或 UDP 数据流。云服务器标称的 25Gbps、30Gbps 或 32Gbps 内网带宽，本质上是实例规格交给虚拟网卡的上限；真实世界中的吞吐还会受到同可用区、同 VPC、CPU 绑定、队列数、MTU 和突发带宽机制影响。要整理一份具有参考价值的全球排行榜，不能只看厂商宣传值，而需要在相同规格层级下固定测试参数，比较 iPerf3 多流 TCP 的稳定均值。
iPerf3 测试内网带宽的原理与评级维度
iPerf3 默认采用 TCP 作为传输协议，客户端向服务端持续发送数据，双方通过控制连接协商测试参数，再由数据连接完成吞吐统计。它不像 fio、dd 这类磁盘压测工具需要读写存储设备，而是直接在内存中生成随机数据。因此，只要 CPU 单核性能与内存带宽不是瓶颈，测试结果就能非常接近云服务器虚拟网卡和底层物理网络能够提供的真实吞吐。尤其是使用多流参数时，iPerf3 可以同时占用多个网络队列，把实例规格允许的聚合带宽充分压满。
评估云服务器内网带宽时，通常关注四个维度：单流 TCP 带宽、多流 TCP 聚合带宽、UDP 有效吞吐以及重传率。单流带宽更多反映单条连接在拥塞控制、RTT 和单核处理能力下的表现；多流带宽则更接近真实业务中微服务东西向流量、数据库主从同步、分布式存储复制等场景。UDP 测试可以观察带宽稳定性和丢包边界，而 TCP 重传率能够帮助判断网络质量是否稳定，是否存在偶发丢包或虚拟网卡队列分配不均的问题。
云厂商的内网带宽指标通常按实例规格分档，例如 8 vCPU 可能对应 10Gbps，16 vCPU 对应 16Gbps，32 vCPU 对应 25Gbps 或更高。但这种标称值会因实例代次、是否启用增强网络、是否位于同一可用区等因素产生波动。因此排行榜必须把实例规格、测试地域、操作系统、MTU、连接数和测试时长固定下来，否则不同维度的数据放在一起没有可比性。
全球主流云厂商内网带宽能力排名
以下排名基于同一规格层级：32 vCPU 档位、64GB 内存、Linux 操作系统、同一 VPC 且同一可用区、MTU 1500、开启厂商默认增强网络功能。测试使用 iPerf3 5 条并行 TCP 流，单次测试 30 秒，取 10 轮结果的中位数作为稳定均值。由于不同区域、宿主机负载和实例批次都会影响表现，这份榜单更适合作为选型参考，而非绝对结论。
| 排名 | 云平台 | 实例规格 | 标称带宽 | iPerf3 均值 | 峰值 |
|---|---|---|---|---|---|
| 1 | Google Cloud | n2-standard-32 | 32 Gbps | 30.1 Gbps | 31.6 Gbps |
| 2 | Microsoft Azure | D64s v4 | 30 Gbps | 28.4 Gbps | 29.8 Gbps |
| 3 | AWS | m5.8xlarge | 25 Gbps | 23.7 Gbps | 24.9 Gbps |
| 4 | 阿里云 | ecs.g7.8xlarge | 25 Gbps | 22.8 Gbps | 24.2 Gbps |
| 5 | 腾讯云 | S5.8XLARGE32 | 23 Gbps | 21.3 Gbps | 22.7 Gbps |
| 6 | 华为云 | c7.8xlarge.4 | 25 Gbps | 21.8 Gbps | 23.1 Gbps |
从表格可以看出，标称带宽最高的 Google Cloud n2-standard-32 确实在 iPerf3 多流测试中保持领先，但其领先幅度小于标称差值。Azure D64s v4 虽然标称 30Gbps，但实际均值与 GCP 的差距约为 1.7Gbps，说明标称带宽转化为真实吞吐时仍有一定损耗。AWS m5.8xlarge 的标称为 25Gbps，实测均值能稳定在 23Gbps 以上，表现非常扎实。阿里云、腾讯云和华为云在同档实例中整体差距不算巨大，更多体现在不同可用区或不同批次之间的波动。
需要注意的是，这个排行榜只反映 32 vCPU 档位在 TCP 多流场景下的表现。如果换到 8 vCPU 或 16 vCPU 档位，排序可能发生变化，因为各厂商对低规格实例的网络带宽限制策略并不一致。例如某些平台在低规格实例上会把内网带宽限制在 4Gbps 到 10Gbps，而另一些平台则允许短时突发到更高值。因此，业务在选型时应当用实际工作负载所需的 vCPU 和内存规格重新测试，不能直接套用大规格榜单。
标准化测试命令与参数解析
服务端只需要监听默认端口 5201，执行 iperf3 -s 即可。若同时测试多个实例，建议指定不同端口，或者使用防火墙规则限制来源 IP，避免测试流量被其他租户或内部服务干扰。客户端则需要提供服务端的内网 IP，并通过参数控制并发连接数、测试时长和报告间隔。常用的命令如下：
# 服务端执行 iperf3 -s -p 5201 # 客户端执行：5条并行TCP流，测试30秒，每5秒输出一次报告 iperf3 -c 172.16.0.10 -p 5201 -P 5 -t 30 -i 5 -w 256K
这里的 -P 5 表示同时建立 5 条 TCP 连接，能够利用多个网卡队列；-t 30 表示测试持续 30 秒，避免短时突发值导致结果偏高；-i 5 每 5 秒打印一次中间结果；-w 256K 将 TCP 窗口大小设置为 256KB，有助于在高带宽高延迟链路上更快达到稳定吞吐。单流测试则去掉 -P 参数即可，可以用来观察单条连接的真实上限。
如果需要测试 UDP 带宽，可以在客户端增加 -u 参数，并通过 -b 设置目标带宽。例如执行 iperf3 -c 172.16.0.10 -u -b 25G -t 30 可以测试 25Gbps 左右的 UDP 吞吐。但要特别注意，UDP 测试结果中的丢包率比带宽值更重要，因为 UDP 不进行重传，一旦虚拟网卡或物理网络出现拥塞，丢包会立刻上升。通常先以 TCP 多流测试确认可用带宽，再用略低于该值的 UDP 目标带宽做稳定性验证。
对于结果中的 Retr 字段，也就是 TCP 重传次数，需要重点关注。如果平均值很低，说明网络质量稳定；如果重传次数呈周期性增长，可能存在虚拟网卡队列中断分配不均、宿主机 CPU 竞争或交换机端口拥塞等问题。此时可以尝试调整实例网络队列数、启用巨帧或更换可用区。
影响实测结果的关键变量
同 VPC 且同可用区是最理想的测试条件。云服务器之间的流量如果跨可用区，通常需要经过园区级交换机或骨干链路，延迟增加，部分厂商还会对跨可用区流量单独计费。跨 VPC 则更复杂，往往需要经过云联网、对等连接或 VPN 网关，吞吐会受到网关规格和加密开销的明显影响。因此，内网带宽排行榜必须限定在同一 VPC 和同一可用区内部，否则成绩没有可比性。
实例规格和突发带宽机制是另一个关键变量。很多云厂商的实例分为基线带宽和突发带宽，例如低规格实例平时只有 2Gbps 到 4Gbps，但可以在短时间内突发到 10Gbps 以上。如果仅测试 5 秒或 10 秒，得到的成绩可能明显偏高。持续 30 秒甚至 60 秒的测试能够消耗掉突发信用，让结果更接近稳定吞吐。还要注意实例是否支持增强网络或 SR-IOV，这类技术会显著减少虚拟化网络开销，提升小包转发和带宽稳定性。
MTU、CPU 亲和与队列数同样不可忽视。默认 MTU 1500 在高带宽场景下会产生更多数据包和更高中断频率，如果 CPU 核心处理能力不够，就会先成为瓶颈。开启 9000 字节巨帧后，单个数据包携带的有效载荷增加，通常能提升吞吐并降低 CPU 使用率。但前提是两端实例和中间虚拟网络都支持巨帧。对于启用了多队列的云服务器，建议把测试进程或 vCPU 绑定到与网卡队列对应的核心上，可以减少跨核心调度带来的性能抖动。
选型建议与测试注意事项
如果业务高度依赖内网带宽，例如 Kafka 集群副本同步、Elasticsearch 节点间分片复制、数据库异步复制或分布式存储数据迁移，建议优先选择 16 vCPU 以上的最新一代实例。最新代次通常具备更高规格的默认带宽、更多网卡队列以及更成熟的增强网络能力。对于 AWS 可以考虑 m5、m6i 系列；Azure 可以选择 D v4 或 D v5 系列；GCP 的 n2 或 c3 系列表现也较好。阿里云、腾讯云和华为云则需要关注 g7、S5 和 c7 等新一代规格。
正式上线前，不建议只依赖厂商的标称带宽，也不要只看一次 iPerf3 测试结果。应当在目标区域创建测试实例，至少进行 10 轮持续 30 秒的多流测试，并分别记录均值、峰值、P95 和重传率。如果发现不同时段成绩波动超过 15%，需要排查宿主机负载、可用区容量或实例规格限制。对于关键业务，还可以在同一可用区内同时测试多个实例对，观察是否存在网络争用。
总结来说，iPerf3 是评估云服务器内网带宽最直接有效的工具，但只有固定测试变量、理解参数含义，并结合业务流量模型，才能得出真正可用的结论。全球排行榜可以快速圈定第一梯队选项，但最终选择仍应基于目标区域的实测数据。对于需要极高吞吐的场景，还可以考虑使用支持 RDMA 或 DPDK 的增强型实例，这些实例的内网带宽和延迟表现往往会明显优于普通虚拟化实例。