目錄

# 開篇

1. 精細MQS TT QoS的行為

1.1 QoS 0: 最多交付一次（At Most Once）

1.2?QoS 1: 至少交付一次（At Least Once）

1.3?QoS 2: 只交付一次（Exactly Once）

1.4?傳輸過程圖示

1.5?總結

2.?MQTT 數據大小限制和發送原理

2.1?EMQX 數據大小限制

2.2?Mosquitto 數據大小限制

2.3?發送數據的原理

2.4?MQTT 原理的時序圖

2.5?Qos中的四次握手

2.6 相關配置示例

2.6.1 EMQX 配置 QoS 示例

2.6.2?Mosquitto 配置 QoS 示例

---

# 開篇

Qos設置：

????????很多時候，使用 MQTT 協議的設備都運行在網絡受限的環境下，而只依靠底層的 TCP 傳輸協議，并不能完全保證消息的可靠到達。因此，MQTT 提供了 QoS 機制，其核心是設計了多種消息交互機制來提供不同的服務質量，來滿足用戶在各種場景下對消息可靠性的要求。

MQTT 定義了三個 QoS 等級，分別為：

• QoS 0，最多交付一次。
• QoS 1，至少交付一次。
• QoS 2，只交付一次。

????????其中，使用 QoS 0 可能丟失消息，使用 QoS 1 可以保證收到消息，但消息可能重復，使用 QoS 2 可以保證消息既不丟失也不重復。QoS 等級從低到高，不僅意味著消息可靠性的提升，也意味著傳輸復雜程度的提升。

????????在一個完整的從發布者到訂閱者的消息投遞流程中，QoS 等級是由發布者在 PUBLISH 報文中指定的，大部分情況下 Broker 向訂閱者轉發消息時都會維持原始的 QoS 不變。不過也有一些例外的情況，根據訂閱者的訂閱要求，消息的 QoS 等級可能會在轉發的時候發生降級。

例如，訂閱者在訂閱時要求 Broker 可以向其轉發的消息的最大 QoS 等級為 QoS 1，那么后續所有 QoS 2 消息都會降級至 QoS 1 轉發給此訂閱者，而所有 QoS 0 和 QoS 1 消息則會保持原始的 QoS 等級轉發。

1. 精細MQS TT QoS的行為

????????讓我們來進一步明確每種 MQS TT QoS 的行為，特別是消息傳輸過程中丟失與重復的風險和保障：

1.1 QoS 0: 最多交付一次（At Most Once）

• 特征：
  • 無消息確認：發送者發送消息后，不需要確認消息是否到達接收者。
  • 無重試：如果消息在傳輸過程中丟失，發送者不會再次發送該消息。
• 風險：消息可能丟失。在網絡不穩定或發生傳輸錯誤時，消息可能不會到達接收者。
• 適用場景：適合對消息丟失不敏感的應用，例如發送傳感器數據，實時監測數據，或日志記錄。

1.2?QoS 1: 至少交付一次（At Least Once）

• 特征：
  • 消息確認：發送者發送消息后，需要接收者（或代理）確認消息已接收（通過 PUBACK）。
  • 支持重試：如果發送者在規定時間內未收到確認，將重新發送消息，直到收到確認。
• 風險：消息可能重復。由于重試機制，如果網絡中斷或接收確認消息丟失，發送者會重發，可能導致接收者收到重復的消息。
• 適用場景：適合需要確保消息到達但能處理重復消息的應用，例如狀態更新、簡單的事務操作。

1.3?QoS 2: 只交付一次（Exactly Once）

• 特征：
  • 高級消息確認：通過復雜的四步握手過程（PUBREC、PUBREL、PUBCOMP），確保消息僅傳輸一次，避免重復。
  • 支持重試：如果在任何一步未收到確認，發送者和接收者都會重試相應步驟，直到完成整個確認過程。
• 風險：消息不會丟失或重復。確保了消息在傳輸中不會丟失，并且不會重復到達接收者。
• 適用場景：適合不能接受消息丟失或重復的應用，例如金融交易、訂單處理等關鍵業務場景。

1.4?傳輸過程圖示

QoS 級別	發送者行為	接收者行為	過程圖示
QoS 0	發送一次	立即處理	Publisher -> Broker -> Subscriber
QoS 1	發送->等待確認	確認->處理	Publisher -> Broker <-> PUBACK -> Subscriber
QoS 2	發送->等待 PUBREC -> PUBREL -> PUBCOMP	確認 PUBREC -> 等待 PUBREL -> 確認 PUBCOMP	Publisher -> Broker <-> PUBREC <-> PUBREL <-> PUBCOMP -> Subscriber

1.5?總結

• QoS 0：適用于對消息丟失無所謂的場景。消息可能丟失。
• QoS 1：適用于需要保證消息到達但能接受重復消息的場景。消息可能重復。
• QoS 2：適用于需要嚴格保證消息不丟失且不重復的場景。消息不會丟失也不會重復。

選擇合適的 QoS 級別取決于應用的可靠性需求和可以容忍的傳輸錯誤類型。

2.?MQTT 數據大小限制和發送原理

2.1?EMQX 數據大小限制

• 默認最大數據大小：1 MB
• 最大可配置數據大小：256 MB
• 設置項：可以通過配置文件 emqx.conf 或 EMQX Dashboard 中的 Max Packet Size 來調整。

2.2?Mosquitto 數據大小限制

• 默認最大數據大小：可以通過 mosquitto.conf 文件中的 message_size_limit 配置項調整，具體默認值隨版本和配置不同而異，一般設置為 268435455 字節 (約 256 MB) 。

2.3?發送數據的原理

MQTT 發送數據的基本流程：

1. 連接：客戶端與 MQTT Broker 建立連接。
2. 訂閱：客戶端訂閱一個或多個主題。
3. 發布：客戶端向訂閱的主題發布消息。
4. 接收：訂閱該主題的客戶端接收消息。
5. 確認：根據 QoS（服務質量）等級，可能會有確認消息的發送。

詳細步驟：

• 建立連接：客戶端使用 MQTT 協議的 CONNECT 報文連接到 Broker。
• 訂閱主題：客戶端發送 SUBSCRIBE 報文，指定要訂閱的主題。
• 發布消息：使用 PUBLISH 報文發布消息到某個主題。
• 消息轉發：Broker 接收到消息后，將其轉發給所有訂閱該主題的客戶端。
• 消息接收和確認：客戶端接收消息，若 QoS 級別要求，需要發送 PUBACK（QoS 1）或 PUBREC/PUBREL/PUBCOMP（QoS 2）確認消息的遞送。

2.4?MQTT 原理的時序圖

????????MQTT（Message Queuing Telemetry Transport）協議是一種基于發布/訂閱模式的輕量級消息傳輸協議，廣泛應用于物聯網（IoT）領域。以下是 MQTT 消息從客戶端到 Broker 再到訂閱者的完整時序圖。

解釋：?

• CONNECT: 客戶端發起連接請求。
• CONNACK: Broker 響應連接請求。
• SUBSCRIBE: 客戶端訂閱一個或多個主題。
• SUBACK: Broker 確認訂閱。
• PUBLISH (QoS 0): 客戶端發布消息，QoS 0 表示最多一次交付，不需要確認。
• PUBLISH (QoS 1): 客戶端發布消息，QoS 1 表示至少一次交付，需要確認。
• PUBLISH (QoS 2): 客戶端發布消息，QoS 2 表示精確一次交付，需經過四次握手確認。
• DISCONNECT: 客戶端斷開連接。

2.5?Qos中的四次握手

????????MQTT（Message Queuing Telemetry Transport）協議中的QoS（Quality of Service）級別有三個等級：0、1、2。QoS 2 是最高級別的保證消息傳遞的質量。

在MQTT中，QoS 2使用了四次握手來確保消息的可靠傳遞：

1. 發起請求：發送端（Publisher）將消息發送給接收端（Subscriber），并請求QoS 2級別的確認。
2. 接收確認：接收端收到消息后，向發送端發送確認收到的消息（PUBREC）。
3. 發送確認：發送端接收到確認消息后，發送PUBREL給接收端，表示可以釋放消息。
4. 完成確認：接收端收到PUBREL后，發送最終的確認消息（PUBCOMP），表示消息已經完成傳遞。

這四次握手確保了消息的可靠性和順序性，即使在網絡不穩定或斷開連接后，也能夠確保消息不會丟失或重復傳輸。

2.6 相關配置示例

2.6.1 EMQX 配置 QoS 示例

在 emqx.conf 中：

mqtt.max_qos = 2

2.6.2?Mosquitto 配置 QoS 示例

Mosquitto 配置 QoS 示例

max_qos 2