2. 设备接入协议基础：MQTT协议详解、CoAP协议简介、HTTP/HTTPS在IoT中的应用

聊到物联网设备接入，绕不开的就是协议选择。我见过不少团队，一上来就纠结用MQTT还是HTTP，结果项目做到一半发现选错了，改起来那叫一个痛苦。今天咱们就把这几个主流协议掰开揉碎，讲讲它们各自适合什么场景，以及我在实际项目中踩过的坑。

2.1 MQTT协议详解

MQTT，全称Message Queuing Telemetry Transport，说白了就是为物联网量身定做的轻量级消息协议。我个人习惯把它比作“邮局系统”——发布者把信投进去，订阅者去取，中间有个邮局帮你管理分发。

2.1.1 核心概念

• Broker（代理服务器）：消息中转站，所有消息都经过它
• Publisher（发布者）：发送消息的设备
• Subscriber（订阅者）：接收消息的设备或应用
• Topic（主题）：消息的分类标签，比如 sensor/temperature

嗯，这里要注意：Topic不是预先创建的，发布者直接往某个Topic发消息，Broker就会自动创建。我第一次用的时候还傻乎乎地去配置Topic列表，后来发现完全没必要。

2.1.2 三种服务质量（QoS）

QoS等级	含义	适用场景
0	最多发一次，不确认	传感器数据，丢了也无所谓
1	至少发一次，有确认	控制指令，允许重复
2	恰好发一次，严格确认	计费、关键告警

我曾经在一个智能门锁项目里，把开锁指令设成了QoS 0，结果网络波动时指令丢了，用户站在门口进不去……从那以后，凡是涉及控制类的消息，我至少用QoS 1。

2.1.3 保留消息与遗嘱消息

这两个特性很实用。保留消息（Retained Message）能让新订阅者立刻拿到最新数据，不用等下一次发布。遗嘱消息（Will Message）则是设备异常断线时，Broker替它发一条“我挂了”的消息。

2.1.4 代码示例：ESP8266连接MQTT

#include <PubSubClient.h>
#include <ESP8266WiFi.h>

const char* mqtt_server = "broker.emqx.io";
const char* topic = "sensor/temp";

WiFiClient espClient;
PubSubClient client(espClient);

void setup() {
  WiFi.begin("SSID", "PASSWORD");
  client.setServer(mqtt_server, 1883);
  client.setCallback(callback);
}

void loop() {
  if (!client.connected()) {
    reconnect();
  }
  client.loop();
  // 发布温度数据
  client.publish(topic, "25.3", true); // 保留消息
}

你想想看，这段代码不到20行，就能让一个单片机连上云端。这就是MQTT的魅力——轻量、简单、可靠。

2.2 CoAP协议简介

CoAP（Constrained Application Protocol）是另一个轻量级协议，专门为资源受限的设备设计。它基于UDP，而不是TCP。说白了，它就像HTTP的“瘦身版”，但跑在UDP上。

2.2.1 与MQTT的对比

特性	MQTT	CoAP
传输层	TCP	UDP
消息模型	发布/订阅	请求/响应
头部开销	2字节	4字节
适用场景	双向通信、实时性高	资源发现、简单查询

我个人习惯：如果设备需要持续上报数据，选MQTT；如果只是偶尔查询状态，CoAP更省电。我在一个智能路灯项目里试过CoAP，每个路灯每5分钟上报一次状态，电池续航比用MQTT多了将近30%。

2.2.2 CoAP的观察模式

CoAP支持一种叫“观察”（Observe）的模式，客户端可以订阅资源的变化。这有点像MQTT的订阅，但实现方式不同。不过说实话，CoAP的生态不如MQTT成熟，我在生产环境中用得不多。

2.3 HTTP/HTTPS在IoT中的应用

很多人觉得HTTP太重，不适合物联网。其实不然。HTTP在IoT里也有它的位置，尤其是那些不需要实时通信的场景。

2.3.1 什么时候用HTTP？

• 设备固件升级：用HTTP下载大文件，比MQTT靠谱
• 设备注册与配置：一次性操作，不需要长连接
• 数据上报频率低：比如每天上报一次电量

我记得有个项目，设备每天只上报一次数据，用MQTT反而浪费了TCP连接资源。后来改成HTTP POST，服务器压力小了很多。

2.3.2 HTTPS的必要性

嗯，这里要重点说一下。很多开发者觉得IoT设备性能差，就跳过HTTPS直接用HTTP。这是个大坑。我曾经接手过一个项目，所有设备都用HTTP明文传输，结果被中间人攻击，数据被篡改，导致生产系统误判。

2.3.3 RESTful API设计示例

// 设备上报数据
POST /api/v1/devices/{device_id}/data
Content-Type: application/json

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

// 服务器响应
HTTP/1.1 201 Created
Location: /api/v1/devices/{device_id}/data/12345

你想想看，这种接口设计跟Web开发一模一样，后端工程师上手毫无压力。所以别一提到IoT就觉得必须用MQTT，HTTP在某些场景下反而更合适。

2.4 协议选型建议

说了这么多，到底怎么选？我总结了一个简单的判断逻辑：

• 设备需要实时双向通信 → MQTT
• 设备资源极度受限（内存<32KB） → CoAP
• 设备偶尔上报数据，或需要下载文件 → HTTP/HTTPS
• 设备需要与Web应用直接交互 → WebSocket（下一章会讲）

最后说一句：没有万能的协议，只有适合场景的协议。我在一个项目里甚至同时用了MQTT和HTTP——MQTT负责实时数据，HTTP负责固件升级。灵活搭配，才是架构师的智慧。