iperf3服务端启动失败提示“address already in use”，常见原因是默认端口5201被占用；应先用ss -tuln | grep :5201确认，再选择换端口（如-p 5202）或谨慎启用--bind-address复用，避免误杀关键进程。
iperf3 服务端启动失败，提示 “address already in use”
直接执行 iperf3 -s 报错，常见原因是 5201 端口被占用（比如之前测试没退出、其他服务监听了该端口）。别急着杀进程，先确认是否真冲突：ss -tuln | grep :5201。如果确实被占，有两个稳妥做法：
- 换端口启动服务端：
iperf3 -s -p 5202，客户端同步改用iperf3 -c 192.168.1.100 -p 5202 - 强制复用端口（适合调试）：
iperf3 -s -p 5201 --bind-address 0.0.0.0，但需确保没其他关键服务依赖该端口
注意：不要用 killall iperf3 粗暴清理——可能误杀后台长期运行的监控任务。
客户端测出带宽远低于物理网卡标称值（如千兆只跑 300 Mbps）
这不是工具不准，而是 TCP 协议栈和系统配置限制了单流吞吐。默认单线程 iperf3 -c 测试结果反映的是“单 TCP 流极限”，不是链路总能力。真实瓶颈常在以下几处：
- 接收端 TCP 窗口太小：Linux 默认
net.ipv4.tcp_rmem可能只有几 MB，加参数强制调大：iperf3 -c 192.168.1.100 --window 2M - CPU 被单核吃满：用
-P 4或-P 8启动多线程，观察是否翻倍提升；若某线程速率明显偏低，检查网卡中断是否绑定到同一 CPU 核 - MTU 不匹配：两端用
ip link show查mtu值，不一致时加--set-mss 1400避免分片
单纯看 [ ID] Interval Transfer Bandwidth 行末尾的 Mbits/sec 数字，忽略 [sender]/[receiver] 标识，容易误读方向——-R 模式下 [sender] 才是服务端发出的速率。
UDP 测试丢包率高，但 ping 却通
ping 用的是 ICMP 小包，而 iperf3 -u -b 1G 发的是大流量 UDP 数据流，二者网络路径处理机制完全不同。丢包不等于链路故障，更可能是：
- 交换机/路由器 QoS 策略限速或丢弃 UDP 流量（尤其企业网）
- 服务端未调大 UDP 接收缓冲区：
sudo sysctl -w net.core.rmem_max=26214400 - 客户端指定的
-b值超过实际可用带宽，例如设-b 1G但链路只有 800 Mbps，必然丢包
关键要看输出里 0.0-10.0 sec 行后的 (0.00%) 丢包率，以及 jitter（抖动）是否突增——抖动 > 10ms 时 VoIP 类业务就会明显卡顿，比丢包更难排查。
测试结果波动大，10 秒内从 900 Mbps 掉到 200 Mbps
瞬时抖动常见，但持续大幅波动大概率暴露底层问题。先排除干扰项：
- 禁用客户端和服务端的节能模式：
sudo cpupower frequency-set -g performance - 关掉非必要后台进程，特别是占用网络或磁盘 I/O 的（如 rsync、logrotate）
- 避免在虚拟机里测——宿主机资源争抢会放大波动；物理机测试时用
taskset -c 2,3 iperf3 -c ...绑定专用 CPU 核
真正难定位的是 NUMA 拓扑问题：若服务端网卡在 Node 0，但 iperf3 进程跑在 Node 1，跨 NUMA 访问内存会导致延迟飙升。用 numactl --hardware 查布局，再用 numactl --cpunodebind=0 --membind=0 iperf3 -s 启动服务端。
