自己动手实现MQTT协议

写在前面

前段时间弄IoT相关的东西，系统学习了一下 MQTT 协议，在此分享出来。

本文先是对 MQTT 协议做了简单的介绍；接着是对 MQTT协议的内容做了较为全面的解读；最后使用 Python 语言去实现一个简单的 MQTT 客户端和服务器。

简介

MQTT 全称是 Message Queue Telemetry Transport，翻译成中文意思是“遥测传输协议”。它最先是由IBM提出，是一种基于 **TCP ** 协议，具有简单、轻量等优点，特别适合于受限环境（带宽低、网络延迟高、网络通信不稳定）的消息分发。MQTT 协议有 3.x, 5.x 等多个版本，目前最常用的版本是 v3.1.1 ，本文也是对此版本的协议进行的解读。MQTT 协议已纳入ISO标准 (ISO/IEC PRF 20922)，现今主流的 IoT 平台都支持该协议。

PS: 更详细的信息可参考 Wikipedia 和 MQTT 官网

快速开始

MQTT 是一种发布-订阅协议，这意味着：

• 客户端（Client）可以向服务端（Broker） 订阅（Subscribe）自己感兴趣的主题（Topic）；
• 客户端还可以向服务端发布（Publish）关于某个主题的信息（主题不需要提前创建，发布消息时指定即可）；
• 服务端在收到客户端发布的消息后，会将该消息转发给订阅了该主题的其他客户端。

我们可以在自己的电脑上运行一个 MQTT 的服务端，和多个 MQTT 的客户端来体验这一过程。

MQTT 服务端有很多可以选择。这里我们使用 Mosquitto，按照其官方文档的说明安装即可，这里不多做介绍。

Mac 用户可以用以下命令安装并启动 Mosquitto：

brew install mosquitto
brew services start mosquitto

Mosquitto 提供了命令行工具 mosquitto_sub 和 mosquitto_pub ,它们可用来向服务端订阅主题 和发布消息。

在一个命令行窗口中，执行以下命令去订阅名为 “foo” 的主题：

mosquitto_sub -h 127.0.0.1 -p 1883 -t foo -q 2

在另一个命令行窗口中，执行以下命令发布消息 “Hello, MQTT” 到 “foo” 主题：

mosquitto_pub -h 127.0.0.1 -p 1883 -t foo -q 2 -m 'Hello, MQTT'

最终我们将看到，在第一个命令行窗口中，打印出了消息 “Hello, MQTT”。这意味着，第一个客户端在主题 “foo” 上，收到了第二个客户端发布的消息。

协议详解

数据包整体格式

从整体上看，数据包分为3个部分：一个是固定头部，它是一定存在的；另一个是可变头部，它不一定存在；剩下一个是载荷，它也不一定存在。数据采用大端方式存储。

+----------------------------+
|                            |
|      固 定 头 部 (必 需 )    |
|                            |
+----------------------------+
|                            |
|     可 变 头 部 (非 必 需)   |
|                            |
+----------------------------+
|                            |
|        载 荷 (非 必 需 )     |
|                            |
+----------------------------+

固定头部（Fixed header）

固定头部格式如下：

+---------------------------------------------------------+
|   bit   |  7  |  6  | 5   |  4  |  3  |  2  |  1  |  0  |
+---------------------------------------------------------+
|  byte1  |      Packet type      |         Flags         |
+---------------------------------------------------------+
| byte2...|              Remaining Length                 |
+---------------------------------------------------------+

包类型（Packet type）

Name	Value	Direction of flow	Description
Reserved	0	Forbidden	Reserved
CONNECT	1	Client to Server	Client request to connect to Server
CONNACK	2	Server to Client	Connect acknowledgment
PUBLISH	3	Client to Server or Server to Client	Publish message
PUBACK	4	Client to Server or Server to Client	Publish acknowledgment
PUBREC	5	Client to Server or Server to Client	Publish received (assured delivery part 1)
PUBREL	6	Client to Server or Server to Client	Publish release (assured delivery part 2)
PUBCOMP	7	Client to Server or Server to Client	Publish complete (assured delivery part 3)
SUBSCRIBE	8	Client to Server	Client subscribe request
SUBACK	9	Server to Client	Subscribe acknowledgment
UNSUBSCRIBE	10	Client to Server	Unsubscribe request
UNSUBACK	11	Server to Client	Unsubscribe acknowledgment
PINGREQ	12	Client to Server	PING request
PINGRESP	13	Server to Client	PING response
DISCONNECT	14	Client to Server	Client is disconnecting
Reserved	15	Forbidden	Reserved

标记（Flags）

不同包类型标记位含义不尽相同，具体情况如下表所示：

Control Packet	Fixed header flags	Bit 3	Bit 2	Bit 1	Bit 0
CONNECT	Reserved	0	0	0	0
CONNACK	Reserved	0	0	0	0
PUBLISH	Used in MQTT 3.1.1	DUP1	QoS2	QoS2	RETAIN3
PUBACK	Reserved	0	0	0	0
PUBREC	Reserved	0	0	0	0
PUBREL	Reserved	0	0	1	0
PUBCOMP	Reserved	0	0	0	0
SUBSCRIBE	Reserved	0	0	1	0
SUBACK	Reserved	0	0	0	0
UNSUBSCRIBE	Reserved	0	0	1	0
UNSUBACK	Reserved	0	0	0	0
PINGREQ	Reserved	0	0	0	0
PINGRESP	Reserved	0	0	0	0
DISCONNECT	Reserved	0	0	0	0

剩余长度（Remaining Length）

Remaining Length 表示的是本数据包剩余部分的字节数，即可变头部和载荷的字节数之和。为了节省传输时的字节数，Remaining Length 采用的是一种变长编码方式。这就是说 Remaining Length 字段的字节数不是固定的，它可能使用1~4个字节。既然 Remaining Length 的字节数是可变的，那么问题来了，我们在解码包数据的时候，怎么知道 Remaining Length 究竟是使用几个字节编码的呢？解决这个问题的办法是，将每个字节的最高位（MSB）作为标志位。若该位的值是1，则意味着下一个字节属于参与 Remaining Length 编码的字节；若该位的值是0，则意味着本字节已经是最后一个参与 Remaining Length 编码的字节了。

举几个