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编码。前面基本上可变头部内容不多，下面

MQTT消息传输机制（协议解读与调用实例）李阳

MQTT消息传输机制（协议解读与调用实例）李阳

MQTT消息传输机制（协议解读与调用实例）李阳

可变头部

协议名称和协议版本都是固定的。

连接标志(Connect Flags)

一个字节表示，除了第1位是保留未使用，其它7位都具有不同含义。

业务上很重要，对消息总体流程影响很大，需要牢记。

Clean Session

0，表示如果订阅的客户机断线了，要保存为其要推送的消息（QoS为1和QoS为2），若其重新连接时，需将这些消息推送（若客户端长时间不连接，需要设置一个过期值）。1，断线服务器即清理相关信息，重新连接上来之后，会再次订阅。

Will Flag

定义了客户端（没有主动发送DISCONNECT消息）出现网络异常导致连接中断的情况下，服务器需要做的一些措施。

简而言之，就是客户端预先定义好，在自己异常断开的情况下，所留下的最后遗愿（Last Will），也称之为遗嘱（Testament）。这个遗嘱就是一个由客户端预先定义好的主题和对应消息，附加在CONNECT的可变头部中，在客户端连接出现异常的情况下，由服务器主动发布此消息。

只有在Will Flag位为1时，Will Qos和Will Retain才会被读取，此时消息体Playload中要出现Will Topic和Will Message具体内容，否则，Will QoS和Will Retain值会被忽略掉。

Will Qos

两位表示，和PUBLISH消息固定头部的QoS level含义一样。这里先掠过，到PUBLISH消息再回过头来看看，会更明白些。

若标识了Will Flag值为1，那么Will QoS就会生效，否则会被忽略掉。

Will RETAIN

如果设置Will Flag，Will Retain标志就是有效的，否则它将被忽略。

MQTT消息传输机制（协议解读与调用实例）李阳

当客户端意外断开服务器发布其Will Message之后，服务器是否应该继续保存。这个属性和PUBLISH固定头部的RETAIN标志含义一样，这里先掠过。

User name 和password Flag：

用于授权，两者要么为0要么为1，否则都是无效。都为0，表示客户端可自由连接/订阅，都为1，表示连接/订阅需要授权。

Playload/消息体

消息体定义的消息顺序（如上表所示），约定俗成，不得更改，否则将可能引起混乱。

若Will Flag值为0，那么在Playload中，Client Identifer后面就不会存在Will Topic和Will Message内容。

若User Name和Password都为0，意味着Playload/消息体中，找不到User Name和password的值，就算有，也是无效。标志决定着是否读取与否。

心跳时间(Keep Alive timer)

以秒为单位，定义服务器端从客户端接收消息的最大时间间隔。一般应用服务会在业务层次检测客户端网络是否连接，不是TCP/IP协议层面的心跳机制(比如开启SOCKET的SO_KEEPALIVE选项)。一般来讲，在一个心跳间隔内，客户端发送一个PINGREQ消息到服务器，服务器返回PINGRESP消息，完成一次心跳交互，继而等待下一轮。若客户端没有收到心跳反馈，会关闭掉TCP/IP端口连接，离线。16位两个字节，可看做一个无符号的short类型值。最大值，2^16-1 = 65535秒= 18小时。最小值可以为0，表示客户端不断开。一般设为几分钟，比如微信心跳周期为300秒。

Will Message编码

MQTT消息传输机制（协议解读与调用实例）李阳

另外，

相关说明：

https://www.360docs.net/doc/5b17691309.html,/wiki/doku.php/will message utf8_support

https://https://www.360docs.net/doc/5b17691309.html,/issues/browse/MQTT-2

连接异常中断通知机制

CONNECT消息一旦设置在可变头部设置了Will flag标记，那就启用了Last-Will-And-Testament特性，此特性很赞。

一旦客户端出现异常中断，便会触发服务器发布Will Message消息到Will Topic主题上去，通知Will Topic订阅者，对方因异常退出。

接收CONNECT后的响应动作

接收到CONNECT消息之后，服务器应该返回一个CONNACK消息作为响应：

1.若客户端绕过CONNECT消息直接发送其它类型消息，服务器应关闭此非法连接若客户端发送CONNECT之后未收到CONNACT，需要关闭当前连接，然后重新连接

2.相同Client ID客户端已连接到服务器，先前客户端必须断开连接后，服务器才能完成新的客户端CONNECT连接客户端发送无效非法CONNECT消息，服务器需要关

闭

CONNACK

MQTT消息传输机制（协议解读与调用实例）李阳

MQTT消息传输机制（协议解读与调用实例）李阳

只有

从上面看出，一个CONNACT，四个字节表示。一个正常的CONNACT消息实际内容可能如下：0x20 0x02 0x00 0x00

若是在私有协议中，两个字节就足够了。

很多时候，客户端和服务器端在没有消息传递时，会一直保持着连接。虽然不能依靠TCP心跳机制（比如SO_KEEPALIVE选项），业务层面定义心跳机制，会让连接状态检测、控制更为直观。

PINGREQ

心跳频率在CONNECT可变头部“Keep Alive timer”中定义时间，单位为秒，无符号16位short表示。

PINGRESP

服务器收到PINGREQ请求之后，会立即响应一个两个字节固定格式的PINGRESP消息。

MQTT消息传输机制（协议解读与调用实例）李阳

行为一致，但对客户端的订阅不会产生影响（不会清除客户端订阅数据），这个需要牢记。

若客户端发送PINGREQ之后的一个心跳周期内接收不到PINGRESP消息，可考虑关闭TCP/IP套接字连接。

DISCONNECT

客户端主动发送到服务器端，表明即将关闭TCP/IP连接。此时要求服务器要完整、干净的进行断开处理，不能仅仅类似于关闭连接描述符类似草草处理之。需要两个字节，值固定：

1.值为0，服务器必须在客户端断开之后继续存储/保持客户端的订阅状态。这些状态包括：

MQTT消息传输机制（协议解读与调用实例）李阳

o存储订阅的消息QoS1和QoS2消息

o正在发送消息期间连接丢失导致发送失败的消息

o以便当客户端重新连接时以上消息可以被重新传递。

2.值为1，服务器需要立刻清理连接状态数据。

有一点需要牢记，服务器在接收到客户端发送的DISCONNECT消息之后，需要主动关闭TCP/IP连接。

针对上述问题提出的解决方案：

1、用户（非）正常断线后的业务回调

Will Topic

Will Flag值为1，这里便是Will Topic的内容。QoS级别通过Will QoS字段定义，RETAIN值通过Will RETAIN标识，都定义在可变头里面。

连接异常中断通知机制

CONNECT消息一旦设置在可变头部设置了Will flag标记，那就启用了Last-Will-And-Testament特性，此特性很赞。

一旦客户端出现异常中断，便会触发服务器发布Will Message消息到Will Topic主题上去，通知Will Topic订阅者，对方因异常退出。

Clean Session

0，表示如果订阅的客户机断线了，要保存为其要推送的消息（QoS为1和QoS为2），若其重新连接时，需将这些消息推送（若客户端长时间不连接，需要设置一个过期值）。1，断线服务器即清理相关信息，重新连接上来之后，会再次订阅。

Will Flag

定义了客户端（没有主动发送DISCONNECT消息）出现网络异常导致连接中断的情况下，服务器需要做的一些措施。

简而言之，就是客户端预先定义好，在自己异常断开的情况下，所留下的最后遗愿（Last Will），也称之为遗嘱（Testament）。这个遗嘱就是一个由客户端预先定义好的主题和对应消息，附加在CONNECT的可变头部中，在客户端连接出现异常的情况下，由服务器主动发布此消息。

只有在Will Flag位为1时，Will Qos和Will Retain才会被读取，此时消息体Playload中要出现Will Topic和Will Message具体内容，否则，Will QoS和Will Retain 值会被忽略掉。

Will Qos

两位表示，和PUBLISH消息固定头部的QoS level含义一样。这里先掠过，到PUBLISH消息再回过头来看看，会更明白些。

若标识了Will Flag值为1，那么Will QoS就会生效，否则会被忽略掉。

MQTT消息传输机制（协议解读与调用实例）李阳

协议中明确指出，在连接时，我们只要设置好它的Last Will【在自己异常断开的情况下，所留下的最后遗愿（Last Will），也称之为遗嘱（Testament）】

类库中对应的封装大致如下，可能会因语言版本不同而有所差异，但大致都是如此：

void Connect();

void Connect(bool cleanStart);

void Connect(string willTopic, QoS willQoS, MqttPayload willMsg, bool willRetain);

void Connect(string willTopic, QoS willQoS, MqttPayload willMsg, bool willRetain, bool cleanStart);

测试结果如下：

2、消息发布后，接收者未在线，上线能接收到之前发布的消息吗？

MQTT消息传输机制（协议解读与调用实例）李阳

答案是肯定的，消息发布时，有一重要参数：retained，建立连接函数中（willRetain）属性和PUBLISH固定头部的RETAIN标志含义一样

类库中对应的封装大致如下，可能会因语言版本不同而有所差异，但大致都是如此：

int Publish(MqttParcel parcel);

int Publish(string topic, MqttPayload payload, QoS qos, bool retained);

retained：表示消息会保留在服务器上，即接收端每一次连接后都将收到保留在服务器上的主题，保留的主题清除方式：直接将主题内容置空即可

注意：发布消息时，retained虽然为true，但接收端不希望每次连接后都收到来自服务器上驻留的消息，怎么办？协议中对此进行了专门的开关设置：属性为Clean Session，因此在与服务器建立连接时，就有一个参数void Connect(string willTopic, QoS willQoS, MqttPayload willMsg, bool willRetain, bool cleanStart);

3、如何获取消息的发送状态

其实，在发布者向服务器通信后，服务器都很礼貌地进行了消息的回复，具体消息见协议：CONNACK

类库中对应的封装大致如下，可能会因语言版本不同而有所差异，但大致都是如此：

void qosManager_MessageReceived(object sender, MqttMessageReceivedEventArgs e)

{

if (e.Message == null)

{

//a null message means we have disconnected from the broker

OnConnectionLost(new EventArgs());

return;

}

switch (e.Message.MsgType)

{

case MessageType.CONNACK:

var connack = ((MqttConnackMessage)e.Message);

if (connack.Response == MqttConnectionResponse.Accepted)

OnConnected(new EventArgs());

MQTT消息传输机制（协议解读与调用实例）李阳

else

OnConnectionLost(new MqttConnackEventArgs(connack.Response));

break;

case MessageType.DISCONNECT:

break;

case MessageType.PINGREQ:

manager.SendMessage(new MqttPingRespMessage());

break;

case MessageType.PUBACK:

MqttPubackMessage puback = (MqttPubackMessage)e.Message;

OnPublished(new CompleteArgs(puback.AckID));

break;

case MessageType.PUBCOMP:

break;

case MessageType.PUBLISH:

MqttPublishMessage m = (MqttPublishMessage)e.Message;

OnPublishArrived(m);

break;

case MessageType.PUBREC:

break;

case MessageType.PUBREL:

MqttPubrelMessage pubrel = (MqttPubrelMessage)e.Message;

OnPublished(new CompleteArgs(pubrel.AckID));

break;

case MessageType.SUBACK:

MqttSubackMessage m1 = (MqttSubackMessage)e.Message;

MQTT消息传输机制（协议解读与调用实例）李阳

OnSubscribed(new CompleteArgs(m1.AckID));

break;

case MessageType.UNSUBACK:

MqttUnsubackMessage m2 = (MqttUnsubackMessage)e.Message;

OnUnsubscribed(new CompleteArgs(m2.AckID));

break;

case MessageType.PINGRESP:

break;

case MessageType.UNSUBSCRIBE:

case MessageType.CONNECT:

case MessageType.SUBSCRIBE:

default:

throw new Exception("Unsupported Message Type");

}

}

类库对外的通知消息显得格外的简单，只是定义了一些诸如：connected,disconnected,publishArrive等事件进行处理，其实对服务器的任何通信都是有回复的，对上述代码其实已经无需做太多的解释，结果已经很明了。

4、消息发送失败及接收端下线，如何确保接收端再次登录后有正常接收到消息？

服务器要根据先前此客户端在发送CONNECT消息可变头部Connect flag中的“Clean session flag”所设置值，再次复习一下：

1.值为0，服务器必须在客户端断开之后继续存储/保持客户端的订阅状态。这些状态包括：

o存储订阅的消息QoS1和QoS2消息

o正在发送消息期间连接丢失导致发送失败的消息

o以便当客户端重新连接时以上消息可以被重新传递。

2.值为1，服务器需要立刻清理连接状态数据。

有一点需要牢记，服务器在接收到客户端发送的DISCONNECT消息之后，需要主动关闭TCP/IP连接。

MQTT消息传输机制（协议解读与调用实例）李阳

这一点与第二点问题描述是相同的，对willRetain和cleanStart两个参数配置设置即可完成此功能

5、用户登录验证，服务器需开启验证机制

原文如下：

Security

Beginning with MQTT v3.1, a username and password can now be sent by the client at connect time. For older clients which do not support username and password, there is the capability of limiting connections to those clients whose clientid starts with one of a set of prefixes, with the clientid_prefixes configuration parameter.

Authentication of Clients

By default, all clients are able to connect regardless of whether they provide a username and password or not. This can be changed by setting the password_file configuration parameter. This points at a password file that lists the valid usernames in the following format:

username:password

As the passwords are stored in clear-text, care must be taken to protect access to the file using standard Operating System file permissions.

The allow_anonymous configuration parameter can be used to control whether clients that do not provide a username and password can still connect to the broker.

译文如下：

MQTT消息传输机制（协议解读与调用实例）李阳

安全

用MQTT V3.1的开始，一个用户名和密码可以发出的客户端在连接时。旧版本客户端不支持的用户名和密码，用clientid_prefixes配置参数可限制以一组前缀连接的客户的ClientID。

认证的客户

默认情况下，所有的客户端都可以连接不管他们是否提供用户名和密码。可以通过设置password_file配置参数的变化。密码文件中列出了有效的用户名，格式：用户名：密码[username:password]

密码以明文形式存储，必须注意保护访问使用标准的操作系统文件的权限的文件。

该allow_anonymous配置参数可用于控制客户是否不提供用户名和密码可以连接到代理。

类库中对应的封装大致如下，可能会因语言版本不同而有所差异，但大致都是如此：

public static IMqtt CreateClient(string connString, string clientId, string username= null, string password= null, IPersistence persistence = null)

{

return new Mqtt(connString, clientId, username, password, persistence);

}

Linux下开启登录验证方法：

1.allow_anonymous false

2.password_file pwfile.example

需写上绝对路径并且不带空格(经测试，非绝对路径将无法启动服务)

以下内容引用互联网：

如果需要配置一些用户名、密码、用户权限的参数，则需要修改安装目录下的mosquitto.conf文件

下面来说说用到的一些参数吧：

MQTT消息传输机制（协议解读与调用实例）李阳

①用户密码：#password_file pwfile.example 后面跟着是用户密码配置文件，需写上绝对路径并且路径不带空格

②创建用户密码：打开doc窗口，进入mosquitto安装目录，运行mosquitto_passwd -c pwfile.example userName 回车，然后输入密码(密码输入两遍后，在该文

件里会自动加密密码)

生成的文件内容格式例如：

userName:$6$Ls7JYQTdn9xagJJ2$zngeT758n1Wn1hnVLjFdK2cHb6lcmI5CMrMTNZe2SqkUj0fBgKts62gvlyWYwdY3/WArx/SAtFRKlvKKnHRCUg==

userName2:$6$bymgVcrtj+7wj8mR$nq1atPD3nreRgA6gDbDjfbUGZIlrmenOcWrXMoneBp+zmAxnOybqJvrBZboxX1XXPnz/TKZwz9aKQJ72zJym5A=

③如果想再增加用户，则执行mosquitto_passwd -u pwfile.example userName2即可

④用户权限：#acl_file aclfile.example 后面跟着是用户权限配置文件，需写上绝对路径并且路径(经测试，非绝对路径将无法启动服务)

文件内容格式为：

user userName

原配置内容介绍如下：

# This affects access control for clients with no username.

topic read $SYS/#

# This only affects clients with username "roger".

user roger

topic foo/bar

# This affects all clients.

pattern write $SYS/broker/connection/%c/state

这里要对官方提供的文档进行纠正，原文“As the passwords are stored in clear-text”，经验证，密码是经过加密的，并非明文

经本人验证，以上方法在Windows无法验证通过

MQTT消息传输机制（协议解读与调用实例）李阳