一、MQTT简介
MQTT被广泛用于物联网(IoT:Internet of Things)领域，其中大量的设备需要进行实时通信和数据交换。它采用了一种发布/订阅(publish/subscribe)模型，其中消息的发送者（发布者）将消息发布到特定的主题（topic），而订阅者可以选择性地订阅感兴趣的主题，以接收相应的消息。
二、MQTT特点
1.轻量级
MQTT的设计非常轻量，协议头部非常小，传输的数据量很小，适用于带宽有限的网络环境，如低速、高延迟或不稳定的网络。
2.简单
MQTT的协议规范相对简单，易于实现和部署。它定义了少量的消息类型和协议操作，使得开发人员可以快速上手。
3.异步通信
MQTT使用异步通信模式，发布者发送消息后，不需要等待接收者的响应，可以继续执行其他操作。这种异步通信模式适合在资源有限的设备和网络中工作。
4.可靠性
MQTT支持三种不同的消息传递质量（QoS）级别：QoS 0（至多一次），QoS 1（至少一次）和QoS 2（只有一次）。这使得可以根据应用程序的要求选择适当的消息交付保证级别。
5.网络状况适应性
MQTT可以适应不稳定的网络状况，如网络中断、重连等。它具有断开连接后自动重连的机制，可以确保消息的可靠传输。
三、订阅和发布模型
1.Publisher(发布者)
发布者是消息的发送者，它将消息发布到特定的主题（topic）上。可以有一个或多个发布者。发布者一次只能向一个主题发送数据，发布者发布消息时也无需关心订阅者是否在线。
2.Subscriber(订阅者)
订阅者通过订阅主题接收消息,订阅者可以对消息感兴趣的实体，它选择性地订阅一个或多个主题。一旦订阅了主题，它就会接收到相应的消息。
3.MQTT Broker(MQTT代理)
MQTT代理是中间件，负责接收发布者发送的消息，并将其路由到对应的订阅者。代理也需要负责处理客户端发起的连接、断开连接、订阅、取消订阅等请求。
4.Topic(主题)
主题是 MQTT 进行消息路由的基础，它类似 URL 路径，使用斜杠 / 进行分层，比如 sensor/1/temperature。一个主题可以有多个订阅者，代理会将该主题下的消息转发给所有订阅者；一个主题也可以有多个发布者，代理将按照消息到达的顺序转发。
MQTT 还支持订阅者使用主题通配符一次订阅多个主题。
四、MQTT QoS
1.QoS介绍
很多时候，使用 MQTT 协议的设备都运行在网络受限的环境下，而只依靠底层的 TCP 传输协议，并不能完全保证消息的可靠到达。因此，MQTT 提供了 QoS（Quality of Service） 机制，其核心是设计了多种消息交互机制来提供不同的服务质量，来满足用户在各种场景下对消息可靠性的要求。
MQTT（Message Queuing Telemetry Transport）协议支持三种不同的QoS级别，用于控制消息的可靠性和传输保证。
MQTT的三个QoS级别:QoS 0（至多一次），QoS 1（至少一次）和QoS 2（只有一次）。
2.QoS三个级别介绍
(1)QoS 0（至多一次）
在QoS 0级别下，消息以“至多一次”传输，没有确认机制。消息被发布后，发布者不会接收到关于消息是否成功传输或交付的确认。MQTT代理会尽最大努力将消息传输给订阅者，但可能会出现消息丢失或重复的情况。此级别适用于对消息传输的可靠性要求不高的场景，如传感器数据的临时更新等。
为什么 QoS 0 消息会丢失？
当我们使用 QoS 0 传递消息时，消息的可靠性完全依赖于底层的 TCP 协议。而 TCP 只能保证在连接稳定不关闭的情况下消息的可靠到达，一旦出现连接关闭、重置，仍有可能丢失当前处于网络链路或操作系统底层缓冲区中的消息。这也是 QoS 0 消息最主要的丢失场景。
(2)QoS 1（至少一次）
为了保证消息到达，QoS 1 加入了应答与重传机制，发送方只有在收到接收方的 PUBACK 报文以后，才能认为消息投递成功，在此之前，发送方需要存储该 PUBLISH 报文以便下次重传。
如果发布者没有收到确认消息，它会再次发送相同的消息，直到收到确认为止。MQTT代理会确保消息至少传输一次给订阅者，但可能会出现重复传输的情况。此级别适用于对消息传输的可靠性要求较高的场景，如控制指令的传递。
QoS 1 需要在 PUBLISH 报文中设置 Packet ID，而作为响应的 PUBACK 报文，则会使用与 PUBLISH 报文相同的 Packet ID，以便发送方收到后删除正确的 PUBLISH 报文缓存。
PUBACK - 发布确认报文
(3)QoS 2（只有一次）
在QoS 2级别下，消息以“只有一次”传输，确保仅传输一次。发布者发送消息后，会等待MQTT代理发送两个确认消息（PUBREC和PUBCOMP）来确认消息的接收和完成。MQTT代理会确保消息仅传输一次给订阅者，没有重复传输的情况。
此级别提供了最高的消息传输可靠性，但也伴随着更高的网络开销。此级别适用于对消息传输的可靠性要求非常高的场景，如金融交易或严格的数据同步
PUBREC – 发布收到报文 （QoS 2，第一步）
PUBREL – 发布释放（QoS 2，第二步）
PUBCOMP – 发布完成（QoS 2，第三步）
QoS 2 解决了 QoS 0、1 消息可能丢失或者重复的问题，但相应地，它也带来了最复杂的交互流程和最高的开销。每一次的 QoS 2 消息投递，都要求发送方与接收方进行至少两次请求/响应流程。
- 首先，发送方存储并发送 QoS 为 2 的 PUBLISH 报文以启动一次 QoS 2 消息的传输，然后等待接收方回复 PUBREC 报文。这一部分与 QoS 1 基本一致，只是响应报文从 PUBACK 变成了 PUBREC。
- 当发送方收到 PUBREC 报文，即可确认对端已经收到了 PUBLISH 报文，发送方将不再需要重传这个报文，并且也不能再重传这个报文。所以此时发送方可以删除本地存储的 PUBLISH 报文，然后发送一个 PUBREL 报文，通知对端自己准备将本次使用的 Packet ID 标记为可用了。与 PUBLISH 报文一样，我们需要确保 PUBREL 报文到达对端，所以也需要一个响应报文，并且这个 PUBREL 报文需要被存储下来以便后续重传。
- 当接收方收到 PUBREL 报文，也可以确认在这一次的传输流程中不会再有重传的 PUBLISH 报文到达，因此回复 PUBCOMP 报文表示自己也准备好将当前的 Packet ID 用于新的消息了。
- 当发送方收到 PUBCOMP 报文，这一次的 QoS 2 消息传输就算正式完成了。在这之后，发送方可以再次使用当前的 Packet ID 发送新的消息，而接收方再次收到使用这个 Packet ID 的 PUBLISH 报文时，也会将它视为一个全新的消息。
选择合适的QoS级别取决于应用程序对消息传输可靠性和网络开销的要求。更高的QoS级别提供了更可靠的传输，但同时也增加了网络开销。因此，需要根据具体场景的需求来选择适当的级别。
