[[396339]]

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

MQTT的工作原理

MQTT協(xié)議是由如下元素構(gòu)成：

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

下圖展示了簡(jiǎn)單的MQTT通信邏輯。

如果某個(gè)云平臺(tái)不適合使用MQTT的通信方式來開發(fā)系統(tǒng)，則可以改用hbmqtt、gmqtt和paho-mqtt lib。

服務(wù)質(zhì)量級(jí)別(QoS)是MQTT協(xié)議的關(guān)鍵功能，作為消息發(fā)送方和接收方之間的約定，它定義了系統(tǒng)傳遞特定消息的能力。

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

為何在物聯(lián)網(wǎng)的開發(fā)中要用到MQTT?

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

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

MQTT的優(yōu)勢(shì)

• 效率是MQTT的一大亮點(diǎn)，它通過諸如AMQP的競(jìng)爭(zhēng)協(xié)議，讓數(shù)據(jù)的傳輸更加順暢。用戶可以快速、輕松地實(shí)現(xiàn)輕量級(jí)的MQTT協(xié)議架構(gòu)。
• 發(fā)送的數(shù)據(jù)包越少，網(wǎng)絡(luò)的使用率就越低。
• 其低功耗特性非常適合連接物聯(lián)網(wǎng)設(shè)備。
• MQTT可以實(shí)現(xiàn)更有效的數(shù)據(jù)分發(fā)。
• 該協(xié)議可以更輕松地實(shí)現(xiàn)遙感(remote sensing)和控制。

MQTT的劣勢(shì)

當(dāng)然，MQTT并非在所有場(chǎng)景中都是理想選擇。MQTT協(xié)議在客觀上存在著如下劣勢(shì)：

• 對(duì)于擁有250個(gè)以上設(shè)備的系統(tǒng)而言，快速傳輸周期是至關(guān)重要的。不過它與CoAP(Constrained Application Protocol)相比，會(huì)在傳輸周期上慢一些。
• MQTT可以運(yùn)行在靈活的主題訂閱系統(tǒng)上。而CoAP使用的是穩(wěn)定的資源發(fā)現(xiàn)系統(tǒng)。
• MQTT雖然用到了TLS/SSL，可是它缺乏安全加密能力。
• 與其他競(jìng)品相比，MQTT協(xié)議難以創(chuàng)建全局性的可擴(kuò)展網(wǎng)絡(luò)。

MQTT v5.0的功能概述

通過各種新功能，MQTT v5.0可以實(shí)現(xiàn)如下目標(biāo)：

• 提高大型系統(tǒng)的性能。MQTT v5.0以一種適當(dāng)?shù)募軜?gòu)，簡(jiǎn)化并協(xié)調(diào)上萬臺(tái)設(shè)備之間的通信。
• 錯(cuò)誤報(bào)告。MQTT v5.0協(xié)議將返回碼重命名為原因碼(reason code)，以指示更多類型的錯(cuò)誤。
• 實(shí)現(xiàn)常規(guī)交互。MQTT v5.0規(guī)范化了設(shè)備間交互的重復(fù)方式，并定義了它們?nèi)绾雾憫?yīng)請(qǐng)求的能力。
• 增加了可擴(kuò)展的機(jī)制。MQTT v5.0新的功能包括：添加自定義的屬性，指定內(nèi)容的類型或負(fù)載的格式。
• 更好的支持。特別是對(duì)于希望通過MQTT來提高生產(chǎn)率的小型用戶而言，能夠從中受益。

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

1.通信功能

• 可以通過負(fù)載內(nèi)部的身份驗(yàn)證方法，以及身份驗(yàn)證類數(shù)據(jù)的屬性，來實(shí)現(xiàn)增強(qiáng)的身份驗(yàn)證。
• 可以使用“會(huì)話過期間隔”屬性。例如，可以在主題內(nèi)包括訂閱的時(shí)間，消息會(huì)被存儲(chǔ)的時(shí)限等。
• 可以內(nèi)置化地限制客戶端和服務(wù)器端的最大數(shù)據(jù)包的體積(待傳輸?shù)淖止?jié)數(shù))和最大接收量(客戶端或服務(wù)器同時(shí)發(fā)送消息的數(shù)量)。
• 通過“待延遲的間隔”屬性，實(shí)現(xiàn)對(duì)消息的延遲發(fā)送。
• “服務(wù)器參考”或“服務(wù)器重定向”屬性，可以協(xié)助將數(shù)據(jù)包傳輸?shù)讲煌拇砘蚍?wù)器處。

2.發(fā)布功能

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

3.訂閱功能

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

4.一般特征

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

MQTT v5.0在小型系統(tǒng)部署中的示例

下面讓我們來看一個(gè)帶有基于Python的客戶端利用MQTT v5.0本地網(wǎng)絡(luò)的示例。在客觀總結(jié)其優(yōu)缺點(diǎn)的同時(shí)，我們還會(huì)將其與MQTT v3.1.1的網(wǎng)絡(luò)進(jìn)行比較。

場(chǎng)景簡(jiǎn)述

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

目標(biāo)

保證主機(jī)設(shè)備與獨(dú)立設(shè)備之間的通信，并在主機(jī)端提供本地?cái)?shù)據(jù)庫的部署和通信。

應(yīng)用要求

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

設(shè)備要求

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

支持MQTT v5.0和Python的代理

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

基于Python的系統(tǒng)如何與MQTT v5.0一起使用

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

MQTT v5.0本地網(wǎng)絡(luò)的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)

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

缺點(diǎn)

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

MQTT v5.0較v3.1.1的改進(jìn)之處

• 存儲(chǔ)附加數(shù)據(jù)的屬性
• 載荷格式的指示符類型包括：字節(jié)、UTF-8或UTF-8字符串對(duì)
• 請(qǐng)求/響應(yīng)模式
• 客戶端連接和斷開的原因碼
• 會(huì)話到期與控制

MQTT v5.0可以簡(jiǎn)化數(shù)據(jù)負(fù)載的處理和解析，具有對(duì)消息、連接和會(huì)話進(jìn)行單獨(dú)且精確控制的能力。而且，它能夠通過屬性來傳輸附加數(shù)據(jù)，開發(fā)者可以據(jù)此創(chuàng)建更為復(fù)雜的IoT解決方案。

MQTT v5.0的挑戰(zhàn)

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

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

總的說來，如果您擁有在設(shè)備與主機(jī)之間進(jìn)行消息通信的托管式代理設(shè)備，而且物聯(lián)網(wǎng)的規(guī)模不大，那么將MQTT v5.0用于本地IoT設(shè)備間的通信則為首選。

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

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】