MQTT协议介绍

MQTT(Message Queuing Telemetry Transport, 消息队列遥测传输协议)，是一种基于发布/订阅(publish/subscribe)模式的"轻量级"通讯协议，该协议构建于TCP/IP协议上，由IBM在1999年发布。MQTT最大优点在于，可以以极少的代码和有限的带宽，为远程连接设备提过实时可靠的消息服务，作为一种低开销、低带宽占用的即时通讯协议，使其在物联网、小型设备、移动应用等方面有较广泛的应用
MQTT是一个基于客户端-服务器的消息发布/订阅传输协议。MQTT协议是轻量、简单、开放和易于实现的，这些特点使它适用范围非常广泛。在很多情况下，包括受限的环境中，如:机器与机器（M2M）通信和物联网(loT)。其在，通过卫星链路通信传感器、偶尔拨号的医疗设备、智能家居、及一些小型化设备中已广泛使用。

一.MQTT概述

1.1 MQTT的发展历史

1999 年：Andy Stanfork-Clark (IBM) 和 Arlen Nipper 发布 MQTT 协议，用于通过卫星连接石油管道遥测系统，MQTT 中的 TT (Telemetry Transport) 就是源于这样一个遥测系统；
2010 年：MQTT 协议免费发布；
2014 年：MQTT 协议正式成为 OASIS 标准，经过多年的发展，MQTT 协议已经成为互联网 (IoT) 的主要协议之一。

1.2 MQTT的应用领域

MQTT是基于二进制消息的发布/订阅编程模式的消息协议，最早由IBM提出的，如今已经成为OASIS规范。由于规范很简单，非常适合需要低功耗和网络带宽有限的IoT场景，比如：
• 遥感数据
• 汽车
• 智能家居
• 智慧城市
• 医疗医护
• 智慧农业
• 工业4.0
MQTT被广泛使用，可以在几乎任何大型硬件和互联网公司中找到，例如Facebook，BP，阿里巴巴，百度。由于MQTT本身的技术优势，越来越多的公司选择MQTT作为物联网产品通信的标准协议。

1.3 MQTT的优点

MQTT的独特功能是每个消息头都可以缩短为2个字节。对于HTTP，为每个新请求消息重新建立HTTP连接会产生可观的开销。 MQ和MQTT使用的持久连接可以大大减少这种开销。
包容不稳定的网络，MQTT和MQ可以从诸如断开连接之类的故障中恢复，无需进一步的代码要求。但是，HTTP本身无法实现此目标，并且客户端必须重试编码，这会增加身份问题。
低功耗MQTT专为低功耗目标而设计。 HTTP设计未考虑此因素，这会增加功耗。
在连接数百万个客户端的情况下，在HTTP堆栈中维护数百万个并发连接需要大量工作才能提供支持。尽管这种支持是可行的，但大多数商业产品都经过优化以处理此订单上的持久连接。 IBM提供了IBM MessageSight，这是一种单机架安装服务器，已经过测试，可以通过MQTT处理多达一百万个并发设备。相反，MQ不是为许多同时进行的客户设计的。
推送通知。您需要能够及时向客户发送通知。为此，您应该使用常规的轮询或推送方法。就电池，系统负载和带宽而言，推送是最佳解决方案。
客户端平台的差异。 HTTP和MQTT客户端都在许多平台上实现。 MQTT的简单性可帮助您以最少的努力在其他客户端上实施MQTT。
防火墙容错能力。某些公司防火墙将出站连接限制到某些预定义的端口，这些端口通常仅限于HTTP（端口80），HTTPS（端口443）等，HTTP在这种情况下显然可以工作。 MQTT封装在WebSockets连接中，并显示为HTTP升级请求，因此可以在这种情况下运行。

1.4 MQTT通信模型

MQTT 协议提供一对多的消息发布，可以降低应用程序的耦合性，用户只需要编写极少量的应用代码就能完成一对多的消息发布与订阅，该协议是基于<客户端-服务器>模型，在协议中主要有三种身份：发布者（Publisher）、服务器（Broker）以及订阅者（Subscriber）。其中，MQTT消息的发布者和订阅者都是客户端，服务器只是作为一个中转的存在，将发布者发布的消息进行转发给所有订阅该主题的订阅者；发布者可以发布在其权限之内的所有主题，并且消息发布者可以同时是订阅者，实现了生产者与消费者的脱耦，发布的消息可以同时被多个订阅者订阅。
MQTT通信模型示意图如下：

MQTT客户端的功能：
1.发布消息给其它相关的客户端。
2.订阅主题请求接收相关的应用消息。
3.取消订阅主题请求移除接收应用消息。
4.从服务端终止连接。

MQTT服务器端功能：
MQTT 服务器常被称为 Broker（消息代理），以是一个应用程序或一台设备，它一般为云服务器，比如BTA三巨头的一些物联网平台就是常使用MQTT协议，它是位于消息发布者和订阅者之间，以便用于接收消息并发送到订阅者之中，它的功能有：
1.接受来自客户端的网络连接请求。
2.接受客户端发布的应用消息。
3.处理客户端的订阅和取消订阅请求。
4.转发应用消息给符合条件的已订阅客户端（包括发布者自身）。

1.5 发布/订阅、主题、会话

MQTT是基于发布(Publish)/订阅(Subscribe)模式来进行通信及数据交换的，与HTTP的请求(Request)/应答(Response)的模式有本质的不同
订阅者(Subscriber)会向消息服务器(Broker)订阅一个主题(Topic)。成功订阅后，消息服务器会将该主题下的消息转发给所有订阅者
主题(Topic)以’/‘为分隔符区分不同的层级，包含通配符’+’ 或 ‘#’的主题又称为主题过滤器(Topic Filters); 不含通配符的成为主题名(Topic Names) 例如:

chat/ room/1sensor/10/temperaturesensor/+/temperature$SYS/broker/metrics/packets/received$SYS/broker/metrics/#

'+' : 表示通配一个层级， 例如a/+，匹配a/x, a/y'#' : 表示通配多个层级，例如a/#，匹配a/x, a/b/c/d注: '+' 通配一个层级，‘#’ 通配多个层级(必须在末尾)

发布者(Publisher)只能向主题名发布消息，订阅者(Subscriber)则可以通过订阅主题过滤器来通配多个主题名称

会话(Session)
每个客户端与服务器建立连接后就是一个会话，客户端和服务器之间有状态交互。会话存在于一个网络之间，也可能在客户端和服务器之间跨越多个连续的网络连接。

二.消息主题与服务质量

2.1 MQTT消息主题

MQTT服务器为每个连接的客户端（订阅者）添加一个标签，该标签与服务器中的所有订阅相匹配，服务器会将消息转发给与标签相匹配的每个客户端（订阅者），当然订阅者也是需要有权限才能订阅对应的主题，比如像阿里云中的，订阅者只能订阅同一个产品下的主题，而不能跨产品订阅，这样子的处理就能达到信息的安全性以及多个订阅者能及时收到消息。一个主题可以有多个级别，各个级别之间用斜杠字符分隔，例如/test 和 /test/test1/test2都 是有效的主题。
发布者与订阅者可以通过主题名字，一般为UTF-8编码（反正用英文字符串就不会错）的形式发布和订阅主题，比如我们可以直接定义一个名字为“test”的主题，绝大多数的MQTT服务器支持动态发布/定阅主题，即当前服务器中没有某个主题，但是客户端直接可以向该主题发布/订阅消息，这样子服务器就会创建对应的主题，当然，服务器中一般也会默认提供多个系统主题，所有连接的客户端均可订阅。
每个客户端与服务器建立连接后就是一个会话，客户端和服务器之间会有状态交互，订阅是基于会话之上，每个订阅中，都会包含一个主题过滤器，它是一个表达式，用于标识订阅相关的一个或多个主题，主题过滤器可以使用通配符，因此订阅者需要指定订阅的主题名字与服务质量（QoS），订阅者能订阅多个主题，也就能接收到多个发布者发布的消息。同理，发布者也需要首先与服务器建立会话，并且指定发送的主题名字与服务质量，同时它也能向多个不同的主题发送消息。

2.2MQTT服务质量

MQTT的服务质量提供3个等级：
QoS0：当 QoS 为 0 时，消息的分发依赖于底层网络的能力。最多发送一次消息，在消息发送出去后，接收者不会发送回应，发送者也不会重发消息，消息可能送达一次也可能根本没送达，这个服务质量常用在不重要的消息传递中，因为即使消息丢了也没有太大关系。

QoS1：当 QoS 为 1 时，可以保证消息至少送达一次。MQTT 通过简单的 ACK 机制来保证 QoS 1。发布者会发布消息，并等待接收者的 PUBACK 报文的应答，如果在规定的时间内没有收到 PUBACK 的应答，发布者会将消息的 DUP 置为 1并重发消息。接收者接收到 QoS 为 1 的消息时应该回应 PUBACK 报文，接收者可能会多次接受同一个消息，无论 DUP 标志如何，接收者都会将收到的消息当作一个新的消息并发送 PUBACK 报文应答。

QoS2：这是最高等级的服务质量，消息丢失和重复都是不可接受的，只不过使用这个服务质量等级会有额外的开销，这个等级常用于支付中，因为支付是必须有且仅有一次成功，总不能没给钱或者给了多次钱吧。
当 QoS 为 2 时，发布者和订阅者通过两次会话来保证消息只被传递一次，这是最高等级的服务质量，消息丢失和重复都是不可接受的。使用这个服务质量等级会有额外的开销。发布者发布 QoS 为 2 的消息之后，会将发布的消息储存起来并等待接收者回复 PUBREC 的消息，发送者收到 PUBREC 消息后，它就可以安全丢弃掉之前的发布消息，因为它已经知道接收者成功收到了消息。发布者会保存 PUBREC 消息并应答一个 PUBREL，等待接收者回复 PUBCOMP 消息，当发送者收到 PUBCOMP 消息之后会清空之前所保存的状态。
当接收者接收到一条 QoS 为 2 的 PUBLISH 消息时，他会处理此消息并返回一条 PUBREC 进行应答。当接收者收到 PUBREL 消息之后，它会丢弃掉所有已保存的状态，并回复 PUBCOMP。
无论在传输过程中何时出现丢包，发送端都负责重发上一条消息。不管发送端是 Publisher 还是 Broker，都是如此。因此，接收端也需要对每一条命令消息都进行应答。

————————————————
版权声明：本文为CSDN博主「Frank-Hu」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/hyz529900/article/details/123917756