一、MQTT 基础定义与核心定位

1.1 协议全称与本质

MQTT 全称：Message Queuing Telemetry Transport，中文译为「消息遥测传输协议」。

注意：MQTT 名称中虽包含「消息队列」，但并非消息队列中间件，是一套基于 TCP/IP 的轻量级发布订阅式通信协议。

1.2 诞生背景与设计初衷

MQTT 由 IBM 于 1999 年设计，最初用于石油管道远程监控场景，核心解决：低带宽、高延迟、不稳定的网络环境下，设备与服务器的可靠数据传输问题。
设计的核心宗旨：极简、轻量、省资源、高可靠，专门为「算力弱、内存小、带宽低」的设备量身打造。

1.3 核心定位

MQTT 是目前 物联网(IoT)领域的事实标准通信协议，也是物联网设备通信的首选协议，没有之一。
适用核心场景：物联网传感器、嵌入式设备、智能家居、工业物联网、车联网、智能硬件等设备与服务端的通信。

二、MQTT 核心特性（最核心）

MQTT 能成为物联网第一协议，核心源于其极致的特性适配，所有特性均围绕「物联网设备痛点」设计：

1. 极致轻量级，协议开销极小
   • MQTT 协议报文为二进制格式，头部最小仅 2个字节，报文结构极简；
   • 客户端实现MQTT协议仅需几十KB内存、几行代码即可完成，完美适配单片机、传感器等嵌入式设备。
2. 极低带宽消耗
   • 传输的数据量极小，没有冗余的请求头/响应头，适合在 2G/3G/4G/NB-IoT/蓝牙 等低带宽网络传输。
3. 支持长连接+低功耗
   • 基于 TCP 长连接通信，建立连接后持续复用，避免频繁建联的开销；
   • 支持心跳保活机制，空闲时可降低心跳频率，大幅降低设备功耗，适配电池供电的物联网设备。
4. 发布订阅解耦通信
   • 核心通信模式为「发布-订阅」，彻底解耦消息的发送方和接收方，二者无需知道对方的存在；
   • 设备之间互不直连，全部通过服务端中转，极大提升系统的扩展性和稳定性。
5. 支持海量设备并发连接
   • 单台 MQTT 服务端可轻松支撑百万级甚至千万级的设备并发连接，这是HTTP协议无法比拟的核心优势。
6. 提供多级消息可靠性保障
   • 内置 3 种消息投递质量等级，可根据业务需求灵活选择，兼顾「传输效率」与「数据可靠性」。
7. 内置物联网专属的高级特性
   • 遗嘱消息、保留消息、会话持久化等，都是为物联网场景量身打造的原生特性，无需二次开发。

三、MQTT 核心通信模型：发布/订阅（Pub/Sub）架构

3.1 核心架构三要素（缺一不可）

MQTT 是典型的发布订阅模式，与 HTTP 的「请求-响应」模式、传统的「点对点」通信模式完全不同，核心由3个角色组成，所有通信均基于这三个角色完成：

1. 发布者（Publisher）：消息的发送方，也叫生产者；可以是任意物联网设备、服务器、手机APP等；发布者只负责发送消息，不关心谁接收消息。
2. 订阅者（Subscriber）：消息的接收方，也叫消费者；可以是任意物联网设备、服务器、手机APP等；订阅者只负责订阅主题，接收对应消息，不关心谁发送消息。
3. 服务端（Broker）：MQTT 的核心中转节点，也叫「消息代理/服务器」；是发布者和订阅者的桥梁，核心职责：接收发布者的消息、根据主题路由消息、将消息推送给对应的订阅者。

✅ 核心解耦价值：发布者和订阅者完全解耦、无直接关联，一方下线不影响另一方，系统扩展性极强，一个设备即可以是发布者也可以是订阅者。为了降低功耗，消息采用Broker推送消息的模式。

3.2 核心核心：主题（Topic）

3.2.1 主题的定义

Topic 是 MQTT 的消息路由标识，本质是一个「层级化的字符串」，用于标识消息的类别和流向，相当于消息的「地址」。

• 发布者发送消息时，必须指定一条「主题」，表示「这条消息属于哪个分类」；
• 订阅者想要接收消息时，必须「订阅对应的主题」，表示「我要接收这个分类的消息」；
• Broker 会根据「消息的主题」，将消息精准推送给所有订阅了该主题的订阅者。

3.2.2 主题的格式规范

• 主题是层级化结构，层级之间用 / 分隔，比如：sensor/temp/room1、device/light/livingroom、car/engine/status；
• 主题区分大小写，sensor/Temp 和 sensor/temp 是两条不同的主题；
• 主题可以自定义，无固定规则，按业务场景设计即可，建议做到「见名知意」。

3.2.3 主题通配符（核心，必用）

MQTT 支持 2种通配符，用于订阅「一类主题」，而不是单条主题，通配符只能在订阅者订阅时使用，发布者发布消息时不能使用，通配符均为特殊符号：

1. 单层通配符：+
   • 匹配「任意单层」主题，只能匹配一个层级，不能跨层级；
   • 示例：订阅 sensor/+/room1，可匹配 sensor/temp/room1、sensor/hum/room1，但不能匹配 sensor/temp/room1/101。
2. 多层通配符：#
   • 匹配「当前层级及所有子层级」，只能放在主题的最后一位，是最常用的通配符；
   • 示例：订阅 sensor/#，可匹配 sensor/temp、sensor/temp/room1、sensor/hum/room2/102 等所有以sensor/开头的主题。

3.3 核心核心：服务质量等级 QoS（Quality of Service）

3.3.1 QoS 的定义

QoS 是 MQTT 协议的核心可靠性保障机制，表示「消息的投递质量/可靠性等级」，定义了发布者与Broker之间、Broker与订阅者之间的消息投递规则。
MQTT 原生定义了 3个QoS等级，可靠性从低到高排序，开销从低到高排序，三者为并列关系，无优劣之分，按需选择即可，这是MQTT最核心的知识点之一。

3.3.2 三种QoS等级详解

QoS 0 ：最多一次（At most once），也叫「尽力而为」

• 核心规则：消息发送后，不确认、不重试，Broker/订阅者收到就收到，收不到就丢了，不会补发；
• 特点：传输效率最高，协议开销最小，可能丢失消息；
• 适用场景：对消息可靠性要求低、允许丢失的场景，比如：传感器实时上报的温度/湿度/心跳数据、日志上报等。

QoS 1 ：至少一次（At least once）

• 核心规则：消息发送后，必须收到对方的「确认回执」，如果没收到回执，会无限重试发送，直到收到回执为止；
• 特点：消息一定不会丢失，但可能重复接收，可靠性中等，开销中等；
• 适用场景：不允许丢失消息、可以容忍少量重复的场景，这是物联网最常用的QoS等级，比如：设备控制指令、报警信息、设备状态变更等。

在下图表示的例子中，虽然发布者的本意只是发布一条消息，但对接收方来说，最终却收到了三条相同的消息：

QoS 2 ：恰好一次（Exactly once），也叫「仅一次」

• 核心规则：基于「四次握手」机制，保证消息只会被成功投递一次，既不丢失、也不重复，是最高级别的可靠性；
• 特点：消息零丢失、零重复，可靠性最高，协议开销最大、传输效率最低；
• 适用场景：对消息一致性要求极高、不允许任何重复和丢失的场景，比如：支付相关数据、金融交易数据、计费数据等。

四次握手机制：

1. 首先，发送方存储并发送 QoS 为 2 的 PUBLISH 报文以启动一次 QoS 2 消息的传输，然后等待接收方回复 PUBREC 报文。这一部分与 QoS 1 基本一致，只是响应报文从 PUBACK 变成了 PUBREC。
2. 当发送方收到 PUBREC 报文，即可确认对端已经收到了 PUBLISH 报文，发送方将不再需要重传这个报文，并且也不能再重传这个报文。所以此时发送方可以删除本地存储的 PUBLISH 报文，然后发送一个 PUBREL 报文，通知对端自己准备将本次使用的 Packet ID 标记为可用了。与 PUBLISH 报文一样，我们需要确保 PUBREL 报文到达对端，所以也需要一个响应报文，并且这个 PUBREL 报文需要被存储下来以便后续重传。
3. 当接收方收到 PUBREL 报文，也可以确认在这一次的传输流程中不会再有重传的 PUBLISH 报文到达，因此回复 PUBCOMP 报文表示自己也准备好将当前的 Packet ID 用于新的消息了。
4. 当发送方收到 PUBCOMP 报文，这一次的 QoS 2 消息传输就算正式完成了。在这之后，发送方可以再次使用当前的 Packet ID 发送新的消息，而接收方再次收到使用这个 Packet ID 的 PUBLISH 报文时，也会将它视为一个全新的消息。

✅ 核心总结：QoS 是端到端的配置，发布者和订阅者可分别配置，最终以「较低的QoS等级」为准；物联网90%的场景使用 QoS 1 即可满足需求。

四、MQTT 物联网专属高级特性

这些特性是 MQTT 区别于其他协议的核心亮点，全部为物联网场景量身打造，是MQTT协议的「加分项」，所有特性均在建立连接时配置，使用成本极低，全部为高频使用特性：

4.1 遗嘱消息（Last Will and Testament，LWT）

• 核心作用：为设备提供「异常离线报警」能力；也叫「遗言消息」。
• 使用规则：设备在建立MQTT连接时，提前向Broker注册一条「遗嘱消息+遗嘱主题」；如果设备异常离线（断电、断网、崩溃，非正常断开连接），Broker会自动将这条「遗嘱消息」发布到指定的遗嘱主题上，订阅了该主题的服务端/设备会立即收到报警。
• 适用场景：监控设备在线状态、设备异常离线告警、智能家居设备离线提醒等。

4.2 保留消息（Retained Message）

• 核心作用：为主题「缓存最新的一条消息」，给「晚订阅的订阅者」提供最新数据。
• 使用规则：发布者发布消息时，可设置「保留标识」；Broker收到该消息后，会将这条消息作为「保留消息」缓存起来，对应主题只会缓存最新的一条保留消息；当有新的订阅者订阅该主题时，Broker会立即将这条保留消息推送给新订阅者。
• 适用场景：传感器实时数据（温度/湿度）、设备最新状态、配置信息同步等，新设备上线后可直接获取最新数据，无需等待发布者再次发送。

4.3 心跳保活机制（Keep Alive）

• 核心作用：检测设备与Broker之间的连接状态，同时降低设备功耗。
• 使用规则：设备建立连接时，指定一个「保活时间间隔（秒）」；在该时间间隔内，如果设备没有发送任何消息，会自动向Broker发送「心跳报文」，Broker收到后回复确认；如果Broker在「1.5倍保活时间」内没有收到设备的任何报文，会判定设备离线，断开连接并触发遗嘱消息。
• 核心价值：避免无效的长连接占用资源，同时保证连接的有效性，适配低功耗设备。

4.4 会话持久化（Clean Session）

• 核心参数：建立连接时的 cleanSession 配置项，只有两个值：true（清理会话）、false（持久化会话）。
  1. cleanSession = true：设备断开连接后，Broker会立即清理该设备的所有会话信息（订阅关系、未投递的消息），下次重连后需要重新订阅主题，是默认配置；
  2. cleanSession = false：设备断开连接后，Broker会持久化保存该设备的会话信息；设备重连后，Broker会自动恢复订阅关系，并将断开期间未投递的消息推送给设备，保证消息不丢失。
• 适用场景：设备频繁离线重连、需要恢复订阅关系和未投递消息的场景，比如：移动设备、网络不稳定的设备。

五、MQTT 协议版本与主流部署方式

5.1 主流协议版本

MQTT 协议的版本迭代非常稳定，无过多兼容问题，主流使用的只有两个版本，均为行业标准：

1. MQTT 3.1.1：目前最主流、最稳定、使用最广泛的版本，所有MQTT Broker和客户端均支持，兼容性最好，推荐生产环境使用。
2. MQTT 5.0：2019年发布的最新版本，在3.1.1的基础上新增了很多实用特性（共享订阅、消息过期、主题别名等），功能更强大；目前主流Broker均已支持，适合新系统选型。

补充：MQTT 3.1 是早期版本，已被3.1.1替代，基本不再使用。

5.2 主流部署传输方式

MQTT 基于 TCP/IP 协议栈实现，核心有两种部署传输方式，适配不同的业务场景：

1. MQTT over TCP：最原生、最主流的方式，直接基于TCP协议传输MQTT报文，效率最高、开销最小，物联网设备首选。
2. MQTT over WebSocket：基于WebSocket协议传输MQTT报文，可穿透防火墙和代理服务器，浏览器/网页端、小程序、H5页面唯一的MQTT接入方式；缺点是比TCP多一层封装，开销略大。

5.3 补充：MQTT-SN 协议

针对「无TCP/IP协议栈」的极简嵌入式设备（如单片机、传感器），MQTT 衍生出了 MQTT for Sensor Networks 协议，基于UDP传输，报文更精简，适配无操作系统的硬件设备。

六、MQTT 报文结构（极简，轻量化根源）

MQTT 协议的「极致轻量化」，核心源于其极简的二进制报文结构，这也是MQTT能在低带宽网络传输的根本原因，所有MQTT通信的报文均遵循此结构，无需深入掌握，但需了解核心设计：

• MQTT 报文为二进制格式，所有数据均为字节流，无文本/json等冗余格式；
• 报文由三部分组成：固定头（Fixed Header） + 可变头（Variable Header） + 有效载荷（Payload）；
  1. 固定头：必选，所有报文都有，最小仅2字节，包含报文类型、QoS等级、标识位等核心信息；
  2. 可变头：可选，仅部分报文有，包含报文的补充信息；
  3. 有效载荷：可选，即实际传输的业务数据（消息内容），只有发布消息的报文才有。
• 核心亮点：大部分MQTT控制报文（如心跳、确认、断开连接）只有固定头，仅2字节，传输效率拉满。

七、MQTT 主流服务端（Broker）中间件

MQTT Broker 是MQTT架构的核心，负责消息中转、路由、存储，相当于MQTT的「服务器」，选择合适的Broker是项目落地的关键，主流分为开源免费和商业云服务两大类，按使用频率排序：

7.1 开源MQTT Broker

1. EMQX（EMQ X）：目前最主流、功能最强大的开源MQTT Broker，基于Erlang开发，单机支持百万级并发连接，支持MQTT 3.1.1/5.0，内置规则引擎、集群、监控等功能，支持Docker部署，是物联网首选。
2. Mosquitto：轻量级开源MQTT Broker，体积小、部署简单、资源占用低，适合单机测试、小型项目、边缘设备部署，支持MQTT 3.1.1，功能简洁够用。
3. RocketMQ / RabbitMQ：传统消息队列中间件，通过插件支持MQTT协议，适合已有消息队列集群的项目，无需单独部署Broker。

7.2 商业云MQTT服务

各大云厂商均提供托管式MQTT服务，无需自己部署和维护，适合快速开发、中小企业项目：

• 阿里云物联网平台、腾讯云物联网通信、华为云IoT平台；
• 优势：免运维、高可用、弹性扩容，内置设备管理、数据解析、告警等功能；
• 劣势：按设备连接数/消息量计费，长期使用成本较高。

八、MQTT 与 HTTP/传统消息队列的核心区别

8.1 MQTT vs HTTP

二者均为应用层协议，基于TCP/IP，核心定位完全不同：

1. 通信模式：HTTP是「请求-响应」模式，客户端主动请求，服务端被动响应，一问一答；MQTT是「发布-订阅」模式，异步通信，无需应答。
2. 连接方式：HTTP默认是短连接，每次请求都要建联/断连，开销大；MQTT是长连接，建联后持续复用，开销极小。
3. 设备适配：HTTP协议开销大，需要较多内存和算力，不适合嵌入式设备；MQTT轻量级，完美适配单片机、传感器等极简设备。
4. 并发能力：单台服务器HTTP能支撑的并发连接数有限（万级）；MQTT可支撑百万级并发连接，专为海量设备设计。
5. 适用场景：HTTP适合「客户端主动获取数据」的场景（网页、APP接口）；MQTT适合「设备主动上报数据、服务端主动推送指令」的物联网场景。

8.2 MQTT vs Kafka/RabbitMQ（传统消息队列）

二者都支持发布订阅，核心定位和适用场景完全不同，互补而非替代：

1. 设计初衷：MQTT 是设备端与服务端的通信协议，解决「物联网设备接入」问题；Kafka/RabbitMQ是服务端与服务端的消息队列中间件，解决「后端服务间的异步通信、削峰填谷」问题。
2. 接入端：MQTT 对接的是「物联网设备、传感器、嵌入式硬件」；Kafka/RabbitMQ 对接的是「后端微服务、应用程序、大数据平台」。
3. 核心能力：MQTT 主打「轻量、低功耗、海量设备接入、设备管理」；Kafka/RabbitMQ 主打「高吞吐、高并发、消息持久化、集群扩容、大数据处理」。
4. 实际落地：物联网项目中，二者通常配合使用 → 设备通过MQTT上报数据到EMQX → EMQX将数据转发到Kafka → 后端服务从Kafka消费数据进行处理。

九、MQTT 典型应用场景

MQTT 协议的适用场景非常广泛，只要是「物联网相关」的场景，MQTT都是首选，核心应用领域如下：

1. 物联网设备通信：智能家居（空调、灯光、摄像头）、工业物联网（PLC、传感器、机床）、农业物联网（温湿度传感器、土壤墒情监测）、智能穿戴设备（手环、手表）等；
2. 车联网：车载设备上报车辆状态、位置信息，云端下发导航、控制指令；
3. 智慧城市：路灯、监控摄像头、充电桩、环境监测设备的联网通信；
4. 消息推送：手机APP的离线推送、公众号模板消息、小程序推送；
5. 低带宽/不稳定网络：卫星通信、偏远地区设备、移动设备的通信；
6. 海量设备连接：共享单车、充电桩、智能电表、水表等大规模设备的联网管理。

十、总结：MQTT 核心价值与核心优势

10.1 核心价值

MQTT 协议的核心价值，是完美解决了物联网场景下的核心痛点：

物联网的核心痛点：设备算力弱、内存小、带宽低、网络不稳定、设备数量庞大；而MQTT的所有设计，都是为了解决这些痛点。

10.2 核心优势总结

1. MQTT 是物联网第一通信协议，行业事实标准，生态完善，几乎所有物联网设备都原生支持；
2. 极致轻量，适配所有嵌入式设备，低带宽、低功耗、低算力，无门槛接入；
3. 发布订阅解耦，系统扩展性极强，海量设备并发连接无压力；
4. 多级可靠性保障+原生高级特性，满足物联网各种业务场景的需求；
5. 部署简单，开源Broker成熟稳定，云服务开箱即用，落地成本极低。

10.3 一句话总结

MQTT 是为物联网而生的通信协议，是连接「物理世界设备」与「数字世界平台」的桥梁，也是物联网领域无可替代的核心协议。