正文
自己动手实现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 编码的字节了。
举几个
