从MQTT说起

MQTT是一个构建在TCP/IP上的通讯协议,是与HTTP、FTP、SSH同属于应用层的协议,它的特点是数据包小且容易构建容易解析,协议本身也十分简单。由于协议对硬件资源消耗极少,所以MQTT是一个适合使用在低功耗物联网平台上的通讯协议。
对于STM8/STM32主控来说,只需要一个已经与MQTT服务器建立TCP连接的接口(通过WIFI模块或蓝牙模块预配置,我使用的是接在i2c接口上的已经开启透传模式的WIFI模块),就可以通过简单的字符串生成和解析来和服务器通讯。
下面简单介绍了一下MQTT协议的具体内容,自己实现并不难,当然也有开源的各种语言的MQTT库供大家使用。

协议关键词

订阅(Subscription)
订阅包含主题筛选器(Topic Filter)和最大服务质量(QoS)。订阅会与一个会话(Session)关联。一个会话可以包含多个订阅。每一个会话中的每个订阅都有一个不同的主题筛选器。

会话(Session)
每个客户端与服务器建立连接后就是一个会话,客户端和服务器之间有状态交互。会话存在于一个网络之间,也可能在客户端和服务器之间跨越多个连续的网络连接。

主题名(Topic Name)
连接到一个应用程序消息的标签,用来标识已发布消息的信息的渠道,该标签与服务器的订阅相匹配。服务器会将消息发送给订阅所匹配标签的每个客户端。

主题筛选器(Topic Filter)
订阅者用它来确定接收到所关心的信息。
它是一个分层的结构,用斜线“/”作为分隔符(这个有点类似于restful风格)。主题还可以通过通配符进行过滤。其中,+可以过滤一个层级,而#只能出现在主题最后表示过滤任意级别的层级。
值得注意的是MQTT允许使用通配符订阅主题,但是并不允许使用通配符广播。举个例子:
building-b/floor-5:代表B楼5层的设备。
+/floor-5:代表任何一个楼的5层的设备。
building-b/#:代表B楼所有的设备。

服务质量(QOS)
QoS 0:最多分发一次。消息的传递完全依赖底层的TCP/IP网络,协议里没有定义应答和重试,消息要么只会到达服务端一次,要么根本没有到达。 QoS 1:至少分发一次。服务器的消息接收由PUBACK消息进行确认,如果通信链路或发送设备异常,或者指定时间内没有收到确认消息,发送端会重发这条在消息头中设置了DUP位的消息。 QoS 2:只分发一次。这是最高级别的消息传递,消息丢失和重复都是不可接受的,使用这个服务质量等级会有额外的开销。在一些要求比较严格的计费系统中,可以使用此级别。

例如共享单车智能锁,智能锁可以定时使用QoS level 0质量消息请求服务器,发送单车的当前位置,如果服务器没收到也没关系,反正过一段时间又会再发送一次。之后用户可以通过App查询周围单车位置,找到单车后需要进行解锁,这时候可以使用QoS level 1质量消息,手机App不断的发送解锁消息给单车锁,确保有一次消息能达到以解锁单车。最后用户用完单车后,需要提交付款表单,可以使用QoS level 2质量消息,这样确保只传递一次数据,否则用户就会多付钱了。 

负载(Payload)
Payload直译为负荷,可能让人摸不着头脑,实际上可以理解为消息主体(body)。
当MQTT发送的消息类型是CONNECT(连接)、PUBLISH(发布)、SUBSCRIBE(订阅)、SUBACK(订阅确认)、UNSUBSCRIBE(取消订阅)时,则会带有负荷。

消息代理(Broker)
MQTT协议的中心服务器/应用需要完成以下任务
接受来自客户的网络连接
接受客户发布的应用信息
处理来自客户端的订阅和退订请求
向订阅的客户转发应用程序消息

包组成

一个MQTT数据包由三部分构成:

  1. 固定头(Fixed header)存在于所有MQTT数据包中,表示数据包类型及数据包的分组类标识
  2. 可变头(Variable header)存在于部分MQTT数据包中,数据包类型决定了可变头是否存在及其具体内容
  3. 消息体(payload)存在于部分MQTT数据包中,表示客户端收到的具体内容

下面对数据包每一位的数据进行解释

MQTT固定头

固定头存在于所有MQTT数据包中,其结构如下:

Bit 前四位 后四位
第一个字节 MQTT数据包类型 不同类型MQTT数据包的具体标识
第二或更多个字节 剩余 长度
MQTT数据包类型

位置:第一个字节的前四位。

相当于一个4位的无符号值,类型如下:

名称 流方向 描述
Reserved 0 不可用 保留位
CONNECT 1 客户端到服务器 客户端请求连接到服务器
CONNACK 2 服务器到客户端 连接确认
PUBLISH 3 双向 发布消息
PUBACK 4 双向 发布确认
PUBREC 5 双向 发布收到(保证第1部分到达)用于高QOS
PUBREL 6 双向 发布释放(保证第2部分到达)用于高QOS
PUBCOMP 7 双向 发布完成(保证第3部分到达)用于高QOS
SUBSCRIBE 8 客户端到服务器 客户端请求订阅
SUBACK 9 服务器到客户端 订阅确认
UNSUBSCRIBE 10 客户端到服务器 请求取消订阅
UNSUBACK 11 服务器到客户端 取消订阅确认
PINGREQ 12 客户端到服务器 PING请求,声明客户端存活,用于维持连接
PINGRESP 13 服务器到客户端 PING应答
DISCONNECT 14 客户端到服务器 中断连接
Reserved 15 不可用 保留位
标识位

位置:第一个字节的后四位。

在不使用标识位的消息类型中,标识位被做为保留位。如果收到无效的标志时,接收端必须关闭网络连接(由于协议错误而断开连接):

数据包 标识位 Bit 3 Bit 2 Bit 1 Bit 0
CONNECT 保留位 0 0 0 0
CONNACK 保留位 0 0 0 0
PUBLISH MQTT 3.1.1使用 DUP QoS1 QoS2 RETAIN
PUBACK 保留位 0 0 0 0
PUBREC 保留位 0 0 0 0
PUBREL 保留位 0 0 1 0
PUBCOMP 保留位 0 0 0 0
SUBSCRIBE 保留位 0 0 1 0
SUBACK 保留位 0 0 0 0
UNSUBSCRIBE 保留位 0 0 1 0
UNSUBACK 保留位 0 0 0 0
PINGREQ 保留位 0 0 0 0
PINGRESP 保留位 0 0 0 0
DISCONNECT 保留位 0 0 0 0
  • DUP:发布消息的副本。用来在保证消息的可靠传输,如果设置为 1,则在下面的变长中增加 MessageId,并且需要回复确认,以保证消息传输完成,但不能用于检测消息重复发送。
  • QoS:发布消息的服务质量,即:保证消息传递的次数,数据共两位
    • 00:最多一次,即:<=1
    • 01:至少一次,即:>=1
    • 10:一次,即:=1
    • 11:预留
  • RETAIN: 发布保留标识,表示服务器要保留这次推送的信息,如果有新的订阅者出现,就把这消息推送给它,如果设有那么推送至当前订阅者后释放。
剩余长度(Remaining Length)

位置:第二个字节及之后的字节。

固定头的第二字节用来保存变长头部和消息体的总大小的,但不是直接保存的。这一字节是可以扩展,其保存机制,后7位用于保存长度,第1位用做标识。当第1位为1时,表示长度不足,需要使用后一个字节继续保存。也就是说,单个字节可以描述的最大长度是127字节。
例如,数字64,编码为一个字节,十进制表示为64,十六进制表示为0×40。数字321(65+2*128)编码为两个字节,重要性最低的放在前面,第一个字节为65+128=193(0xC1),第二个字节是2(0x02),表示2×128。
由于MQTT协议最多只允许使用四个字节表示剩余长度,并且最后一字节最大值只能是0x7F不能是0xFF,所以能发送的最大消息长度是256MB。

MQTT可变头

MQTT数据包中包含一个可变头,它驻位于固定的头和负载之间。可变头的内容因数据包类型而不同,较常的应用是做为包的标识:

Bit 7 6 5 4 3 2 1 0
byte 1 标识符(MSB)
byte 2…… 标识符(LSB)

SUBSCRIBE,UNSUBSCRIBE和PUBLISH(QoS大于0)控制报文必须包含一个非零的16位报文标识符(Packet Identifier)。客户端每次发送一个新的这些类型的报文时都必须分配一个当前未使用的报文标识符 。如果一个客户端要重发这个特殊的控制报文,在随后重发那个报文时,它必须使用相同的标识符。当客户端处理完这个报文对应的确认后,这个报文标识符就释放可重用。
QoS 1的PUBLISH对应的是PUBACK,QoS 2的PUBLISH对应的是PUBCOMP,与SUBSCRIBE或UNSUBSCRIBE对应的分别是SUBACK或UNSUBACK。
发送一个QoS 0的PUBLISH报文时,相同的条件也适用于服务端。QoS 0的PUBLISH报文不能包含报文标识符。 PUBACK, PUBREC, PUBREL报文必须包含与最初发送的PUBLISH报文相同的报文标识符。类似地,SUBACK和UNSUBACK必须包含在对应的SUBSCRIBE和UNSUBSCRIBE报文中使用的报文标识符。

控制报文 报文标识符字段
CONNECT 不需要
CONNACK 不需要
PUBLISH 需要(如果QoS > 0)
PUBACK 需要
PUBREC 需要
PUBREL 需要
PUBCOMP 需要
SUBSCRIBE 需要
SUBACK 需要
UNSUBSCRIBE 需要
UNSUBACK 需要
PINGREQ 不需要
PINGRESP 不需要
DISCONNECT 不需要

Payload消息体

Payload消息体位MQTT数据包的第三部分,CONNECT、SUBSCRIBE、SUBACK、UNSUBSCRIBE四种类型的消息 有消息体:

  • CONNECT,消息体内容主要是:客户端的ClientID、订阅的Topic、Message以及用户名和密码。
  • SUBSCRIBE,消息体内容是一系列的要订阅的主题以及QoS。
  • SUBACK,消息体内容是服务器对于SUBSCRIBE所申请的主题及QoS进行确认和回复。
  • UNSUBSCRIBE,消息体内容是要订阅的主题。

协议的其他特点

由于每个类型的包具体内容各有不同,此处不再赘述。

遗愿标志(Will Flag)

在可变报文头的连接标志位字段(Connect Flags)里有三个Will标志位:Will Flag、Will QoS和Will Retain Flag,这些Will字段用于监控客户端与服务器之间的连接状况。如果设置了Will Flag,就必须设置Will QoS和Will Retain标志位,消息主体中也必须有Will Topic和Will Message字段。

那遗愿消息是怎么回事呢?服务器与客户端通信时,当遇到异常或客户端心跳超时的情况,MQTT服务器会替客户端发布一个Will消息。当然如果服务器收到来自客户端的DISCONNECT消息,则不会触发Will消息的发送。  因此,Will字段可以应用于设备掉线后需要通知用户的场景。

连接保活心跳机制(Keep Alive Timer)

MQTT客户端可以设置一个心跳间隔时间(Keep Alive Timer),表示在每个心跳间隔时间内发送一条消息。如果在这个时间周期内,没有业务数据相关的消息,客户端会发一个PINGREQ消息,相应的,服务器会返回一个PINGRESP消息进行确认。如果服务器在一个半(1.5)心跳间隔时间周期内没有收到来自客户端的消息,就会断开与客户端的连接。心跳间隔时间最大值大约可以设置为18个小时,0值意味着客户端不断开。

二进制格式实现

MQTT基于二进制实现而不是字符串,比如HTTP和XMPP都是基于字符串实现。由于HTTP和XMPP拥有冗长的协议头部,而MQTT固定报文头仅有两字节,所以相比其他协议,发送一条消息最省流量。

MQTT的安全

由于MQTT运行于TCP层之上并以明文方式传输,这就相当于HTTP的明文传输,使用Wireshark可以完全看到MQTT发送的所有消息,消息指令一览无遗。这样可能会产生以下风险:

  • 设备可能会被盗用;
  • 客户端和服务端的静态数据可能是可访问的(可能会被修改);
  • 协议行为可能有副作用(如计时器攻击);
  • 拒绝服务攻击;
  • 通信可能会被拦截、修改、重定向或者泄露;
  • 虚假控制报文注入。

作为传输协议,MQTT仅关注消息传输,提供合适的安全功能是开发者的责任。安全功能可以从三个层次来考虑——应用层、传输层、网络层。

  • 应用层:在应用层上,MQTT提供了客户标识(Client Identifier)以及用户名和密码,可以在应用层验证设备。
  • 传输层:类似于HTTPS,MQTT基于TCP连接,也可以加上一层TLS,传输层使用TLS加密是确保安全的一个好手段,可以防止中间人攻击。客户端证书不但可以作为设备的身份凭证,还可以用来验证设备。
  • 网络层:如果有条件的话,可以通过拉专线或者使用VPN来连接设备与MQTT代理,以提高网络传输的安全性。

选择用户数据格式

MQTT协议只实现了传送消息的格式,并没有限制用户协议需要按照一定的风格,因此在MQTT协议之上,我们需要定义一套自己的通信协议。比如说,发布者向设备发布一条打开消息,设备可以回复一个消息并携带返回码,这样的消息格式是使用二进制、字符串还是JSON格式呢?下面就简单做个选型参考。

十六进制/二进制

MQTT原本就是基于二进制实现的,所以用户协议使用二进制实现是一个不错的选择。虽然失去了直观的可读性,但可以将流量控制在非常小。其实对于单片机开发者来说十六进制并不陌生,因为单片机寄存器都是以位来操作的,芯片间通信也会使用十六进制/二进制。而对于没有单片机开发经验的工程师来说,十六进制/二进制可能就太原始了。下面我们继续看看还有没有其他方案。

字符串

对单片机开发者来说,字符串也是一个选择。比如通过串口传输的AT指令就是基于字符串通信的。使用字符串方便了人阅读,但是对高级语言开发者来说,字符串依旧不是最佳选择,恐怕键值对(Key-Value)才是最优形式。

JSON

JSON中文全称是JavaScript对象标记语言,在这门语言中,一切都是对象。因此,任何支持的类型都可以通过JSON来表示,例如字符串、数字、对象、数组等。其语法规则是:

  • 对象表示为键值对;
  • 数据由逗号分隔;
  • 花括号保存对象;
  • 方括号保存数组。

JSON层次结构简洁清晰,易于阅读和编写,同时也易于机器解析和生成,有效提升网络传输效率。
对于单片机开发者,主流的微控制器软件开发工具Keil有提供JSON库,可以用于STC、STM32等微控制器开发,所以在微控制器上解析JSON不需要自己写一个JSON解析器或者移植了。
如果实在懒得使用JSON库生成或解析,也可以直接使用C语言中的sprintf生成JSON字符串,比如:

sprintf(buf, "{\"String\":\"%s\", \"Value\":%d}", "Hello World!", 12345);

这样就可以生成一个{“String”:”Hello World!”, “Value”:12345}JSON字符串了。

XML

MQTT协议只负责通信部分,用户协议可以自己选择,当然也可以选择复杂又冗长的XML格式。可是既然要选择MQTT+XML,为什么不考虑换为XMPP呢?

此部分参考文献:
https://blog.csdn.net/anxianfeng55555/article/details/80908795
https://github.com/mcxiaoke/mqtt
https://itbilu.com/other/relate/4kHBsx_Pg.html

基于MQTT的设备通讯

低功耗硬件部分

由于MQTT协议对硬件性能的要求比较低,所以笔者在SMT8单片机上使用MQTT协议进行状态提交及远程控制,首先下载官方库或自己封装库,(由于STM8的资源很少,所以根据实际需要可以进一步对协议库进行阉割)放入自己的工程中,使用预先配置好的通讯模块或由主控动态配置通讯模块之后使用MQTT协议与服务器建立连接。

微信小程序部分

由于微信允许小程序通过HTTP/WebSocket协议连接第三方服务器,所以我们需要在MQTT服务器上同时开启一个HTTP/WebSocket API(此处使用免费的第三方平台即可),然后微信小程序即可订阅MQTT消息以及发送MQTT订阅。