4、TCP/IP协议栈：模组内置协议栈、TCP/UDP客户端建立、心跳包机制设计
说到蜂窝模组联网，最核心的一层就是 TCP/IP 协议栈。很多刚入行的朋友总觉得这玩意儿很神秘，其实说白了，模组厂商已经把最复杂的部分替你封装好了。你只需要通过 AT 指令告诉它：“我要连哪个服务器，用什么协议”，剩下的三次握手、数据重传、滑动窗口，模组自己就搞定了。
我个人习惯把模组的协议栈比作一个“黑盒子”。你不需要知道里面怎么拆包组包，但你必须清楚它的边界在哪里。比如，它支持多少个 socket？最大发送缓冲区多大？这些参数决定了你的产品能跑多稳。
核心要点：模组内置协议栈 ≠ 通用 Linux 协议栈。它资源受限，通常只支持 TCP/UDP/HTTP/MQTT 等有限协议，且并发连接数一般不超过 10 个。
4.1 模组内置协议栈的工作模式
目前主流的蜂窝模组（比如移远、广和通、中移物联的系列）都内置了完整的 TCP/IP 协议栈。你不需要在 MCU 上跑 lwIP 或 uIP，省下的 RAM 和 Flash 非常可观。
工作模式主要有两种：
- 透传模式：模组自动处理协议，MCU 只管收发数据。适合数据量小、逻辑简单的场景。
- AT 指令模式：每一步操作都由 MCU 通过 AT 指令控制。灵活性高，适合复杂业务。
我在项目中遇到过一个问题：某款模组在透传模式下，如果服务器 30 秒没发数据，模组会自动断开连接。当时排查了好久，最后发现是模组内部的“空闲超时”参数默认值太短。嗯，这里要注意，透传模式虽然方便，但很多细节参数需要你主动去配。
| 特性 | 透传模式 | AT 指令模式 |
|---|---|---|
| MCU 资源占用 | 低 | 中 |
| 灵活性 | 低 | 高 |
| 适用场景 | 简单数据上报 | 复杂交互、多连接 |
| 调试难度 | 低 | 中 |
4.2 TCP 客户端建立流程
建立一个 TCP 连接，其实就是三步：激活网络 → 配置 socket → 发起连接。我习惯用移远模组的指令集来举例，其他厂商的指令大同小异。
- 检查网络注册状态：
AT+CREG?，返回+CREG: 0,1表示已注册。 - 激活 PDP 上下文：
AT+CGACT=1,1，激活场景 1。 - 建立 TCP socket：
AT+QIOPEN=1,0,"TCP","192.168.1.100",8080,0,0。 - 等待连接成功：模组返回
+QIOPEN: 0,0表示成功。
小技巧：我建议在发送 AT+QIOPEN 后，加一个 5 秒的超时等待。有些模组在弱信号下握手时间会变长，直接读返回值容易误判为失败。
你想想看，如果服务器 IP 写错了，或者端口被防火墙挡住了，模组会返回什么？它会返回 +QIOPEN: 0,65536（错误码）。这时候不要慌，先 ping 一下服务器，再检查模组的 APN 配置。我曾经因为 APN 少写了一个字母，折腾了整整一下午。
4.3 UDP 客户端建立流程
UDP 比 TCP 简单得多，因为它不需要握手。你直接告诉模组：“我要往这个 IP 和端口发数据”，它就把数据扔出去了。至于对方收没收到，它不管。
建立 UDP 客户端的指令：
AT+QIOPEN=1,0,"UDP","192.168.1.100",8080,0,0注意看，和 TCP 的唯一区别就是把 "TCP" 换成了 "UDP"。但实际使用中，UDP 有个坑：模组在发送数据前，需要先调用 AT+QISEND 指定对端地址。有些工程师忘了这一步，结果数据发到了空地址上。
避坑指南：我曾经在做一个环境监测项目时，用 UDP 上报数据。服务器那边一直收不到，查了三天，最后发现是模组的 UDP socket 在发送前没有绑定本地端口。加上 AT+QILOCALPORT=12345 后，问题立刻解决。
| 对比项 | TCP | UDP |
|---|---|---|
| 可靠性 | 高（有重传） | 低（无重传） |
| 实时性 | 中 | 高 |
| 资源消耗 | 高 | 低 |
| 适用场景 | 指令下发、文件传输 | 实时数据流、广播 |
4.4 心跳包机制设计
这是本章的重头戏。很多物联网设备掉线，不是因为信号不好，而是因为心跳包设计不合理。
为什么要用心跳包？因为运营商的 NAT 网关会定时清理空闲连接。比如中国移动的 NAT 超时通常是 5 分钟，如果你 5 分钟内没发任何数据，网关就把你的连接映射删掉了。这时候服务器还傻傻等着，设备却已经失联了。
心跳包的设计原则，我总结为三点：
- 频率要合理：比 NAT 超时时间短一半。比如 NAT 超时 300 秒，心跳间隔设为 120 秒。
- 内容要轻量：只带必要信息，比如设备 ID 和一个时间戳。别把整包数据塞进去。
- 要有超时重试：如果连续 3 次心跳没收到回复，主动断开重连。
经验之谈：我建议心跳包和数据包分开处理。数据包走业务逻辑，心跳包走保活逻辑。两者互不干扰，这样即使业务数据量很大，心跳依然能按时发送。
具体实现上，我通常会在 MCU 里开一个定时器，每隔 T 秒发送一条心跳指令。模组收到后，服务器回复一个 ACK。如果 MCU 连续 3 次没收到 ACK，就认为连接已断开，然后执行重连流程。
// 伪代码示例
void heartbeat_task(void)
{
static uint8_t fail_count = 0;
if (send_heartbeat() == SUCCESS) {
fail_count = 0;
} else {
fail_count++;
if (fail_count >= 3) {
disconnect();
reconnect();
fail_count = 0;
}
}
}你可能会问：心跳包会不会增加功耗？会，但影响很小。一个心跳包通常只有几十个字节，发送耗时不到 100 毫秒。相比模组待机时的毫安级电流，这点消耗可以忽略不计。
下面这张图展示了心跳包在整个连接生命周期中的位置：
4.5 常见问题与调试技巧
最后分享几个我在项目中踩过的坑：
- 连接被 RST：通常是服务器端主动断开了连接。检查服务器端的超时配置，或者看看是不是发了非法数据。
- 发送超时：模组的发送缓冲区满了。我建议每次发送前检查缓冲区剩余空间，用
AT+QISEND=0,0查询。 - 心跳包冲突：如果心跳包和数据包同时发送，模组可能会卡死。解决办法是加一个互斥锁，或者让心跳优先级高于数据包。
调试利器：我习惯在 MCU 的串口日志里打印每次 socket 事件的返回值。比如 +QIURC: "closed",0 表示连接被关闭，看到这个就立刻触发重连。别等到下次发送数据才发现掉线。
好了，TCP/IP 协议栈这部分就聊到这儿。记住一句话：模组内置协议栈是工具，不是黑魔法。你理解了它的边界和限制，就能用好它。