MQTT協議的初淺認識之通信級別和持久會話

背景

這是我最近了解MQTT協議的最後一部份內容了，MQTT協議裏面的QOS和Keep Alive是兩個比較重要的內容。QOS的設置，直接影響了訂閱客戶端與中間件之間的消息交互行爲。而Keep Alive直接影響了客戶端與中間件鏈接狀態。

QOS

MQTT中QOS的三個級別：

• 0:最多一次傳送 (只負責傳送，發送事後就無論數據的傳送狀況)
• 1:至少一次傳送 (確認數據交付)
• 2:正好一次傳送 (保證數據交付成功)

QOS 0

這種狀況下面，中間件接收發布者的推送消息後，不會給發佈者響應任何消息，也就是說消息推送出去，就無論消息有沒有訂閱者被收到了。

QOS 1

QoS級別1保證消息至少一次傳遞給訂閱者。 發送者存儲消息，直到它從訂閱者得到確認收到消息的PUBACK數據包。 能夠屢次發送或傳遞消息。也就是說每次推送一個消息，必定會收到一個訂閱者確認收到的PUBACK消息，若是中間件沒有收到PUBACK確認消息，中間件就會一直給訂閱發消息，直到訂閱者響應PUBACK確認消息。

QOS 2

QoS 2是MQTT中的最高級別。 此級別保證每一個消息僅由預期訂閱者接收一次。 QoS 2是最安全和最慢的QOS水平。 保證由發佈者和訂閱者之間的至少兩個請求/響應流（四個握手）提供。 發佈者和訂閱者使用原始PUBLISH消息的包標識符來協調消息的傳送。

當訂閱者從發佈者得到QoS 2 PUBLISH數據包時，它會相應地處理髮布消息，並使用PUBREC數據包回覆發佈者。 若是發佈者沒有從訂閱者得到PUBREC數據包，它會再次發佈帶有重複（DUP）標誌的PUBLISH數據包，直到收到確認。

一旦發佈者從訂閱者接收到PUBREC數據包，發送方就能夠安全地丟棄初始PUBLISH數據包。 發佈者存儲來自訂閱者的PUBREC數據包，並以PUBREL數據包進行響應。

在訂閱者得到PUBREL數據包以後，訂閱者能夠丟棄全部存儲的狀態，並用PUBCOMP數據包回答（當發佈者收到PUBCOMP時也是如此）。 在訂閱者完成處理並將PUBCOMP分組發佈回發佈者以前，訂閱者存儲對原始PUBLISH分組的分組標識符的引用。 此步驟對於避免第二次處理消息很是重要。 在發送者收到PUBCOMP數據包以後，已發佈消息的數據包標識符可供重用。

當QoS 2流程完成時，雙方都肯定消息已發送且發送者已確認交付。

若是數據包在途中丟失，則發送者有責任在合理的時間內從新傳輸消息。 若是發送者是MQTT客戶機或MQTT中間件，則一樣如此。 訂閱者有責任相應地響應每條命令消息。

級別簡單總結：

• QOS0：發送消息不可靠。
• QOS1：消息可靠，性能比QOS2好，但可能屢次收到消息，我選這個。
• QOS2：消息可靠，且只能收到一次消息，解決QOS1，可是，性能比QOS1差。

Keep Alive

這個參數很重要，這個影響到消息是否可以及時收到。當發送者與訂閱者之間長時間沒有收到消息，這個keep alive定義，訂閱者與發佈者之間能夠忍受的時間。這個keep alive時間定義多長時間訂閱客戶端發PINGREQ消息給中間件的消息，中間件收到PINGREQ消息後，迴應PINGRESP消息給訂閱者客戶端，通常60s。

總結

MQTT協議，咱們就告一段落了，建議你們能夠本身閱讀HiveMQ的MQTT Essentials Part1-10，十篇文章很容易理解。

參考：

MQTT

MQTT Essentials Part 6: Quality of Service 0, 1 & 2

MQTT Essentials Part 10: Keep Alive and Client Take-Over