MQTT协议介绍及EMQX安装部署

大猩猩爱分享

已于 2022-08-20 14:35:00 修改

阅读量1.2k

点赞数 2

分类专栏：中间件文章标签：网络 mqtt emqx

于 2022-08-20 14:31:24 首次发布

本文链接：https://blog.csdn.net/xrq1995/article/details/126439175

版权

中间件专栏收录该内容

13 篇文章 0 订阅

订阅专栏

一、MQTT协议介绍

1、概览

MQTT是一个轻量的发布订阅模式消息传输协议，专门针对低带宽和不稳定网络环境的物联网应用设计。
MQTT官网: http://mqtt.org(opens new window)
MQTT V3.1.1协议规范: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.htm

2、特点

开放消息协议，简单易实现
发布订阅模式，一对多消息发布
基于TCP/IP网络连接
1字节固定报头，2字节心跳报文，报文结构紧凑
消息QoS支持，可靠传输保证

3、应用

MQTT协议广泛应用于物联网、移动互联网、智能硬件、车联网、电力能源等领域。
物联网M2M通信，物联网大数据采集
Android消息推送，WEB消息推送
移动即时消息，例如Facebook Messenger
智能硬件、智能家具、智能电器
车联网通信，电动车站桩采集
智慧城市、远程医疗、远程教育
电力、石油与能源等行业市场

4、MQTT基于主题(Topic)消息路由

MQTT协议基于主题(Topic)进行消息路由，主题(Topic)类似URL路径，例如:

chat/room/1

sensor/10/temperature

sensor/+/temperature

$SYS/broker/metrics/packets/received

$SYS/broker/metrics/#

主题(Topic)通过'/'分割层级，支持'+', '#'通配符:

1 2	`'+': 表示通配一个层级，例如a/+，匹配a/x, a/y` `'#': 表示通配多个层级，例如a/#，匹配a/x, a/b/c/d`

订阅者与发布者之间通过主题路由消息进行通信，例如采用mosquitto命令行发布订阅消息:

1 2	`mosquitto_sub -t a/b/+ -q 1` `mosquitto_pub -t a/b/c` `-m hello -q 1`

订阅者可以订阅含通配符主题，但发布者不允许向含通配符主题发布消息。

5、MQTT V3.1.1协议报文

报文结构

固定报头(Fixed header)
可变报头(Variable header)
报文有效载荷(Payload)

固定报头

+----------+-----+-----+-----+-----+-----+-----+-----+-----+

| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |

+----------+-----+-----+-----+-----+-----+-----+-----+-----+

| byte1 | MQTT Packet type | Flags |

+----------+-----------------------+-----------------------+

| byte2... | Remaining Length |

+----------+-----------------------------------------------+

报文类型


类型名称	类型值	报文说明
CONNECT	1	发起连接
CONNACK	2	连接回执
PUBLISH	3	发布消息
PUBACK	4	发布回执
PUBREC	5	QoS2消息回执
PUBREL	6	QoS2消息释放
PUBCOMP	7	QoS2消息完成
SUBSCRIBE	8	订阅主题
SUBACK	9	订阅回执
UNSUBSCRIBE	10	取消订阅
UNSUBACK	11	取消订阅回执
PINGREQ	12	PING请求
PINGRESP	13	PING响应
DISCONNECT	14	断开连接

PUBLISH发布消息

PUBLISH报文承载客户端与服务器间双向的发布消息。 PUBACK报文用于接收端确认QoS1报文，PUBREC/PUBREL/PUBCOMP报文用于QoS2消息流程。

PINGREQ/PINGRESP心跳

客户端在无报文发送时，按保活周期(KeepAlive)定时向服务端发送PINGREQ心跳报文，服务端响应PINGRESP报文。PINGREQ/PINGRESP报文均2个字节。

MQTT消息QoS

MQTT发布消息QoS保证不是端到端的，是客户端与服务器之间的。订阅者收到MQTT消息的QoS级别，最终取决于发布消息的QoS和主题订阅的QoS。

发布消息的 QoS	主题订阅的 QoS	接收消息的 QoS
0	0	0
0	1	0
0	2	0
1	0	0
1	1	1
1	2	1
2	0	0
2	1	1
2	2	2

QoS 0 - 最多分发一次

当 QoS 为 0 时，消息的分发依赖于底层网络的能力。发布者只会发布一次消息，接收者不会应答消息，发布者也不会储存和重发消息。消息在这个等级下具有最高的传输效率，但可能送达一次也可能根本没送达。

Qos 1 - 至少分发一次

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

QoS 2 - 只分发一次

当 QoS 为 2 时，发布者和订阅者通过两次会话来保证消息只被传递一次，这是最高等级的服务质量，消息丢失和重复都是不可接受的。使用这个服务质量等级会有额外的开销。

发布者发布 QoS 为 2 的消息之后，会将发布的消息储存起来并等待接收者回复 PUBREC 的消息，发送者收到 PUBREC 消息后，它就可以安全丢弃掉之前的发布消息，因为它已经知道接收者成功收到了消息。发布者会保存 PUBREC 消息并应答一个 PUBREL，等待接收者回复 PUBCOMP 消息，当发送者收到 PUBCOMP 消息之后会清空之前所保存的状态。

当接收者接收到一条 QoS 为 2 的 PUBLISH 消息时，他会处理此消息并返回一条 PUBREC 进行应答。当接收者收到 PUBREL 消息之后，它会丢弃掉所有已保存的状态，并回复 PUBCOMP。

无论在传输过程中何时出现丢包，发送端都负责重发上一条消息。不管发送端是 Publisher 还是 Broker，都是如此。因此，接收端也需要对每一条命令消息都进行应答。