测出来的内网带宽忽高忽低，丢包率统计也让人看不懂，这种情况在云服务器上并不少见。iperf3是网络性能测试中最常用的工具之一，它本身并不复杂，但如果启动参数、端口放行、系统缓冲区或云主机规格没有配合好，很容易得到误导性的结果。本文以同VPC下的两台云服务器为对象，演示一套标准的iperf3测试流程，并说明如何从TCP吞吐和UDP丢包两个维度判断内网质量。
iperf3安装与环境准备
测试前需要在这两台云服务器上都安装iperf3。Ubuntu和Debian可以直接使用apt安装，CentOS或RHEL需要先启用EPEL仓库。安装完成后执行iperf3 -v确认版本，建议两台机器使用相同或相近的版本，避免因为协议兼容问题导致结果无法汇总。
# Ubuntu / Debian sudo apt update sudo apt install -y iperf3 # CentOS / RHEL sudo yum install -y epel-release sudo yum install -y iperf3 # 查看版本 iperf3 -v
云服务器与本地虚拟机不同，除了操作系统自带的防火墙，还额外有安全组或网络ACL。iperf3默认监听TCP和UDP的5201端口，因此需要在控制台放行该端口。如果修改为其他端口，例如-p 5202，则要同步放行对应端口。以下命令用于在操作系统内放行流量，安全组规则仍需要在云控制台单独配置。
# Ubuntu系统防火墙放行 sudo ufw allow 5201/tcp sudo ufw allow 5201/udp # CentOS系统防火墙放行 sudo firewall-cmd --add-port=5201/tcp --permanent sudo firewall-cmd --add-port=5201/udp --permanent sudo firewall-cmd --reload
角色上，接收数据的一方运行服务端模式，发送数据的一方运行客户端模式。由于内网链路通常不对称，建议双向都测一遍，因此两台机器都需要完整安装iperf3。
TCP带宽测试与结果分析
iperf3默认使用TCP协议，适合测试内网最大吞吐量。服务端只需要运行iperf3 -s，然后客户端通过-c指定服务端内网IP。建议先做一个30秒的单线程测试，再进行4线程或8线程的并发测试。-t表示测试时长，-i表示输出间隔，-P表示并发连接数。
# 服务端启动，监听5201端口 iperf3 -s # 如需自定义端口和刷新间隔 iperf3 -s -p 5201 -i 1
# 客户端单线程TCP测试 iperf3 -c 192.168.1.10 -t 30 -i 1 # 客户端4线程并发测试 iperf3 -c 192.168.1.10 -P 4 -t 30 -i 1
测试结束后需要同时关注客户端和服务端的输出。客户端输出中sender表示发送端统计，服务端输出中receiver表示接收端统计。正常情况下两者差距不大，如果接收端带宽明显低于发送端，可能是内核丢包、接收缓冲区不足或网络设备缓存过小。下面是一组典型输出。
[ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-30.00 sec 3.21 GBytes 920 Mbits/sec 12 sender [ 4] 0.00-30.00 sec 3.20 GBytes 916 Mbits/sec receiver
这里的920 Mbits/sec约等于115 MB/s。Retr字段表示TCP重传次数，示例中30秒内只有12次重传，属于轻微拥塞或链路抖动，不影响整体判断；如果重传数达到数百甚至上千，说明链路质量较差，需要继续排查。单线程测试容易受CPU单核性能限制，在高速内网上可能无法跑满带宽，这时多线程测试更接近真实能力。
除了正向测试，还可以使用-R参数进行反向测试，让服务端向客户端发送数据，用来评估另一方向的带宽。-d参数可以同时进行双向传输，帮助观察全双工场景下的总吞吐。
# 反向测试 iperf3 -c 192.168.1.10 -R -t 30 -i 1 # 双向同时测试 iperf3 -c 192.168.1.10 -d -t 30 -i 1
UDP丢包率测试与注意事项
UDP没有重传机制，适合评估实时传输质量，例如语音、视频或游戏数据。使用iperf3测UDP时必须指定-b带宽，否则默认只有1 Mbit/s，远低于云服务器内网能力，测出来的丢包率完全没有参考价值。通常先根据TCP测试结果确定一个略高于实际吞吐的带宽，例如TCP结果为920 Mbits/sec，可以设置-b 1G。
# 服务端开启UDP模式 iperf3 -s -u # 客户端UDP测试，目标带宽1G，持续20秒 iperf3 -c 192.168.1.10 -u -b 1G -t 20 -i 1
UDP测试结果中需要重点看两个字段：Jitter表示抖动，Lost/Total Datagrams表示丢包数量和总包数。下面示例中抖动只有0.023毫秒，丢包率为0%，说明链路非常稳定。如果丢包率超过0.5%，尤其达到1%以上，就需要排查发送端CPU是否满载、云服务器是否有带宽突发限制、接收端网卡队列是否不足等问题。
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 5] 0.00-20.00 sec 2.33 GBytes 1000 Mbits/sec 0.023 ms 0/1703821 (0%)
默认UDP包长较小，高速测试时会产生大量小包，增加CPU处理开销，容易造成虚假丢包。可以适当增大包长，例如-l 1400，减少包数量，让测试更接近真实应用。下面是一个带包长参数的UDP测试命令。
# 使用1400字节UDP包进行测试 iperf3 -c 192.168.1.10 -u -b 1G -l 1400 -t 20 -i 1
判断丢包率是否正常还要结合云服务器规格。小规格突发性能实例可能存在网络突发上限，持续打满带宽后会触发限速，UDP丢包会随之升高。可以按100 M、200 M、500 M、1 G逐步提升-b参数，观察丢包从哪个速率开始出现，从而找到实际可用带宽边界。
常见问题与结果优化
如果客户端提示Connection refused或No route to host，优先检查服务端是否启动、端口是否放行。可以使用nc -zv快速验证TCP连通性。UDP测试不通时还要注意安全组是否单独放行了UDP协议，很多云平台的安全组规则需要分别设置TCP和UDP。
# 检查TCP端口连通性 nc -zv 192.168.1.10 5201
带宽测试结果波动大，常见原因是同一时间段有其他任务占用内网带宽，或者云主机CPU积分耗尽导致网络处理能力下降。可以尝试增加iperf3的TCP窗口大小，例如-w 256K，也可以调整系统内核参数提高网络缓冲区。对于高速内网，建议使用4到8线程测试，线程数过高反而会引入调度开销。
# 使用256KB窗口进行TCP测试 iperf3 -c 192.168.1.10 -w 256K -t 30 -i 1
UDP丢包但TCP正常时，不要急于怀疑云厂商。先观察发送端CPU使用率，如果top显示iperf3进程已经占满单核，说明发送速率超过CPU处理能力，可以降低-b或增加包长。对于多核服务器，可以尝试使用-P参数并行发送UDP流，但要注意每一路UDP的带宽之和不能超过物理上限。
最后给出一个简单的综合测试脚本，将TCP多线程测试和UDP丢包测试串起来执行，方便在不同时段快速复测。执行前需要将SERVER_IP替换为实际内网地址。
#!/bin/bash SERVER_IP=192.168.1.10 echo "开始TCP 4线程测试" iperf3 -c $SERVER_IP -P 4 -t 30 -i 1 echo "开始UDP丢包率测试" iperf3 -c $SERVER_IP -u -b 1G -t 20 -i 1
iperf3的结果本身只是原始数据，关键在于控制变量并理解每个字段的含义。版本一致、端口放行、测试时长合理、UDP带宽明确，再加上TCP和UDP组合测试，基本就能还原云服务器内网的真实传输质量。对于偶发丢包和抖动，建议在不同时间段各测一轮，避免把瞬时波动当成稳定性能。
