物联网通信消息队列客户端-MQTT简介

简介: 物联网通信消息队列客户端-MQTT简介

1. MQTT简介

MQTT(MessageQueuingTelemetryTransport,消息队列遥测传输协议)是一种基于发布/订阅(publish/subscribe)模式的“轻量级”通讯协议,该协议构建于TCP/IP协议上,由IBM在1999年发布。

MQTT最大优点在于,作为一种低开销、低带宽占用的即时通讯协议,可以以极少的代码和有限的带宽,为连接远程设备提供实时可靠的消息服务。使其在物联网、小型设备、移动应用等方面有较广泛的应用。


TCP/IP参考模型可以分为四层:应用层、传输层、网络层、链路层。TCP和UDP位于传输层,应用层常见的协议有HTTP、FTP、SSH等。**MQTT**协议运行于**TCP****之上,属于应用层协议,**因此只要是支持TCP/IP协议栈的地方,都可以使用MQTT。

2. MQTT特性

对负载内容屏蔽的消息传输;


使用TCP/IP提供网络连接;


小型传输,开销很小(固定长度的头部是2字节),协议交换最小化,以降低网络流量;


使用LastWill和Testament特性(最后遗嘱)通知有关各方客户端异常中断的机制。

3. MQTT术语

3.1 应用消息ApplicationMessage

  • MQTT协议通过网络传输应用数据;
  • 应用消息通过MQTT传输时,它们有关联的服务质量(QoS)和主题(Topic)。

3.2 客户端Client

使用MQTT的程序或设备。客户端总是通过网络连接到服务端。它可以:

  • 发布应用消息给其它相关的客户端;
  • 订阅以请求接受相关的应用消息;
  • 取消订阅以移除接受应用消息的请求;
  • 从服务端断开连接。

3.3 服务端Server

一个程序或设备,作为发送消息的客户端和请求订阅的客户端之间的中介。它可以:

  • 服务端接受来自客户端的网络连接;
  • 接受客户端发布的应用消息;
  • 处理客户端的订阅和取消订阅请求;
  • 转发应用消息给符合条件的已订阅客户端。

3.4 订阅Subscription

  • 订阅包含一个主题过滤器(TopicFilter)和一个最大的服务质量(QoS)等级;
  • 订阅与单个会话(Session)关联;
  • 会话可以包含多于一个的订阅。会话的每个订阅都有一个不同的主题过滤器。

3.5 主题名TopicName

  • 附加在应用消息上的一个标签,服务端已知且与订阅匹配;
  • 服务端发送应用消息的一个副本给每一个匹配的客户端订阅。

3.6 主题过滤器TopicFilter

  • 订阅中包含的一个表达式,用于表示相关的一个或多个主题;
  • 主题过滤器可以使用通配符。

3.7 会话Session

  • 客户端和服务端之间的状态交互;
  • 一些会话持续时长与网络连接一样,另一些可以在客户端和服务端的多个连续网络连接间扩展。

3.8 控制报文MQTTControlPacket

  • 通过网络连接发送的信息数据包;
  • MQTT规范定义了十四种不同类型的控制报文,其中一个(PUBLISH报文)用于传输应用消息。

4. 什么是主题

MQTT协议通过网络传输应用消息,应用消息通过MQTT传输时,它们有关联的服务质量(QoS)和主题(Topic)。主题本质上是一个字符串,MQTT协议规定主题是UTF-8编码的字符串,这意味着,主题过滤器和主题名的比较可以通过比较编码后的UTF-8字节或解码后的Unicode字符。

4.1 主题名和主题过滤器

4.1.1 主题名

  • 附加在应用消息上的一个标签,服务端已知且与订阅匹配。
  • 服务端发送应用消息的一个副本给每一个匹配的客户端订阅。

4.1.2 主题过滤器

订阅中包含的一个表达式,用于表示相关的一个或多个主题。主题过滤器可以使用通配符。

如果订阅的主题过滤器与消息的主题名匹配,应用消息会被发送给每一个匹配的客户端订阅。

主题资源可以是管理员在服务端预先定义好的,也可以是服务端收到第一个订阅或使用那个主题名的应用消息时动态添加的。

服务端可以使用一个安全组件有选择地授权客户端使用某个主题资源。

4.2 主题和主题过滤器命名的规则

MQTT协议中规定了主题是一段UTF-8编码的字符串,主题需要满足以下规则:


所有的主题名和主题过滤器必须至少包含一个字符。

主题名和主题过滤器是大小写敏感的。ACCOUNTS和Accounts是不同的主题名。

主题名和主题过滤器可以包含空格字符。Accountspayable是合法的主题名

主题名或主题过滤器以前置或后置斜杠/区分。/finance和finance是不同的。


只包含斜杠/的主题名或主题过滤器是合法的。


主题名和主题过滤器不能包含null字符(UnicodeU+0000)。


主题名和主题过滤器是UTF-8编码字符串,除了不能超过UTF-8编码字符串的长度限制之外,主题名或主题过滤器的层级数量没有其它限制。

4.3 主题层级

4.3.1 主题层级分隔符

斜杠(“/”U+002F)用于分割主题的每个层级,为主题名提供一个分层结构。分隔符用于将结构化引入主题名。如果存在分隔符,它将主题名分割为多个主题层级,是消息主题层级设计中很重要的符号。比方说:aaa/bbb、aaa/bbb/ccc和aaa/bbb/ccc/ddd这样的消息主题格式,是一个层层递进的关系,可通过多层通配符同时匹配两者,或者单层通配符只匹配一个。这在现实场景中,可以应用到:公司的部门层级推送、国家城市层级推送等包含层级关系的场景。


MQTT订阅报文包含一个主题过滤器(TopicFilter)和一个最大的服务质量(QoS)等级。订阅的主题过滤器可以包含特殊的通配符,允许客户端一次订阅多个主题。当客户端订阅指定的主题过滤器包含两种通配符时,主题层级分隔符就很有用了。主题层级分隔符可以出现在主题过滤器或主题名字的任何位置。相邻的主题层次分隔符表示一个零长度的主题层级。


主题过滤器中可以使用通配符,但是主题名不能使用通配符。单层通配符和多层通配符只能用于订阅(subscribe)消息而不能用于发布(publish)消息,层级分隔符两种情况下均可使用。

4.3.2 多层通配符

井字符号(“#”U+0023)是用于匹配主题中任意层级的通配符。多层通配符表示它的父级和任意数量的子层级。


例如,如果客户端订阅主题sport/tennis/player1/#,它会收到使用下列主题名发布的消息:


sport/tennis/player1

sport/tennis/player1/ranking

sport/tennis/player1/score/wimbledon

因为多层通配符包括它自己的父级,所以sport/#也匹配单独的sport主题名,sport/tennis/player1/#也可以匹配sport/tennis/player1。


单独的多层通配符#是有效的,它会收到所有的应用消息。


多层通配符必须单独指定,或者跟在主题层级分隔符后面。多层通配符必须是主题过滤器的最后一个字符。因此,sport/tennis#和sport/tennis/#/ranking都是无效的多层通配符。

4.3.3 单层通配符

加号(“+”U+002B)是只能用于单个主题层级匹配的通配符。例如,sport/tennis/+匹配sport/tennis/player1和sport/tennis/player2,但是不匹配sport/tennis/player1/ranking。同时,由于单层通配符只能匹配一个层级,sport/+不匹配sport但是却匹配sport/。


在主题过滤器的任意层级都可以使用单层通配符,包括第一个和最后一个层级,可以在主题过滤器中的多个层级中使用它,也可以和多层通配符一起使用,+、+/tennis/#、sport/+/player1都有有效的。在使用单层通配符时,单层通配符占据过滤器的整个层级,sport+是无效的。

4.3.4 以\$开头的主题

服务端不能将$字符开头的主题名匹配通配符(#或``+)开头的主题过滤器,订阅#的客户端不会收到任何发布到以$开头主题的消息,订阅+/monitor/Clients的客户端也不会收到任何发布到$SYS/monitor/Clients的消息。服务端应该阻止客户端使用这种主题名与其他客户端交换消息,客户端注意不能使用$字符开头的主题。


服务端实现可以将$开头的主题名用作其他目的。,例如$SYS/被广泛用作包含服务器特定信息或控制接口的主题的前缀。订阅$SYS/#的客户端会收到发布到以$SYS/开头主题的消息,订阅$SYS/monitor/+的客户端会收到发布到$SYS/monitor/Clients主题的消息,如果客户端想同时接受以$SYS/开头主题的消息和不以KaTeX parse error: Expected 'EOF', got '#' at position 17: …头主题的消息,它需要同时订阅`#̲`和`SYS/#`。

4.3.5 举个例子

比如我们用传感器监视家里的卧室、客厅以及厨房的温度、湿度和空气质量,可以设计一下几个主题:


myhome/bedroom/temperature

myhome/bedroom/humidity

myhome/bedroom/airquality

myhome/livingroom/temperature

myhome/livingroom/humidity

myhome/livingroom/airquality

myhome/kitchen/temperature

myhome/kitchen/humidity

myhome/kitchen/airquality

当我们想获取卧室的所有数据时,可以订阅myhome/bedroom+主题,当我们想获取三个房间的温度数据的时候,可以订阅myhome/+/temperature主题,当我们想获取所有的数据的时候,可以订阅myhome/#或者#

5. 消息服务质量

5.1 QoS0,At most once,至多一次;

5.2 QoS1,At least once,至少一次;

5.3 QoS 2,Exactly once,确保只有一次。

PUBREC消息

发布收到。是对QoS级别为2的PUBLISH消息的响应。它是QoS级别2协议流的第二个消息。PUBREC消息由服务器响应来自发布端的PUBLISH消息,或订阅端响应来自服务器的PUBLISH消息。发布端或服务器收到PUBREC消息时,会响应PUBREL消息。


PUBREL消息

发布释放。是从发布端对PUBREC的响应,或从服务器对订阅端PUBREC消息的响应。这是QoS级别2协议流中第三个消息。当服务器从发布者收到PUBREL消息时,服务器会将PUBLISH消息发送到订阅端,并发送PUBCOMP消息到发布端。当订阅端收到来自服务器的消息PUBREL时,使得消息可用于应用程序并将PUBCOMP消息发送到服务器。


PUBCOMP消息

发布完成。是服务器对来自发布端的PUBREL消息的响应,或订阅者对来自服务器的PUBREL消息的响应。它是QoS级别2协议流程中的第四个也是最后一个消息。当发布端收到PUBCOMP消息时,它会丢弃原始消息,因为它已经将消息发给了服务器。

5.4 特别注意

需要注意的是MQTT发布与订阅操作中的QoS代表了不同的含义:


发布时的QoS表示消息发送到MQTT服务器使用的QoS等级;


订阅时的QoS表示MQTTBroker向自己转发消息时可以使用的最大QoS等级。


需要保障发送与订阅的**QoS**一致,才能确保最终收到的消息是固定的**QoS**等级,否则会出现消费降级的情况。例如:A发送的消息QoS为2,B订阅的消息QoS为1,则最终接收到消息的QoS为1。

6. 保留消息和最后遗嘱

6.1 保留消息

RetainedMessages。MQTT中,无论是发布还是订阅都不会有任何触发事件。1个Topic只有唯一的retain消息,Broker会保存每个Topic的最后一条retain消息。发布消息时把retain设置为true,即为保留信息。每个Client订阅Topic后会立即读取到retain消息。如果需要删除retain消息,可以发布一个空的retain消息,因为每个新的retain消息都会覆盖最后一个retain消息。

6.2 最后遗嘱

LastWill&Testament。MQTT本身就是为信号不稳定的网络设计的,所以难免一些客户端会无故的和Broker断开连接。当客户端连接到Broker时,可以指定LWT,Broker会定期检测客户端是否有异常。当客户端异常掉线时,Broker就往连接时指定的Topic里推送当时指定的LWT消息。

相关实践学习
钉钉群中如何接收IoT温控器数据告警通知
本实验主要介绍如何将温控器设备以MQTT协议接入IoT物联网平台,通过云产品流转到函数计算FC,调用钉钉群机器人API,实时推送温湿度消息到钉钉群。
阿里云AIoT物联网开发实战
本课程将由物联网专家带你熟悉阿里云AIoT物联网领域全套云产品,7天轻松搭建基于Arduino的端到端物联网场景应用。 开始学习前,请先开通下方两个云产品,让学习更流畅: IoT物联网平台:https://iot.console.aliyun.com/ LinkWAN物联网络管理平台:https://linkwan.console.aliyun.com/service-open
目录
相关文章
|
16小时前
|
消息中间件 存储 监控
消息队列通信的优缺点
【10月更文挑战第29天】消息队列通信具有诸多优点,如解耦性强、异步通信、缓冲削峰等,能够有效地提高系统的灵活性、可扩展性和稳定性。但同时也存在一些缺点,如系统复杂性增加、性能开销、数据一致性挑战和实时性受限等。在实际应用中,需要根据具体的业务需求和场景,权衡其优缺点,合理地选择和使用消息队列通信机制,以实现系统的高效运行和优化。
|
16小时前
|
消息中间件 存储 供应链
进程间通信方式-----消息队列通信
【10月更文挑战第29天】消息队列通信是一种强大而灵活的进程间通信机制,它通过异步通信、解耦和缓冲等特性,为分布式系统和多进程应用提供了高效的通信方式。在实际应用中,需要根据具体的需求和场景,合理地选择和使用消息队列,以充分发挥其优势,同时注意其可能带来的复杂性和性能开销等问题。
|
4月前
|
消息中间件 Java C语言
消息队列 MQ使用问题之在使用C++客户端和GBase的ESQL进行编译时出现core dump,该怎么办
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
|
12天前
|
网络协议 物联网 网络性能优化
物联网协议比较 MQTT CoAP RESTful/HTTP XMPP
【10月更文挑战第18天】本文介绍了物联网领域中四种主要的通信协议:MQTT、CoAP、RESTful/HTTP和XMPP,分别从其特点、应用场景及优缺点进行了详细对比,并提供了简单的示例代码。适合开发者根据具体需求选择合适的协议。
36 5
|
2月前
|
网络协议 物联网 网络性能优化
物联网江湖风云变幻!MQTT CoAP RESTful/HTTP XMPP四大门派谁主沉浮?
【9月更文挑战第3天】物联网(IoT)的兴起催生了多种通信协议,如MQTT、CoAP、RESTful/HTTP和XMPP,各自适用于不同场景。本文将对比这些协议的特点、优缺点,并提供示例代码。MQTT轻量级且支持QoS,适合大规模部署;CoAP基于UDP,适用于低功耗网络;RESTful/HTTP易于集成但不适合资源受限设备;XMPP支持双向通信,适合复杂交互应用。通过本文,开发者可更好地选择合适的物联网通信协议。
37 2
|
3月前
|
网络协议 物联网 网络性能优化
物联网江湖风云变幻!MQTT CoAP RESTful/HTTP XMPP四大门派谁主沉浮?
【8月更文挑战第14天】本文概览了MQTT、CoAP、RESTful/HTTP及XMPP四种物联网通信协议。MQTT采用发布/订阅模式,轻量高效;CoAP针对资源受限设备,基于UDP,低延迟;RESTful/HTTP易于集成现有Web基础设施;XMPP支持双向通信,扩展性强。每种协议均附有示例代码,助您根据不同场景和设备特性作出最佳选择。
35 5
|
3月前
|
物联网 C# 智能硬件
智能家居新篇章:WPF与物联网的智慧碰撞——通过MQTT协议连接与控制智能设备,打造现代科技生活的完美体验
【8月更文挑战第31天】物联网(IoT)技术的发展使智能家居设备成为现代家庭的一部分。通过物联网,家用电器和传感器可以互联互通,实现远程控制和状态监测等功能。本文将探讨如何在Windows Presentation Foundation(WPF)应用中集成物联网技术,通过具体示例代码展示其实现过程。文章首先介绍了MQTT协议及其在智能家居中的应用,并详细描述了使用Wi-Fi连接方式的原因。随后,通过安装Paho MQTT客户端库并创建MQTT客户端实例,演示了如何编写一个简单的WPF应用程序来控制智能灯泡。
94 0
|
3月前
|
物联网 网络性能优化 Python
"掌握MQTT协议,开启物联网通信新篇章——揭秘轻量级消息传输背后的力量!"
【8月更文挑战第21天】MQTT是一种轻量级的消息传输协议,以其低功耗、低带宽的特点在物联网和移动应用领域广泛应用。基于发布/订阅模型,MQTT支持三种服务质量级别,非常适合受限网络环境。本文详细阐述了MQTT的工作原理及特点,并提供了使用Python `paho-mqtt`库实现的发布与订阅示例代码,帮助读者快速掌握MQTT的应用技巧。
69 0
|
3月前
|
安全 网络性能优化
MQTT 客户端 MQTT.fx 使用说明
MQTT 客户端 MQTT.fx 使用说明
331 0
|
4月前
|
消息中间件 JavaScript Linux
消息队列 MQ操作报错合集之客户端在启动时遇到了连接错误,是什么原因
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。

相关产品

  • 云消息队列 MQ