Linux--(三）MQTT协议参数

一、QoS

QoS 是 Quality of Service 的缩写，所以中文名便是服务质量。一个物联网通信中有些信息非常重要，我们需要确保这类重要信息可以准确无误的发送和接收，而有些信息则相对不那么重要，这类信息如果在传输中丢失不会影响系统的运行；QoS 便用于告诉客户端或服务器哪些信息是重要信息，需要准确无误的传输、不可丢失；哪些信息不是那么重要，即使在传输过程中丢失也无妨！

MQTT 设计了一套保证消息稳定传输的机制，包括消息应答、存储和重传。在这套机制下，提供了三种不同级别的 QoS （ Quality of Service ），也就是 MQTT 协议有三种服务质量等级：

⚫ QoS = 0 ：最多发一次；

不管接收方收没收到，发送放只发送一次。

⚫ QoS = 1 ：保证收一次；

发送端向接收端发送 PUBLISH 报文，当接收端收到 PUBLISH 报文后会向发送端回复一个 PUBACK 报文，如果发送端收到 PUBACK 报文，那么它就知道消息已经被接收端成功接收！

假如过了一段时间后，发送端没有收到 PUBACK 报文，那么发送端会再次发送消息（发送 PUBLISH 报文），然后再次等待接收端的 PUBACK 确认报文。因此，当 QoS=1 时，发送端在一定时间内没有收到接收端的 PUBACK 确认报文，会重复发送同一条消息。

⚫ QoS = 2 ：保证只收一次。

MQTT 服务质量最高级是 2 级，即 QoS=2 。当 MQTT 服务质量为 2 级时， MQTT 协议可以确保接收端只接收一次消息（注意是只接收到一次，在 QoS=1 的情况下，接收端接收到消息的次数可能不止一次： >=1 ）。

另外，要想实现 QoS>0 的 MQTT 通信，客户端在连接服务端时务必要将 cleanSession 设置为 false 。如果这一步没有实现，那么客户端是无法实现 QoS>0 的 MQTT 通信，因为如果 cleanSession 设置为 true ，则意味着客户端不会接收到任何离线消息，包括 QoS1 和 QoS2 的情况。

服务质量降级

当客户端在发布消息和订阅主题时用的不同接别的QOS，服务端会采用低级别的质量等级进行服务。

二、保留消息

保留消息的作用，其实非常简单，就是让服务端对客户端发布的消息进行保留，如果有其它客户

端订阅了该消息对应的主题时，服务端会立即将保留消息推送给订阅者，而不必等到发送者向主题发布新消息时订阅者才会收到消息。

更新保留消息

但是需要注意的是，每一个主题只能有一个“保留消息”，如果客户端想要更新“保留消息”，就需要向该主题发送一条新的“保留消息”，这样服务端会将新的“保留消息”覆盖旧的“保留消息”。当有客户端订阅该主题时，服务端就会将最新的“保留消息”发送给订阅者。

三、MQTT心跳机制

在医院里，医生利用心跳来判断患者是否还有生命体征。对于 MQTT 服务器来说，它要判断 MQTT 客 户端是否依然与它保持着连接，就是检查该客户端是不是经常给它发送心跳数据包，如果经常收到客户端的消息，那么证明该客户端肯定在线。

四、MQTT的遗嘱机制

客户端断开与服务端的连接通常是有两种方式的：

⚫ 客户端主动向服务端发送 DISCONNECT 报文，请求断开连接，自然服务端也就知道了客户端要离线了；

⚫ 客户端 意外掉线 。被动与服务端断开了连接

MQTT 协议允许客户端在“活着”的时候就写好遗嘱，这样一旦客户端 意外断线 ，服务端就可以将客户端的遗嘱公之于众。请注意，在这段话中，意外断线 这几个字特意做了加粗处理，这是因为，客户端的遗嘱只在意外断线时才会发布，如果客户端正常的断开了与服务端的连接（主动断开），这个遗嘱机制是不会启动的，服务端也不会将客户端的遗嘱公布。

那什么是意外断线？其实除了客户端主动向服务端发送 DISCONNECT 报文请求断开连接这种情况之外，其它断线的情况都属于意外断开连接，譬如网络不稳定、客户端设备没电关机了等。

五、MQTT用户密码设置

有些 MQTT 服务端需要客户端在连接时提供用户名和密码，只有客户端正确提供了用户名和密码后， 才能连接服务端，否则服务端将会拒绝客户端连接，那么客户端也就无法发布和订阅消息了。

用户名和密码除了用于在连接服务端时进行认证、校验这一功能外，有些 MQTT 服务端也利用此信息来识别客户端属于哪一个用户，从而对客户端进行管理。譬如用户可以拥有私人主题，这些主题只有该用户可以发布和订阅；对于私人主题，服务端就可以利用客户端连接时的用户名和密码来判断该客户端是否有发布订阅该用户私人主题的权限。