Go 里直接调用 iperf3 做容器网络压测最稳
别碰所谓 “Go 实现的 netperf” —— 没有成熟、维护活跃、支持 TCP/UDP 多流 + 时延统计 + 容器内稳定运行的纯 Go 网络压测库。硬写会掉进 socket 选项、拥塞控制绕过、缓冲区对齐、CPU 绑核、cgroup 限速干扰等坑里，得不偿失。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在容器镜像中
apt install iperf3（Debian/Ubuntu）或apk add iperf3（Alpine），确保二进制可用且版本 ≥ 3.10（修复了部分容器内时钟漂移导致的速率误报） - 用 Go 的
os/exec.Command调用，而非自己实现协议：避免重传逻辑错位、RTT 计算偏差、JSON 输出解析错误 - 服务端启动加
-s -J（JSON 输出），客户端加-c <server> -t 30 -P 4 -i 1 -J</server>，强制统一输出格式，方便 Go 解析stdout - 注意容器网络模式：
host模式下iperf3 -s可能被宿主机其他实例抢占端口；bridge模式要暴露端口且确认 iptables/NFT 规则未截断大包
iperf3 JSON 输出字段含义和解析要点
官方 JSON schema 松散，不同版本字段名微调（比如 end.streams[0].sender vs end.streams[0].sender.bps），直接 unmarshal 易 panic。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先用
iperf3 -c localhost -t 2 -J | jq '.end.sum看实际返回结构，别信文档 - 关键指标只取
.end.sum.bits_per_second（聚合带宽）、.end.sum.jitter_ms（抖动）、.end.sum.lost_percent（丢包率）—— 这三个字段在 3.9+ 版本中稳定存在 - Go 解析时用
map[string]interface{}+ 类型断言，别强依赖 struct；对缺失字段设默认值（如抖动为 0） - 注意时间单位：
jitter_ms是毫秒，但end.time.start_timestamp是 ISO8601 字符串，别直接减
容器内跑 iperf3 遇到 Connection refused 或吞吐远低于预期
不是代码问题，是网络栈或资源限制在捣鬼。常见于 Kubernetes Pod 或 Docker --network=bridge 场景。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 检查
netstat -tuln | grep :5201——iperf3 -s默认监听0.0.0.0:5201，但某些精简镜像（如 distroless）没netstat，改用ss -tuln - 确认 client 能 ping 通 server IP：K8s 中 Service ClusterIP 不支持
iperf3直连，必须用 Pod IP 或 NodePort - 限制 CPU 的 Pod（
resources.limits.cpu: "500m"）可能让iperf3 -s单线程无法及时收包，加-A（异步 I/O）或升到"1"再试 - UDP 测试必加
-u -b 100M，否则默认单流 UDP 带宽极低；同时 server 端开大接收缓冲区：iperf3 -s -u -w 4M
为什么不用 netperf 或自研 Go TCP flood 工具
netperf 本身已多年无主维护，最新版（2.7.0）不支持现代 TCP 选项（如 BBRv2、TSO/GSO 自动协商），容器内常因 sysctl 参数缺失导致测试结果虚高；而手写 Go flood 工具会绕过内核拥塞控制，测的不是“网络性能”，是“发包能力”。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 如果必须用
netperf（如对接旧监控系统），固定用netperf -t TCP_STREAM -H <ip> -- -l 30 -P 0</ip>，禁用多端口（-P 0）避免 bind 失败 - 所有 Go 自研工具务必开启
TCP_NODELAY和SetWriteBuffer，但依然无法模拟真实应用流量模型（如 HTTP chunked、TLS record 分片） - 真正需要对比协议栈行为时，用
tcpdump -i any port 5201 -w perf.pcap抓包，看 retransmit / SACK / window update 是否正常，比任何数字都准
压测工具链越贴近生产环境使用的协议栈路径，结果越不可篡改。拿 iperf3 当黑盒用，比把它当库集成更可靠。
