MQTT系列 | MQTT基础概念

你说的曾经没有我的故事 提交于 2019-11-28 07:36:25

MQTT 的全称为 Message Queue Telemetry Transport(消息队列遥测传输协议),是在 1999 年,由 IBM 的 Andy Stanford-Clark 和 Arcom 的 Arlen Nipper 为了一个通过卫星网络连接输油管道的项目开发的。为了满足低电量消耗和低网络带宽的需求,MQTT 协议在设计之初就包含了以下一些特点:

  1. 实现简单
  2. 提供数据传输的 QoS
  3. 轻量、占用带宽低
  4. 可传输任意类型的数据
  5. 可保持的会话(session)

之后 IBM 一直将 MQTT 作为一个内部协议在其产品中使用,直到 2010 年,IBM 公开发布了 MQTT 3.1 版本。在 2014 年,MQTT 协议正式成为了 OASIS(结构化信息标准促进组织)的标准协议。简单地来说MQTT协议具有以下特性:

  • 基于 TCP 协议的应用层协议;
  • 采用 C/S 架构;
  • 使用订阅/发布模式,将消息的发送方和接受方解耦;
  • 提供 3 种消息的 QoS(Quality of Service): 至多一次,最少一次,只有一次;
  • 收发消息都是异步的,发送方不需要等待接收方应答。

下文将从以下四个方面对MQTT的基础概念进行介绍:

  • MQTT 协议的通信模型
  • MQTT Client
  • MQTT Broker
  • MQTT协议数据包

1. MQTT 协议的通信模型

MQTT 的通信是通过发布/订阅的方式来实现的,订阅和发布又是基于主题(Topic)的。发布方和订阅方通过这种方式来进行解耦,它们没有直接地连接,它们需要一个中间方。在 MQTT 里面我们称之为 Broker,用来进行消息的存储和转发。一次典型的 MQTT 消息通信流程如下所示:

  1. 发布方(Publisher)连接到Broker;
  2. 订阅方(Subscriber)连接到Broker,并订阅主题Topic1;
  3. 发布方(Publisher)发送给Broker一条消息,主题为Topic1;
  4. Broker收到了发布方的消息,发现订阅方(Subscriber)订阅了Topic1,然后将消息转发给订阅方(Subscriber);
  5. 订阅方从Broker接收该消息;

MQTT通过订阅与发布模型对消息的发布方和订阅方进行解耦后,发布方在发布消息时并不需要订阅方也连接到Broker,只要订阅方之前订阅过相应主题,那么它在连接到Broker之后就可以收到发布方在它离线期间发布的消息。我们可以称这种消息为离线消息。

在该通信模型中,有两组身份需要区别:

  • 一组是发布方Publisher和订阅方Subscriber
  • 另一组是发送方Sender和接收方Receiver

1.1. Publisher和Subscriber

publisher和subscriber是相对于Topic来说的身份,如果一个Client向某个Topic发布消息,那么这个Client就是publisher;如果一个Client订阅了某个Topic,那么它就是Subscriber。

1.2. Sender和Receiver

Sender和Receiver则是相对于消息传输方向的身份。当publisher向Broker发送消息时,那么此时publisher是sender,Broker是receiver;当Broker转发消息给subscriber时,此时Broker是sender,subscriber是receiver。

2. MQTT Client

Publisher 和 Subscriber 都属于 Client,Pushlisher 或者 Subscriber 只取决于该 Client 当前的状态——是在发布消息还是在订阅消息。当然,一个 Client 可以同时是 Publisher 和 Subscriber。client的范围很广,任何终端、嵌入式设备、服务器只要运行了MQTT的库或者代码,都可以称为MQTT Client。MQTT Client库很多语言都有实现,可以在这个网址中找到:MQTT Client库大全

3. MQTT Broker

MQTT Broker负责接收Publisher的消息,并发送给相应的Subscriber,是整个MQTT 订阅/发布的核心。现在很多云服务器提供商都有提供MQTT 服务,比如阿里云、腾讯云等。当然我们自己也可以搭建一个MQTT Broker,个人倾向于使用 mosquitto来搭建自己的MQTT Broker。mosquitto官方网址

4. MQTT协议数据包

MQTT 协议数据包的消息格式为:固定头|可变头|消息体

由下面三个部分组成:

  • 固定头(Fixed header):存在于所有的MQTT数据包中,用于表示数据包类型及对应标志、数据包大小等;
  • 可变头(Variable header):存在于部分类型的MQTT数据包中,具体内容是由相应类型的数据包决定的;
  • 消息体(Payload):存在于部分的MQTT数据包中,存储消息的具体数据。

4.1. 固定头

固定头格式:

固定头的第一个字节的高4位Bit用于表示该数据包的类型,MQTT的数据包有以下一些类型:

名称 方向 描述
Reserved 0 不可用 保留位
CONNECT 1 Client 到 Broker Client 请求连接到 Broker
CONNACK 2 Broker 到 Client 连接确认
PUBLISH 3 双向 发布消息
PUBACK 4 双向 发布确认
PUBREC 5 双向 发布收到
PUBREL 6 双向 发布释放
PUBCOMP 7 双向 发布完成
SUBSCRIBE 8 Client 到 Broker Client 请求订阅
SUBACK 9 Broker 到 Client 订阅确认
UNSUBSCRIBE 10 Client 到 Broker Client 请求取消订阅
UNSUBACK 11 Broker 到 Client 取消订阅确认
PINGREQ 12 Client 到 Broker PING 请求
PINGRESP 13 Broker 到 Client PING 应答
DISCONNECT 14 Client 到 Broker Client 主动中断连接
Reserved 15 不可用 保留位

低4位Bit则用于表示数据包的Flag,不同的数据包类型,Flag的定义不同,每种数据包对应的Flag如下:

数据包 标识位 Bit 3 Bit 2 Bit 1 Bit 0
CONNECT 保留位 0 0 0 0
CONNACK 保留位 0 0 0 0
PUBLISH MQTT 3.1.1 使用 DUP QoS QoS RETAIN
PUBACK 保留位 0 0 0 0
PUBREC 保留位 0 0 0 0
PUBREL 保留位 0 0 0 0
PUBCOMP 保留位 0 0 0 0
SUBSCRIBE 保留位 0 0 0 0
SUBACK 保留位 0 0 0 0
UNSUBSCRIBE 保留位 0 0 0 0
UNSUBACK 保留位 0 0 0 0
PINGREQ 保留位 0 0 0 0
PINGRESP 保留位 0 0 0 0
DISCONNECT 保留位 0 0 0 0

从固定头的第2字节开始是用于表示MQTT数据包剩余长度的字段,**最少一个字节,最大四个字节。每一个字节的低7位用于标识值,范围为0~127。最高的1位是标识位,用来说明是否有后续字节来标识长度。**标识为0,代表没有后续字节;标识为1,代表后续还有一个字节用于标识包的长度。MQTT协议相应字节数对应的最小、最大包长度如下表所示:

字节数 最小包长度(除固定头外) 最大包长度(除固定头外)
1 0字节(0x00) 127字节(0x7F)
2 128字节(0x80,0x01) 16 383字节(0xFF,0x7F)
3 16 384字节(0x80,0x80,0x01) 2 097 151字节(0xFF,0xFF,0x7F)
4 2 097 152字节(0x80,0x80,0x80,0x01) 268 435 455字节(0xFF,0xFF,0xFF,0x7F)

可知MQTT协议中数据包(除固定头外)的最大长度为268435455 字节,约 256M。

注意:上述的剩余长度不包含固定头的大小,是指后面的可变报文头加消息体的总长度

4.2. 可变头

可变报文头主要包含协议名、协议版本、连接标志(Connect Flags)、心跳间隔时间(Keep Alive timer)、连接返回码(Connect Return Code)、主题名(Topic Name)等,后面会针对此部分进行具体讲解。

4.3. 消息体

当MQTT发送的消息类型是CONNECT(连接)、PUBLISH(发布)、SUBSCRIBE(订阅)、SUBACK(订阅确认)、UNSUBSCRIBE(取消订阅)时,则会带有负荷。

5. 发布订阅实验演示

本实验中演示使用的Broker是mosquitto,mosquitto具体的安装步骤不再阐述,可自行搜索安装教程。下面按照[MQTT 协议的通信模型](#MQTT 协议的通信模型)中所提到的流程对发布和订阅这种模式进行一个直观的演示:

  • 第一步:启动Broker

  • 第二步:subscriber订阅相应的Topic

​ 如图所示,通过mosquitto_sub命令向Broker订阅了名为test的Topic,运行Broker的终端界面也打印了相关的 订阅信息。

  • 第三步:publisher发布相应Topic的消息

如图所示,通过mosquitto_pub命令向主题名为test的发布了两条消息,这时候订阅方(即运行mosquitto_sub命令的终端页面)收到了发布的消息。Broker输出的信息为处理的过程:

  1. publisher连接到Broker
  2. Broker回复了一个CONNACK数据包给publisher
  3. Broker从publisher那收到了PUBLISH数据包
  4. Broker将其PUBLISH数据包转发给subscriber
  5. Broker收到了publisher发来的DISCONNECT数据包,然后断开了连接。

在这里插入图片描述

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!