隨著 5G 時代的來臨，萬物物聯的偉大構想正在成為現實。聯網的物聯網設備在 2018 年已經達到了 70 億，在未來兩年，僅智能水電氣表就將超過10億。
海量的設備接入和設備管理對網絡帶寬、通信協議以及平臺服務架構都帶來了很大挑戰。對於物聯網協議來說，必須針對性地解決物聯網設備通信的幾個關鍵問題：其網絡環境複雜而不可靠、其內存和閃存容量小、其處理器能力有限。
MQTT 是基於 Publish/Subscribe 模式的物聯網通信協議，憑藉簡單易實現、支持 QoS、報文小等特點，佔據了物聯網協議的半壁江山：
MQTT 的誕生
MQTT was created by Andy Stanford-Clark of IBM, and Arlen Nipper (then of Arcom Systems, later CTO of Eurotech).
據 Arlen Nipper 在一 IBM Podcast 上的自述 ，MQTT 原名是 MQ TT ， 注意 MQ 與 TT 之間的空格，其全稱為: MQ Telemetry Transport，是九十年代早期，他在參與 Conoco Phillips 公司的一個原油管道數據採集監控系統(pipeline SCADA system)時，開發的一個實時數據傳輸協議。它的目的在於讓傳感器通過帶寬有限的 VSAT ，與 IBM 的 MQ Integrator 通信。由於 Nipper 是遙感和數據採集監控專業出身，所以按業內慣例給了個 MQ TT 的名字。
MQTT 設計原則
按照 Nipper 的介紹，MQTT 必須簡單容易實現，必須支持 QoS(設備網絡環境複雜)，必須輕量且省帶寬(因為那時候帶寬很貴)，必須數據無關(不關心 Payload 數據格式)，必須有持續地會話感知能力(時刻知道設備是否在線)。下面將介紹 MQTT (3.1.1 版本) 的幾個核心特色，分別對應了這幾個設計原則的實現。
靈活的發佈訂閱和主題設計
發佈訂閱模式是傳統 Client/Server 模式的一種解耦方案。發佈者通過 Broker 與消費者之間通信，Broker 的作用是將受到的消息通過某種 過濾規則 ，正確地發送給消費者。發佈/訂閱模式 相對於 客戶端/服務器模式 的好處在於：
- 發佈者和消費者之間不必預先知道對方的存在，比如不需要預先溝通對方的 IP Address 和 Port
- 發佈者和消費者之間不必同時運行。因為 Broker 是一直運行的。
在 MQTT 協議裡，上面提到的 過濾規則 是 Topic 。比如：所有發佈到 news 這個 Topic 的消息，都會被 Broker 轉發給已經訂閱了 news 的訂閱者:
some msg news some msg
[Publisher] ---------------------------> [Broker] ---------------------------> [Subscriber]
上圖中訂閱者預先訂閱了 news ，然後發佈者向 Broker 發佈了一條消息 "some msg" 並制定發佈到 news 主題，Broker 通過 Topic 匹配，決定將這條消息轉發給訂閱者。
MQTT 的 Topic 有層級結構，並且支持通配符 + 和 # :
- + 是匹配單層的通配符。比如 news/+ 可以匹配 news/sports ， news/+/basketball 可匹配到 news/sports/basketball 。
- # 是一到多層的通配符。比如 news/# 可以匹配 news 、 news/sports 、 news/sports/basketball 以及 news/sports/basketball/x 等等。
MQTT 的主題是不要預先創建的，發佈者發送消息到某個主題、或者訂閱者訂閱某個主題的時候，Broker 就自動創建了這個主題。
帶寬消耗最小化
MQTT 協議將協議本身佔用的額外消耗最小化，消息頭部最小隻需要佔用 2 個字節。
MQTT 的消息格式分三部分：
固定長度頭部，2 個字節，所有消息類型裡都有可變長度頭部，只有某些消息類型裡有Payload，只有某些消息類型裡有
MQTT 的主要消息類型有：
- CONNECT / CONNACK
- PUBLISH / PUBACK
- SUBSCRIBE / SUBACK
- UNSUBSCRIBE / UNSUBACK
- PINGREQ / PINGRESP
- DISCONNECT.
其中 PINGREQ / PINGRESP 和 DISCONNECT 報文是不需要可變頭部的，也沒有 Payload，也就是說它們的報文大小僅僅消耗 2 個字節。
在 CONNECT 報文的可變長度頭部裡，有個 Protocol Version 的字段。為了節省空間，只有一個字節。所以版本號不是按照字符串 "3.1.1" 存放的，而是使用數字 4 來表示 3.1.1 版本。
三個可選的 QoS 等級
為適應設備不同的網絡環境，MQTT 設計了 3 個 QoS 等級，0, 1, 2:
- At most once (0)
- At least once (1)
- Exactly once (2).
QoS 0 是一種 "fire and forget" 的消息發送模式：Sender (可能是 Publisher 或者 Broker) 發送一條消息之後，就不再關心它有沒有發送到對方，也不設置任何重發機制。
QoS 1 包含了簡單的重發機制，Sender 發送消息之後等待接收者的 ACK，如果沒收到 ACK 則重新發送消息。這種模式能保證消息至少能到達一次，但無法保證消息重複。
QoS 2 設計了 略微複雜 的重發和重複消息發現機制，保證消息到達對方並且嚴格值到達一次。
會話保持
MQTT 沒有假設設備或 Broker 使用了 TCP 的保活機制，而是設計了協議層的保活機制：在 CONNECT 報文裡可設置 Keepalive 字段，來設置保活心跳包 PINGREQ/PINGRESP 的發送時間間隔。當長時間無法收到設備的 PINGREQ 的時候，Broker 就會認為設備已經下線。
總的來說，Keepalive 有兩個作用：
- 發現對端死亡或者網絡中斷
- 在長時間無消息交互的情況下，保持連接不被網絡設備斷開
對於那些想要在重新上線後，重新收到離線期間錯過的消息的設備，MQTT 設計了持久化連接：在 CONNECT 報文裡可設置 CleanSession 字段為 False，則 Broker 會為終端存儲：
- 設備所有的訂閱
- 還未被設備確認的 QoS1 和 QoS 消息
- 設備離線時錯過的消息
在線狀態感知
MQTT 設計了遺願(Last Will) 消息，讓 Broker 在發現設備異常下線的情況下，幫助設備發佈一條遺願消息到指定的主題。
實際上在某些 MQTT Broker 的實現裡 (比如 EMQX)，設備上線或下線的時候 Broker 會通過某些系統主題發佈設備狀態更新，更符合實際應用場景。
閱讀更多 sandag 的文章
