MQTT是基於TCP/IP協議棧構建的異步通信消息協議，是一種輕量級的發佈、訂閱信息傳輸協議。MQTT已逐漸成為IoT領域最熱門的協議，也是國內外各大物聯網平臺最主流的傳輸協議，阿里雲IoT物聯網平臺很多設備都是通過MQTT接入。

本文將詳細介紹MQTT協議的歷史演進，以及阿里雲IoT物聯網平臺在MQTT協議層實踐中的一些關鍵設計及思考。

本文主要包含了以下內容：

• MQTT協議演進歷史及協議特點，總結和分析MQTT協議族的優缺點，分析和總結了為什麼相比於其他協議，MQTT適合IoT等。

• 阿里雲IoT MQTT3和5協議在實踐中的一些關鍵設計及思考。包括連接複用、狀態一致性、擴展增值能力設計等。

一、MQTT協議

1.1 MQTT協議演進

MQTT最初由IBM於20世紀90年代發明，最初是用於石油管道的傳感器與衛星之間數據傳輸。MQTT v3.1.1於2014.10月正式發佈，與此同時v3.1.1已成為OASIS協議標準（就是3.1.1已升級為國際物聯網標準）。正如HTTP為人們通過web分享信息鋪平了道路一樣，MQTT標準化能將幾十億低成本、IoT設備連接到網絡。毫無疑問，MQTT是當前最主流、增長最迅速的IoT應用層傳輸協議，目前，阿里雲IoT平臺許多在線設備都是通過MQTT接入的。

MQTT v5.0 於2018.5月正式發佈，2019年3月，v5.0 成為了新的 OASIS 標準。v5.0在 v3.1.1的基礎上做了較大的改變且不做向下兼容，顯然是有太多的新東西要被引入，所有現有的實現要重新實現。此次通過的v5.0是自2014年的v3.1.1以來最重要的協議升級，新協議能適應近年來行業發展的新需求，同時也為未來物聯網行業發展的做了協議上的準備。阿里雲IoT平臺從2020.12月開始支持 MQTT5.0。

1.2 MQTT協議族

每一種協議都是在特定上下文、約束下得出的折中設計，從來都沒有完美的協議。MQTT經過幾十年的發展，針對不同場景已經演進出相對成熟的多版本協議。

1.2.1 MQTT v3

MQTT v3協議是為在低帶寬、不可靠的網絡上工作的傳感器而設計的基於TCP的應用層協議，適用於IoT場景。它具有以下幾項重要特性：使用發佈/訂閱消息模式，支持一對多的消息分發，解除設備和業務之間的耦合；報文格式設計精簡， 適用於小規模數據傳輸以及資源受限的IoT設備。固定頭部是2字節，開銷很小，支持QoS0、QoS1、QoS2 三種消息QoS。

MQTT3.1.1在MQTTv3基礎上引入了一些新特性， 主要包括：clientId優化，支持broker給設備指定clientId，增大了clientId最大長度。ack響應優化，connect ack中引入session Present標識等。

MQTTv3/v3.1.1 在實際應用中存在以下不足：1）錯誤碼設計的不夠完整，設備難以完整感知到broker的處理異常；2）不支持設備跟broker之間的能力發現/協商，broker不能提供可選能力等。3）協議設計的過於精簡，沒有預留擴展空間，無法直接在協議層做擴展，協議能力相對簡陋。4）對於一些高階能力支持不夠，例如協議層缺乏流控、優先級、報頭壓縮等功能。5）MQTT3是基於TCP的應用層協議，TCP固有的一些缺點也被MQTT繼承了。

1.2.2 MQTT-SN

MQTT-SN(Sensor Networks) 是MQTT協議的傳感器網絡版本，最早用在zigBee無線網絡中，主要面對電池供電，有限的處理器能力和存儲能力的設備。只有很小的內存和CPU，TCP 對於這些設備來說非常奢侈，甚至無法允許TCP協議棧。還有一些網絡，比如 zigBee，報文的長度在幾百字節以下，無法承載太大的數據包。MQTT-SN有主要特點：1） MQTT-SN支持運行在鏈路層、IP、UDP之上。2） QOS增加了-1級別，只用於傳輸，盡力而為，無保證。3）更豐富且開銷更低的Topic類型。4）. 網絡架構增加了SN網關。

1.2.3 MQTT v5

MQTT 5.0在協議層提供了更大的自定義擴展空間，平臺基於擴展點可支持更豐富的協議能力。v3.1版本中，只能通過overlay方式，在業務層提供擴展能力。MQTT5.0 主要設計目標是提高錯誤反饋能力、增加可擴展能力、提高系統的伸縮性、優化資源受限和小客戶端接入、常見範式下沉至協議層等。目前主流MQTT Broker開源社區基本已經支持v5.0，並且開源SDK也已經初步支持v5.0，與此同時，國內IoT雲廠商還沒有支持v5.0，但未來已來。

二、MQTT協議層實踐

2.1 MQTT應用架構

主要分為6大模塊：

• 基礎接入模塊：包括多版本協議編解碼、多協議端口複用、會話管理、心跳檢測、連接管理等。

• 協議擴展模塊：包括基於自定義協議擴展，實現的一系列擴展功能，包括通道解壓縮、低功耗免ping等。

• 增值消息服務：包括Rrpc、廣播、時鐘同步、腳本前置解析等。

• 業務埋點模塊：設備行為統計、在線時長聚合、網絡延時診斷等。

• 安全防禦模塊：包括黑名單機制、入口流控等。

• 高可用模塊：包括流量分組調度、容災降級等。

• 運維管控模塊：主要包括流量分組調度、限流管理、連接診斷

2.2 協議層設計挑戰

• 設備狀態一致性策略設計，包括session管理機制、心跳檢測機制、異地登陸問題、狀態最終一致性策略。

• 在MQTT發佈/訂閱異步分發模型上，如何滿足多樣的業務場景。例如同步調用、廣播等。

• 如何同時滿足不同場景下設備對MQTT接入需求，單應用上如何同時支持兩個版本MQTT協議

• MQTTv3協議過於精簡，業務從MQTT3切換到v5的過渡時間，如何擴展協議層能力，提高客戶接入體驗。

2.3 MQTT關鍵策略設計

2.3.1 設備在線狀態

協議層本地有session管理器來對本地會話進行管理，通過心跳檢測、會話自檢來保證跟設備之間的連接狀態一致性，當前平臺單設備不支持同時同設備多端登陸，基於分佈式會話，協議層通過分佈式會話識別異地登陸，將異常連接踢下線。

設備狀態一致性策略：設備到MQTT協議接入層之間是tcp長連接，通過心跳機制保證心跳週期內設備狀態的最終一致性。同時通過分佈式會話版本號，保證分佈式會話併發更新安全，通過上行消息/心跳定時觸發會話自檢機制，解決異常情況下本地/分佈式會話狀態不一致的問題。

2.3.2 消息推送模式

MQTT協議是基於PUB/SUB的異步通信模式，針對單設備緯度實現基礎的發佈/訂閱推送外，還支持了複雜的消息推送方式：RRpc和在線廣播。

在傳統的基於PUB/SUB通信模式的中間件中， 消息的Producer/Consumer只負責生產和消費，彼此之間不會直接通訊。而在某些業務場景不僅僅是將消息投遞至訂閱方，訂閱方收到消息後可能還會執行一些操作並返回結果，PUB/SUB模式下實現這種請求/響應模式會非常繁瑣，在MQTT中通信雙方需要事先協商請求和響應topic。

針對這一痛點，協議層在發佈訂閱模式之上構建了一套Rpc通訊模式，解決開發者痛點。Rrpc模式允許Producer發出消息後，以同步形式等待Consumer消費這條消息並返回響應，達到類似Rpc的調用效果。Rrpc模式使得MQTT應用具備了同步調用的能力，擴展了使用場景，使其具備更多的可能性

• 通過topic中包含的messageId匹配請求與響應，對業務數據零侵入

• messageId的生成與匹配、超時控制等邏輯，調用方無感知

• 簡化了業務方調用邏輯，擴展了MQTT使用場景。

2.3.3 多種類接入方式

MQTT協議層針對不同場景支持多種MQTT接入方式，同時支持tcp直連、tls、ws、wss等方式接入，用於滿足不同場景接入需求。為了實現更好的網絡穿透性，協議層實現了多協議端口複用，也就是一個端口同時支持多種協議。

• 邊解析邊判斷，處理效率高；

• 節約常用端口，實現更好的網絡穿透性

• 內部能力擴展對設備側無感知

• 針對MQTT協議5和3，通過協議解析也實現了同時兼容。

2.3.4 自定義協議擴展

MQTTv3在實際應用中存在一些缺點，而MQTTv5生態的繁榮推廣還需要很長時間的推進， 在MQTT3到5的過渡時間，我們在v3.1.1基礎上通過overlay的方式，提供了擴展套件來解決客戶痛點，豐富接入增值能力，提高接入體驗。思路：沒有什麼問題不是封一層解決不了的，如果有那就再封一層

• 通過在建連clientId中擴展ext參數，實現端雲之間能力協商

• 通過擴展消息topic格式，實現支持自定義屬性

• 定義一套ext異常推送topic規範

三、展望未來

當前阿里雲IoT平臺協議層已支持了MQTT主流協議，並支持了多種協議接入方式，但還存在一些會進一步優化的地方：1）更豐富的消息質量模型，例如支持QoS2，支持消息優先級等；2）完善低功耗領域的網關側支持，可以跟SDK/邊緣網關合作，支持MQTT-SN協議等。