在AWS上部署高吞吐应用时，内网带宽往往是决定架构能否支撑流量的核心指标。iPerf3作为轻量级网络性能测试工具，可以快速给出两个EC2实例之间的TCP或UDP吞吐数据，但如果不注意测试方法和实例本身的网络特性，结果可能与真实负载下的表现相差甚远。本文将从实际评测角度出发，介绍如何搭建测试环境、执行多维度测试并解读输出结果。
一、影响EC2内网带宽的主要因素
实例规格决定了基础网络性能上限。AWS EC2不同实例类型对应不同的基准带宽、突发带宽和最大带宽，例如m5.large、c5.xlarge、c5.4xlarge等规格之间差距明显。测试前必须先确认双方实例的网络性能等级，可以通过AWS官方文档查询当前规格的带宽指标。如果两个实例规格差异过大，低规格实例可能成为瓶颈，导致测试结果无法反映高规格实例的真实能力。
网络模式同样关键。老一代EC2实例可能使用Intel 82599 VF等传统网络接口，而较新的实例默认启用增强网络ENA，后者能够支持更高的包转发率和带宽上限，最多可达100 Gbps。未启用ENA的情况下，驱动性能会限制吞吐。可以通过AWS控制台或命令行查看实例的ENA支持状态，确保使用最新驱动。此外，测试跨可用区时，流量会经过AWS区域骨干网，延迟略高，但带宽通常不会明显下降；而跨区域测试则完全不同，不属于内网评测范畴。
安全组、网络ACL、路由以及MTU都会直接影响测试结果。iPerf3默认监听5201端口，必须提前在安全组中放行该端口的TCP和UDP入站流量，否则连接无法建立。如果测试双方位于不同子网，还需确认路由表配置正确。MTU方面，AWS支持巨帧，可以将MTU设置为9001以减少协议开销，但这要求VPC、子网以及实例操作系统都启用巨帧支持，否则可能导致分片异常。
二、安装iPerf3并启动基础吞吐测试
在两台EC2实例上分别安装iPerf3。Amazon Linux 2023可以使用命令sudo yum install iperf3 -y完成安装，Ubuntu系统则使用sudo apt install iperf3 -y。安装完成后，选择其中一台作为服务端运行iperf3 -s，另一台作为客户端执行iperf3 -c 10.0.1.10，其中10.0.1.10是服务端的私有IP地址。服务端默认监听5201端口，确认安全组放行后即可进行测试。
基础单流测试命令如下：
# 服务端启动 iperf3 -s # 客户端测试10秒 iperf3 -c 10.0.1.10 -t 10
单流测试输出中会显示发送方和接收方的带宽值，但这种方式很容易受到中断请求和单核处理能力的限制。对于高带宽实例，单流TCP测试往往只能达到理论带宽的30%到50%。例如c5.4xlarge标称带宽可达10 Gbps，但单流测试可能只有3到5 Gbps。原因是TCP连接的处理集中在单个CPU核心上，尤其是接收方需要处理网络中断和协议栈，多队列网卡的优势无法发挥。
基础测试因此只能作为初步参考，不能代表实例的最高吞吐能力。要想获得接近真实上限的数据，必须尝试多并行流测试，并观察CPU使用率的变化。如果单侧CPU占用接近100%，说明计算资源成为瓶颈，需要调整测试方法或更换更高规格实例。
三、并行流与窗口调优：逼近真实带宽上限
iPerf3的-P参数可以指定并行客户端线程数。例如iperf3 -c 10.0.1.10 -P 8 -t 20会同时建立8个TCP连接，将流量分散到不同CPU核心，显著提升吞吐。一般建议从4个并行流开始测试，并逐步增加，找到吞吐不再明显增长的临界值。过多并行流可能带来额外的CPU开销和拥塞风险，反而降低整体性能。
TCP窗口大小在高带宽高延迟网络中非常重要。对于AWS同区域低延迟环境，默认窗口通常足够，但当测试跨可用区或网络距离较远时，适当增大窗口可以提升吞吐。iPerf3使用-w参数设置窗口，例如iperf3 -c 10.0.1.10 -P 4 -w 2M。需要根据实际延迟和带宽计算合理的窗口值，避免盲目调大导致内存占用过高。
反向测试和双向测试能够更全面地评估网络能力。-R选项让客户端接收数据，测试下行带宽；-d选项则同时测试上下行。代码示例如下：
# 反向测试，客户端接收数据 iperf3 -c 10.0.1.10 -P 4 -R -t 20 # 双向测试，同时上下行 iperf3 -c 10.0.1.10 -P 4 -d -t 20
很多实际应用并非单向流量，双向测试可以揭示实例的全双工性能。某些实例的聚合带宽是双向共享，单向测试可能无法展现出真实的带宽上限，而双向测试的结果更贴近生产环境中的双向数据传输场景。
四、UDP测试与结果解读
实时音视频、在线游戏等应用更关注UDP性能。iPerf3使用-u参数开启UDP测试，并通过-b指定目标发送带宽，例如iperf3 -c 10.0.1.10 -u -b 8G -t 10。注意如果不指定-b，默认值只有1 Mbps，很容易让人误以为UDP带宽极低。服务端会统计丢包率和抖动，这些指标比带宽数值更值得关注。
结果解读时，TCP测试要重点查看带宽值和重传次数。如果重传率很高，说明存在网络拥塞或链路质量问题，需要检查MTU设置、安全组规则、虚拟网卡驱动以及物理网络状态。UDP测试则要关注丢包率和抖动，高带宽场景下即便0.1%的丢包也可能严重影响应用体验，因此不能只看带宽是否达标。
通常在同VPC同可用区、启用ENA的实例上，多流TCP测试能够达到官方标称带宽的80%到95%，UDP测试结果可能略低。如果测试结果远低于预期，应逐一排查安全组、实例规格、增强网络驱动、CPU负载、MTU以及测试参数是否合理。记录测试环境详细信息有助于后续对比和问题定位。
五、评测过程避坑与优化建议
避免将跨可用区测试作为唯一评估依据。虽然AWS内网跨AZ的带宽通常足够高，但延迟增加会影响小包吞吐，对高频小消息类应用影响较大，而大文件传输类应用则影响较小。建议在同一可用区内进行基准测试，并记录双方实例类型、AMI版本、内核版本、安全组规则等信息，以便复现。
测试期间应关闭其他可能消耗CPU或网络资源的服务。iPerf3本身在高带宽下也会占用大量CPU，尤其是客户端发送端和接收端。可以使用htop或top监控CPU使用率，如果某一侧CPU接近100%，说明计算资源成为瓶颈，此时需要更换更高CPU配额的实例，或者适当调整并行流数量以避免过载。
巨帧设置可以进一步提升大块数据传输效率。在VPC和子网层面开启巨帧支持后，可以在实例上执行sudo ip link set dev eth0 mtu 9001将MTU设置为9001。更大的MTU能减少数据包数量，降低协议开销。但必须确保整条网络路径上的所有设备都支持该MTU，否则会出现分片或丢包，反而降低吞吐。测试前可以先ping一个大数据包验证连通性。
通过对实例规格、网络模式、并行流、窗口大小、UDP参数以及MTU的系统性测试，可以准确评估AWS EC2实例的内网带宽上限，为容量规划和架构设计提供可靠数据支撑。评测过程中保持环境隔离、记录全部配置、多次重复测试取稳定值，才能避免偶然因素干扰，得到可信结论。
