MQTT5.0消息發布流程是什么

本篇內容介紹了“MQTT5.0消息發布流程是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

QOS報文格式及處理流程

在 MQTT 協議中，消息分為 3 個等級，分別用 QoS0, QoS1, QoS2, 這三個不同的 QoS 值所代表的是不同

的服務質量等級。以下是每一個服務質量級別的具體描述：

0 ： 最多一次發送（若消息等級為 QoS 0，發布者在發布消息時只會發送一次，不管消息是否送達）; 1 ： 至少一次消息發送（若消息等級為 QoS 1，發布者在發布消息時會重復發送以確保消息發送成功）； 2 ： 消息只發送一次，并保證送達。（若消息等級為 QoS 2, 發布者在發布消息時確保接收者只接收到一個消息并且消息不會重復）。

在三種 QoS 消息等級中，QoS 0 是最節省計算資源的， 而 QoS 1 在發布完消息后還需要去接收到一個發布確認報文來停止重復的報文發送， QoS 2 消息的傳輸則需要更多的步驟，它需要 4 次報文發送來確保消息是單次送達的，是所有消息類型中最費計算資源和帶寬的。

以下是 3 種不同 QoS 值的處理流程圖：

在 MQTT 3.0 中，QoS 0的消息發布流程是這樣

• QoS 0 消息

  發送者	控制報文流向	接受者
  PUBLISH QoS = 0, DUP = 0
  	—>
  		接收消息（可能不會收到）并處理

• QoS 1 消息

  發送者	控制報文流向	接受者
  存儲消息
  發送 PUBLISH QoS1, DUP = 0，帶有 Packetld	—>
  		接收消息并處理
  		發送帶有 Packetld 和 PUBACK 確認報文
  丟棄消息

  若接收者沒有接收到 QoS1 消息或者接收到的 QoS 1 消息有問題，是不會去發送 PUBACK 確認報文的，因此發送者不會丟棄 QoS1 消息，它還會再發送 這個消息，所以 QoS1 消息是有可能被重復發布的。

• QoS 2 消息

  發送者	控制報文流向	接受者
  存儲消息
  發送 PUBLISH QoS1, DUP = 0，帶有 Packetld
  	—>
  		存儲 Packet ID 然后準備應用消息的發送
  		發布帶有 Packetld 和 Reason Code 的 PUBREC 報文
  	<---
  丟棄存儲的消息，存儲接收到的帶有相同 packet ID 的 PUBREC 報文
  發送 PUBREC 報文	—>	丟棄 Packetld
  		發送帶有 Packetld 的 PUBCOMP 報文
  	<---
  丟棄存儲的狀態

為了保證消息單次發送且能送達。首先它要發布一個 PUBLISH 報文，然后接收者在接收完成時并不會返回確認報文，它會存儲接收到的消息，然后返回 PUBREC 報文給發送者，發送者在接收到 PUBREC 報文后， 將存儲的 PUBLISH 報文替換成收到的 PUBREC 報文，然后發送 PUBREL 報文給接收者。 接收者收到 PUBREL 消息后丟棄之前存儲的狀態，此時消息已經到達接收者，并且能夠確保只到達了一次。

MQTT 協議面對的是計算能力低下的嵌入式設備，雖然 MQTT 5.0 協議中對 QoS2 消息的處理流程做了一些輕微的優化，然而使用用 QoS2 消息通信仍然是非常耗資源的操作，所以通常情況下，如果對于消息傳輸的優先級要示不是特別高的話，請盡量不要傳送 QoS 2 消息。

MQTT5.0升級

MQTT5.0在QoS上的升級主要體現在QoS2的接收者在處理報文的時候一點變化，

• 在 MQTT 5.0 協議中，這里對 QoS2 消息的發布處理流程與 MQTT 3.0 協議稍有不同，在 MQTT 3.0 中，接收者接收到 QoS2 消息后既可以存儲消息，也可以存儲 Packet ID, 在 5.0 中則強制協議實現者只能存儲 Packet Id。這么做是為了強制 MQTT 協議開發者減少 QoS2 消息的帶寬損耗。

• 在QoS2的接收者端，除了之前返回的PacketId之外，還返回了標識Reason Code的PUBREC報文。

EMQ發布的最新版本3.0已經包含了對MQTT5.0協議的支持，歡迎讀者試用。

“MQTT5.0消息發布流程是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！