第 1 章 · 01 从物联网到 MQTT 本节摘要:MQTT 不是凭空出现的——它是 IBM 工程师在"用电话线连接输油管道传感器"这种极端场景里逼出来的设计。本节先讲清这个诞生故事,再归纳物联网场景对消息协议的四个硬约束(设备小、带宽慢、供电弱、数量多),然后把 MQTT 与 HTTP 摆在一起对比,最后交代协议的标准化历程。读完本节,你会理解 MQTT 的每一个设计取舍,背后都是"省字节、省功耗"四个字。 学习目标 阅读完本节,你应当能够: 复述 MQTT 的诞生背景与全称含义。 列出物联网场景对消息协议的四个约束。 用三句话对比 MQTT 与 HTTP 的差异(模型/开销/适用场景)。 说出 MQTT 的标准化时间线(OASIS 标准、ISO 标准)。
本节摘要:MQTT 不是凭空出现的——它是 IBM 工程师在"用电话线连接输油管道传感器"这种极端场景里逼出来的设计。本节先讲清这个诞生故事,再归纳物联网场景对消息协议的四个硬约束(设备小、带宽慢、供电弱、数量多),然后把 MQTT 与 HTTP 摆在一起对比,最后交代协议的标准化历程。读完本节,你会理解 MQTT 的每一个设计取舍,背后都是"省字节、省功耗"四个字。
阅读完本节,你应当能够:
1999 年,IBM 的工程师 Andy Stanford-Clark 和 Arcom 的工程师 Arlen Nipper 面临一个棘手问题:如何把输油管道的传感器数据通过卫星链路传回监控中心?
当时的约束极其苛刻:
他们需要的不是 HTTP 那种"肥胖"协议,而是一个极简的消息协议:协议头要小到几个字节,功耗要低到电池能撑几年,解析要简单到单片机跑得动。MQTT(Message Queuing Telemetry Transport,消息队列遥测传输)就此诞生——"Telemetry"直译就是遥测,它的基因里写的就是"机器传数据"。
物联网场景可以归纳为四个约束,而 MQTT 的每个设计都是对它们的回应:
| 约束 | 现实 | MQTT 的回应 |
|---|---|---|
| 设备小 | MCU 内存以 KB 计,主频几十 MHz | 协议头最小仅 2 字节,解析逻辑极简,客户端库可裁剪到几 KB |
| 带宽慢 | 2G/3G 网络、卫星链路,按流量计费 | 固定报头 2 字节起步,所有字段都压缩编码(剩余长度用 1-4 字节变长编码) |
| 供电弱 | 电池供电,几年不换 | 一条心跳报文仅 2 字节;支持"断线后由服务端代发遗嘱",设备无需保活长连接常驻 |
| 数量多 | 百万级设备并发 | 发布/订阅模型让服务端(代理)做路由,设备之间零耦合 |
💡 核心心法:MQTT 的每一个字节都是省出来的。第 2 章讲剩余长度编码时会看到,连"长度"这种字段都要用变长编码省字节。
把 MQTT 与 HTTP 对比,能最快理解它的定位:
| 维度 | HTTP | MQTT |
|---|---|---|
| 通信模型 | 请求-响应(客户端主动拉) | 发布-订阅(服务端主动推) |
| 方向性 | 一问一答,天然阻塞 | 异步推送,单向/双向皆可 |
| 协议头开销 | 数百字节(Header + Cookie 等) | 最小 2 字节 |
| 服务质量 | 依赖 TCP 重传,无应用层语义 | 三层 QoS,可精确控制送达语义 |
| 连接 | 每次请求一个连接(或 Keep-Alive 复用) | 一条长连接,靠心跳保活 |
| 典型场景 | Web 浏览、API 调用 | 传感器上报、命令下发、消息推送 |
MQTT 不是要取代 HTTP——Web 服务用 HTTP 很好。但当场景变成"一个弱小的设备,要持续把数据送给不确定的接收方"时,MQTT 的发布/订阅模型就显出优势:发布者不需要知道谁在订阅,订阅者不需要知道谁在发布,中间由代理(Broker) 完成路由。这种解耦正是百万设备场景的刚需。
⚠️ 注意:MQTT 5.0 标准(2019 年)在 3.1.1 基础上增加了大量特性(原因码、用户属性、共享订阅等),但 3.1.1 仍是当前部署最广的版本(几乎所有主流 Broker 和云平台默认支持)。本教程基于 3.1.1,学透后再迁移 5.0 会很轻松。
MQTT 诞生于"省钱"的极端场景,它的全部设计都可以归结为最小字节数 × 最大解耦度。理解了这一点,后续章节里"为什么这个字段只有 1 位""为什么这个报文这么短"就都有了答案。