一、MQTT簡介
MQTT是基于TCP/IP協定棧建構的異步通信消息協定，是一種輕量級的釋出、訂閱資訊傳輸協定。
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應用層傳輸協定。
MQTT v5.0 于2018.5月正式釋出，2019年3月，v5.0 成為了新的 OASIS 标準。v5.0在 v3.1.1的基礎上做了較大的改變且不做向下相容，顯然是有太多的新東西要被引入，所有現有的實作要重新實作。此次通過的v5.0是自2014年的v3.1.1以來最重要的協定更新，新協定能适應近年來行業發展的新需求，同時也為未來物聯網行業發展的做了協定上的準備。
1.2 MQTT協定族
1.2.1 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.2 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.3 MQTT v5
MQTT 5.0在協定層提供了更大的自定義擴充空間，平台基于擴充點可支援更豐富的協定能力。v3.1版本中，隻能通過overlay方式，在業務層提供擴充能力。MQTT5.0 主要設計目标是提高錯誤回報能力、增加可擴充能力、提高系統的伸縮性、優化資源受限和小用戶端接入、常見範式下沉至協定層等。
二、協定層設計挑戰
2.1 MQTT應用架構
主要分為6大子產品：
基礎接入子產品：包括多版本協定編解碼、多協定端口複用、會話管理、心跳檢測、連接配接管理等。
協定擴充子產品：包括基于自定義協定擴充，實作的一系列擴充功能，包括通道解壓縮、低功耗免ping等。
增值消息服務：包括Rrpc、廣播、時鐘同步、腳本前置解析等。
業務埋點子產品：裝置行為統計、線上時長聚合、網絡延時診斷等。
安全防禦子產品：包括黑名單機制、入口流控等。
高可用子產品：包括流量分組排程、容災降級等。
運維管控子產品：主要包括流量分組排程、限流管理、連接配接診斷
2.2 協定層設計挑戰
裝置狀态一緻性政策設計，包括session管理機制、心跳檢測機制、異地登陸問題、狀态最終一緻性政策。
在MQTT釋出/訂閱異步分發模型上，如何滿足多樣的業務場景。例如同步調用、廣播等。
如何同時滿足不同場景下裝置對MQTT接入需求，單應用上如何同時支援兩個版本MQTT協定（主要是MQTT v3和v5）
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協定等。