- 客户端 (Client):使用 MQTT 协议的程序或设备。
- 服务器(Server):在发送消息的客户端与已订阅的客户端之间充当中介角色的程序或设备。
- 会话(Session):每个客户端与服务器建立连接后就是一个会话,客户端和服务器之间有状态交互。
- 订阅(Subscription):订阅包含一个主题过滤器(Topic Filter)和一个最大的服务质量(QoS)等级。订阅与单个会话(Session)关联。会话可以包含多于一个的订阅。会话的每个订阅都有一个不同的主题过滤器。
- 主题名(Topic Name):附加在应用消息上的一个标签,被用于匹配服务端已存在的订阅。服务端会向所有匹配订阅的客户端发送此应用消息。
- 主题过滤器(Topic Filter):仅在订阅时使用的主题表达式,可以包含通配符,以匹配多个主题名。
- 载荷(Payload):对于 PUBLISH 报文来说载荷就是业务消息,它可以是任意格式(二进制、十六进制、普通字符串、JSON 字符串、Base64)的数据。消息订阅者所具体接收的内容。
3. 为什么使用MQTT
3.1. 发布订阅模式
发布订阅模式是传统 Client/Server 模式的一种解耦方案。
发布者通过Broker与消费者之间通信,Broker的作用是将收到的消息通过某种过滤规则
,正确地发送给消费者。
发布/订阅模式 相对于 客户端/服务器模式 的好处在于:
- 发布者和消费者之间不必预先知道对方的存在,比如不需要预先沟通对方的 IP Address 和 Port
- 发布者和消费者之间不必同时运行。因为 Broker 是一直运行的。
4. MQTT应用场景
5. MQTT设计原则
必须支持 QoS(设备网络环境复杂)。
必须轻量且省带宽(因为那时候带宽很贵)。
必须数据无关(不关心 Payload 数据格式)。
必须有持续地会话感知能力(时刻知道设备是否在线)。
5.1 QoS
QoS是网络的一种安全机制, 是用来解决网络延迟和阻塞等问题的一种技术。
QoS中译:质量服务
质量:通讯质量,即 “消息的可靠性”。
服务:保证消息可靠的机制。
QoS等级1:至少0次,只管发,不管收。
QoS等级2:至少1次。
QoS等级3:刚好1次,保证相同的消息只接收一条。
5.2 Topic
上面提到的 过滤规则
是 Topic
。
MQTT 的 Topic 有层级结构,并且支持通配符 +
和 #
:
+
是匹配单层的通配符。比如news/+
可以匹配news/sports
,news/+/basketball
可匹配到news/sports/basketball
。#
是一到多层的通配符。比如news/#
可以匹配news
、news/sports
、news/sports/basketball
以及news/sports/basketball/x
等等。
MQTT的主题是不要预先创建的,发布者发送消息到某个主题、或者订阅者订阅某个主题的时候,Broker 就会自动创建这个主题。
5.3 带宽消耗最小化
MQTT协议将协议本身占用的额外消耗最小化,消息头部最小只需要占用 2 个字节。
MQTT协议是应用层协议,需要借助TCP/IP协议进行传输,类似HTTP协议。
5.4 MQTT的消息格式
消息格式 | |
---|---|
固定长度头部,2 个字节 | MQTT协议分很多种类型,如连接,发布,订阅,心跳等。所有消息类型里都有。 |
可变长度头部 | 可变头部不是可选的意思,而是指这部分在有些协议类型中存在,在有些协议中不存在。 |
Payload消息载体 | 就是消息内容。与可变头一样,在有些协议类型中有消息内容,有些协议类型中没有消息内容。 |
- 固定头包含两部分内容,首字节(字节1)和剩余消息报文长度(1-4字节)。
- 可变头部在固定头部和消息内容之间,其内容根据报文类型不同而不同。
- Payload意思是消息载体的意思,如PUBLISH的Payload就是指消息内容。而CONNECT的Payload则包含Client Identifier,Will Topic,Will Message,Username,Password等信息。
报文类型 | 数据方向 | 描述 | 包含可变头 | 包含Payload |
---|---|---|---|---|
Reserved | 禁止 | 保留 | ||
CONNECT | 客户端向服务端 | 客户端连接请求服务端 | YES | |
CONNACK | 服务端到客户端 | 连接报文确认 | ||
PUBLISH | 两个方向都允许 | 发布消息 | YES(QoS>0) | 可选 |
PUBACK | 两个方向都允许 | QoS 1消息发布收到确认 | YES | |
PUBREC | 两个方向都允许 | 发布收到(保证交付第一步) | YES | |
PUBAEL | 两个方向都允许 | 发布释放(保证交付第二步) | YES | |
PUBCOMP | 两个方向都允许 | QoS 2消息发布完成(保证交付第三步) | YES | |
SUBSCRIBE | 客户端向服务端 | 客户端订阅请求 | YES | YSE |
SUBACK | 服务端向客户端 | 订阅请求报文确认 | YES | YES |
UNSUBSCRIBE | 客户端到服务端 | 客户端取消订阅请求 | YES | YES |
UNSUBACK | 服务端到客户端 | 取消订阅报文确认 | YES | |
PINGREQ | 客户端到服务端 | 心跳请求 | ||
PINGRESP | 客户端到客户端 | 心跳响应 | ||
DISCONNECT | 客户端到服务端 | 客户端断开连接 | ||
Reserved | 禁止 | 保留 |
5.5 会话保持
MQTT 没有假设设备或 Broker 使用了 TCP 的保活机制,而是设计了协议层的保活机制。
在 CONNECT 报文里可设置 Keepalive 字段,来设置保活心跳包 PINGREQ/PINGRESP 的发送时间间隔。
当长时间无法收到设备的 PINGREQ 的时候,Broker 就会认为设备已经下线。
总的来说,Keepalive 有两个作用:
最后
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Java工程师,想要提升技能,往往是自己摸索成长,自己不成体系的自学效果低效漫长且无助。
因此收集整理了一份《2024年嵌入式&物联网开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上嵌入式&物联网开发知识点,真正体系化!
如果你觉得这些内容对你有帮助,需要这份全套学习资料的朋友可以戳我获取!!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新!!
伙伴深入学习提升的进阶课程,基本涵盖了95%以上嵌入式&物联网开发知识点,真正体系化!**
如果你觉得这些内容对你有帮助,需要这份全套学习资料的朋友可以戳我获取!!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新!!