之前有位读者给我留言说想要了解一下什么是 MQTT 协议,顺便还把我夸了一把,有点不好意思啦。 那么读者的要求必须要满足啊,所以现在 @一下这位小姐姐,来听课啦! 什么是 MQTT 协议MQTT 协议的全称是 Message Queuing Telemetry Transport,翻译为消息队列传输探测,它是 ISO 标准下的一种基于发布 - 订阅模式的消息协议,它是基于 TCP/IP 协议簇的,它是为了改善网络设备硬件的性能和网络的性能来设计的。MQTT 一般多用于 IoT 即物联网上,广泛应用于工业级别的应用场景,比如汽车、制造、石油、天然气等。 在了解了 MQTT 的概念和应用场景后,我们下来就来走进 MQTT 的学习中了,先来看一下 MQTT 有哪些概念。 MQTT 基础上面我们解释了 MQTT 协议的基本概念,MQTT 协议总结一点就是一种轻量级的二进制协议,MQTT 协议与 HTTP 相比具有一个明显的优势:数据包开销较小,数据包开销小就意味着更容易进行网络传输。还有一个优势就是 MQTT 在客户端容易实现,而且具有易用性,非常适合当今资源有限的设备。
MQTT 协议由 Andy Stanford-Clark (IBM) 和 Arlen Nipper(Arcom,现为 Cirrus Link)于 1999 年发明。他们需要一种通过卫星连接石油管道的协议,以最大限度地减少电池损耗和带宽。所以他们为这个协议规定了几种要求:
这些设计也是 MQTT 的精髓所在,MQTT 经过不断的发展,已经成为了物联网 IoT 所必备的一种消息探测协议,官方强烈推荐使用的版本是 MQTT 5。 发布 - 订阅模式发布 - 订阅模式我相信接触消息中间件架构的同学都听过,这是一种传统的客户端 - 服务器架构的替代方案,因为一般传统的客户端-服务器是客户端能够直接和服务器进行通信。 但是发布 - 订阅模式 pub/sub 最重要的方面是 publisher 与 subscriber 的解藕,这种耦合度有下面三个维度:
总之,发布/订阅模式消除了传统客户-服务器之间的直接通信,把通信这个操作交给了 broker 进行代理,并在空间、时间、同步三个维度上进行了解藕。 可拓展性pub/sub 比传统的客户端-服务器模式有了更好的拓展,这是由于 broker 的高度
事件驱动是一种 消息过滤在 pub/sub 的架构模式中,broker 扮演着至关重要的作用,其中非常重要的一点就是 broker 能够对消息进行过滤,使每个订阅者只接收自己感兴趣的消息。 broker 有几个可以过滤的选项
MQTT 是基于 subject 的消息过滤的,每条消息都会有一个 topic ,接收客户端会向 borker 订阅感兴趣的 topic,订阅后,broker 就会确保客户端收到发布到 topic 中的消息。
在基于内容的过滤中,broker 会根据特定的内容过滤消息,接受客户端会经过过滤他们感兴趣的内容。这种方法的一个显著的缺点就是必须事先知道消息的内容,不能加密或者轻易修改。
在使用面向对象的语言时,基于消息(事件)的类型过滤是一种比较常见的过滤方式。 为了发布/订阅系统的挑战,MQTT 具有三个服务质量级别,你可以指定消息从客户端传到 broker 或者从 broker 传到客户端,在 topic 的订阅中,会存在 topic 没有 subscriber 订阅的情况,作为 broker 必须知道如何处理这种情况。 MQTT 与消息队列的区别我们现在知道,MQTT 是一种消息队列传输探测协议,这种协议是看似是以消息队列为基础,但却与消息队列有所差别。 在传统的消息队列模式中,一条消息会存储在消息队列中等待被消费,每个传入的消息都存储在消息队列中,直到它被客户端(通常称之为消费者)所接收,如果没有客户端消费消息的话,这条消息就会存在消息队列中等待被消费。但是在消息队列中,不会存在消息没有客户端消费的情况,但是在 MQTT 中,确存在 topic 无 subscriber 订阅的情况。 在传统的消息队列模式中,一条消息只能被一个客户端所消费, 在传统的消息队列模式中,必须使用单独的命令来显式创建队列,只有队列创建后,才可以生产或者消费消息;而在 MQTT 中,topic 比较灵活,可以即时创建。
我们知道,broker 将 publisher 和 subscriber 进行分离,因此客户端的连接由 broker 代理,所以在我们深入理解 MQTT 之前,我们需要先知道客户端和代理的含义。 MQTT 重要概念MQTT client当我们讨论关于客户端的概念时,一般指的就是 MQTT Client,publisher 和 subscriber 都属于 MQTT Client。之所以有发布者和订阅者这个概念,其实是一种相对的概念,就是指当前客户端是在发布消息还是在接收消息,发布和订阅的功能也可以由同一个 MQTT Client 实现。 MQTT 客户端是指运行 MQTT 库并通过网络连接到 MQTT broker 的任何设备,这些设备可以从微控制器到成熟的服务器。基本上,任何使用 TCP/IP 协议使用 MQTT 设备的都可以称之为 MQTT Client。MQTT 协议的客户端实现非常简单直接。易于实施是 MQTT 非常适合小型设备的原因之一。MQTT 客户端库可用于多种编程语言。例如,Android、Arduino、C、C 、C#、Go、iOS、Java、JavaScript 和 .NET。 MQTT broker与 MQTT client 对应的就是 MQTT broker,broker 是任何发布/订阅机构的核心,根据实现的不同,代理可以处理多达数百万连接的 MQTT client。 broker 负责接收所有消息,过滤消息,确定是哪个 client 订阅了每条消息,并将消息发送给对应的 client,broker 还负责保存会话数据,这些数据包括订阅的和错过的消息。broker 还负责客户端的身份验证和授权。 MQTT ConnectionMQTT 是基于 TCP/IP 协议基础之上的,所以 MQTT 的 client 和 broker 都需要 TCP/IP 协议的支持。 MQTT 的连接总是在 client 和 broker 之间进行,client 和 client 之间并不会相互连接。如果要发起连接的话,那么 client 就会向 broker 发起 消息报文MQTT 的消息报文主要分为 CONNECT 和 CONNACK 消息。 CONNECT我们上面提到了为了初始化连接,需要 client 向 broker 发送 CONNECT 消息,如果这个 CONNECT 消息格式错误或者打开套接字(因为基于 TCP/IP 协议栈需要初始化 Socket 连接)时间过长,亦或是发送连接消息时间过长的话,broker 就会关闭这条连接。 一个 MQTT 客户端发送一条 CONNECT 连接,这条 CONNECT 连接可能会包含下面这些信息: 我这里解释一下这些信息都是什么概念
在聊完 client 与 broker 之间发送建立连接的 CONNECT 消息后,我们再来聊一下 broker 需要对 CONNECT 进行确认的 CONNACK 消息。 CONNACK当 broker 收到 CONNECT 消息时,它有义务回复 CONNACK 消息进行响应。CONNACK 消息包括两部分内容
消息类型发布当 MQTT client 在连接到 broker 之后就可以发送消息了,MQTT 使用的是基于 topic 主题的过滤。每条消息都应该包含一个 topic ,broker 可以使用 topic 将消息发送给感兴趣的 client。除此之外,每条消息还会包含一个 MQTT 是数据无关性的,也就是说数据是由发布者 - publisher 决定要发送的是 XML 、JSON 还是二进制数据、文本数据。 MQTT 中的 PUBLISH 消息结构如下。
当 client 向 broker 发送消息时,broker 会读取消息,根据 Qos 的级别进行消息确认,然后处理消息。处理消息其实就是确定哪些 subscriber 订阅了 topic 并将消息发送给他们。 最初发布消息的 client 只关心将 PUBLISH 消息发送给 broker,一旦 broker 收到 PUBLISH 消息,broker 就有责任将其传递给所有 subscriber。发布消息的 client 不会知道是否有人对发布的消息感兴趣,同时也不知道多少 client 从 broker 收到了消息。 订阅client 会向 broker 发送 SUBSCRIBE 消息来接收有关感兴趣的 topic,这个 SUBSCRIBE 消息非常简单,它包含了一个唯一的数据包标识和一个订阅列表。
确认消息client 在向 broker 发送 SUBSCRIBE 消息后,为了确认每个订阅,broker 会向 client 发送 SUBACK 确认消息。这个 SUBACK 包含原始 SUBSCRIBE 消息的 packetId 和返回码列表。 其中
到现在我们已经探讨过了三种消息类型,发布 - 订阅 - 确认消息,这三种消息的示意图如下。 退订SUBSCRIBE 消息对应的是 确认退订取消订阅也需要 broker 的确认,此时 broker 会向 client 发送一个 退订和确认退订的流程如下。 当 client 收到来自 broker 的 UNSUBACK 消息后,就可以认为 UNSUBSCRIBE 消息中的订阅被删除了。 聊聊 Topic聊了这么多关于 MQTT 的内容,但是我们还没有好好聊过 Topic。在 MQTT 中,Topic 是指 broker 为每个连接的 client 过滤消息的 与传统的消息队列相比,MQTT Topic 非常轻量级,client 在发布或订阅之前不需要先创建所需要的 Topic,broker 在接收每个 Topic 前不用进行初始化操作。 通配符 当客户端订阅 Topic 时,它可以订阅已发布消息的确切 Topic,也可以使用通配符来同时订阅多个 Topic。通配符有两种:单级和多级。 单级通配符单级通配符可以替换 Topic 的一个级别, 如果 Topic 包含任意字符串而不是通配符,则任何 Topic 都能够和单级通配符匹配。例如 myhome/groundfloor/ /temperature 就有下面这几种匹配方式。 多级通配符多级通配符涵盖多个 Topic, 下面是 myhome/groundfloor/# 的几个例子 当 client 订阅带有多级通配符的 Topic 时,不论 Topic 有多长多深,它都会收到通配符之前 Topic 的所有消息。如果你只将 Topic 定义为 # 的话,那么你将会收到所有的消息。 总结这篇文章的起因是有小伙伴留言说想要了解一下 MQTT 协议,因为之前没有了解过这个协议,更别谈写了。MQTT 相当于是舒适区之外的新东西,是值得花时间研究的,这也是我写这篇文章的原因。 文中可能有写的不太好或者有勘误的地方,大家多多提出建设性意见呀~ 我们下篇文章见。 |
|