服务质量(QoS)级别是MQTT的关键特性之一，定义了消息投递的规则。 该特性在设计与broker和连接客户端交互的稳健可靠通信系统中至关重要，尤其在物联网(IoT)领域。
以下列举QoS特性在MQTT中帮助解决的主要挑战：
- 网络可靠性：MQTT依赖TCP作为数据传输协议。在恶劣网络条件下，TCP无法保证数据包必定送达。QoS 1和QoS 2通过按需求确保消息投递来应对此问题。
- 系统崩溃：若发布者或订阅者在消息发送后、处理前崩溃，QoS可避免消息丢失。
- 防止重复：QoS 2设计为确保消息仅被投递给接收者一次。
- 避免订阅者过载：在QoS 1和QoS 2下，若客户端未确认前序消息的接收，发布者将不再继续向其发送新消息。
- 消息持久化：MQTT支持为当前离线的客户端持久化QoS 1和QoS 2消息。客户端下次连接时，这些遗漏的消息会被投递。
QoS级别
MQTT定义了三个服务质量级别：
- QoS 0-至多一次（默认）。用于非关键数据，速度优先于可靠性。
- QoS 1-至少一次。用于重要数据，偶尔重复可接受。
- QoS 2-恰好一次。用于关键数据，不允许丢失或重复。
QoS 0-至多一次
在此默认模式下，消息可能投递一次也可能不投递。不会出现重复消息。
需要一条消息：
- 发送方发送 PUBLISH (1) 报文。
消息发送后，发送方将其从消息队列移除。 因此该模式有时称为 “发射即忘”。 与QoS 1不同，发送方不期望接收方对消息已送达进行确认。
QoS 0需要最少的网络占用，因无确认开销而具备最快性能（最低延迟）。
同时QoS 0具有最低可靠性，无法保证消息投递。因此不适合必须收到每条消息的关键数据。
QoS 1-至少一次
消息至少投递一次，确保接收方收到，但不保证只投递一次。
需要两条消息：
- 发送方发送 PUBLISH (1) 报文。
- 接收方回复 PUBACK (2) 报文。
在不稳定连接场景下可能出现重复消息，例如：
- 发送方发出PUBLISH报文，但接收方未收到。发送方会反复重发PUBLISH。收到接收方的PUBACK确认后，消息才从队列移除。
- 发送方发出PUBLISH，接收方收到并回复PUBACK，但回复在途中丢失。发送方无法得知接收方是否收到，会继续重发直到收到确认。
使用QoS 1能确保重要数据不会因传输问题丢失，但也意味着任何未确认都会导致重复消息。
QoS 2-恰好一次
消息恰好投递一次，既无重复也无丢失。
需要4条消息：
- 发送方发送 PUBLISH (1) 报文。
- 接收方回复 PUBREC (2) 报文。
- 发送方收到PUBREC后发送 PUBREL (3) 报文，包含报文ID等用于保证恰好一次投递的关键信息。
- 接收方收到PUBREL后回复 PUBCOMP (4) 报文。
只有收到PUBCOMP后，发送方才能重传PUBLISH或发送具有相同Packet ID的新消息。
通过发送方与接收方间的四步握手保证恰好一次投递，代价是最慢性能和最高网络占用。
如何选择QoS？IoT用例
以下为IoT系统中选择合适QoS时需考虑的一些常见场景。
QoS 0-至多一次
适用于速度优先于可靠性或偶发消息丢失（如网络不稳定、客户端意外断开、broker过载等）可接受的场景，如非关键传感器数据。
- 环境传感器数据
- 用例：温室的温度传感器向监控系统发送周期性更新。
- 使用原因：偶发数据丢失可接受，因为后续读数会提供最新状态。
- 非关键通知
- 用例：智能灯系统向中心服务器发送状态更新。
- 使用原因：若消息丢失，下次更新会纠正状态，即时一致性不是关键。
QoS 1-至少一次
适用于数据丢失不可接受但可处理重复的场景。
- 车辆遥测数据
- 用例：车辆向车队管理系统发送遥测数据（如位置、速度、油量）。 若车辆遭遇短暂断网或broker的确认延迟/丢失，车辆MQTT客户端会重发遥测数据，导致车队管理系统收到多次相同数据。
- 使用原因：确保重要数据至少被接收一次，即使出现重复。
- 家庭安防告警
- 用例：家庭安防系统向户主手机应用发送告警（如检测到移动、门被打开）。 当broker因网络延迟或中断未能发送确认时，安防系统会重发告警，户主可能收到同一事件的多次通知。
- 使用原因：重要告警必须送达应用，即使需要处理重复。
QoS 2-恰好一次
最适合消息重复或丢失不可接受的关键应用，如金融交易或关键指令。
- 金融交易
- 用例：支付系统在终端与中心服务器间发送交易详情。
- 使用原因：确保每笔交易恰好处理一次，防止重复或丢失。
- 工业自动化指令
- 用例：发送至工业机械以进行精确控制与操作的指令。
- 使用原因：关键指令必须恰好执行一次，避免错误或事故。
对比表
| 性能 | 消息是否投递 | 重复 | 报文 | |
| QoS 0-至多一次 | 最快 | 可能 | 不可能 | 1. PUBLISH |
| QoS 1-至少一次 | 一般 | 是 | 可能 | 1. PUBLISH 2. PUBACK |
| QoS 2-恰好一次 | 最慢 | 是 | 不可能 | 1. PUBLISH 2. PUBREC 3. PUBREL 4. PUBCOMP |
降级
在MQTT通信中，发布者与订阅者必须使用相同的服务质量才能正确理解彼此。 但发布消息的QoS与订阅客户端的QoS可能不同。
QoS不同时适用一条简单规则：采用较低的QoS，无论该QoS来自发送方还是接收方。 例如，客户端A以QoS 1发布消息，而客户端B以QoS 2订阅同一主题，则消息将以QoS 1投递。
消息排队与会话持久化
在MQTT协议中，消息队列行为取决于所选的服务质量，直接影响消息的投递与存储。
若会话为清洁会话（clean session设为true），无论所选QoS如何，broker都不会为客户端存储任何信息，会话在客户端断开时结束。 任何排队或未确认的消息都会丢失。
若会话为持久会话（clean session标志设为false）且选择了 QoS 1 或 QoS 2，broker会为已断开的、且订阅了消息发布主题的客户端排队消息。 排队的消息在客户端重连后发送。broker保证消息按发布顺序投递，即使客户端重连后亦然。
重连时，客户端须能处理可能大量涌入的排队消息，这可能影响性能并需要高效的消息处理逻辑。 每条消息须由客户端确认才能从队列移除。 重连后，若客户端离线前已收到部分消息，重连时可能收到重复消息。 客户端需妥善处理这些重复。
请注意，对于 QoS 0，broker不排队消息。