【如何构建商业级别聊天系统】 MQTT 篇（一）初识 MQTT

﹏ヽ暗。殇╰゛Y 2023-01-23 14:53 1阅读 0赞

### 聊聊 MQTT ###

完整版请访问：[聊聊 MQTT][MQTT]

首先 MQTT （Message Queuing Telemetry Transport，消息队列遥测传输协议） 是个通信协议，其诞生是为了进行轻量级通信，可以在更加轻量的设备上进行通信。而不像 HTTP 这么庞大。

一般聊到 MQTT 的时候都会聊到一个名词 IoT 是 **Internet of Things** 的缩写，一般翻译过来是物联网，而对于我来说，对物联网的理解还停留在 网络连接灯、门锁、摄像头，这些。很自然而然的排除了最最常见的 手机，电脑。那其实来说所有连接网络的物理设备都可以称作物联网。而我们现在电脑手机越来越多的使用 wifi、4G 这种连接方式，网络不稳定是常事，MQTT 应运而生。

#### 设计规范 ####

*  精简
 *  发布订阅模式 -> 方便消息传递
 *  动态创建主题 -> 零运维成本
 *  低传输量 -> 高传输效率
 *  考虑 低带宽、高延迟、不稳定网络因素
 *  支持连续会话控制
 *  考虑 低计算能力客户端
 *  提供服务质量管理
 *  不强求传输数据类型与格式 -> 保持灵活

#### 特性 ####

1.  发布订阅消息模式，提供一对多消息发布。实现与应用程序解耦
2.  对负载内容屏蔽的消息传输机制
3.  使用 TCP/IP 提供网络连接
4.  消息传输提供三种服务质量 QoS（Quality of Service 服务质量）
    
    1.  最多一次，这一级别会发生消息重复或者丢失 QoS = 0
    2.  至多一次，这一级别会确保消息到达，但消息可能会重复 QoS = 1
    3.  只有一次，确保消息只有一次到达，QoS = 2
5.  数据传输最小化，固定长度的头部只有 2 字节
6.  使用 Last Will 和 Tesament 特性通知有关各方客户端异常中断机制。
    
    1.  Last Will 遗言机制，用于通知同一主题下的其他设备，发送遗言的设备已经断开连接。

#### MQTT 的一些要点 ####

在通讯过程中，MQTT 有三种身份： 发布者 Publish 、代理 Broker 、订阅者 Subscribe

其中 发布者、订阅者 由 **客户端** 来充当，代理则为 **服务端**

**都在说的 发布订阅模式 到底好在哪？**

*  空间解耦：发布者和订阅者不需要相互了解。
 *  时间解耦：发布者和订阅者不需要同时运行。
 *  同步解耦：两个组件的操作在发布或接收时不需要中断。

发布/订阅 模型消除了 消息发布者 和 消息订阅者之间的直接通信。通过代理来控制哪个订阅者接收哪个消息。

**MQTT 是消息队列吗？ 它和消息队列有什么区别？**

1.  消息队列

**Clean Session**

clean session 标识用于告诉 broker 服务器 是否建立长久会话。

如果是长久会话 即 CleanSession = false ，broker 将存储 client 所有的订阅，以及 QoS 级别为 1 或者 2 所有丢失的消息。

如果非持久会话 CleanSession = true ，broker 将不会存储任何来自于客户端的信息并且会清楚任何上次持久会话的信息。

**Username/Password**

MQTT 可以发送用户名和密码来为客户端进行验证和授权。

**Will Message**

遗言消息，last will message 是 Last Will 和 Testament （LWT）的一部分。当客户端异常断开连接的时候，这个消息将会通知到其他客户端。当客户端进行连接时，它可以以 MQTT 消息 和 CONNECT 消息中的主题的形式向 broker 提供 last will 信息，如果客户端异常断开，broker 服务器将代表客户端发送 LWT 消息。

**KeepAlive**

keep alive 是客户端在建立连接时指定给 broker 的秒级时间间隔，此间隔定义了 broker 和 client 在不发送任何消息的情况下所能忍受的最大时间，客户端承诺向 broker 发送常规 PING 请求消息，代理以 PING response 进行相应，这是 客户端 与 broker 保活的重要方式

### Broker 的 CONNACK 回复 ###

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3Nz58mws-1626351560553)(/Users/admin/Library/Application Support/typora-user-images/image-20210715144819580.png)\]

当 broker 接收到 CONNECT 消息，其有义务回复 CONNACK 消息

CONNACK message 包含两部分

*  The session present flag 会话当前标识
 *  A connect return code 连接返回状态码

**Session Present flag**

此标识告诉客户端，在先前的交互中 broker 是否已经保持 可用的持久会话。当 客户端设置了 Clean Session 为 true 时，这个值总是不可用的 即 false ，因为这里永远不会有可用的会话。如果设置 Clean Session 为 false

这里会出现两种情况：

如果 对应 clientId 的会话信息可用，且 broker 已存储会话信息，此时返回为 true

否则 如果 broker 没有 clientId 的任何会话信息，返回为 false

**Connect return code**

connect return code 用于告知 client 端连接是否可用

<table> 
 <thead> 
  <tr> 
   <th>Return Code</th> 
   <th>Return Code Response</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>0</td> 
   <td>Connection accepted 连接接受</td> 
  </tr> 
  <tr> 
   <td>1</td> 
   <td>Connection refused，unacceptable protocol version 连接拒绝，不可接受的协议版本</td> 
  </tr> 
  <tr> 
   <td>2</td> 
   <td>Connection refused, identifier rejected 标识符被拒绝</td> 
  </tr> 
  <tr> 
   <td>3</td> 
   <td>Connection refused, server unavailable 服务不可用</td> 
  </tr> 
  <tr> 
   <td>4</td> 
   <td>Connection refused, bad user name or password 错误的用户名或密码</td> 
  </tr> 
  <tr> 
   <td>5</td> 
   <td>Connection refused, not authorized 未授权</td> 
  </tr> 
 </tbody> 
</table>

[MQTT]: https://mp.weixin.qq.com/s/sr2u5GLOMvRy2R568z0YjA