关于物联网:一文读懂物联网-MQTT-协议之基础特性篇

2次阅读

共计 7160 个字符，预计需要花费 18 分钟才能阅读完成。

欢送大家关注我的微信公众号【老周聊架构】，Java 后端支流技术栈的原理、源码剖析、架构以及各种互联网高并发、高性能、高可用的解决方案。

上个月有个读者问我物联网 MQTT 协定实战相干的问题，我说前面会搞，没想到人不知; 鬼不觉一个月了，太忙了，再怎么忙许可的事件还是要给读者一个交代，所以就有了此文。

2.1 什么是 MQTT 协定

MQTT（Message Queuing Telemetry Transport，音讯队列遥测传输协定），是一种基于公布 / 订阅（publish/subscribe）模式的“轻量级”通信协定，该协定构建于 TCP/IP 协定上，由 IBM 于 1999 年创造。MQTT 协定的次要特色是凋谢、简略、轻量级和易于实现，这些特色使得它实用于受约束的应用环境，如：

网络受限 ：网络带宽较低且传输不牢靠
终端受限 ：协定运行在嵌入式设施上，嵌入式终端的处理器、内存等是受限的

通过 MQTT 协定，目前曾经扩大出了数十种 MQTT 服务器端程序，能够通过 PHP、Java、Python、C、C# 等语言向 MQTT 发送音讯。因为凋谢源代码、耗电量小等特点，MQTT 十分实用于物联网畛域，如传感器与服务器的通信、传感器信息采集等。

2.2 公布 / 订阅模式

公布 / 订阅模式并不是 MQTT 协定特有的模式，像咱们很多消息中间件都有应用公布 / 订阅模式，这里你是不是想说，这不就是咱们所说的观察者模式嘛，还真不是，这两个模式很容易混同。观察者模式只有观察者 + 被观察者两个角色，而公布 / 订阅模式还有一个经纪人 Broker；往更深层次的讲观察者和被观察者，是松耦合的关系，而发布者和订阅者，则齐全不存在耦合。

在客户端 / 服务器模型中，客户端间接与服务器端点通信。而公布 / 订阅模式 pub/sub 就不一样了，公布 / 订阅模式会将发送音讯的发布者 publisher 与接管音讯的订阅者 subscribers 进行拆散，publisher 与 subscribers 并不会间接通信，他们甚至都不分明对方是否存在，他们之间的交换由第三方组件 broker 代理。

pub/sub 最重要的方面是音讯的发布者与接收者（订阅者）的解耦。这种解耦有几个维度：

空间解耦：发布者和订阅者不须要相互了解（例如，不替换 IP 地址和端口）。
工夫解耦：发布者和订阅者不须要同时运行。
同步解耦：两个组件的操作在公布或接管时不须要中断。

总之，公布 / 订阅模式打消了传统客户端 / 服务器之间的间接通信，把通信这个操作交给了 broker 进行代理，并在空间、工夫、同步三个维度上进行理解藕。

2.3 可扩展性

pub/sub 比传统的客户端 / 服务器模式有了更好的拓展，这是因为 broker 的高度并行化，并且是基于事件驱动的模式。可扩展性还体现在音讯的缓存和音讯的智能路由，还能够通过集群代理来实现数百万的连贯，应用负载均衡器将负载调配到更多的单个服务器上，这就是 MQTT 的深度利用了。

2.4 音讯过滤

很显著，broker 在 pub/sub 过程中起着无足轻重的作用。然而代理如何过滤所有音讯，以便每个订阅者只接管感兴趣的音讯？broker 有几个能够过滤的选项：

基于主题的过滤
此过滤基于属于每条音讯的主题。接管客户端向代理订阅感兴趣的主题，订阅后，broker 就会确保客户端收到公布到 topic 中的音讯。
基于内容的过滤
在基于内容的过滤中，broker 会依据特定的内容过滤音讯，承受客户端会通过过滤他们感兴趣的内容。这种办法的一个显著的毛病就是必须当时晓得音讯的内容，不能加密或者轻易批改。
基于类型的过滤
当应用面向对象的语言时，基于音讯（事件）的类型 / 类进行过滤是一种常见做法。例如，订阅者能够收听所有类型为 Exception 或任何子类型的音讯。

2.5 MQTT 与音讯队列的区别

这里你又会说了，既然 MQTT 与支流的音讯的队列都采纳公布 / 订阅模式，那他们就是一样的。这里老周得再提一嘴，的确和音讯队列很多类似的中央，但还有有些差别的，上面就来说道说道：

音讯队列存储音讯直到音讯被生产 应用音讯队列时，每条传入音讯都存储在队列中，直到被客户端（通常称为消费者）接管。如果没有客户端接管到音讯，音讯将放弃在队列中并期待被生产。在音讯队列中，不会存在音讯没有客户端生产的状况，然而在 MQTT 中，却存在 topic 无 subscriber 订阅的状况。
一条音讯只被一个客户端生产 另一个很大的区别是，在传统的音讯队列中，一条音讯只能被一个消费者解决。负载散布在队列的所有消费者之间。在 MQTT 中，行为齐全相同：订阅主题的每个订阅者都会收到音讯，每个订阅者有雷同的负载。
队列是命名的，必须显式创立 队列比主题严格得多。在应用队列之前，必须应用独自的命令显式创立队列。只有在队列命名和创立之后，才能够公布或生产音讯。相比之下，MQTT 主题非常灵活，能够即时创立。

3.1 MQTT Client

publisher 和 subscriber 都属于 MQTT Client，之所以有发布者和订阅者这个概念，其实是一种绝对的概念，就是指以后客户端是在公布音讯还是在接管音讯，公布和订阅的性能也能够由同一个 MQTT Client 实现。

MQTT 客户端是运行 MQTT 库并通过网络连接到 MQTT 代理的任何设施（从微控制器到成熟的服务器）。例如，MQTT 客户端能够是一个十分小的、资源受限的设施，它通过无线网络进行连贯并具备一个最低限度的库。基本上，任何应用 TCP/IP 协定应用 MQTT 设施的都能够称之为 MQTT Client。MQTT 协定的客户端实现非常简单间接，易于施行是 MQTT 非常适合小型设施的起因之一。MQTT 客户端库可用于多种编程语言。例如，Android、Arduino、C、C++、C#、Go、iOS、Java、JavaScript 和 .NET。

3.2 MQTT Broker

与 MQTT Client 对应的就是 MQTT Broker，Broker 是任何公布 / 订阅协定的外围，依据实现的不同，代理能够解决多达数百万连贯的 MQTT Client。

Broker 负责接管所有音讯，过滤音讯，确定是哪个 Client 订阅了每条音讯，并将音讯发送给对应的 Client，Broker 还负责保留会话数据，这些数据包含订阅的和错过的音讯。Broker 还负责客户端的身份验证和受权。

3.3 MQTT Connection

MQTT 协定基于 TCP/IP。客户端和代理都须要有一个 TCP/IP 协定反对。

MQTT 连贯始终位于一个客户端和代理之间。客户端从不间接相互连接。要发动连贯，客户端向代理发送 CONNECT 音讯。代理应用 CONNACK 音讯和状态代码进行响应。建设连贯后，代理将放弃关上状态，直到客户端发送断开连接命令或连贯中断。

4.1 CONNECT

为了创立连贯，客户端向代理发送命令音讯。如果此 CONNECT 音讯格局谬误（依据 MQTT 标准）或关上网络套接字和发送连贯音讯之间的工夫过长，代理将敞开连贯。

一个 MQTT 客户端发送一条 CONNECT 连贯，这条 CONNECT 连贯可能会蕴含上面这些信息：

咱们将重点关注以下选项：

ClientId：ClientId 的长度能够是 1-23 个字符，在一个服务器上 ClientId 不能反复。如果超过 23 个字符，则服务器返回 CONNACK 音讯中的返回码为 Identifier Rejected。在 MQTT 3.1.1 中，如果您不须要代理持有状态，您能够发送一个空的 ClientId。空的 ClientId 导致连贯没有任何状态。在这种状况下，clean session 标记必须设置为 true，否则代理将回绝连贯。
Clean Session：Clean Session 标记通知代理客户端是否要建设长久会话。在长久会话 (CleanSession = false) 中，代理存储客户端的所有订阅以及以服务质量（QoS）级别 1 或 2 订阅的客户端的所有失落音讯。如果会话不是长久的 (CleanSession = true)，代理不为客户端存储任何内容，并革除任何先前长久会话中的所有信息。
Username/Password：MQTT 能够发送用户名和明码进行客户端认证和受权。然而，如果此信息未加密或散列，则明码将以纯文本模式发送。咱们强烈建议将用户名和明码与平安传输一起应用。像 HiveMQ 这样的代理能够应用 SSL 证书对客户端进行身份验证，因而不须要用户名和明码。
Will Message：LastWillxxx 示意的是遗愿，client 在连贯 broker 的时候将会设立一个遗愿，这个遗愿会保留在 broker 中，当 client 因为非正常起因断开与 broker 的连贯时，broker 会将遗愿发送给订阅了这个 topic（订阅遗愿的 topic）的 client。
KeepAlive：keepAlive 是 client 在连贯建设时与 broker 通信的工夫距离，通常以秒为单位。这个工夫指的是 client 与 broker 在不发送音讯下所能接受的最大时长。

4.2 CONNACK

当 broker 收到 CONNECT 音讯时，它有任务回复 CONNACK 音讯进行响应。CONNACK 音讯包含两局部内容：

The session present flag：会话以后标记
A connect return code：连贯返回码

Session Present flag

会话以后标记，这个标记会通知 client 以后 broker 是否有一个持久性会话与 client 进行交互。SessionPresent 标记和 CleanSession 标记无关，当 client 在 CleanSession 设置为 true 的状况下连贯时，SessionPresent 始终为 false，因为没有持久性会话能够应用。如果 CleanSession 设置为 false，则有两种可能性，如果 ClientId 的会话信息可用，并且 broker 曾经存储了会话信息，那么 SessionPresent 为 true，否则如果没有 ClientId 的任何会话信息，那么 SessionPresent 为 false。
Connect return code

CONNACK 音讯中的第二个标记是连贯确认标记。这个标记蕴含一个返回码，通知客户端连贯尝试是否胜利。连贯确认标记有上面这些选项：

4.3 PUBLISH

MQTT 客户端能够在连贯到 broker 后立刻公布音讯，MQTT 应用的是基于 topic 主题的过滤。每条音讯都必须蕴含一个主题，broker 能够应用该主题将音讯转发给感兴趣的客户端。通常，每条音讯都有一个负载（Payload），其中蕴含要以字节格局传输的数据。MQTT 是数据无关性的，也就是说数据是由发布者 – publisher 决定要发送的是 XML、JSON 还是二进制数据、文本数据。

MQTT 中的 PUBLISH 音讯有几个咱们想要具体探讨的属性：

Topic Name：主题名称是一个简略的字符串，它以正斜杠作为分隔符进行分层构造。例如，“我的家 / 客厅 / 温度”或“德国 / 慕尼黑 / 十月节 / 人”。
QoS：此数字示意音讯的服务质量 (QoS)。有三个级别：0、1 和 2。服务级别决定了音讯达到预期接收者（客户端或代理）的保障类型。
Retain Flag：此标记示意 broker 将最近收到的一条 RETAIN 标记位为 true 的音讯保留在服务器端（内存或者文件）。
Payload：这个是每条音讯的理论内容。MQTT 是数据无关性的。能够发送任何文本、图像、加密数据以及二进制数据。
Packet Identifier：这个 packetId 标识在 client 和 broker 之间惟一的音讯标识。packetId 仅与大于零的 QoS 级别相干。
DUP flag：该标记表明该音讯是反复的并且因为预期的接收者（客户端或代理）没有确认原始音讯而被从新发送。这仅与 QoS 大于 0 相干。

当客户端向 MQTT broker 发送音讯进行公布时，broker 读取音讯、确认音讯（依据 QoS 级别）并解决音讯。broker 的解决包含确定哪些客户端订阅了主题并将音讯发送给他们。

最后公布音讯的客户端只关怀将 PUBLISH 消息传递给 broker。一旦 broker 收到 PUBLISH 音讯，broker 就有责任将消息传递给所有订阅者。公布客户端不会失去对于是否有人对公布的音讯感兴趣或有多少客户端从 broker 收到音讯的任何反馈。

4.4 Subscribe

client 会向 broker 发送 SUBSCRIBE 音讯来接管无关感兴趣的 topic，这个 SUBSCRIBE 音讯非常简单，它蕴含了一个惟一的数据包标识和一个订阅列表。

Packet Identifier：这个 PacketId 和下面的 PacketId 一样，都示意音讯的惟一标识符。
List of Subscriptions：一个 SUBSCRIBE 音讯能够蕴含一个客户端的多个订阅。每个订阅由一个主题和一个 QoS 级别组成。订阅音讯中的主题能够蕴含通配符，使订阅主题模式而不是特定主题成为可能。如果一个客户端存在重叠订阅，则代理会传送该主题具备最高 QoS 级别的音讯。

4.5 Suback

为了确认每个订阅，broker 向客户端发送一个 SUBACK 确认音讯。该音讯蕴含原始 Subscribe 音讯的数据包标识符（以明确标识该音讯）和返回码列表。

Packet Identifier：包标识符是用于标识音讯的惟一标识符。它与 SUBSCRIBE 音讯中的雷同。
Return Code：broker 为它在 SUBSCRIBE 音讯中收到的每个主题 /QoS 对发送一个返回代码。例如，如果 SUBSCRIBE 音讯有五个订阅，则 SUBACK 音讯蕴含五个返回码。返回码确认每个主题并显示 broker 授予的 QoS 级别。如果 broker 回绝订阅，则 SUBACK 音讯蕴含该特定主题的失败返回代码。例如，如果客户端没有足够的权限订阅主题或主题格局谬误。

客户端胜利发送 SUBSCRIBE 音讯并收到 SUBACK 音讯后，它会获取与 SUBSCRIBE 音讯蕴含的订阅中的主题匹配的每条已公布音讯。

4.6 Unsubscribe

SUBSCRIBE 音讯的对应是 UNSUBSCRIBE 音讯。此音讯删除 broker 上客户端的现有订阅。UNSUBSCRIBE 音讯与 SUBSCRIBE 音讯相似，具备数据包标识符和主题列表。

4.7 Unsuback

为了确认勾销订阅，broker 向客户端发送一个 UNSUBACK 确认音讯。此音讯仅蕴含原始 UNSUBSCRIBE 音讯的数据包标识符（以明确标识该音讯）。

客户端收到来自 broker 的 UNSUBACK 后，能够认为 UNSUBSCRIBE 音讯中的订阅被删除了。

后面咱们说了很多 MQTT 协定的格局以及音讯列表，这一节咱们来说下 Topics 主题。主题在 MQTT 中很重要，因为咱们写代码的时候往往都是须要先确认好 MQTT 的 Topics。

在 MQTT 中，主题一词是指 broker 用于为每个连贯的客户端过滤音讯的 UTF-8 字符串。主题由一个或多个主题级别组成。每个主题级别由正斜杠（主题级别分隔符）分隔。

与音讯队列相比，MQTT 主题十分轻量级。客户端在公布或订阅它之前不须要创立所需的主题。broker 承受每个无效主题而无需任何当时初始化。

5.1 通配符

当客户端订阅主题时，它能够订阅已公布音讯的确切主题，也能够应用通配符同时订阅多个主题。通配符只能用于订阅主题，不能用于公布音讯。有两种不同类型的通配符：单级和多级。

单级：+

顾名思义，单级通配符替换一个主题级别。加号代表主题中的单级通配符。
```
     ![在这里插入图片形容](https://img-blog.csdnimg.cn/20210716003135963.png)
```
如果主题蕴含任意字符串而不是通配符，则任何主题都与具备单级通配符的主题匹配。例如，订阅 myhome/groundfloor/+/temperature 能够产生以下后果：

多级：#

多级通配符涵盖多个主题级别。哈希符号代表主题中的多级通配符。为了让代理确定哪些主题匹配，多级通配符必须作为主题中的最初一个字符搁置，并以正斜杠结尾。

当客户端订阅带有多级通配符的主题时，无论主题多长或多深，它都会收到以通配符之前的模式结尾的主题的所有音讯。如果您仅将多级通配符指定为主题 (#)，您将收到发送到 MQTT 代理的所有音讯。如果您冀望高吞吐量，独自应用多级通配符订阅是一种反模式（请参阅上面的最佳实际）。

5.2 以 $ 结尾的主题

通常，您能够依据须要命名 MQTT 主题。然而，有一个例外：以 $ 符号结尾的主题具备不同的目标。当您将多级通配符作为主题 (#) 订阅时，这些主题不是订阅的一部分。$-symbol 主题保留用于 MQTT 代理的外部统计信息。客户端无奈向这些主题公布音讯。目前，此类主题尚无官网标准化。通常，$SYS/ 用于所有以下信息，但代理实现各不相同。MQTT GitHub wiki 中提供了对 $SYS-topics 的一项倡议。这里有些例子：