阿里云ECS在购买页面都会标注一个内网带宽上限，比如2.5 Gbps、10 Gbps，但这个数字是理论规格，实际业务里能跑多少、怎么验证，很多同学并不清楚。iPerf3是目前最常用的网络性能测试工具之一，它通过在两台机器之间建立TCP或UDP连接来打流，直接输出吞吐量、丢包率、延迟抖动等指标，非常适合用来验证ECS实例之间的内网带宽。本文用两台同地域同可用区的ECS实例做一次完整测试，顺便聊聊测试过程中容易踩的坑。
一、测试前的准备：实例选型与环境搭建
这次测试用的是两台ecs.g7.xlarge实例，4核16G，官方标称内网带宽最高10 Gbps。两台实例放在同一个地域的同一个可用区，这是有讲究的：同可用区内网延迟通常在0.1毫秒左右，如果跨可用区，延迟会上升到1毫秒上下，虽然对带宽影响不大，但对小包、高频率传输的测试数据会有干扰。
系统统一使用Alibaba Cloud Linux 3，iPerf3直接用yum安装。如果用的是Ubuntu，换成apt即可：
# CentOS / Alibaba Cloud Linux yum install -y iperf3 # Ubuntu / Debian apt update && apt install -y iperf3 # 验证安装 iperf3 --version
安装完成后，需要确认两件事：一是实例规格标称的内网带宽值，可以在阿里云控制台的实例详情页查看，也可以查官方实例规格文档；二是两台实例的网络类型必须相同，都走同一个专有网络VPC。如果一台是经典网络一台是VPC，内网是不互通的，这一点在老账号环境里要格外注意。
二、安全组与防火墙放行配置
iPerf3默认使用5201端口，测试失败最常见的原因就是安全组没有放行这个端口。阿里云的安全组规则需要在控制台配置，方向选择入方向，授权策略允许，端口范围填5201/5201，授权对象填客户端实例的内网IP，不要图省事填0.0.0.0/0，虽然内网环境风险相对可控，但最小化开放永远是好习惯。
除了安全组，系统内部的防火墙也可能拦截。Alibaba Cloud Linux默认firewalld是关闭的，但如果开启过，需要手动放行：
# 检查firewalld状态 systemctl status firewalld # 放行5201端口（若firewalld开启） firewall-cmd --permanent --add-port=5201/tcp firewall-cmd --reload
配置完成后可以先做一个连通性验证。在客户端实例上ping服务端的内网IP，确认网络可达，再用telnet或者nc探测5201端口是否通。这两步都通过了，iPerf3测试基本不会遇到连接类报错。如果telnet不通但ping通，问题十有八九出在安全组，回去检查规则的方向和端口范围是否写对。
三、TCP单线程与多线程测试
先在服务端启动监听，这条命令会一直挂在前台运行，建议用screen或者nohup包一层：
# 服务端：启动iperf3服务，监听默认5201端口 iperf3 -s # 客户端：TCP单线程测试，持续60秒 iperf3 -c 172.16.0.20 -t 60 # 客户端：TCP多线程测试，8个并行流 iperf3 -c 172.16.0.20 -t 60 -P 8
单线程测试的结果是9.41 Gbits/sec左右，多线程8并发时稳定在9.5到9.6 Gbits/sec之间，距离标称的10 Gbps约95%以上。这说明单线程其实已经基本打满了，因为Linux内核较新的TCP拥塞控制算法（默认cubic）在高带宽低延迟的链路上已经能很好地发挥窗口能力。不过要注意，单线程能否跑满和CPU也有关系，iPerf3是单线程模型，如果实例只有1核或2核，单线程可能被CPU限制住，这时多线程的价值就体现出来了。
测试时建议加-t 60跑满一分钟而不是默认的10秒，前几秒TCP还在慢启动阶段，数据会偏低，跑长一点能观察到更稳定的吞吐曲线。另外可以加上-i 1参数每秒输出一次报告，方便观察是否有波动。如果吞吐曲线呈现明显锯齿状且周期性掉到很低，多半是触发了限速或者有其他业务在抢内网带宽。
四、UDP测试与丢包率分析
TCP测试的是可靠传输下的极限吞吐，而UDP测试更能反映网络本身的承载能力，尤其是丢包率这个指标。测试UDP时必须手动指定目标带宽，因为iPerf3默认的UDP发送速率很小：
# 客户端：UDP测试，目标带宽10Gbps，持续30秒 iperf3 -c 172.16.0.20 -u -b 10G -t 30 -i 5 # 服务端正常启动即可 iperf3 -s
实测下来，指定10G目标带宽时，接收端报告的丢包率约为0.02%，抖动（jitter）在0.02毫秒以内，这个数据在云内网环境里属于正常水平。如果把目标带宽故意调到超过实例规格，比如15G，就会发现发送端看似正常，但接收端的丢包率会飙升到百分之几甚至更高，这是因为超出的部分在虚拟化网络层被丢弃了。通过逐步调高目标带宽观察丢包拐点，可以相对精确地摸出实例的真实带宽上限，这比TCP测试更直观。
还有一个细节：UDP测试时如果服务端报告的速率和客户端发送速率差距很大，且伴随丢包告警，先别急着怀疑网络，检查一下接收端实例的规格。低规格实例的vCPU处理中断的能力有限，高PPS的UDP流量会把CPU打满，表现出来的现象和网络丢包非常相似。用top观察服务端软中断占用即可区分。
五、常见问题与结果判断标准
整理几个测试中高频出现的问题。第一，连接超时，报unable to connect to server，绝大多数是安全组5201端口没放行，少数是服务端没启动。第二，吞吐远低于标称值，检查两点：实例是否是突发性能规格（这类规格的基准带宽有限，只有突发时才能到峰值），以及是否开启了公网带宽限速（公网带宽限速不影响内网，但部分共享型实例内外网共享限速）。第三，跨可用区测试延迟偏高属于正常现象，如果对延迟敏感，尽量把互相通信的实例放在同一可用区。
关于结果判断，业界一般的标准是实测值达到标称值的90%以上即可认为符合预期。因为虚拟化网络栈本身有开销，加上TCP协议头、以太网帧头的开销，100%打满既不现实也无必要。如果长期稳定在标称值的70%以下，就需要排查了：看看有没有其他业务占带宽、安全组流控规则、或者实例本身是不是共享型规格。
最后给一个实用建议：内网带宽测试不要只测一次。业务高峰期和空闲期的测试结果可能差别很大，建议在典型业务时段各测几轮，取稳定值作为容量规划的依据。同时把测试脚本固化下来，实例扩容或者迁移可用区后跑一遍，能快速确认网络性能没有回退。iPerf3轻量、零侵入，配合-J参数输出JSON格式结果还能接入监控系统做自动化基线对比，值得纳入日常运维工具箱。