4. TCP/UDP吞吐测试方法：用iperf灌包，把模组跑满
吞吐测试，说白了就是看模组到底能跑多快。你想想看，一个4G Cat.1模组标称能到10Mbps下行，实际挂到产品上可能连一半都跑不到。为什么？TCP窗口没调、MTU不对、服务器端瓶颈、甚至天线没拧紧——都有可能。
我个人习惯，第一步永远是用iperf做基准测试。先把模组和服务器之间的原始通道摸清楚，再谈优化。
4.1 iperf工具：TCP/UDP灌包的正确姿势
iperf是业界标准工具，几乎所有的通信模组厂商、芯片原厂都在用。它分两端：服务端（-s）和客户端（-c）。
核心原则：服务端跑在PC或云服务器上，客户端跑在模组侧（通过AT指令或嵌入式代码调用）。
4.1.1 TCP吞吐测试
先看服务端怎么起：
# 服务端（PC/服务器）
iperf3 -s -p 5001 -i 1参数说明：-s 服务端模式，-p 端口，-i 1 每秒打印一次结果。
模组侧怎么发起？如果模组支持直接运行iperf（比如OpenLinux方案），直接跑：
# 客户端（模组侧）
iperf3 -c 192.168.1.100 -p 5001 -t 30 -i 1 -P 4-t 30 跑30秒，-P 4 开4个并行流。为什么要并行？单连接往往压不满带宽，尤其是高延迟链路。
我的经验：测试TCP吞吐时，-P 参数从1开始往上加，观察吞吐量曲线。我在一个项目中遇到过，单连接只能跑3Mbps，开到4个并行流直接飙到9Mbps——原来是模组的TCP窗口太小，单连接发完一个窗口就得等ACK。
4.1.2 UDP吞吐测试
UDP测试更简单，因为没有拥塞控制，测的是裸带宽：
# 服务端
iperf3 -s -p 5002 -u
# 客户端
iperf3 -c 192.168.1.100 -p 5002 -u -b 10M -t 30 -i 1-b 10M 指定目标带宽。UDP测试的关键指标是丢包率和抖动。
| 测试类型 | 关键参数 | 关注指标 | 典型问题 |
|---|---|---|---|
| TCP | -P 并行流数 | 吞吐量、重传率 | 窗口太小、RTT过高 |
| UDP | -b 目标带宽 | 丢包率、抖动 | 带宽不足、缓冲区溢出 |
注意：UDP测试时，如果丢包率超过1%，说明链路或模组处理能力已经到瓶颈了。我曾经在某个Cat.1模组上测UDP，-b设到15M，丢包率直接飙到8%——后来发现是模组的UDP接收缓冲区只有16KB，根本来不及收。
4.2 AT+QISEND / AT+QIRD：模组侧的收发指令
很多物联网模组（比如移远、广和通）不支持直接跑iperf，你得用AT指令来收发数据。这里以移远的AT+QISEND和AT+QIRD为例，其他厂商的指令大同小异。
4.2.1 AT+QISEND：发送数据
先建立TCP连接：
AT+QIOPEN="TCP","192.168.1.100",5001
// 返回 CONNECT OK然后发数据：
AT+QISEND=0,100
// 输入100字节数据（十六进制或ASCII）
// 返回 SEND OK参数：0 是连接ID，100 是数据长度。注意，每次发送前要等SEND OK，不能连续发。
吞吐测试技巧：用循环发大包。比如每次发1460字节（TCP MSS典型值），连续发1000次。我习惯在MCU端写一个循环脚本，每收到SEND OK就发下一包，同时用定时器统计总耗时。
4.2.2 AT+QIRD：接收数据
接收数据有两种方式：
- 主动查询：
AT+QIRD=0,1460读最多1460字节 - URC通知：模组收到数据会自动上报
+QIURC: "recv",0
吞吐测试时，我建议用URC方式，否则轮询会浪费大量CPU时间，影响测试结果。
// 设置URC上报
AT+QCFG="urc/ri/ring",1
// 收到数据时，模组会主动上报
+QIURC: "recv",0
// 然后你用AT+QIRD去读4.3 单连接 vs 多连接测试
这是很多人容易忽略的点。单连接和多连接，测出来的结果可能天差地别。
4.3.1 单连接测试
只建立一个TCP/UDP连接，持续灌包。适合评估：
- 模组单通道的处理能力
- TCP窗口调优效果
- 链路RTT对吞吐的影响
我见过一个案例：某模组单连接TCP只能跑2Mbps，但UDP能跑8Mbps。说明问题出在TCP协议栈上，不是物理层带宽不够。
4.3.2 多连接测试
同时建立多个连接（比如4个、8个），每个连接独立收发。适合评估：
- 模组的多任务处理能力
- 并发场景下的稳定性
- 服务器端负载能力
用iperf的-P参数就是多连接。用AT指令的话，你得手动创建多个AT+QIOPEN连接。
| 对比项 | 单连接 | 多连接 |
|---|---|---|
| 测试目的 | 单通道极限 | 并发能力 |
| 典型场景 | 视频流、文件上传 | 多设备接入、网关 |
| 常见瓶颈 | TCP窗口、CPU单核 | 内存、连接数限制 |
| 测试时长 | 30-60秒 | 2-5分钟（需稳定） |
避坑指南：我曾经在测试某款模组时，单连接跑得好好的，一开4个连接就频繁断连。查了半天，发现是模组的最大连接数只有6个，而且每个连接默认分配的内存太小，数据一多就OOM。所以多连接测试一定要先看模组规格书里的最大连接数和每连接缓冲区大小。
4.4 吞吐测试流程总图
下面这张图概括了整个测试流程，从环境搭建到结果分析：
4.5 实战中的几个坑
最后分享几个我踩过的坑，希望能帮你省点时间：
- 服务器端防火墙：iperf默认端口5001，很多云服务器默认不开。记得在安全组里放行。
- MTU不一致：模组默认MTU是1500，但有些运营商网络会分片。我遇到过MTU设成1500时吞吐只有2Mbps，改成1400直接翻倍。
- AT指令的流控：用AT+QISEND连续发大包时，一定要等
SEND OK。我曾经没加流控，结果模组缓冲区溢出，数据全丢了。 - 测试时长：TCP测试至少跑30秒，UDP至少60秒。短时间测试看不出问题，尤其是TCP的慢启动阶段。
我的习惯：每次测试前，先ping一下服务器，确认RTT和丢包率。如果ping都丢包，那吞吐测试就不用做了——先修网络。