MQTT消息传输机制(协议与调用实例)探究.pdf

MQTT 消息传输机制（协议解读与调用实例） MQTT 消息传输机制（协议解读与调用实例） 李阳 MQTT 消息传输机制（协议解读与调用实例） 前言 最近在研究 MQTT 时，我发现我身边的同事都在看类似 android 中实现 mqtt 通信、java 如何调用 mqtt 实现消息推送等，这种方式在现实编程中见怪不怪，也是常规的解决思 路，但也有诸多疑惑是常规思路中不能轻易达成的，原因有以下几点： 1. 代码调用简单，仅实现基本的功能； 2. 现成的类库文档较少，影响对类库的理解； 3. 开发者自身知其然，不知其所以然，等等 由此产生了很多令人困惑的问题，诸如： 1. 用户（非）正常断开连接，代码能对断开的用户进行后续的逻辑处理吗（断开后的业务回调）？ 2. 消息发布后，接收者未在线，上线能接收到之前发布的消息吗？ 3. 如何进行用户的登录验证？ 4. 消息发送失败及接收端下线，如何确保接收端再次登录后有正常接收到消息？ 5. …… 本篇会把连接(CONNECT)、心跳(PINGREQ/PINGRESP)、确认(CONNACK)、断开连接(DISCONNECT)和在一起，通过对协议的解读，结合类库的调用来对以上问题进行逐一解 答。 CONNECT 像前面所说，MQTT 有关字符串部分采用的修改版的 UTF-8 编码，CONNECT 可变头部中协议名称、消息体都是采用修改版的 UTF-8 编码。前面基本上可变头部内容不多，下面 是一个较为完整的 CONNECT 消息结构： Description 7 6 5 4 3 2 1 0 Fixed header/固定头部 Message Type(1) DUP QoS level RETAIN MQTT 消息传输机制（协议解读与调用实例） MQTT 消息传输机制（协议解读与调用实例） 李阳 Description 7 6 5 4 3 2 1 0 flag byte 1 0 0 0 1 x x x x byte 2 Remaining Length Variable header/可变头部 Protocol Name byte 1 Length MSB (0) 0 0 0 0 0 0 0 0 byte 2 Length LSB (6) 0 0 0 0 0 1 1 0 byte 3 M 0 1 0 0 1 1 0 1 byte 4 Q 0 1 0 1 0 0 0 1 byte 5 I 0 1 0 0 1 0 0 1 byte 6 s 0 1 1 1 0 0 1 1 byte 7 d 0 1 1 0 0 1 0 0 byte 8 p 0 1 1 1 0 0 0 0 Protocol Version Number byte 9 Version (3) 0 0 0 0 0 0 1 1 Connect Flags MQTT 消息传输机制（协议解读与调用实例） MQTT 消息传输机制（协议解读与调用实例） 李阳 Description 7 6 5 4 3 2 1 0 User Name Flag Password Flag Will Retain Will QoS Will Flag Clean Session Reserved byte 10 1 1 0 0 1 1 1 x Keep Alive timer byte 11 Keep Alive MSB (0) 0 0 0 0 0 0 0 0 byte 12 Keep Alive LSB (10) 0 0 0 0 1 0 1 0 Playload/消息体 Client Identifier(客户端 ID) 1-23 个字符长度，客户端到服务器的全局唯一标志，如果客户端 ID 超出 23 个字符长度，服务器需要返回码为 2，标识符被拒绝响应的 CONNACK 消 息。 处理 QoS 级别 1 和 2 的消息 ID 中，可以使用到。 必填项。 Will Topic Will Flag 值为 1，这里便是 Will Topic 的内容。QoS 级别通过 Will QoS 字段定义，RETAIN 值通过 Will RETAIN 标识，都定义在可变头里面。 Will Message Will Flag 若设为 1，这里便是 Will Message 定义消息的内容，对应的主题为 Will Topic。如果客户端意外的断开触发服务器 PUBLISH 此消息。 长度有可能为 0。 在 CONNECT 消息中的 Will Messag