3、通信协议基础：HTTP/HTTPS协议、MQTT协议、CoAP协议在IoT中的应用

做美容仪固件升级，说白了就是让设备跟服务器「说话」。怎么说话？用什么语言？这就是通信协议要解决的问题。

我刚开始做IoT项目时，总觉得协议选型无所谓。后来踩了坑才明白——选错协议，轻则升级失败，重则设备变砖。今天咱们就聊聊三种主流协议：HTTP/HTTPS、MQTT、CoAP。它们各有脾气，用对了地方就是好工具。

3.1 HTTP/HTTPS协议：最熟悉的陌生人

HTTP协议，你每天都在用。打开网页、刷视频、看公众号，背后都是HTTP在干活。但把它用在IoT设备上，有些细节得注意。

3.1.1 HTTP的核心特点

  • 请求-响应模式：客户端发请求，服务器回响应。一问一答，简单直接。
  • 无状态：服务器不记得你是谁。每次请求都是「初次见面」。
  • 文本协议：报文是纯文本，可读性强，但体积大。

美容仪场景：HTTP适合做固件包的下载。设备先发GET请求，服务器返回固件二进制数据。流程清晰，实现简单。

3.1.2 HTTPS：加把锁更安全

HTTPS就是HTTP + SSL/TLS。说白了，就是在HTTP外面套了一层加密壳。为什么要加密？

你想想看，美容仪固件里可能包含用户隐私数据。如果不加密，中间人攻击就能篡改固件包。我曾经见过一个案例——某品牌美容仪因为固件被篡改，导致设备过热烫伤用户。嗯，这就是血的教训。

避坑指南：我曾经在项目里图省事，直接用HTTP传输固件。结果测试时发现，固件包在传输过程中被运营商插入了广告代码。从那以后，所有OTA升级必须走HTTPS。

3.1.3 HTTP在美容仪中的典型用法

// 设备检查新版本
GET /api/firmware/check?device_id=DEV001&current_ver=1.2.3 HTTP/1.1
Host: ota.example.com

// 服务器响应
HTTP/1.1 200 OK
Content-Type: application/json

{
  "has_update": true,
  "new_version": "1.2.4",
  "download_url": "https://ota.example.com/firmware/v1.2.4.bin",
  "file_size": 1048576,
  "md5": "a1b2c3d4e5f6..."
}

3.2 MQTT协议：轻量级消息之王

MQTT，全称Message Queuing Telemetry Transport。名字很长，但核心思想很简单——发布/订阅模式。

我个人习惯把MQTT比作「微信群」。有人发消息（发布者），群里所有人都能收到（订阅者）。服务器就是群主（Broker），负责转发消息。

3.2.1 MQTT的核心优势

  • 极轻量：最小报文只有2字节。对美容仪这种资源受限的设备非常友好。
  • 双向通信：服务器可以主动给设备发消息。不像HTTP，只能设备主动问。
  • 三种QoS等级：根据场景选择可靠性。
QoS等级 含义 适用场景
0 最多发一次，不确认 传感器数据上报（丢几条无所谓）
1 至少发一次，可能重复 升级指令通知（重复了设备去重就行）
2 恰好发一次，最可靠 支付指令、关键配置（绝对不能丢）

我的经验：美容仪OTA升级，我建议用QoS 1。为什么？QoS 0可能丢消息，QoS 2开销太大。QoS 1偶尔重复，但设备端做好幂等处理就行。

3.2.2 MQTT在美容仪中的典型用法

// 设备订阅升级通知主题
Topic: /beauty/device/DEV001/ota/cmd
Subscribe: 设备订阅此主题

// 服务器发布升级指令
Topic: /beauty/device/DEV001/ota/cmd
Payload: {
  "cmd": "start_update",
  "version": "1.2.4",
  "url": "https://ota.example.com/firmware/v1.2.4.bin",
  "md5": "a1b2c3d4e5f6..."
}

// 设备上报升级进度
Topic: /beauty/device/DEV001/ota/progress
Payload: {
  "progress": 45,
  "status": "downloading"
}

3.3 CoAP协议：专为受限设备而生

CoAP，Constrained Application Protocol。名字里就带着「受限」二字。它专门为内存只有几十KB、CPU跑在几十MHz的设备设计。

我第一次接触CoAP是在一个智能灯泡项目上。灯泡的MCU只有16KB RAM，跑HTTP太吃力，MQTT的库又太大。CoAP刚好合适。

3.3.1 CoAP的核心特点

  • 基于UDP：没有TCP的三次握手，延迟更低。
  • 类似HTTP的RESTful风格：GET/POST/PUT/DELETE，上手快。
  • 内置发现机制：设备可以自动发现服务端资源。
  • 支持观察模式：类似MQTT的订阅，服务器可以主动推送。

对比一下：同样传输一个温度值，HTTP报文大约200字节，CoAP只需要20字节。对于美容仪这种电池供电的设备，省下的每一字节都是续航。

3.3.2 CoAP在美容仪中的典型用法

// 设备请求检查更新
req: GET coap://ota.example.com/firmware/check?device=DEV001&ver=1.2.3

// 服务器响应
res: 2.05 Content
{
  "update": true,
  "ver": "1.2.4",
  "size": 1048576,
  "uri": "coap://ota.example.com/firmware/v1.2.4.bin"
}

// 设备分块下载固件（CoAP支持块传输）
req: GET coap://ota.example.com/firmware/v1.2.4.bin?block=0,1024
res: 2.05 Content (Block2: 0/1024/4096)
[前1024字节固件数据]

3.4 如何选择？我的实战建议

三种协议各有千秋。怎么选？我给大家一个简单的决策树：

场景 推荐协议 理由
固件包下载（大文件） HTTPS 成熟稳定，支持断点续传，安全性高
升级指令下发（小消息） MQTT 双向通信，服务器主动推送，实时性好
超低功耗设备 CoAP UDP协议，报文极小，省电省带宽
混合场景 MQTT + HTTPS MQTT传指令，HTTPS下载固件，各取所长

重要提醒：不要试图用一种协议解决所有问题。我见过有人非要用MQTT传固件包，结果Broker内存爆了。也见过有人用HTTP轮询检查更新，结果服务器被请求打崩了。合适的才是最好的。

3.5 小结

通信协议是OTA升级的「血管」。选对了，数据流动顺畅；选错了，处处是坑。

我个人建议：美容仪OTA升级，优先考虑MQTT + HTTPS的组合。MQTT负责指令下发和状态上报，HTTPS负责固件包下载。既保证了实时性，又兼顾了安全性和可靠性。

下一章，咱们聊聊具体的OTA升级流程设计。到时候我会拿一个实际项目案例，带大家走一遍完整的升级链路。

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