MQTT (Message Queuing Telemetry Transport，消息隊列遙測傳輸) 是壹種基於 TCP/IP 協議族的應用層協議。MQTT 協議是專門針對硬件性能低下 & 網絡狀況不穩定的場景設計的，這使得 MQTT 在物聯網和移動應用等受限場景得到廣泛應用。
目前，MQTT 主要分為兩個大版本：
物聯網和移動應用場景的特點是硬件性能低下和網絡狀況不穩定，而 MQTT 協議就是專門針對這種環境設計的，主要在四個方面有優勢：
結論：這三種協議並沒有絕對的優勝者，最好的協議取決於具體的需求和限制條件。但如果只從帶寬、電池、功能多樣性這些基本條件看，MQTT 在其中是更占優的選擇。
MQTT 協議的設計特性中包含了壹項 “高可靠性交付”，它需要壹個保證可靠的底層傳輸層協議，因此 TCP 協議、TLS 協議、WebSocket 協議都可以作為 MQTT 的底層協議。而無連接的 UDP 協議會丟失或重排數據，不能滿足 MQTT 協議的傳輸需要。
MQTT 是基於發布 - 訂閱模型 (pub/sub) 的消息傳遞協議，與請求 - 響應模型不同，發布 - 訂閱模型主要有三種角色： publisher & subscriber & subscriber ：
當 client 發布某個主題的消息時，broker 會將該消息分發給任何已訂閱該主題的 client。通常來說，client 不會存儲消息，壹旦消息被發送到這些 client，消息就會從 broker 上刪除。另外，保留消息、持久連接和服務質量 QoS 可能會導致消息臨時存儲在 broker 上。
發布 - 訂閱模式使得 消息的發布者和訂閱者解耦 ，主要體現為空間解耦和時間解耦：
圖片引用自 /post/6976441705067184135 —— cxuan 著
壹個 MQTT 消息由三部分組成：
1、固定報頭： 每壹個 MQTT 消息都包含壹個固定報頭，包含消息類型、標誌位和剩余長度三個部分。固定報頭長度為 2 ~ 5 字節，具體取決於 “剩余長度” 的大小，格式如下：
2、可變報頭： 不同消息的可變報頭內容不壹樣，不過其中有壹個比較通用的字段：
3、載荷： 某些 MQTT 消息會包含壹個有效載荷，對於 PUBLISH 消息來說，有效載荷就是應用消息。
MQTT 的連接總是發生在 client 和 broker 之間，兩個 client 之間不會互相感知。請求連接時，client 會向 broker 發送 CONNECT 連接消息，broker 接受連接後會響應 CONNACK 連接確認消息。壹旦連接建立，連接會壹直保持打開狀態，直到 client 發送 DISCONNECT 斷開連接消息或連接異常中斷。
CONNECT 是 client 發送給 broker 的首個消息，並且在壹次連接中，client 只能發送壹次 CONNECT 消息，發送的第二個 CONNECT 消息會被 broker 當作違反協議處理，並斷開連接。在 CONNECT 消息中，主要包含以下內容：
CONNACK 消息用於確認 CONNECT 消息。CONNECT 是 client 發送給 broker 的首個消息，相應地，broker 發送給 client 的首個消息壹定是 CONNACK 消息。在 CONNACK 消息中，主要包含以下內容：
DISCONNECT 消息由 client 發送給 broker，用於斷開連接。 DISCONNECT 消息沒有可變報頭和有效載荷，也沒有對應的確認應答消息，表示壹個幹凈利索地斷開連接操作 。斷開連接後，client 不能再發送除 CONNECT 消息之外的消息，broker 也需要丟棄和當前會話有環的遺囑消息。
MQTT 是基於發布訂閱模型的協議，在建立連接後，client 可以向 broker 訂閱感興趣的壹個或多個話題。
SUBSCRIBE 消息由 client 發送給 broker，用於訂閱感興趣的話題，SUBSCRIBE 消息主要包含以下內容：
SUBACK 消息用於確認 SUBSCRIBE 消息。SUBACK 消息主要包含以下內容：
UNSUBSCRIBE 消息由 client 發送給 broker，用於退訂不感興趣的話題，UNSUBSCRIBE 消息主要包含以下內容：
UNSUBACK 消息用於確認 UNSUBSCRIBE 消息。UNSUBACK 消息非常簡單，只有壹個包唯壹標識（位於可變報頭）。
當 MQTT client 在連接到 broker 之後就可以發送消息了，每條 PUBLISH 消息都包含壹個 topic ，broker 會根據 topic 將消息發送給感興趣的 client。除此之外，每條消息還會包含壹個 Payload，Payload 是真正發布的應用消息，載荷的內容和格式由應用層決定，MQTT 協議層不關心。
PUBLISH 消息可以由 client 發送給 broker，也可以由 broker 發送給 client，用來運送應用層消息。PUBLISH 消息主要包含以下內容：
PUBLISH 消息的接收方需要發送確認應答，不同 QoS 等級的 PUBLISH 消息響應的消息不同：
當 client 和 broker 在壹段時間內沒有數據交互時，client 會發送 PINGREQ 探測消息，用於判斷連接是否正常，來決定是否要關閉該連接，這就是 MQTT 協議的保活機制。
PINGREQ 消息由 client 發送給 broker。
PINGRESP 消息由 broker 發送給 client，代表 client 是存活的。
MQTT 主題本質上是壹種 “尋址形式” ，用於將應用層消息分發到期望的客戶端。MQTT 主題是壹種類似於文件系統的分層結構，使用 “/” 正斜杠 作為分隔符。
客戶端訂閱主題時，可以訂閱確定的主題（例如 “group/group123”），也可以使用 “通配符” 來同時訂閱多個主題。需要註意的是： 在發布消息是不允許使用主題通配符，client 每次發布消息只能發布到單個主題。
$SYS 主題是 broker 上默認創建的只讀主題，除此之外，broker 不會默認創建任何主題，所有主題都是由客戶端訂閱或發布才創建的，都不是永久性的。關於 $SYS 主題的更多介紹在 這裏
當 client 連接到 broker 時，可以使用持久連接或非持久連接，這是通過 CONNECT 消息中的 CleanSession 標誌來決定的（當 CleanSession = 0 時表示持久連接）。對於持久會話，broker 會存儲會話狀態；而對於非持久會話，broker 不會存儲 client 的任何內容。會話狀態主要包含以下內容：
QoS 0 等級的 PUBLISH 消息的交付能力完全依賴於底層傳輸層，QoS 1 和 QoS 2 等級開始在應用層提高 PUBLISH 消息的交付能力。當消息丟失時，發送端會重新發送早前嘗試發送過的 PUBLISH 消息（DUP = 1），接收者收到消息也會發送確認響應消息。
在 QoS 0 的等級的 PUBLISH 消息中不包含包唯壹標識。發送者不考慮消息交付結果，接收者也不發送響應。接收者最多只能收到壹次消息，也有可能壹次也收不到。
在 QoS 1 等級的 PUBLISH 消息中包含包唯壹標識，發送方會壹直將該消息當作 “未確認” 的消息，直到收到對應的 PUBACK 確認消息。具體消息流如下：
QoS 2 是最高的服務質量，保證消息不會丟失也不會重復，缺點是會增加開銷。在 QoS 2 等級的 PUBLISH 消息中包含包唯壹標識，發送者會壹直將該消息當作 “未確認” 的消息，知道收到對應的 PUBCOMP 確認消息。
當 client 發布某個主題的消息時，broker 會將該消息分發給任何已訂閱該主題的 client，隨後這條消息會從 broker 上刪除。可以設置 RETAIN 保留標誌設置該 PUBLISH 消息為保留消息，broker 會存儲該主題的最後壹條保留消息，當新的 client 註冊訂閱時，並且匹配該消息主題時，該保留消息會發送給訂閱者。 需要註意：broker 只會為每個主題保存最近壹條保留消息，新收到的 RETAIN = 1 的消息會覆蓋原本那條保留消息；
持久會話 & 服務質量等級 & 保留消息都會影響新訂閱者是否接受消息，總結如下表：
標記 DUP = 1 的消息是重復發送的消息，MQTT 消息重傳有兩種場景：
需要註意：DUP 標誌只對 OoS > 0 的消息有效，所有 QoS = 0 的消息 DUP 標誌必須設置為 0；
TCP 協議的報文重傳機制是對所有 TCP 報文有效的重傳機制，而 MQTT 協議的消息重傳機制只對壹小部分消息有效，用於實現更可靠的消息交付保證。雖然 TCP 協議在壹般情況下可以保證不丟包，但是這並不是絕對的，依然存在請求超時或者連接中斷等情況。而 MQTT 協議的 QoS 1 和 QoS 2 要求更可靠的交付能力，並且需要在客戶端重連後也能保證交付。因此，MQTT 協議也定義了壹個消息重傳機制。
到這裏，關於 MQTT 協議的工作原理 & 協議消息格式 & 核心特性等內容就介紹完了。我知道妳應該會對 MQTT 協議的實戰應用更加感興趣，下壹篇文章裏，我將帶妳實現基於 MQTT 協議的 IM 服務，請關註。