最近在公司开发了一个需求， 要求使用 mqtt 建立通道去接收和发送消息， 虽然最后功能实现了， 但是对于为什么不使用 http 接口还是有点疑惑， 所以下来还是进行了了解
1. 通信模型
-
MQTT
- 发布/订阅模式：设备（发布者）将消息发送到 Broker 的指定主题（Topic），订阅该主题的设备（订阅者）自动接收消息，实现解耦和一对多通信。
- 中介依赖：依赖 Broker（如 EMQX、Mosquitto）管理消息路由，设备不直接交互。
-
直接调用后端接口（HTTP）
- 请求-响应模式：客户端主动发起请求（如 GET/POST），后端返回响应后连接关闭（HTTP/1.1 可复用连接，但本质仍是同步交互）。
- 点对点通信：客户端直接与后端服务交互，无中间代理。
2. 性能与效率
| 维度 | MQTT | HTTP |
|---|---|---|
| 连接开销 | 长连接（一次握手，持久保持） | 短连接（每次请求需重建连接，HTTP/2 可复用） |
| 报文开销 | 头部极小（最小 2 字节），适合小数据包 | 头部大（通常数百字节），有效负载占比低 |
| 实时性 | 毫秒级延迟，支持双向实时推送 | 依赖轮询，延迟高（秒级） |
| 弱网适应性 | 支持 QoS 等级（0/1/2）、离线消息缓存 | 无内置重试机制，弱网易失败 |
| 功耗 | 长连接 + 低心跳流量，适合电池设备 | 频繁重建连接耗电高 |
3. 可靠性机制
-
MQTT
-
QoS 分级：
- QoS 0（至多一次）：可能丢失，无重试。
- QoS 1（至少一次）：确保送达，可能重复。
- QoS 2（恰好一次）：严格一次送达。
-
持久会话：Broker 缓存离线消息，设备重连后补发。
-
-
HTTP
- 依赖 TCP 重传，无应用层重试机制；需自行实现幂等性。
4. 适用场景
| 场景 | 推荐协议 | 原因 |
|---|---|---|
| 传感器高频上报（温度、位置） | MQTT | 低带宽、小数据包、实时性强 |
| 远程设备控制（开关指令） | MQTT | 双向通信、低延迟 |
| 弱网络环境（工业物联网） | MQTT | 离线缓存、自动重连 |
| 用户查询数据（Web 页面） | HTTP RESTful API | 标准化接口、浏览器兼容 |
| 文件上传/配置更新 | HTTP | 支持大文件传输、易实现 |
| 快速后端集成（第三方系统） | HTTP | 无需 Broker，直接调用 |
5. 开发与运维复杂度
-
MQTT
- 额外组件：需部署和维护 Broker（如 EMQX）。
- 调试工具：需专用客户端（如 MQTT Explorer）。
-
HTTP
- 生态成熟：前端原生支持（Fetch API、Axios），调试工具丰富（Postman）。
- 无中介依赖：直接对接后端服务，架构简单。
6. 安全机制
-
MQTT
- 依赖 TLS/SSL 加密传输，需配置主题 ACL 控制权限（如限制发布/订阅范围）。
-
HTTP
- 成熟 HTTPS 加密 + OAuth/JWT 鉴权，易于集成现有安全体系。
实际系统设计建议
-
混合架构：
- 物联网设备用 MQTT 上报实时数据 → Broker 转发至后端。
- Web 前端通过 HTTP API 查询历史数据或下发配置。
-
纯 MQTT 场景：强实时控制（如工业自动化）、海量设备连接（如智慧城市）。
-
纯 HTTP 场景：低频交互（如固件下载）、标准化第三方集成。
MQTT 胜在实时性、低开销和弱网可靠性，适合设备间通信；HTTP 胜在易用性、标准化和生态成熟，适合前后端交互。
