MQTT 入門(2)--MQTT 發布訂閱詳解

本文主要介紹 MQTT 協議中發布訂閱的詳細程序，

1、Connect(連接)

MQTT 協議基于 TCP/IP 協議，MQTT Broker 和 Client 都有需要有 TCP/IP 地址，Client 連接 MQTT Broker 時有如下相關配置項：

Client ID

服務端使用 ClientId 識別客戶端，連接服務端的每個客戶端都有唯一的 ClientId ，客戶端和服務端都必須使用 ClientId 識別兩者之間的 MQTT 會話相關的狀態，

ClientId 必須存在，但是服務端可以允許客戶端提供一個零位元組的 ClientId，如果這樣做了，服務端必須將這看作特殊情況并分配唯一的 ClientId 給那個客戶端，然后正常處理這個 CONNECT 報文，

Username/Password

MQTT 可以通過發送用戶名和密碼來進行相關的認證和授權，但是，如果此資訊未加密，則用戶名和密碼是以明文的方式發送的，

Keep Alive

保持連接（Keep Alive）是一個以秒為單位的時間間隔，它是指在客戶端傳輸完成一個控制報文的時刻到發送下一個報文的時刻，兩者之間允許空閑的最大時間間隔，客戶端負責保證控制報文發送的時間間隔不超過保持連接的值，如果沒有任何其它的控制報文可以發送，客戶端必須發送一個 PINGREQ 報文，

如果 Keep Alive 的值非零，并且服務端在一點五倍的 Keep Alive 時間內沒有收到客戶端的控制報文，它必須斷開客戶端的網路連接，認為網路連接已斷開，

Clean Session

客戶端和服務端可以保存會話狀態，以支持跨網路連接的可靠訊息傳輸，這個標志告訴服務器這次連接是不是一個全新的連接，

客戶端的會話狀態包括：

• 已經發送給服務端，但是還沒有完成確認的 QoS 1 和 QoS 2 級別的訊息
• 已從服務端接收，但是還沒有完成確認的 QoS 2 級別的訊息，

服務端的會話狀態包括：

• 會話是否存在，即使會話狀態的其它部分都是空，
• 客戶端的訂閱資訊，
• 已經發送給客戶端，但是還沒有完成確認的 QoS 1 和 QoS 2 級別的訊息，
• 即將傳輸給客戶端的 QoS 1和 QoS 2 級別的訊息，
• 已從客戶端接收，但是還沒有完成確認的 QoS 2 級別的訊息，
• 可選，準備發送給客戶端的 QoS 0 級別的訊息，

如果 CleanSession 標志被設定為 1，客戶端和服務端必須丟棄之前的任何會話并開始一個新的會話，會話僅持續和網路連接同樣長的時間，

如果 CleanSession 標志被設定為 0，服務端必須基于當前會話（使用 ClientId 識別）的狀態恢復與客戶端的通信，如果沒有與這個客戶端識別符號關聯的會話，服務端必須創建一個新的會話，當連接斷開后，客戶端和服務端必須保存會話資訊，

2、Connack(確認連接請求)

客戶端發送 Connect 報文請求對服務器的連接，服務器必須發送 Connack 報文作為對 來自客戶端的 Connect 報文的回應，如果客戶端在合理的時間內沒有收到服務端的CONNACK報文，客戶端應該關閉網路連接，合理的時間取決于應用的型別和通信基礎設施，

Connack 報文包含 Session Present 和 Connect Return code 兩個重要的標志，

Session Present

Session Present 標志表示當前會話是否是一個新的會話，如果服務端收到 CleanSession 標志為1的連接，Connack報文中的 SessionPresent 標志為 0 ，如果服務端收到一個 CleanSession 為0的連接，SessionPresent 標志的值取決于服務端是否已經保存了 ClientId 對應客戶端的會話狀態，如果服務端已經保存了會話狀態，Connack 報文中的 SessionPresent 標志為 1，如果服務端沒有已保存的會話狀態，Connack 報文中的 SessionPresent 標志為 0.

Connect Return code

Connect Return code 表示服務器對此次 Connect 的回應，0 表示連接已被服務器接受，如果服務端收到一個合法的 CONNECT 報文，但出于某些原因無法處理它，服務端應該嘗試發送一個包含非零回傳碼（表格中的某一個）的 CONNACK 報文，如果服務端發送了一個包含非零回傳碼的CONNACK 報文，那么它必須關閉網路連接，

如果認為上表中的所有連接回傳碼都不太合適，那么服務端必須關閉網路連接，不需要發送CONNACK 報文，

3、Subscribe(訂閱主題)

客戶端向服務端發送 Subscribe 報文用于創建一個或多個訂閱，每個訂閱注冊客戶端關心的一個或多個主題，為了將應用訊息轉發給與那些訂閱匹配的主題，服務端發送 Publish 報文給客戶端，Subscribe 報文為每個訂閱指定了最大的 QoS 等級，服務端根據這個發送應用訊息給客戶端，

Subscribe 報文的有效載荷必須包含至少一對主題過濾器 和 QoS 等級欄位組合，沒有有效載荷的 Subscribe 報文是違反協議的，

4、Suback(訂閱確認)

服務端發送 Suback 報文給客戶端，用于確認它已收到并且正在處理 Subscribe 報文，

Suback 報文包含一個原因碼串列，用于指定授予的最大QoS等級或 Subscribe 報文所請求的每個訂閱發生的錯誤,每個原因碼對應 Subscribe 報文中的一個主題過濾器，Suback 報文中的原因碼順序必須與 Subscribe 報文中的主題過濾器順序相匹配，

允許的回傳碼值：

• 0x00 - 最大QoS 0
• 0x01 - 成功 – 最大QoS 1
• 0x02 - 成功 – 最大 QoS 2
• 0x80 - Failure 失敗

5、Publish(發布訊息)

Publish 報文是指從客戶端向服務端或者服務端向客戶端傳輸一個應用訊息，服務器收到 Publish 報文后根據主題過濾器將訊息轉發給其他客戶端，

發布訊息時有如下配置項：

Topic

主題名（Topic Name）用于識別訊息應該被發布到哪一個會話，服務端發送給訂閱客戶端的 Publish 報文的主題名必須匹配該訂閱的主題過濾器，

QoS

QoS 表示應用訊息分發的服務質量等級保證

Publish 報文不能將 QoS 所有的位設定為 1，如果服務端或客戶端收到 QoS 所有位都為 1 的 Publish 報文，它必須關閉網路連接，

Retain

如果客戶端發給服務端的 Publish 報文的保留（RETAIN）標志被設定為 1，服務端必須存盤這個應用訊息和它的服務質量等級（QoS），以便它可以被分發給未來的主題名匹配的訂閱者 ，一個新的訂閱建立時，對每個匹配的主題名，如果存在最近保留的訊息，它必須被發送給這個訂閱者，如果服務端收到一條保留（RETAIN）標志為1的Q訊息，它必須丟棄之前為那個主題保留的任何訊息，并將這個新的訊息當作那個主題的新保留訊息，

保留標志為 1 且有效載荷為零位元組的 Publish 報文會被服務端當作正常訊息處理，它會被發送給訂閱主題匹配的客戶端，此外，同一個主題下任何現存的保留訊息必須被移除，因此這個主題之后的任何訂閱者都不會收到保留訊息，

服務端發送 Publish 報文給客戶端時，如果訊息是作為客戶端一個新訂閱的結果發送，它必須將報文的保留標志設為 1，當一個 Publish 報文發送給客戶端是因為匹配一個已建立的訂閱時，服務端必須將保留標志設為 0，不管它收到的這個訊息中保留標志的值是多少，

如果客戶端發給服務端的 Publish 報文的保留標志位 0，服務端不能存盤這個訊息也不能移除或替換任何現存的保留訊息，

Payload

有效載荷包含將被發布的應用訊息，資料的內容和格式是應用特定的，可以發送影像，任何編碼的文本，加密的資料以及幾乎所有二進制資料，

參考：https://www.emqx.com/zh/blog/how-to-use-mqtt-packet-to-implement-publishing-and-subscribing-functions

標籤：Java

上一篇：執行緒安全，這詞你懂了嗎？

下一篇：java如何使用多個分隔符