必须用iperf3多线程测试：服务端运行iperf3 -s，客户端用-p 4或-p 8并发、-t 30+时长、-w调窗口，并关闭防火墙；结果看bitrate（实测吞吐）、retr（重传）和transfer（总传输量）三指标。
要准确测出两台Linux服务器之间内网链路的真实吞吐能力，必须绕过单线程CPU瓶颈、排除防火墙干扰、匹配网卡物理能力，并用多流并发压满带宽。
准备两台机器并安装iperf3
在待测的两台Linux服务器上分别执行对应命令：Ubuntu/Debian运行sudo apt install iperf3 -y，CentOS/RHEL运行sudo yum install iperf3 -y。安装完成后用iperf3 -v确认版本不低于3.1，低于此版本可能缺失-P参数支持。
注意：两台机器必须能互相ping通，且处于同一局域网段（如192.168.1.0/24），不能跨路由或NAT——否则测的不是内网吞吐量，而是网关转发能力。
启动服务端监听
选定其中一台作为服务端，在其终端直接运行：iperf3 -s。
这条命令会让服务端在默认5201端口监听TCP连接。如果该端口被占用，可换用iperf3 -s -p 5202指定新端口；若需后台常驻，加-D参数：iperf3 -s -D，但首次测试建议不加-D，便于实时观察日志。
客户端发起多线程TCP吞吐测试
在另一台机器（客户端）上执行以下任一命令：
方法一：基础压测（适合千兆网卡）
iperf3 -c 192.168.1.100 -P 4 -t 30
其中192.168.1.100替换为服务端真实IP，-P 4启用4个并行TCP流，-t 30延长测试至30秒以规避瞬时抖动干扰。
方法二：万兆网卡满载测试
iperf3 -c 192.168.1.100 -P 8 -t 60 -w 4M
-P 8提升并发数，-w 4M手动扩大TCP接收窗口，避免长肥管道（Long Fat Network）场景下因窗口太小限制吞吐——这一步对跨机房或高延迟内网尤为关键。
方法三：反向测试验证上行能力
iperf3 -c 192.168.1.100 -R -P 4
加-R后数据由服务端发出、客户端接收，专门测服务端所在机器的发包能力。很多云服务器上行带宽受限，此项不可省略。
【务必关闭客户端和服务端的防火墙】：Ubuntu执行sudo ufw disable，CentOS执行sudo systemctl stop firewalld。若仅放行端口，易因连接跟踪表满导致中途断流，临时关防火墙最可靠。
解读结果中的关键字段
测试结束后，客户端输出中找这一行：
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-30.00 sec 10.2 GBytes 2.89 Gbits/sec 12
Bitrate就是实测吞吐量，单位是Gbits/sec（注意是bit不是Byte）；Retr是重传次数，大于0说明链路存在丢包或拥塞，需检查交换机缓存、网线质量或网卡驱动；Transfer是总传输量，可用于交叉验证——例如30秒跑出2.89Gbps，理论应传输约10.8GB，若实际Transfer明显偏小，大概率是磁盘I/O或内存带宽成了瓶颈，而非网络本身。
若Bitrate长期卡在940Mbps上下，基本可判定是千兆网卡物理上限；若始终低于700Mbps，优先查网线是否为超五类以下、交换机端口是否协商成百兆、网卡是否被限速（ethtool eth0看Speed字段）。
