4、吞吐量测试方法：iperf3工具使用、TCP/UDP吞吐量对比、多线程测试、测试环境搭建
吞吐量测试，说白了就是看看你的WiFi链路到底能跑多快。很多工程师调完WiFi参数后，凭感觉说“好像快了”，这不行。你得用数据说话。我个人习惯用iperf3，这工具轻量、跨平台，而且结果稳定，业界公认。
这一章，我会带你从环境搭建开始，到TCP/UDP对比，再到多线程压测，把吞吐量测试这件事彻底讲透。
4.1 测试环境搭建：别让环境坑了你
先说说环境。我见过太多人，拿着笔记本在办公室随便找个位置就开始测，结果数据忽高忽低，根本没法用。你想想看，WiFi信号受干扰、同频AP、甚至微波炉都能影响结果。所以，环境搭建是第一道坎。
具体来说，你需要准备：
- 两台设备：一台做服务端（Server），一台做客户端（Client）。可以是两台Linux电脑，或者一台电脑+一台开发板。
- 有线连接：服务端最好用有线接入路由器，避免服务端本身成为瓶颈。客户端通过WiFi连接被测AP。
- 固定位置：客户端和AP之间距离固定，通常2-3米，无遮挡。我建议用支架固定，别用手拿着。
- 关闭干扰源：关闭蓝牙、关闭其他无线设备、关闭同频段的AP。
嗯，这里要注意：如果你测的是2.4GHz频段，记得把微波炉关掉。我曾经在客户现场排查吞吐量低的问题，折腾了半天，最后发现是隔壁茶水间的微波炉在加热午餐……
4.2 iperf3 安装与基本用法
iperf3 安装很简单。Linux上一条命令搞定：
# Ubuntu/Debian
sudo apt-get install iperf3
# CentOS/RHEL
sudo yum install iperf3
# macOS
brew install iperf3Windows用户可以去官网下载预编译的exe文件，或者用WSL。
基本用法分两步：
- 启动服务端：在服务端执行
iperf3 -s，默认监听5201端口。 - 启动客户端：在客户端执行
iperf3 -c 服务端IP，开始测试。
举个例子，服务端IP是192.168.1.100，客户端执行：
iperf3 -c 192.168.1.100默认情况下，iperf3会进行10秒的TCP测试，每秒输出一次结果，最后汇总。输出大概长这样：
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 112 MBytes 94.0 Mbits/sec
[ 5] 10.00-20.00 sec 110 MBytes 92.3 Mbits/sec
[ 5] 20.00-30.00 sec 115 MBytes 96.5 Mbits/sec
[ 5] 30.00-40.00 sec 108 MBytes 90.6 Mbits/sec
[ 5] 40.00-50.00 sec 113 MBytes 94.8 Mbits/sec
[ 5] 50.00-60.00 sec 111 MBytes 93.1 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-60.00 sec 669 MBytes 93.6 Mbits/sec sender
[ 5] 0.00-60.00 sec 669 MBytes 93.6 Mbits/sec receiver看最后一行，93.6 Mbits/sec 就是平均吞吐量。注意，这里单位是Mbps，不是MB/s。1 Byte = 8 bits，所以93.6 Mbps ≈ 11.7 MB/s。
-t 参数可以指定测试时长，比如 -t 30 测30秒。加 -i 1 可以每秒输出一次结果，方便观察波动。
4.3 TCP vs UDP 吞吐量对比
TCP和UDP的吞吐量表现完全不同。为什么？因为TCP有拥塞控制、重传机制，而UDP只管发，不管收没收到。
我直接说结论：TCP吞吐量通常低于UDP，但更接近真实应用场景。因为你的网页、视频、文件传输，底层都是TCP。UDP吞吐量更多用来测试WiFi链路的极限能力。
测试UDP吞吐量，客户端加 -u 参数：
iperf3 -c 192.168.1.100 -u -b 100M-b 100M 表示以100Mbps的速率发送UDP数据包。如果不加 -b，iperf3默认只发1Mbps，测不出极限。
来看一个实际对比：
| 测试项 | TCP吞吐量 | UDP吞吐量 | 丢包率 |
|---|---|---|---|
| 近距离（2米，无遮挡） | 93.6 Mbps | 112.4 Mbps | 0.02% |
| 远距离（10米，隔一堵墙） | 45.2 Mbps | 78.1 Mbps | 3.5% |
| 强干扰环境 | 12.8 Mbps | 35.6 Mbps | 12.3% |
看到了吗？UDP在远距离和干扰环境下，吞吐量依然比TCP高不少，但代价是丢包率飙升。TCP虽然慢，但数据完整。这就是为什么视频通话偶尔会卡，但不会花屏——它用的是UDP，丢包了就丢帧。
4.4 多线程测试：压出真实性能
单线程测试只能反映一条TCP流的表现。但实际应用中，你的手机可能同时跑着、抖音、浏览器……多个连接并发。这时候，单线程的吞吐量就不够看了。
iperf3支持多线程测试，用 -P 参数指定并行线程数：
iperf3 -c 192.168.1.100 -P 4 -t 30这条命令会同时开4个TCP线程，持续30秒。输出结果会分别显示每个线程的吞吐量，最后汇总：
[SUM] 0.00-30.00 sec 1.02 GBytes 292 Mbits/sec多线程测试能帮你发现两个问题：
- WiFi芯片的多流处理能力：有些低端芯片，单线程能跑80Mbps，但4线程一压，总吞吐量反而下降，说明芯片处理不过来。
- AP的并发瓶颈：AP的CPU或无线模块可能成为瓶颈。多线程测试能暴露这个问题。
我建议的测试策略：
- 先测单线程，记录基准值。
- 再测2线程、4线程、8线程，观察总吞吐量变化。
- 如果总吞吐量不再随线程数增加而提升，说明已经到瓶颈了。
4.5 测试流程与避坑指南
最后，我总结一套标准测试流程，你照着做，数据就有说服力：
- 环境准备：固定设备位置，关闭干扰源，确保服务端有线连接。
- 服务端启动：
iperf3 -s，保持终端打开。 - 客户端测试：先测TCP单线程，再测UDP，最后测多线程。
- 记录数据：每次测试至少跑30秒，记录平均吞吐量和丢包率（UDP）。
- 重复三次：取平均值，避免偶然误差。
避坑指南：
- 我曾经遇到过一个问题：测试结果忽高忽低，后来发现是服务端的防火墙限制了iperf3的端口。记得放行5201端口。
- 我曾经在客户现场，客户端和服务端时间不同步，导致测试结果异常。iperf3依赖系统时间，建议先同步NTP。
- 还有一次，我测UDP时忘了加
-b参数，结果只有1Mbps，还以为是WiFi坏了……
4.6 本章知识体系
下面这张图，帮你理清本章的核心逻辑：