3、通信协议基础：TCP/IP协议栈、MQTT协议、HTTP协议在物联网中的应用

做物联网通信这些年，我见过太多人一上来就调MQTT，结果连TCP握手都抓不明白。说白了，协议栈就像快递系统——你只关心包裹能不能到，但底层怎么分拣、怎么运输，心里得有数。

这一章，咱们就聊聊物联网里最常用的三个协议：TCP/IP、MQTT、HTTP。我会结合项目里的实际坑点，帮你把它们的定位和用法理清楚。

3.1 TCP/IP协议栈：物联网通信的基石

TCP/IP不是单个协议，而是一整套协议族。我习惯把它分成四层来看：

层级 典型协议 作用
应用层 HTTP、MQTT、CoAP 定义数据格式和交互逻辑
传输层 TCP、UDP 提供端到端的数据传输服务
网络层 IP、ICMP 寻址和路由，把数据包送到目标网络
网络接口层 以太网、WiFi、蜂窝 物理介质上的数据收发

在蜂窝模组开发中，我们最常打交道的是传输层和应用层。模组内部已经封装好了TCP/IP协议栈，你只需要通过AT指令或者SDK接口去操作就行。但有个坑——不同模组的协议栈实现细节不一样，比如缓冲区大小、重传策略，这些会直接影响你的通信稳定性。

我曾经踩过的坑： 某款4G模组默认TCP Keep-Alive时间是120秒，而服务器端60秒没收到心跳就会断开连接。结果设备经常莫名其妙掉线，查了两天才发现是两边参数没对齐。所以，一定要确认模组和服务器的心跳参数是否匹配。

3.2 MQTT协议：物联网的首选

MQTT（Message Queuing Telemetry Transport）是IBM开发的轻量级发布/订阅协议。为什么它在物联网里这么火？说白了，就三个字：轻、快、省。

  • 轻量级：最小报文只有2字节，非常适合窄带宽、低功耗场景
  • 发布/订阅模型：解耦了发送方和接收方，设备不用关心数据给谁用
  • 三种QoS等级：根据场景选择可靠性，灵活控制

3.2.1 MQTT的核心概念

MQTT里有几个关键角色，我画了张图帮你理解：

MQTT 发布/订阅模型 MQTT Broker （消息代理服务器） 发布者（Publisher） 订阅者（Subscriber） 订阅者（Subscriber） 工作流程： 1. 订阅者向Broker订阅感兴趣的主题（Topic），如 sensor/temperature 2. 发布者向Broker发布消息到指定主题 3. Broker将消息推送给所有订阅了该主题的订阅者

MQTT的Topic设计很灵活，我建议你用分层结构来组织。比如一个温湿度传感器，可以这样设计：

factory/area1/sensor001/temperature
factory/area1/sensor001/humidity
factory/area1/sensor001/status

这样做的好处是，订阅方可以用通配符一次性订阅多个主题。比如 factory/area1/+/temperature 就能收到area1所有传感器的温度数据。

3.2.2 QoS等级选择

MQTT定义了三个服务质量等级，我直接给你说结论：

QoS等级 含义 适用场景
0 最多发一次，不确认 传感器上报（丢几条无所谓）
1 至少发一次，可能重复 设备状态变更（允许少量重复）
2 恰好发一次，最可靠 控制指令、支付消息（必须精确一次）
我的建议： 大部分物联网场景用QoS 1就够了。QoS 2虽然可靠，但开销大、延迟高。我在一个智能电表项目里试过QoS 2，结果因为网络抖动导致消息堆积，反而把Broker搞崩了。后来改成QoS 1 + 应用层去重，问题就解决了。

3.3 HTTP协议：传统但依然重要

HTTP在物联网里用得也不少，尤其是设备配置、固件升级、数据查询这些场景。但说实话，HTTP在物联网里有两个硬伤：

  • 请求/响应模式：服务器不能主动推送数据，设备得轮询
  • 报文开销大：一个简单的GET请求，头部可能几百字节

不过，HTTP也有它的优势：生态成熟、调试方便。你随便打开浏览器就能测试API，这在开发阶段特别有用。

3.3.1 RESTful API设计

在物联网里，我习惯用RESTful风格来设计HTTP接口。举个例子：

方法 URL 功能
GET /devices/{id}/data 查询设备最新数据
POST /devices/{id}/data 上报设备数据
PUT /devices/{id}/config 更新设备配置
DELETE /devices/{id} 注销设备

数据格式一般用JSON，简单直观。比如上报温度数据：

POST /devices/sensor001/data HTTP/1.1
Host: api.iot.example.com
Content-Type: application/json

{
  "temperature": 25.6,
  "humidity": 68.2,
  "timestamp": "2024-01-15T10:30:00Z"
}

3.4 协议选择：什么时候用哪个？

很多初学者会问：到底该用MQTT还是HTTP？我的回答是：看场景。

我整理了一个对比表，你一看就明白：

对比维度 MQTT HTTP
通信模型 发布/订阅 请求/响应
报文开销 极小（2字节起） 较大（头部几百字节）
实时性 高（Broker主动推送） 低（需要轮询）
可靠性 支持QoS 0/1/2 依赖TCP
适用场景 实时数据上报、控制指令 设备配置、固件升级、数据查询

实战经验： 我在一个智慧农业项目里，用MQTT做传感器数据的实时上报（每秒一次），用HTTP做历史数据查询和固件升级。这样既保证了实时性，又利用了HTTP的生态优势。说白了，没有最好的协议，只有最合适的组合。

3.5 蜂窝模组中的协议栈实现

蜂窝模组通常内置了完整的TCP/IP协议栈，你不需要自己实现。但有几个关键点要注意：

  1. AT指令操作：大部分模组通过AT指令来建立TCP/UDP连接、发送数据。比如移远EC200系列的AT+QIOPEN指令。
  2. PDP上下文：模组需要先激活PDP上下文（相当于建立数据通道），才能进行IP通信。
  3. DNS解析：模组通常支持AT+QIDNSG指令进行域名解析，但有些老模组需要你手动指定IP。

举个例子，用AT指令通过MQTT发送数据：

AT+QIOPEN="TCP","mqtt.example.com",1883
// 建立TCP连接

AT+QMTCONN="client001","username","password"
// 连接MQTT Broker

AT+QMTPUB=0,1,"sensor/temp","25.6"
// 发布消息，QoS 1，主题sensor/temp，内容25.6
注意： 不同模组的AT指令集差异很大。我吃过一次亏——把华为模组的指令直接套用到移远模组上，结果连不上网。所以，一定要仔细阅读模组厂商的AT指令手册。

3.6 本章小结

这一章我们聊了TCP/IP协议栈的分层结构，MQTT的发布/订阅模型和QoS等级，以及HTTP在物联网中的定位。核心就一句话：TCP/IP是基础，MQTT是主力，HTTP是补充。

在实际项目中，我建议你优先考虑MQTT做实时通信，HTTP做非实时操作。如果设备资源极度受限，还可以考虑CoAP协议（基于UDP），那是另一个话题了。

← 上一章 📖 返回目录 下一章 →