1.1概要
MQTT(Message Queuing Telemetry Transport,消息列队遥测传输)是IBM开发的一个即时通讯协议,有可能成为物联网的重要组成部分。该协议支持所有平台,几乎可以把所有联网物品和外部连接起来,被用来当做传感器和制动器的通信协议
物联网(IoT)设备必须连接互联网。通过连接到互联网,设备就能相互协作,以及与后端服务协同工作。互联网的基础网络协议是TCP/IP。MQTT(消息队列遥测传输)是基于TCP/IP协议栈而构建的,已成为IoT通信的标准
由于规范很简单,非常适合需要低功耗和网络带宽有限的IoT场景,比如:遥感数据,车联网,智能家居,智慧城市,医疗医护,智能农业。
1.2基本实现
MQTT协议要求基础传输层能够提供有序的、可靠的、双向传输的字节流,例如TCP/IP协议
客户端(Client): 使用MQTT的程序或设备,客户端通过网络连接到服务端
1.发布应用消息给其它相关的客户端
2.订阅以请求接受相关的应用消息
3.取消订阅以移除接受应用消息的请求
4.从服务端断开连接
服务端(Server/Broker): 一个程序或设备,作为发送消息客户端和订阅消息客户端之间的中介
1.接受来自客户端的网络连接
2.接受客户端发布的应用消息
3.处理客户端的订阅和取消订阅请求
4.转发应用消息给符合条件的客户端订阅
1.3设计原则
由于物联网的场景的特殊性,MQTT协议在设计和实现使遵循以下原则:
- MQTT 必须简单容易实现
2.必须支持 QoS(设备网络环境复杂)
3.必须轻量且省带宽(IoT设备环境无法保证宽带)
4.发布/订阅(Pub/Sub)模式,方便消息在传感器之间传递
5.允许用户动态创建主题,零运维成本
6.支持连续的会话控制
7.理解客户端计算能力可能很低
8.提供服务质量管理
9.假设数据不可知,不强求传输数据的类型与格式,保持灵活性
1.4订阅模式
发布订阅模式是传统 Client/Server 模式的一种解耦方案。发布者通过 Broker 与消费者之间通信,Broker 的作用是将收到的消息通过某种过滤规则,正确地发送给消费者。在 MQTT 协议里,上面提到的 过滤规则 是 Topic。比如:所有发布到 news 这个 Topic 的消息,都会被 Broker 转发给已经订阅了 news 的订阅者
上图中订阅者预先订阅了 news,然后发布者向 Broker 发布了一条消息 "some msg" 并指定发布到 news 主题,Broker 通过 Topic 匹配,决定将这条消息转发给订阅者。
MQTT 的 Topic 有层级结构,并且支持通配符 + 和 #:
- +是匹配单层的通配符。比如 news/+ 可以匹配 news/sports,news/+/basketball 可匹配到 news/sports/basketball。
- #是一到多层的通配符。比如 news/# 可以匹配 news、 news/sports、news/sports/basketball 以及 news/sports/basketball/x 等等。
MQTT 的主题是不要预先创建的,发布者发送消息到某个主题、或者订阅者订阅某个主题的时候,Broker 就会自动创建这个主题
二、MQTT控制报文结构
MQTT协议报文由三部分组成:固定报文头,可变报文头,有效荷载,报文使用大端序,文本字段编码遵循UTF-8。具体报文结构详见链接
三、MQTT QoS(服务质量)介绍
MQTT 协议 中规定了消息服务质量(Quality of Service),它保证了在不同的网络环境下消息传递的可靠性,QoS 的设计是 MQTT 协议里的重点。作为专为物联网场景设计的协议,MQTT 的运行场景不仅仅是 PC,而是更广泛的窄带宽网络和低功耗设备,如果能在协议层解决传输质量的问题,将为物联网应用的开发提供极大便利。
1、MQTT QoS 等级
MQTT 设计了 3 个 QoS 等级。
- QoS 0:消息最多传递一次,如果当时客户端不可用,则会丢失该消息。
- QoS 1:消息传递至少 1 次。
- QoS 2:消息仅传送一次。
QoS 0 是一种 "fire and forget" 的消息发送模式:Sender (可能是 Publisher 或者 Broker) 发送一条消息之后,就不再关心它有没有发送到对方,也不设置任何重发机制。
QoS 1 包含了简单的重发机制,Sender 发送消息之后等待接收者的 ACK,如果没收到 ACK 则重新发送消息。这种模式能保证消息至少能到达一次,但无法保证消息重复。
QoS 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,都是如此。因此,接收端也需要对每一条命令消息都进行应答。
3、QoS 在发布与订阅中的区别
MQTT 发布与订阅操作中的 QoS 代表了不同的含义,发布时的 QoS 表示消息发送到服务端时使用的 QoS,订阅时的 QoS 表示服务端向自己转发消息时可以使用的最大 QoS。
- 当客户端 A 的发布 QoS 大于客户端 B 的订阅 QoS 时,服务端向客户端 B 转发消息时使用的 QoS 为客户端 B 的订阅 QoS。
- 当客户端 A 的发布 QoS 小于客户端 B 的订阅 QoS 时,服务端向客户端 B 转发消息时使用的 QoS 为客户端 A 的发布 QoS。