MQTT5.0 消息發佈流程

概覽

MQTT5.0協議對部分QoS報文，以及報文處理的流程作了一些升級，本文對此這部分升級的內容作簡單的介紹。

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協議的支持，歡迎讀者試用。

---

更多信息請訪問咱們的官網 emqx.io，或關注咱們的開源項目 github.com/emqx/emqx ，詳細文檔請訪問 官方文檔。