[[396339]]

【51CTO.com快譯】于1999年面市的MQTT，最初被用于油氣管道與遠程衛星之間的通信。目前它作為一種工具，被廣泛地用在各種規模的部署中，以連接多種類型的物聯網(IoT)設備。由于是基于TCP/IP的網絡協議，因此MQTT采用的是發布方-訂閱方(publisher-subscriber)的通信模型。它的輕量級特性足以讓其運行在IoT設備上，而其強大的功能又確保了它能夠在不穩定的網絡條件下工作。

MQTT的工作原理

MQTT協議是由如下元素構成：

• 發布方(Publisher)：設備通過主題將消息發送給訂閱方。
• 主題(Topic)：每個資源都有一個唯一的標識符。發布方將消息發送至主題，然后將其傳遞給訂閱方。
• 訂閱方(Subscriber)：作為終端設備，訂閱方通過主題從發布方處接收消息。
• 代理(Broker)：服務器作為中央樞紐，負責發布方和訂閱方之間的組織級通信。

下圖展示了簡單的MQTT通信邏輯。

如果某個云平臺不適合使用MQTT的通信方式來開發系統，則可以改用hbmqtt、gmqtt和paho-mqtt lib。

服務質量級別(QoS)是MQTT協議的關鍵功能，作為消息發送方和接收方之間的約定，它定義了系統傳遞特定消息的能力。

客戶端可以選擇與其所處網絡的可靠性，以及應用程序的邏輯，相匹配的服務級別。由于MQTT能夠通過重新傳輸的機制，來管理并保證消息的傳遞(即使是底層的傳輸并不可靠)，因此QoS可以讓不可靠網絡中的通信更加安全。

為何在物聯網的開發中要用到MQTT?

憑借其“節能(energy-efficient)”的數據傳輸方式，MQTT往往被用在CPU和內存(RAM)功率有限的低功耗設備上，以及如下場景用例中：

• 高效的通信。MQTT的低數據量和低能耗特性，使其成為實時的、基于文本的消息傳遞應用的首選。
• 安全性。在家庭安防系統中，MQTT系統的QoS機制可以確保重要消息的成功傳遞，進而確保危險警告能夠發送給居民。
• 消息匯總。MQTT使得組織能夠有效地，從諸如智能手機或汽車傳感器等多個來源收集數據。
• 同步傳感器。例如，多個火災報警探測器可以相互通信，以辨別危險是否真的存在。
• 醫療物聯網應用。通過多個傳感器去監控出院患者的健康參數。
• 車聯網。與HTTP不同，MQTT能夠在客戶端和代理之間保持持久性的會話。該特性對于車聯網特別實用。例如，當車輛離開了蜂窩網絡的盲區，會話能夠重新連接，繼續平穩地收發數據，而無需進行復雜的HTTP握手。

MQTT的優勢

• 效率是MQTT的一大亮點，它通過諸如AMQP的競爭協議，讓數據的傳輸更加順暢。用戶可以快速、輕松地實現輕量級的MQTT協議架構。
• 發送的數據包越少，網絡的使用率就越低。
• 其低功耗特性非常適合連接物聯網設備。
• MQTT可以實現更有效的數據分發。
• 該協議可以更輕松地實現遙感(remote sensing)和控制。

MQTT的劣勢

當然，MQTT并非在所有場景中都是理想選擇。MQTT協議在客觀上存在著如下劣勢：

• 對于擁有250個以上設備的系統而言，快速傳輸周期是至關重要的。不過它與CoAP(Constrained Application Protocol)相比，會在傳輸周期上慢一些。
• MQTT可以運行在靈活的主題訂閱系統上。而CoAP使用的是穩定的資源發現系統。
• MQTT雖然用到了TLS/SSL，可是它缺乏安全加密能力。
• 與其他競品相比，MQTT協議難以創建全局性的可擴展網絡。

MQTT v5.0的功能概述

通過各種新功能，MQTT v5.0可以實現如下目標：

• 提高大型系統的性能。MQTT v5.0以一種適當的架構，簡化并協調上萬臺設備之間的通信。
• 錯誤報告。MQTT v5.0協議將返回碼重命名為原因碼(reason code)，以指示更多類型的錯誤。
• 實現常規交互。MQTT v5.0規范化了設備間交互的重復方式，并定義了它們如何響應請求的能力。
• 增加了可擴展的機制。MQTT v5.0新的功能包括：添加自定義的屬性，指定內容的類型或負載的格式。
• 更好的支持。特別是對于希望通過MQTT來提高生產率的小型用戶而言，能夠從中受益。

MQTT v5.0與MQTT 3.1.1的基本功能

1.通信功能

• 可以通過負載內部的身份驗證方法，以及身份驗證類數據的屬性，來實現增強的身份驗證。
• 可以使用“會話過期間隔”屬性。例如，可以在主題內包括訂閱的時間，消息會被存儲的時限等。
• 可以內置化地限制客戶端和服務器端的最大數據包的體積(待傳輸的字節數)和最大接收量(客戶端或服務器同時發送消息的數量)。
• 通過“待延遲的間隔”屬性，實現對消息的延遲發送。
• “服務器參考”或“服務器重定向”屬性，可以協助將數據包傳輸到不同的代理或服務器處。

2.發布功能

• 消息到期間隔，可用于設置消息的保留期限。
• 負載格式標識符和內容類型屬性，可被定義為二進制字節、UTF-8或MIME類型。
• 支持主題別名。例如，通過將topic/v1/device/賦予別名“1”，可以最大程度地減少所需的數據包的數量。
• MQTT協議的“響應主題”，類似HTTP協議的響應請求方案(response-request scheme)。

3.訂閱功能

• 非本地發布，可以讓用戶選擇不接收客戶端發布的消息。
• 留存消息控制可以控制消息的排序。
• 訂閱標識符，可用于在訂閱中識別服務器。
• 共享訂閱，可通過其他標志和過濾功能，來實現更靈活的訂閱。

4.一般特征

• 在MQTT v3.1.1中，服務器無法提供有關在建立通信、發布消息、以及訂閱主題等不同階段的問題與錯誤原因。但是，v5.0可以提供所有ACK消息的原因碼。
• 與MQTT 3.1不同，在MQTT v5.0中，客戶端和服務器端可以彼此傳遞有關掉線信息的數據包。
• 不同的用戶屬性可以被存儲在各種鍵值中。

MQTT v5.0在小型系統部署中的示例

下面讓我們來看一個帶有基于Python的客戶端利用MQTT v5.0本地網絡的示例。在客觀總結其優缺點的同時，我們還會將其與MQTT v3.1.1的網絡進行比較。

場景簡述

假設有一棟實現了局域網(LAN)覆蓋的建筑物。其中某些房間被安裝了三種設備--獨立的運動傳感器、照相傳感器和音頻傳感器。其主機設備位于LAN之中，并通過無線或網線的方式連接到路由器上。它能夠定期從獨立的設備上收集或處理數據，并且將這些數據存儲在本地數據庫中。目前，我們使用SQLLite數據庫或更簡單的替代方法，僅在收到三種傳感器的消息后，才會被激活工作。

目標

保證主機設備與獨立設備之間的通信，并在主機端提供本地數據庫的部署和通信。

應用要求

• 從傳感器到主機設備的所有消息，都必須遵從MQTT v5.0附加屬性的限制(包括：傳輸給主題消息的字節數限制等)。
• 來自主題的消息必須是MIME類型，以便于在主機端進行快速編碼。
• 消息必須存儲在本地數據庫的實例中。

設備要求

• 獨立設備：帶有已連接的傳感器，而且能夠訪問本地網絡的x86或基于ARM的設備(如，Raspberry Pi)。
• 主機設備：具有MQTT代理、且能夠處理來自獨立設備消息的基于x86或基于ARM的設備。

支持MQTT v5.0和Python的代理

雖然paho-mqtt是兩種常見的代理。但是，由于它們并無內置的MQTT v5.0代理，因此無法實現網絡的本地部署。對此，我們采用支持MQTT v5.0的Mosquitto作為代理。其配套的文檔鏈接為--https://mosquitto.org/。它能夠代理大約200到300個設備，且一次性僅支持一個連接。

基于Python的系統如何與MQTT v5.0一起使用

在Python開發人員看來，MQTT v5.0協議里的庫和文檔并不多。其唯一的Python 客戶端便是上面提到的gmqtt和paho-mqtt。

MQTT v5.0本地網絡的優缺點

優點

• 無需諸如GCP(Google Cloud Platform)或AWS之類的云服務提供商，也不需要用于本地IoT系統的WAN連接，便可實現LAN內自主設備的全面交互。
• 網絡延遲和數據傳輸速度。傳輸速度僅取決于本地設備的硬件功能。在LAN環境中，通過放置設備可以最大程度地減少延遲。
• 與競品相比，MQTT的能效更高。
• 網絡安全性高。由于本地網絡不會暴露到WAN中，因此帶有消息的數據包不會被本地網絡之外實體捕獲或跟蹤到。同時，MQTT v5.0協議提供了服務器與客戶端之間的相互身份驗證。此外，MQTT還可以使用TLS證書的安全連接和數據傳輸。
• 可以將數據包的各種限制，作用于網絡內的代理上。
• 其容器化特征更易于模擬和調試。

缺點

• 用于處理消息的線程應當實現并行管理，以確保設備的正常運行。
• 開發人員必須定期進行調試和排障，并且必須使用安全的SSH，來保護主機和獨立設備之間的WAN連接。
• MQTT協議不支持流式傳輸。
• 由于無法實現大型的文件傳輸，因此需要專用的bucket上傳或HTTP協議。
• 代理無法智能地管理數據。當然，在斷開連接期間，數據可以被存儲一段時間。

MQTT v5.0較v3.1.1的改進之處

• 存儲附加數據的屬性
• 載荷格式的指示符類型包括：字節、UTF-8或UTF-8字符串對
• 請求/響應模式
• 客戶端連接和斷開的原因碼
• 會話到期與控制

MQTT v5.0可以簡化數據負載的處理和解析，具有對消息、連接和會話進行單獨且精確控制的能力。而且，它能夠通過屬性來傳輸附加數據，開發者可以據此創建更為復雜的IoT解決方案。

MQTT v5.0的挑戰

• 在生產環境中，開發者需要管理那些用于在獨立設備上，并行發布和偵聽消息的進程與線程。
• 在paho-mqtt之類的代碼包中，各種類的實現過程并不清晰，而且可參考的文檔十分有限。
• 由于文檔匱乏，因此開發者很難安裝代理，并將其升級到MQTT v5.0。
• 為了識別網絡中的設備，我們需要將IP發現器添加到系統中。

到底是否該選用MQTT v5.0?

總的說來，如果您擁有在設備與主機之間進行消息通信的托管式代理設備，而且物聯網的規模不大，那么將MQTT v5.0用于本地IoT設備間的通信則為首選。

原文標題：MQTT 5 vs. MQTT v3.1.1 for IoT App Development，作者：Daniil Liadov

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】