MQTT vs. 普通 HTTP 请求：一篇面向工程师的深度对比

一句话摘要：如果把 HTTP 想象成「点菜 + 上菜」的单向流程，那么 MQTT 更像是「自助餐厅」——食客（客户端）和厨师（Broker）之间的窗口永远敞开，随时能端进端出。对于大量 小包、双向、实时 的物联网流量，MQTT 往往效率高得多；而在 文件传输、一次性查询、网页接口 等场景，HTTP 依旧是不二之选。

---

1. 协议诞生背景

协议	初衷	设计关键词
HTTP/1.1 → 3	1990 年代为网页文档而生	请求-响应、无状态、通用
MQTT 3.1 → 5.0	1999 年为油管 SCADA 引擎远程监控而生	轻量、发布/订阅、低带宽/高丢包

HTTP 的核心是「一次请求换一次响应」，天然适合浏览器/REST API；MQTT 则针对「窄带、频繁、双向」的物联网通信做了彻底减负设计。

---

2. 通信模型：请求-响应 vs. 发布/订阅

• HTTP

  1. 客户端发起 TCP/TLS 连接
  2. 发送 GET/POST… 请求
  3. 服务器返回响应并可立即关闭或复用连接（HTTP/1.1 Keep-Alive、HTTP/2 多路复用）

• MQTT

  1. 客户端 一次 CONNECT → CONNACK 建立会话
  2. 任何时刻可 PUBLISH 消息到主题，也可 SUBSCRIBE 主题接收下行
  3. 直到 DISCONNECT，同一套接字始终保持，Broker 能主动推送

这种 双向、多对多 的 Broker 转发模式，让设备间无需知道彼此 IP/URI，只认主题即可。

---

3. 长连接 vs. 短连接

维度	MQTT	HTTP
连接生命周期	单次握手，常驻 Keep Alive	每次请求常见重新握手 (或靠 HTTP/2 复用)
心跳机制	PINGREQ/PINGRESP 默认 10–300 s	无协议级心跳；靠 TCP/HTTP 层超时
NAT 友好度	需定期心跳避免 NAT 回收	短连接每次重建，基本无 NAT 问题

在蜂窝/运营商网络里，NAT 空闲回收常设为 5 分钟左右，因此 MQTT Keep Alive 建议 120–300 s；HTTP 轮询则天然避免此问题，但牺牲了时效和流量。

4. 帧开销与带宽利用

指标	MQTT (最小)	HTTP/1.1 (最小)
报文首部	2 字节 0x10 0x00	≥ 8 字节 GET / HTTP/1.1…
典型交互	单 PUBLISH 8–10 B	一次 GET/POST 数十到上百 B

当设备只发几字节传感器值时，HTTP 头部开销会远超有效负载；MQTT 则几乎全部都是业务数据。实际测试显示，在 100 字节以下消息高频发送场景，MQTT 流量可比 HTTP 省 70 % 以上。

---

5. 可靠性：QoS 与重传策略

层级	MQTT	HTTP
传输层	TCP/TLS (可选 WebSocket)	TCP/TLS / QUIC
应用层重试	QoS 0/1/2 (至多一次、至少一次、仅一次)	无；成功就靠 TCP ACK
离线缓存	Session Expiry / Persistent Session	需客户端自行实现
遗嘱消息	支持	无原生

MQTT 5 进一步引入 Reason Code、Session Expiry Interval 等机制，细粒度控制离线行为，而 HTTP 若想做到同等可靠性，需要额外的应用层逻辑。

---

6. 安全与鉴权

• 传输层：二者都能跑在 TLS 之上；MQTT 常用 8883，HTTP s 443。

• 身份鉴权：

  • HTTP 依赖 Token/Cookie/JWT；
  • MQTT 可用用户名/密码、X.509、基于主题的 ACL。

• 细粒度权限：MQTT Broker 可按 主题树 授权订阅/发布粒度，而 HTTP 通常按 URL 路径控制。

---

7. 生态与实现成本

维度	MQTT	HTTP
服务器/Broker	Mosquitto、EMQX、HiveMQ、RabbitMQ…	Nginx、Apache、Node.js、云函数
客户端 SDK	10 kB 级别 C 库到全栈语言	浏览器原生、cURL、各种 REST SDK
调试工具	MQTT Explorer, mosquitto_sub/pub	Postman, curl, 浏览器 F12

HTTP 几乎无处不在，浏览器和后端框架原生支持；而 MQTT 需要部署 Broker，但重量级服务器也越来越云原生（EMQX-K8s、HiveMQ Cloud）。([hivemq.com][2])

---

8. 典型应用场景对比

选 MQTT 的理由	选 HTTP 的理由
高频小包：传感器秒级上报	低频大包：固件 OTA、图像上传
实时下行：云控继电器、推送	配置读取：一次性查询设备状态
弱网 / 付费流量：蜂窝、星链	已有 Web 基础：RESTful 微服务
需要离线缓存：电梯监控、油井	标准化接口：三方对接、浏览器

---

9. 结语

• MQTT = 轻量、长连、发布/订阅、双向实时
• HTTP = 通用、无状态、请求/响应、生态庞大

在 IoT 端云 通信里，两者并非零和：

控制与事件 → MQTT，配置与下载 → HTTP/HTTPS
同一设备跑双协议 的架构，已经是工业网关和云平台的常态。

理解它们的底层差异，才能在架构设计时把“实时性、功耗、带宽、复杂度”四个指标调到最优。希望本文能帮助你在下一个项目中 选对协议、少走弯路。