1. 蜂窝网络基础与吞吐概念
各位同学好，我是老张。做蜂窝模组测试这行十几年了，今天咱们聊聊吞吐测试最底层的那些事儿。
很多人一上来就拿着模组跑 iperf，看数字高低。但说实话，吞吐量低的时候，你连从哪下手都不知道。为什么？因为你不懂网络在背后干了什么。
这一章，我把蜂窝网络的演进、吞吐量的定义、还有那些绕不开的关键指标，掰开了讲清楚。嗯，都是我在项目里踩过的坑，你听完就知道该关注什么了。
1.1 蜂窝网络演进：从 4G 到 5G 再到 IoT
蜂窝网络不是一天建成的。咱们先捋一遍主流制式，你心里有个谱。
| 制式 | 典型下行峰值 | 典型上行峰值 | 时延（RTT） | 主要场景 |
|---|---|---|---|---|
| 4G LTE Cat.4 | 150 Mbps | 50 Mbps | 30-50 ms | 手机、CPE、车载 |
| 4G LTE Cat.6 | 300 Mbps | 50 Mbps | 25-40 ms | 高速移动宽带 |
| 5G NR (Sub-6) | 1-2 Gbps | 100-200 Mbps | 5-15 ms | eMBB、低时延应用 |
| 5G NR mmWave | 4-10 Gbps | 500 Mbps+ | 3-10 ms | 热点、固定无线接入 |
| NB-IoT | ~250 kbps | ~250 kbps | 1-10 s | 水表、烟感、资产追踪 |
| LTE Cat.M1 | ~1 Mbps | ~1 Mbps | 100-500 ms | 可穿戴、移动 POS、物流 |
你看这张表，从 4G 到 5G，峰值速率差了上百倍。但 NB-IoT 和 Cat.M 反而「倒退」了。为什么？
我刚开始做 IoT 项目时也不理解。后来在智慧水务项目里，客户要求电池撑 5 年，模组还得在地下井盖里工作。你想想看，用 Cat.4 跑 150 Mbps？信号都穿不过井盖，电池两天就没了。
所以，选对制式比跑高吞吐更重要。NB-IoT 和 Cat.M 牺牲了速率，换来了深度覆盖和超低功耗。这是蜂窝网络「分场景设计」的智慧。
核心认知：蜂窝网络不是「越新越快就越好」。5G 的高吞吐依赖高频段和大带宽，覆盖范围反而小。NB-IoT 虽然慢，但能穿三层楼。选型时，先问自己三个问题：
- 数据量多大？—— 几 KB 还是几百 MB？
- 时延要求多高？—— 秒级还是毫秒级？
- 供电条件如何？—— 市电还是电池？
1.2 吞吐量定义与关键指标
吞吐量，说白了就是「单位时间内能传多少有效数据」。但测试时，你不能只看一个数字。
我见过不少测试报告，只写「下行吞吐量 50 Mbps」。然后客户问：为什么实际用起来卡？因为那 50 Mbps 是空口物理层速率，不是应用层能拿到的。
咱们得把几个关键指标拆开看：
1.2.1 Mbps —— 你看到的数字不一定是真的
Mbps（兆比特每秒）是最直观的指标。但要注意：
- 物理层速率：基站和模组之间能跑的理论最大值。受限于带宽、调制阶数、MIMO 层数。
- MAC 层速率：去掉物理层开销（CRC、重传、调度等待）后的速率。通常比物理层低 10-20%。
- 应用层吞吐：你跑 iperf 或 FTP 看到的数字。还要去掉 TCP/IP 头、协议握手、窗口限制。
我曾经测一个 Cat.4 模组，物理层显示 150 Mbps，但 iperf 死活跑不到 80 Mbps。查了半天，发现是 TCP 窗口太小，加上 RTT 偏高，带宽延迟积没算对。嗯，这个后面章节会细讲。
1.2.2 BLER —— 无线环境的「晴雨表」
BLER（Block Error Rate，误块率）是无线链路质量的核心指标。它表示传输的数据块中，有多少被基站或模组判定为错误。
- 目标 BLER：通常 LTE/NR 外场测试目标在 10% 以下。实验室可以做到 1% 甚至更低。
- BLER 过高：说明信道条件差，模组会触发 HARQ 重传，吞吐量直接腰斩。
- BLER 过低：也不一定是好事。可能意味着基站用了过于保守的调制编码策略（MCS），浪费了信道容量。
我的经验：调试吞吐时，先看 BLER。如果 BLER 超过 10%，别急着调 TCP 参数，先解决无线链路问题。我曾经在弱信号场景下，把天线从内置换成外置，BLER 从 25% 降到 3%，吞吐量翻了 3 倍。
1.2.3 RTT —— 被很多人忽略的「隐形杀手」
RTT（Round-Trip Time，往返时延）对 TCP 吞吐影响极大。TCP 的拥塞控制算法依赖 ACK 反馈，RTT 越大，吞吐量上限越低。
简单估算公式：最大 TCP 吞吐 ≈ TCP 接收窗口大小 / RTT
举个例子：
- 接收窗口 64 KB，RTT 50 ms → 最大吞吐 ≈ 10.5 Mbps
- 接收窗口 64 KB，RTT 200 ms → 最大吞吐 ≈ 2.6 Mbps
你看，RTT 从 50 ms 涨到 200 ms，吞吐直接掉了 75%。很多 NB-IoT 项目的 RTT 在 1-10 秒级别，所以 TCP 吞吐极低，必须用非 IP 优化方案（如 CoAP、LwM2M）。
注意：RTT 不是固定值。它受网络负载、基站调度、核心网处理延迟影响。测试时建议取多次平均值，并记录最大值和抖动（Jitter）。
1.3 影响吞吐的核心因素
吞吐量不是单一因素决定的。我习惯把它拆成三层来看：
这三层，每一层都可能成为瓶颈。我总结了一个排查优先级：
- 先看物理层：信号强度（RSRP）够不够？信噪比（SINR）好不好？BLER 高不高？
- 再看网络层：RTT 是否稳定？有没有频繁切换基站？核心网有没有限速？
- 最后调应用层：TCP 窗口、缓冲区、协议选择。
为什么是这个顺序？因为物理层是地基。地基不稳，上面调得再好也没用。我见过有人花了两周调 TCP 参数，结果发现是天线没接好——信号 -120 dBm，神仙也救不了。
1.4 本章小结
这一章咱们把基础打牢了：
- 蜂窝网络不是越新越好，选对制式是关键
- 吞吐量要看三层：物理层、网络层、应用层，别被一个数字骗了
- BLER 和 RTT 是两个最容易被忽略但影响巨大的指标
- 排查问题从物理层开始，别跳级