加 -R 才能测出真实下行，因默认 iperf3 -c 测客户端上行吞吐，-R 切换为服务端发送、客户端接收，反映服务器推数据能力；实操中测 Web/CDN/下载必须加 -R。
iperf3 测带宽，为什么加 -R 才能测出真实下行？
默认情况下 iperf3 -c 是客户端发、服务端收，测的是「上行吞吐」（即客户端出口能力）。但多数业务关心的是服务器能否把数据高效推给客户端——也就是「下行吞吐」。不加 -R，你看到的其实是客户端网卡往外打的数据，不是服务端响应用户请求的能力。
实操建议：
- 测 Web 服务器响应带宽（比如 CDN 回源、API 下载），必须加
-R：iperf3 -c 192.168.1.100 -R -t 10 - 加
-R后，sender行显示的是服务端发送速率，receiver行是客户端接收速率；丢包和重传统计也以服务端视角为准 - 别用
-b限速后还加-R——限速值作用于 sender 端，-R切换后限速就变成服务端输出限速，容易误判链路能力
netperf 的 TCP_RR 和 TCP_CRR 到底在测什么？
TCP_RR（Request/Response）模拟的是「小请求+小响应」交互场景，比如数据库查询、HTTP GET；而 TCP_CRR（Connection Request/Response）只测 TCP 连接建立本身（三次握手 + ACK），不传业务数据。两者单位都是 tps（每秒事务数），但瓶颈点完全不同。
常见错误现象：
- 测
TCP_RR得到 800 tps，但实际 HTTP 接口 QPS 只有 200 ——说明瓶颈不在网络栈，而在应用层处理或线程池 -
TCP_CRR低于 2000 tps，基本可判定内核连接建立慢：net.ipv4.tcp_tw_reuse未开、SYN 队列溢出（netstat -s | grep "listen overflows"）、或中断集中在单个 CPU 核上 - 测试时漏加
-- -r 2048,2048，默认请求/响应各 1 字节，结果严重失真；真实业务至少设为 1KB~4KB
UDP 测试必须同时看丢包率和抖动，光看带宽没意义
iperf3 -u 默认跑 UDP 流，但它不保证可靠交付。带宽数字再高，如果 Retr（重传）为 0 而 datagrams received out-of-order 或 packets lost 显著，说明底层链路或接收端处理已出问题。
实操建议：
- UDP 测试务必加
-b控制发送速率，否则突发流量直接打爆接收端缓冲区：iperf3 -c 192.168.1.100 -u -b 50M -t 30 - 服务端需确认是否启用了足够大的 UDP 接收缓冲区：
sysctl net.core.rmem_max至少设为 4MB，否则大量socket buffer errors - 抖动（jitter）值在输出里是毫秒级，但注意：iperf3 计算抖动基于接收时间戳差，若客户端和服务端时钟不同步（如没开 NTP），抖动读数会系统性偏高
别把 iperf3 和 netperf 输出混着比，它们的“吞吐”定义根本不同
iperf3 的 bitrate 是纯 payload 数据速率（不含协议头），单位是 bits/sec；而 netperf TCP_STREAM 的 throughput 默认包含 TCP/IP 头部开销，且受 -m（消息大小）和 -l（测试时长）影响极大——短时测试易受 TCP 慢启动干扰，长时测试又可能掩盖瞬时拥塞。
容易踩的坑：
- 用
iperf3测出 9.2Gbps，netperf TCP_STREAM却只有 7.8Gbps，就断言“netperf 更准”——其实只是 netperf 默认用了 64KB 消息大小，而 iperf3 是流式连续发送 - 对比前没统一测试条件：iperf3 用
-P 4开 4 并行流，netperf 却只跑单流，结果差距本质是并行度差异，不是工具偏差 - netperf 输出里的
elapsed time包含连接建立、参数协商等控制开销，真正数据传输时间要减去首秒左右的 ramp-up 阶段
最常被忽略的一点：所有工具测出的数字，都依赖于你是否压到了真正的瓶颈。比如 iperf3 显示 950Mbps，但 mpstat -P ALL 1 发现某个 CPU 核跑满 100%，那瓶颈其实在软中断处理，不是网卡或带宽。
