- MQTT 根據此處定義的服務質量 (QoS) 級別傳送應用程序消息。
- 傳送協議是對稱的，在下面的描述中，客戶端和服務器各自可以充當發送者或接收者的角色。 傳送協議僅涉及將應用程序消息從單個發送方傳送到單個接收方。
- 當服務器向多個客戶端傳遞應用程序消息時，每個客戶端都會被單獨處理。
- 用於向客戶端傳送出站應用程序消息的 QoS 級別可能與入站應用程序消息的 QoS 級別不同。
1. QoS 0 最多一次傳遞，不保證收到
該級別消息接收方沒發送響應，發送方也不會重試。消息要麼到達被接收一次，要麼沒有到達。
該消息PUBLISH 數據包 QoS=0 DUP=0
| Sender | 數據包方向 | Receiver |
|---|---|---|
| PUBLISH QoS 0， DUP=0 | ----> | |
| ----> | 收到消息，以QoS0 轉發 |
2. QoS 1 最少一次傳遞，確保收到，但是會重複
使用QoS 1 級別發送時，發送方必須：
- 每次由新消息要發佈時，必須分配一個未使用的數據包標識符 Packet Identifier
- PUBLISH 數據包中的 QoS 設置爲 1，DUP=0
- 必須將PUBLISH 數據包視爲 未確認，直到收到接收方的PUBACK 數據包
一旦收到PUBACK 數據包，PacketIdentifier 就可以重複使用了。發送放可以在等待接收確認時發送具有不同PacketIdentifier 的更多的數據包。
接收方必須：
- 使用來自傳入的PUBLISH 數據包的PacketIdentifier 標識PUBACK 數據包
- 發送PUBACK數據包後，接收方必須將任何包含相同數據包標識符的傳入PUBLISH包視爲新的發佈，無論其DUP 設置如何（服務端重複接收）
交互流程：
| Sender | 數據包方向 | Receiver |
|---|---|---|
| 本地存儲消息 | ||
| 發送 PUBLISH QoS1，DUP=0 消息 | ---> | |
| 得到消息所有權，準備轉發或者發出PUBLISHACK | ||
| <--- | Send PUBACK（PacketIdentifier= Sender PacketId） | |
| 丟棄消息 |
3. QoS 2 精確收到一次，不會重複。
- 這是最高質量的服務，適合在消息丟失或重複均不可接受的情況下使用。 與這種服務質量相關的開銷會增加。
- QoS 2 PUBLISH 數據包的接收方通過兩步確認過程來確認接收
使用 QoS 2 級別時，發送方必須：
- 爲消息分配一個未被使用的PacketIdentifier
- PUBLISH數據包必須設置OoS=1，DUP=0，並在本地將數據包存儲，並視爲“未確認”，直到收到PUBREC數據包。
- 當發送方收到PUBREC時，必鬚髮送PUBREL數據包，且PacketIdentifier 與原始PUBLISH 數據包相同。在收到PUBCOMP 數據包前，PUBREL 數據包（需要本地存儲）必須被視爲“未確認”。
- 一旦發送了相應了PUBREL 數據包，就不能重新發送PUBLISH 數據包。
注意：
- 一旦發送方收到了 PUBCOMP 數據包，PacketIdentifier就可以重用
此時，接收方必須：
- 收到PUBLISH包後，立即發送PUBREC 數據包，保持PacketIdentifier一致。並得到消息所有權。
- 收到相應的 PUBREL數據包前，接收方必須通過發送 PUBREC 來確認具有相同PacketIdentifier 的任何後續PUBLISH數據包。這種情況下，不能將重複消息轉發給任何其他接收方。
- 必須通過發送PUBCOMP 來響應 PUBREL 數據包（PacketIdentifier相同)
- 發送完PUBCOMP數據包後 ，接收方將任何包含該PacketIdentifier 的PUBLISH數據包視爲新的發佈。
3.1 交互流程
| Sender | 數據包方向 | Receiver |
|---|---|---|
| 存儲消息 | ||
| 發送PUBLISH QoS 2，DUP=0 | ---> | |
| 處理方法1 存儲消息,持有消息所有權 或者處理辦法2.存儲PacketIdentifier，然後開始轉發消息 |
||
| PUBREC | ||
| <--- | ||
| 丟棄消息，存儲PacketIdentifier | ||
| 發送 PUBREL（相同PaketIdentifier） | ||
| ---> | ||
| 處理方式1：啓動轉發，然後丟棄消息 .或處理方式2 丟棄PacketIdentifier | ||
| 發送PUBCOMP 消息 | ||
| <--- | ||
| 丟棄存儲的PacketIdentifier |
4. 消息重發
當客戶端在CleanSession 設置爲0 的情況下重新連接時，客戶端和服務端都愮使用原始數據包標識符 PacketIdentifier重新發送任何未確認的PUBLISH 數據包和PUBREL 數據包。
5. 消息回執 Message receipt
當服務器獲得傳入應用程序消息的所有權時，它必須將其添加到具有匹配訂閱的那些客戶端的會話狀態中。
在正常情況下，客戶端會收到響應其創建的訂閱的消息。 客戶端還可能收到與其任何顯式訂閱都不匹配的消息。 如果服務器自動向客戶端分配訂閱，則可能會發生這種情況。 客戶端還可以在取消訂閱操作正在進行時接收消息。 客戶端必須根據適用的 QoS 規則確認其收到的任何發佈數據包，無論其是否選擇處理其中包含的應用程序消息
6. 消息順序
客戶端在實現協議時需要遵循以下規則：
- 當它重新發送任何PUBLISH 數據包時，必須按照原始PUBLISH數據包的發送順序重新發送消息（適用於QoS1 和QoS2）
- 必須按照接收相應的PUBLISH數據包的順序發送PUBACK 數據包（QoS1）
- 必須按照接收相應的PUBLISH 數據包的順序發送PUBREC數據包（QoS2）
- 必須按照接收相應的PUBREC數據包的順序發送PUBREL數據包（QoS2）
默認情況下，服務器將每個主題視爲“有序主題”。可以提供管理機制允許一個或多個主題被視爲“無序主題"
當服務器處理已發佈到有序主題的消息時，它在向每個訂閱者傳遞消息時必須遵循上面列出的規則。 此外，它必須按照從任何給定客戶端接收到的順序將 PUBLISH 數據包發送給消費者（對於相同的主題和 QoS）