c++ mqtt客户端_MQTT原理学习总结

简介

MQTT(消息队列遥测传输)英文全称: Message Queue Telemetry Transport

MQTT是一种轻量级的发布-订阅消息传递协议，它可能最适合各种物联网设备。你可以在此处找到有关MQTT的更多信息。

MQTT 协议可以为大量的低功率、工作网络环境不可靠的物联网设备提供通讯保障。而它的应用范围也不仅如此，在移动互联网领域也大有作为：很多 Android App 的推送功能，都是基于 MQTT 实现的，也有一些 IM的实现，是基于 MQTT 的。

特点

简单的来说 MQTT 协议有以下特性：

• 基于 TCP 协议的应用层协议；
• 采用 C/S 架构；
• 使用订阅/发布模式，将消息的发送方和接受方解耦；
• 提供 3 种消息的 QoS(Quality of Service): 至多一次，最少一次，只有一次；
• 收发消息都是异步的，发送方不需要等待接收方应答。

Client和Broker建立连接

CONNECT

连接的建立由 Client 端发起，Client 端首先向 Broker 发送一个 CONNECT 数据包，CONNECT 数据包包含以下内容(这里我们略过 Fixed header)。

可变头(Variable header)

在 CONNECT 数据包可变头中，含有以下信息。

• 协议名称(Protocol Name)：值固定为字符 “MQTT”。
• 协议版本(Protocol Level)：对 MQTT 3.1.1 来说，值为 4。
• 用户名标识(User Name Flag)：消息体中是否有用户名字段，1bit，0 或者 1。
• 密码标识(Password Flag)：消息体中是否有密码字段，1bit，0 或者 1。
• 遗愿消息 Retain 标识(Will Retain)：标识遗愿消息是否是 Retain 消息，1bit，0 或者 1。
• 遗愿消息 QOS 标识(Will QOS)：标识遗愿消息的 QOS，2bit，0、1 或者 2。
• 遗愿标识(Will Flag)：标识是否使用遗愿消息，1bit，0 或者 1。
• 会话清除标识(Clean Session)：标识 Client 是否建立一个持久化的会话，1bit，0 或者 1，当 CleanSession 的标识设为 0 时，代表 Client 希望建立一个持久会话的连接，Broker 将存储该 Client 订阅的主题和未接受的消息，否则 Broker 不会存储这些数据，同时在建立连接时清除这个 Client 之前存在的持久化会话所保存的数据。
• 连接保护(Keep Alive): 设置一个单位为秒的时间间隔，Client 和 Broker 之间在这个时间间隔之内需要至少有一次消息交互，否则 Client 和 Broker 会认为它们之间的连接已经断开。

消息体(Payload)

CONNECT 数据包的消息体中包含以下数据。

• 客户端标识符(Client Identifier)：Client Identifier 是用来标识 Client 身份的字段，在 MQTT 3.1.1 的版本中，这个字段的长度是 1 到 23 个字节，而且只能包含数字和 26 个字母(包括大小写)，Broker 通过这个字段来区分不同的 Client。所以在连接的时候，Client 应该保证它的 Identifier 是唯一的，通常我们可以使用比如 UUID，唯一的设备硬件标识，或者 Android 设备的 DEVICE_ID 等作为 Client Identifier 的取值来源。 MQTT 协议中要求 Client 连接时必须带上 Client Identifier，但是也允许 Broker 在实现时 Client Identifier为空，这时 Broker 会为 Client 分配一个内部唯一的 Identifier。如果你需要使用持久化会话，那就必须自己为Client 设定一个唯一的 Identifier。
• 用户名(Username)：如果可变头中的用户名标识设为 1，那么消息体中将包含用户名字段，Broker 可以使用用户名和密码来对接入的 Client 进行验证，只允许已授权的 Client 接入。注意不同的 Client 需要使用不同的 Client Identifier，但它们可以使用同样的用户名和密码进行连接。
• 密码(Password)：如果可变头中的密码标识设为 1，那么消息体中将包含密码字段。
• 遗愿主题(Will Topic)：如果可变头中的遗愿标识设为 1，那么消息体中将包含遗愿主题，当 Client 非正常地中断连接的时候，Broker 将向指定的遗愿主题中发布遗愿消息。
• 遗愿消息(Will Message)：如果可变头中的遗愿标识设为 1，那么消息体中将包含遗愿消息，当 Client 非正常的中断连接的时候，Broker 将向指定的遗愿主题中发布由该字段指定的内容。

CONNACK

当 Broker 收到 Client 的 CONNECT 数据包之后，将检查并校验 CONNECT 数据包的内容，之后回复 Client一个 CONNACK 数据包。

CONNACK 数据包包含以下内容(这里我们略过 Fixed header)。

可变头(Variable header)

CONNACK 数据包的可变头中，含有以下信息。

• 会话存在标识(Session Present Flag)：用于标识在 Broker 上，是否已存在该 Client(用 Client Identifier区分)的持久性会话，1bit，0 或者 1。当 Client 在连接时设置 Clean Session=1，则 CONNACK 中的Session Present Flag 始终为 0；当 Client 在连接时设置 Clean Session=0，那么就有两种情况——如果Broker 上面保存了这个 Client 之前留下的持久性会话，那么 CONNACK 中的 Session Present Flag 值为 1；如果 Broker 没有保存该 Client 的任何会话数据，那么 CONNACK 中的 Session Present Flag 值为 0。Session Present Flag 这个特性是在 MQTT 3.1.1 版本中新加入的，之前的版本中并没有这个标识。
• 连接返回码(Connect Return code)：用于标识 Client 是 Broker 的连接是否建立成功，连接返回码有以下一些值：

Return Code连接状态0连接已建立1连接被拒绝，不允许的协议版本2连接被拒绝，Client Identifier 被拒绝3连接被拒绝，服务器不可用4连接被拒绝，错误的用户名或密码5连接被拒绝，未授权

这里重点讲一下 Return Code 4 和 5。

Return Code 4 在 MQTT 协议中的含义是 Username 和 Password 的格式不正确，但是在大部分的 Broker 实现中，在使用错误的用户名密码时，得到的返回码也是 4。所以这里我们认为 4 就是代表错误的用户名或密码。

Return Code 5 一般在 Broker 不使用用户名和密码而使用 IP 地址或者 Client Identifier 进行验证的时候使用，来标识 Client 没有通过验证。

注意： Return Code 2 代表的