MQTT学习笔记

Climber47

已于 2024-01-03 15:17:21 修改

阅读量952

点赞数 20

分类专栏： MQTT协议文章标签：笔记 tcp/ip mt

于 2023-11-22 18:08:33 首次发布

本文链接：https://blog.csdn.net/Ws_Te47/article/details/134559353

版权

MQTT协议专栏收录该内容

1 篇文章 0 订阅

订阅专栏

MQTT 对比 HTTP

1、MQTT 的最小报文仅为 2 个字节，比 HTTP 占用更少的网络开销。
2、MQTT 与 HTTP 都能使用 TCP 连接，并实现稳定、可靠的网络连接。
3、MQTT 基于发布订阅模型，HTTP 基于请求响应，因此 MQTT 支持双工通信。
4、MQTT 可实时推送消息，但 HTTP 需要通过轮询获取数据更新。
5、MQTT 是有状态的，但是 HTTP 是无状态的。
6、MQTT 可从连接异常断开中恢复，HTTP 无法实现此目标。

MQTT的优点

三种消息服务质量等级（Quality of Service）

QoS 0：消息最多传递一次

只管发送1次，不管收到与否
在这里插入图片描述

消息可能丢失，原因：

消息的可靠性完全依赖于底层的 TCP 协议。

而 TCP 只能保证在连接稳定不关闭的情况下消息的可靠到达，一旦出现连接关闭、重置，仍有可能丢失当前处于网络链路或操作系统底层缓冲区中的消息。

QoS 1：消息传递至少 1 次

无限制重传，保证收到，可能收多次

在这里插入图片描述

消息可能重复，原因：

1、PUBLISH 未到达接收方
2、PUBLISH 已经到达接收方，接收方的 PUBACK 报文还未到达发送方

未收到PUBACK原因
(1)、Receiver—>Broker受阻
(2)、Broker—>Sender受阻

QoS 2：消息仅传送一次。

有条件的重传，保证到达一次。

在这里插入图片描述

消息保证不重复，原因：

QoS 1 中，仅有一个PUBLISH 和 PUBREC ，用于确定是否收到，只要收到就立刻释放了Packet ID，相同的ID无法分辨是重传还是新的消息。所以遇到就都收，不敢拒收。

QoS 2 中，增加了PUBEREL和PURBCOMP报文。再上述之后，再次确认Packet ID是否可以释放、复用。所以可以确定相同ID一定是相同消息，因此可以拒收。

性能比较

0和1基本差不多，高负载情况1会稍慢。
2差不多是0、1的一半。

本部分参考自

https://www.emqx.com/zh/blog/introduction-to-mqtt-qos

MQTT工作流程

1、客户端使用 TCP/IP 协议与 Broker 建立连接，可以选择使用 TLS/SSL 加密来实现安全通信。客户端提供认证信息，并指定会话类型（Clean Session 或 Persistent Session）。

2、客户端既可以向特定主题发布消息，也可以订阅主题以接收消息。当客户端发布消息时，它会将消息发送给 MQTT Broker；而当客户端订阅消息时，它会接收与订阅主题相关的消息。

3、MQTT Broker 接收发布的消息，并将这些消息转发给订阅了对应主题的客户端。它根据 QoS 等级确保消息可靠传递，并根据会话类型为断开连接的客户端存储消息。

MQTT主题

主题通配符

单层通配符

+：表示单层通配符，例如 a/+ 匹配 a/x 或 a/y。
eg：

+ 有效
sensor/+ 有效
sensor/+/temperature 有效
sensor+ 无效（没有占据整个层级）

多层通配符

#：表示多层通配符，例如 a/# 匹配 a/x、a/b/c/d。

# 有效，匹配所有主题
sensor/# 有效
sensor/bedroom# 无效（没有占据整个层级）
sensor/#/temperature 无效（不是主题最后一个字符）

$开头的主题

系统主题

以 $SYS/ 开头的主题为系统主题
eg：

主题	说明
$SYS/brokers	EMQX 集群节点列表
$SYS/brokers/emqx@127.0.0.1/version	EMQX 版本
$SYS/brokers/emqx@127.0.0.1/uptime	EMQX 运行时间
$SYS/brokers/emqx@127.0.0.1/datetime	EMQX 系统时间
$SYS/brokers/emqx@127.0.0.1/sysdescr	EMQX 系统信息

举例

在这里插入图片描述

共享订阅

即时消息

常见的 MQTT 主题使用建议有哪些？

1、不建议使用 # 订阅所有主题；
2、不建议主题以 / 开头或结尾，例如 /chat 或 chat/；
3、不建议在主题里添加空格及非 ASCII 特殊字符；
4、同一主题层级内建议使用下划线 _ 或横杆 - 连接单词（或者使用驼峰命名）；
5、尽量使用较少的主题层级；
6、当使用通配符时，将唯一值的主题层（例如设备号）越靠近第一层越好。例如，device/00000001/command/# 比device/command/00000001/# 更好。

MQTT共享订阅

带群组的共享订阅

在这里插入图片描述

不带群组的共享订阅

在这里插入图片描述

共享订阅的负载均衡策略

即，共享订阅的几个设备之间，消息发给谁。

1、随机（Random），在共享订阅组内随机选择一个会话发送消息。
2、轮询（Round Robin），在共享订阅组内按顺序选择一个会话发送消息，循环往复。
3、哈希（Hash），基于某个字段的哈希结果来分配。
4、粘性（Sticky），在共享订阅组内随机选择一个会话发送消息，此后保持这一选择，直到该会话结束再重复这一过程。
5、本地优先（Local），随机选择，但优先选择与消息的发布者处于同一节点的会话，如果不存在这样的会话，则退化为普通的随机策略。

举例

这个地方我搜了半天网上没找到通俗的，期待大佬指正指路。

1、一个自己想的不一定对的

共享家居，一个温度传感器，有2个手机、2个主控需要接受数据。因为对温度实时性要求不高，所以随机、轮转应该都可以。

2、来自GPT4，感觉不理解不知道对不对。。。

随机（Random）策略：
应用场景：假设有多个智能灯泡连接到同一个智能家居系统。当用户通过智能家居App发送一个“关闭所有灯泡”的指令时，系统可以使用随机策略随机选择一个在线的智能灯泡会话来传递关闭指令，因为实际上关闭任何一个灯泡的指令都是相同的。

轮询（Round Robin）策略：
应用场景：在一个有多个空调的房间中，为了均匀分摊空调的使用时间和维护成本，智能家居系统可能会使用轮询策略来依次控制每台空调的开关，确保每台空调都有均等的工作时间。

哈希（Hash）策略：
应用场景：智能家居系统中的多个音响可能需要根据房间的位置播放不同的音乐。系统可以根据房间号（或其他唯一标识符）的哈希值将播放指令发送到对应的音响，保证每个房间都能播放适当的音乐。

粘性（Sticky）策略：
应用场景：假设智能家居系统中的安防摄像头需要发送定期的状态更新。系统可以为每个摄像头分配一个会话，并使用粘性策略在摄像头的生命周期内维持这个会话，确保状态更新始终通过同一通道发送，直到摄像头关闭或会话结束。

本地优先（Local）策略：
应用场景：在分布式智能家居系统中，如果有多个中心节点，每个节点管理着不同的设备群组。一个节点可能需要向其他节点发送数据，但如果目标设备与发送者在同一节点下，系统会使用本地优先策略。这样可以减少网络延迟，提高效率。例如，如果节点A和节点B都有智能窗帘，当节点A收到关闭所有窗帘的指令时，它会优先关闭自己节点下的窗帘，然后再将指令通过网络发送给节点B。