4_4_MQTT 协议讲解|学习笔记

开发者学堂课程【HaaS 物联网应用开发课程：4_4_MQTT 协议讲解】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/801/detail/13838

4_4_MQTT 协议讲解

 

内容介绍：

一、MQTT 基本介绍

二、MQTT 协议细节

 

一、MQTT 基本介绍

1. MQTT 简介

MQTT ( Message Queuing Telemetry Transport，消息队列遥测传输协议），是一种基于发布/订阅 ( publish/subscribe )模式的"轻量级"通讯协议，该协议构建于 TCP/IP 协议上，由 IBM 在1999年发布。MQTT 最大优点在于，可以以极少的代码和有限的带宽，为连接远程设备提供实时可靠的消息服务。作为一种低开销、低带宽占用的即时通讯协议，使其在物联网、小型设备、移动应用等方面有较广泛的应用。

如图，MQTT 作为左侧发布端，通过 MQTT Broker 发送给右侧订阅端。

2. 物联网常见协议介绍

物联网最常用的协议主要有下面两种:

MQTT (Message Queuing Telemetry Transport，消息队列遥测传输)

·最早由 IBM 开发的，专门为计算能力有限，工作在低带宽，不可靠网络的控制设备进行通信而设计的

·基于 TCP/IP，开销小，支持 QoS

·常连接，支持多对多的协议

COAP (Constrained Application Protocol，受限制的应用协议)·基于 UDP，采用请求响应的工作模式

·无连接，只支持一对一

一般 loT 与云端通信用 MQTT 协议要多一些，局域网通信一般采用 CoAP 协议

其余常用的网络通信协议，如 http，https 等协议很复杂，对计算能力要求较高，不适合计算能力有限的 loT 设备，在 loT 领域应用相对比较少

3.MQTT 和 COAP 帧结构介绍

Payload length <128时

- payload 占比为 payload/(payload + variable header +3)

-在 variable header=0时，payload 占比介于25%~97.7%

Payload length <128时

- payload 占比为 payload/(4 + token + options 1 + payload)

-在 tokenloptions 长度为0时，payload 占比介于20%~96.2%

图中可以看出 MQTT 帧结构和 CoAP 帧结构中头部占比相对较少。MQTT 头部占用有固定两个字节和可变字节。

loT 设备跟云端进行交互的消息一般都比较短，HTTPHTTPS 协议头部少则几十多则上百字节，传输效率相比MQTT/CoAP 低太多。

 

二、MQTT 协议细节

1.MQTT 主要特点

MQTT 最早设计用于监控穿越沙漠中的油管的监控状况其主要特点如下:

·基于 TCP 长连接

·使用发布者/订阅者的模式，提供一对多的消息发布·构建并提供底层传输通道，不关心负载内容

·QoS 支持“至少一次”，“至多一次”，“只有一次”三种不同的模式

·开销很小(固定字节的头部只有2个 Byte)

截止目前，MQTT 有三个版本，3.1.0，3.1.1和最新的5.0版本，5.0版本也已经被纳入 OASIS 标准

2.MQTT 模式与角色

一种模式:发布者/订阅者模式

三种角色:发布者、代理服务器、订阅者

发布者/订阅者模式:

分为发布者(Publish)、代理（Broker）服务器、订阅者(Subscribe）三种角色

消息的发布者和订阅者都是客户端，消息代理是服务器，消息发布者也可以同时是订阅者。

客户端和服务器的两种角色

·客户端

·MQTT 连线的发起者

·发布消息供到其它订阅者订阅的主题

·订阅/退订主题（用于接收其它客户端向该主题发布的消息)服务器

·接收来自客户端的连线请求

·接收客户端的的订阅/退订主题需求向订阅的客户端转发其订阅主题的消息

3. MQTT 模式与角色举例

图中空调既是发布者又是订阅者，发布状态信息，订阅温度、定时等控制指令。所有信息都会以中间 MQTT Broker作为中介来传输。当作为发布者时，状态信息通过 MQTT Broker 发送给订阅者监控面板。如果想人为控制空调，可以通过上报信息实施控制。比如温度定时等控制指令，通过 MQTT Broker 发送给空调，从而完成整个数据通信。

完成这个模式需要协议内部的帧来完成。

 4. MQTT 数据帧类型

其中 CONNECT、CONNACK、SUBSCRIBE、SUBACK、PUBLISH、PUBACK、PINGREQ、PINGRESP 使用较多。

应用场景可以 MQTT QOS 机制来看。

5. MQTT QOS 机制

MQTT 传输的消息分为:主题和负载两部分

·主题(Topic)

·消息的类型，订阅者订阅(Subscribe）一个主题后，就会收到该主题的消息内容(payload)

·负载( payload)

·消息的内容，是指订阅者具体要使用的内容

MQTT 会构建底层网络传输:它将建立客户端到服务器的连接，提供两者之间的一个有序的、无损的、基于字节流的双向传输。MQTT 协议中规定了消息服务质量（Quality of Service)，它保证了在不同的网络环境下消息传递的可靠性。

MQTT 设计了3个 QoS 等级。

QoS 0:消息最多传递一次，如果当时客户端不可用，则会丢失该消息。QoS 1:消息传递至少1次。

QoS 2:消息仅传送一次。

Qos O是:Sender (可能是Publisher或者Broker)发送一条消息之后，就不再关心它有没有发送到对方，也不设置任何重发机制。QoS1包含了简单的重发机制，Sender 发送消息之后等待接收者的 ACK，如果没收到 ACK 则重新发送消息。这种模式能保证消息至少能到达一次，但无法保证消息重复。

QoS 2设计了重发和重复消息发现机制，保证消息到达对方并且严格只到达一次。

6. MQTT QOS0

QoS0:- Fire and Forget 机制，一般局域网信息或无关紧要的互联网信息传输

·最多传输一次

·适用于不重要的消息传输

传输方式为从发送者发送 Publisher 的消息给 Broker，Broker 再调用 Publish 发送给订阅者，最后 Publisher 会自动删除。

7. MQTT QOS1

QoS1:-简单的 ACK 机制，适用于一般互联网实时消息的传递

·最少传输一次

·适用于对可靠性有要求，但对重复度没有要求的消息传输

流程为首先保存将要发送的消息，调用 Publish 发送消息，Broker 收到消息之后保存下来，再发送消息到订阅者，并且回复 Publisher ACK 表示收到了 Publish，Publisher 发送消息并且收到回应，说明消息至少传输了一次，Broker 需要等到订阅者收到 Publish 后回应后再删除消息，因为引入了 Store 机制存储信息，从而保证至少传输一次的功能。

8. MQTT QOS2

QoS2:-复杂的消息及 ACK 流程，适用于敏感信息（如国防工业及医疗设备等应用场景）的传递

·只传输一次

·适用于有可靠性要求，也不允许发生重复的消息传输

具体流程为 Publisher 首先把消息保存下来，通过 Publish 发送给 Broker，Broker 收到消息后也会保存下来并且回复收到的消息。Publisher 收到回复的 ACK 之后会再回应一个确认的 ACK，Broker 收到确认之后保障前面不会再发送，此时再把消息发送给订阅者。发送结束之后会回应一个 Publish 表示完成，此时把消息删除。对于 Publisher 来说就只传输了一次。

Subscriber 收到消息之后也会把消息保存下来并且回应确认帧。Broker 收到确认帧之后回应确认。

Subscribe 通知之后会回应表示 Publish 环节完成，Broker 最后删除消息，Subscribe 处理完之后也会删除消息。

9. MQTT 应用一般流程

通过 Client 数据帧和 Server 端建立联接。此处 Client 和 Server 就是订阅方和 Broker 作为连接，Server 回应 ACK 从而连接，连接后 Client 会做订阅，即 SUSCRIBE 以及订阅的 ACK。订阅可有多个主题，每一个主题的订阅都需要SUSCRIBE 的报文并且订阅成功会回应 SUBACK。订阅之后如果 Client 想要发送消息，把 Publish 发送给 Server，Server 收到消息之后回应 PUBACK，从而完成数据传输。经常也会 Client 发送 Request，Server 端回应 Response，完成整个过程长连接的维护。如果想要断开则需要调用 Disconnect 的数据帧。