从 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 数据包由三部分构成：
- 固定头（Fixed header）存在于所有 MQTT 数据包中，表示数据包类型及数据包的分组类标识
- 可变头（Variable header）存在于部分 MQTT 数据包中，数据包类型决定了可变头是否存在及其具体内容
- 消息体（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 订阅。