1. 蜂窝模组吞吐性能全景概览
各位工程师朋友，咱们直接进入正题。吞吐量——说白了就是模组在单位时间内能传多少有效数据。你买再贵的模组，如果吞吐上不去，那跟用便宜货没啥区别。我这些年调试过的模组少说也有几十款，每次客户抱怨“网速慢”，十有八九不是运营商的问题，而是吞吐没调透。
1.1 吞吐量定义与关键性能指标
吞吐量（Throughput）通常用 Mbps（兆比特每秒）表示。但注意，这里说的是有效载荷的传输速率，不是物理层速率。物理层给你标称 150Mbps，实际应用层能跑到 80Mbps 就算不错了。
核心公式：
有效吞吐量 = 传输数据量 ÷ 传输耗时（含重传、协议开销）
我习惯把 KPI 分成三档来看：
| 指标 | 说明 | 我关注的阈值 |
|---|---|---|
| 峰值吞吐量 | 理想信道下的最大速率 | ≥ 理论值 90% |
| 平均吞吐量 | 长时间测试的均值 | ≥ 峰值 70% |
| 边缘吞吐量 | 弱信号场景下的表现 | ≥ 峰值 30% |
| 时延抖动 | RTT 的波动范围 | ≤ 20ms |
嗯，这里要注意：峰值吞吐量好看没用，真正影响用户体验的是边缘吞吐量。我曾经在某个智慧港口项目里，模组在基站边缘死活跑不到 5Mbps，后来发现是 TCP 窗口没针对高时延链路做优化——这个后面章节会细讲。
1.2 影响吞吐的三大核心维度
吞吐上不去，原因逃不出这三个圈：射频、协议栈、应用层。我画了张图，帮你把关系理清楚。
1.3 射频维度：信号质量决定天花板
射频是吞吐的物理基础。你想想看，信号不好，协议栈再优化也没用。我习惯先看三个关键参数：
- RSRP（参考信号接收功率）：低于 -110dBm 基本就别想高速率了。
- SINR（信干噪比）：低于 10dB 时，MCS 会降阶，吞吐直接腰斩。
- MCS（调制与编码策略）：决定了每个符号能扛多少比特。
我的调试习惯：
先用 AT+CSQ 看信号强度，再用 AT+CESQ 看详细信道质量。如果 SINR 低于 15dB，别急着调协议栈，先检查天线位置和馈线损耗。我曾经在车载项目里，就因为天线被金属支架遮挡，SINR 掉了 8dB，吞吐从 80Mbps 掉到 30Mbps。
1.4 协议栈维度：看不见的隐形瓶颈
协议栈是模组的“大脑”。很多人只盯着射频，却忽略了协议栈的配置。这里有几个常见的坑：
- RLC 分段大小：默认 1500 字节不一定最优，大包场景下可以调到 3000 字节。
- HARQ 重传次数：最大重传次数设太大，时延会爆炸；设太小，误码率压不住。
- TCP 窗口缩放因子：很多模组出厂默认窗口只有 64KB，高时延链路下根本跑不满带宽。
⚠️ 注意：
修改协议栈参数前，一定要确认模组固件版本是否支持。我遇到过某款模组，文档说支持 TCP 窗口缩放，实际固件有 bug，改了反而死机。所以，改参数前先做回归测试。
1.5 应用层维度：最后一公里的优化
应用层是离用户最近的一层，也是最容易被忽视的。你想想看，射频和协议栈都调好了，结果应用层代码写得稀烂，吞吐照样上不去。
我总结了几条应用层优化原则：
- 减少 AT 指令交互：每次 AT 指令都有几十毫秒的延迟，频繁交互会吃掉大量吞吐。
- 合理设置 Socket 缓冲区：发送缓冲区太小会导致 TCP 发送窗口无法打开。
- 数据打包粒度：单次发送 1KB 和 10KB，吞吐差距可能超过 50%。
一个真实案例：
某视频监控项目，模组上报 1080P 图像，每帧 200KB。客户代码里每帧分 20 次发送，每次 10KB。我改成一次发送完整帧后，吞吐从 12Mbps 提升到 35Mbps。说白了，应用层的一个小改动，效果比调射频还明显。
1.6 本章小结
吞吐性能不是单一维度的优化，而是射频、协议栈、应用层三者的协同。我个人习惯的排查顺序是：
- 先看射频信号质量（RSRP / SINR）
- 再查协议栈配置（RLC / TCP 窗口）
- 最后优化应用层代码（打包 / 缓冲区）
记住一句话：射频决定上限，协议栈决定效率，应用层决定落地。后面的章节，我会带着你一步步拆解每个维度的调优方法。嗯，咱们下个知识点见。