發布日期：2022-07-14 點擊率：51
MQTT 協議是什么？
隨著 5G 時代的來臨，萬物互聯的偉大構想正在成為現實。聯網的 物聯網設備 在 2018 年已經達到了 70 億，在未來兩年，僅智能水電氣表就將超過10億。
海量的設備接入和設備管理對網絡帶寬、通信協議以及平臺服務架構都帶來了很大挑戰。對于 物聯網協議 來說，必須針對性地解決物聯網設備通信的幾個關鍵問題：其網絡環境復雜而不可靠、其內存和閃存容量小、其處理器能力有限。
MQTT 協議 是基于發布／訂閱模式的物聯網通信協議，憑借簡單易實現、支持 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 的訂閱者：
上圖中訂閱者預先訂閱了 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 的?；顧C制，而是設計了協議層的?；顧C制：在 CONNECT 報文里可設置 Keepalive 字段，來設置?；钚奶?PINGREQ／PINGRESP 的發送時間間隔。當長時間無法收到設備的 PINGREQ 的時候，Broker 就會認為設備已經下線。
總的來說，Keepalive 有兩個作用：
發現對端死亡或者網絡中斷
在長時間無消息交互的情況下，保持連接不被網絡設備斷開
對于那些想要在重新上線后，重新收到離線期間錯過的消息的設備，MQTT 設計了持久化連接：在 CONNECT 報文里可設置 CleanSession 字段為 False，則 Broker 會為終端存儲：
設備所有的訂閱
還未被設備確認的 QoS1 和 QoS 消息
設備離線時錯過的消息
在線狀態感知
MQTT 設計了遺愿（Last Will） 消息，讓 Broker 在發現設備異常下線的情況下，幫助設備發布一條遺愿消息到指定的主題。
實際上在某些 MQTT 服務器的實現里 （比如 EMQX），設備上線或下線的時候 Broker 會通過某些系統主題發布設備狀態更新，更符合實際應用場景。
開源 MQTT 服務器如何選擇
到目前為止，比較流行的開源 MQTT 服務器有幾個：
Eclipse Mosquitto使用 C 語言實現的 MQTT 服務器。Eclipse 組織還還包含了大量的 MQTT 客戶端項目：https：／／www．eclipse．org／paho／＃
EMQX使用 Erlang 語言開發的 MQTT 服務器，內置強大的規則引擎，支持許多其他 IoT 協議比如 MQTT－SN、 CoAP、LwM2M 等。
Mosca使用 Node．JS 開發的 MQTT 服務器，簡單易用。
VerneMQ同樣使用 Erlang 開發的 MQTT 服務器．
從支持 MQTT 5．0、穩定性、擴展性、集群能力等方面考慮，EMQX 的表現應該是最好的：
使用 Erlang OTP 開發，容錯能力好 （電信領域久經考驗的語言，曾經做出過 99．9999999％ 可用性的交換機設備）
官方有大量的擴展插件可供擴展。有很多認證插件，數據存儲（backend）插件可供選擇?？芍С指鞣N關系型數據庫，NoSQL 數據庫，以及常見消息隊列如 Kafka，RabbitMQ，Pulsar 等
支持集群，支持節點水平擴展
單節點支持 2000K 并發連接
支持規則引擎和編解碼
MQTT 協議快速體驗
MQTT 在線服務器
EMQX MQTT 物聯網云服務 提供了一個在線的公共 MQTT 5．0 服務器，不需要任何安裝您就可以快速開始 MQTT 協議的學習、測試或原型制作。
該 MQTT 服務器的詳細接入信息請見 EMQ 官網頁面：免費的在線 MQTT 服務器。
MQTT 在線客戶端
EMQ 也提供了支持瀏覽器訪問的 MQTT 在線客戶端工具，該工具支持通過普通或者加密的 WebSocket 端口連接至 MQTT 服務器，同時也支持緩存連接方便下次訪問使用。
原創文章，作者：EMQ，如若轉載，請注明出處
原文標題 : EMQ幫助開發者快速了解 MQTT 協議及其相關特性
