4. 吞吐量测试：使用 iperf3 进行 TCP/UDP 吞吐量测试，理解带宽与窗口大小关系

吞吐量测试，说白了就是看看你的网络到底能跑多快。我刚开始做通信系统测试那会儿，总觉得这玩意儿很简单——不就是发数据、收数据、算速率嘛。直到有一次在数据中心做压力测试，发现千兆网卡死活只能跑到 300Mbps，排查了三天才发现是 TCP 窗口大小没调对。嗯，从那以后我再也不敢小看这个测试了。

今天咱们就用 iperf3 这个工具，把 TCP 和 UDP 的吞吐量测试彻底搞明白。你想想看，如果连自己的网络能跑多快都不清楚，后面做系统调优那就是盲人摸象。

4.1 iperf3 基础用法

iperf3 是目前最主流的网络吞吐量测试工具。我个人习惯把它装在测试链路的两端——一台当服务器，一台当客户端。安装很简单，Linux 上直接 apt install iperf3 或者 yum install iperf3 就行。

先看最基本的 TCP 测试：

# 服务端（IP: 192.168.1.100）
iperf3 -s

# 客户端
iperf3 -c 192.168.1.100

跑完之后你会看到类似这样的输出：

[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  1.10 GBytes   945 Mbits/sec                  sender
[  5]   0.00-10.00  sec  1.10 GBytes   945 Mbits/sec                  receiver

这里 945 Mbits/sec 就是 TCP 吞吐量。注意看，发送端和接收端的数据量基本一致，说明没有丢包。如果接收端明显少于发送端，那就要小心了——网络可能有瓶颈。

我的小技巧： 测试时建议加 -t 30 参数把时间拉长到 30 秒。短时间测试容易受突发流量影响，数据不够稳定。我在项目中吃过这个亏，10 秒测试看着挺好，一上线跑业务就崩。

4.2 TCP 窗口大小与带宽的关系

这里有个核心概念你必须理解——TCP 窗口大小决定了你能跑多快。为什么会这样？

TCP 是可靠传输协议，发送方发出去的数据，必须等接收方确认（ACK）之后才能继续发。窗口大小就是「不需要等待确认就能连续发送的数据量」。窗口越大，管道里能塞的数据就越多，吞吐量自然就上去了。

理论上有条公式：

最大吞吐量 = 窗口大小 / RTT（往返时延）

举个例子：如果 RTT 是 10ms，窗口大小是 64KB，那最大吞吐量就是 64KB / 0.01s = 6.4MB/s ≈ 51.2Mbps。想跑到 1Gbps？窗口至少得 1.25MB。

用 iperf3 测试不同窗口大小的影响：

# 客户端指定窗口大小（Linux 上单位是字节）
iperf3 -c 192.168.1.100 -w 64K
iperf3 -c 192.168.1.100 -w 256K
iperf3 -c 192.168.1.100 -w 1M

我在一次跨国链路测试中遇到过这种情况：默认窗口下只能跑 20Mbps，把窗口调到 4MB 之后直接飙到 200Mbps。你想想看，差了整整 10 倍！

窗口大小 RTT 10ms RTT 50ms RTT 100ms
64KB 51.2 Mbps 10.2 Mbps 5.1 Mbps
256KB 204.8 Mbps 41.0 Mbps 20.5 Mbps
1MB 838.9 Mbps 167.8 Mbps 83.9 Mbps
4MB 3.3 Gbps 671.1 Mbps 335.5 Mbps

看到没？高延迟链路对窗口大小的敏感度极高。这也是为什么卫星通信、跨国专线这类场景特别需要调窗口参数。

注意： 窗口不是越大越好。我曾经把窗口调到 16MB 测试，结果内存占用飙升，反而因为系统缓存压力导致性能下降。实际调优时建议从 256KB 起步，逐步翻倍测试，找到拐点。

4.3 UDP 吞吐量测试

UDP 测试和 TCP 不太一样。UDP 不关心可靠性，它只管发。所以 iperf3 的 UDP 测试需要你手动指定带宽目标：

# 服务端
iperf3 -s

# 客户端，尝试发送 100Mbps 的 UDP 流量
iperf3 -c 192.168.1.100 -u -b 100M

输出结果会告诉你实际发了多少、收到了多少、丢包率是多少：

[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec   119 MBytes   100 Mbits/sec  0.003 ms  0/15238 (0%)  
[  5]   0.00-10.00  sec   119 MBytes   100 Mbits/sec  0.004 ms  0/15238 (0%)

如果丢包率超过 0.1%，说明网络已经扛不住了。我在视频流媒体项目中就用这个方法找到了链路的极限带宽——逐步增加 -b 参数，直到丢包率开始飙升。

UDP 测试还有个重要指标叫 Jitter（抖动）。它衡量的是数据包到达时间的稳定性。实时通信场景（比如 VoIP、视频会议）对 Jitter 很敏感，一般要求低于 20ms。

# 测试不同带宽下的 Jitter 变化
iperf3 -c 192.168.1.100 -u -b 50M
iperf3 -c 192.168.1.100 -u -b 200M
iperf3 -c 192.168.1.100 -u -b 500M
核心结论： UDP 测试的关键是找到「不丢包的最大带宽」。这个值就是你的网络实际能承载的 UDP 吞吐量上限。TCP 因为有拥塞控制机制，实际吞吐量会比这个值低一些。

4.4 多流并发测试

真实业务场景中，很少只有一个连接在跑。我习惯用 iperf3 的并行流参数模拟多用户场景：

# 4 个并行流
iperf3 -c 192.168.1.100 -P 4

# 10 个并行流
iperf3 -c 192.168.1.100 -P 10

你会看到每个流的独立统计和汇总统计。多流测试有个好处——它能暴露单流无法达到的瓶颈。比如单流只能跑 500Mbps，但 4 流加起来能跑 1.8Gbps，说明瓶颈在单连接层面（可能是 CPU 中断处理、也可能是窗口限制）。

我曾经帮一个客户排查问题，他们的应用只用单连接传输大文件，死活跑不满带宽。我建议改成多连接并发，性能直接翻倍。有时候问题不在网络，而在应用的设计上。

4.5 反向测试与双向测试

默认情况下 iperf3 是从客户端往服务端发数据。但实际网络往往是非对称的——下载和上传性能不一样。用 -R 参数做反向测试：

# 服务端到客户端方向
iperf3 -c 192.168.1.100 -R

双向测试用 --bidir：

# 同时测试两个方向
iperf3 -c 192.168.1.100 --bidir

我在运营商网络测试中发现过不少案例：下行能跑 900Mbps，上行只有 300Mbps。如果不做双向测试，你根本发现不了这个问题。

4.6 测试结果解读与常见问题

跑完测试拿到数据，怎么判断正不正常？我一般看这几个点：

  • 吞吐量 vs 带宽上限： 如果千兆网卡只跑出 200Mbps，肯定有问题
  • 发送 vs 接收： 差值超过 5% 就要排查丢包
  • CPU 占用率： iperf3 本身很轻量，如果 CPU 跑满说明瓶颈在主机
  • 多流 vs 单流： 多流能提升说明单连接有限制

常见问题排查思路：

  1. 吞吐量上不去 → 检查窗口大小、RTT、CPU 负载
  2. UDP 丢包严重 → 降低发送速率或检查交换机缓冲区
  3. 双向测试不对称 → 检查链路协商模式、网卡驱动
  4. 多流反而下降 → 可能是 CPU 软中断瓶颈
避坑指南： 我曾经在虚拟化环境中测试，发现吞吐量忽高忽低。排查了半天，结果是宿主机上另一个虚拟机在做备份，抢了带宽。记住——iperf3 测的是「当前网络状态」，不是「网络能力」。测试前要确保环境干净。

4.7 知识体系总结

这一章的内容比较多，我画了张图帮你梳理核心逻辑：

吞吐量测试知识体系 iperf3 吞吐量测试 TCP 吞吐量测试 UDP 吞吐量测试 多流并发测试 窗口大小调优 RTT 影响分析 带宽延迟积 丢包率与 Jitter 带宽极限测试 实时业务评估 单流 vs 多流 CPU 瓶颈排查 应用层优化 核心目标：找到网络极限，定位瓶颈，指导调优

这张图把本章的核心知识点串起来了。TCP 测试关注窗口和 RTT，UDP 测试关注丢包和 Jitter，多流测试用来排查单连接瓶颈。三个方向最终都指向同一个目标——找到网络的真实极限。

好了，这一章的内容就到这里。记住，吞吐量测试不是跑一次就完事的。不同时间、不同负载、不同参数下，结果可能天差地别。多测几次，取平均值，再结合业务场景分析，才能真正摸清你网络的底细。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →