MQTT協(xié)議工作原理
MQTT是一種輕量級(jí)的消息傳輸協(xié)議，常用于物聯(lián)網(wǎng)設(shè)備之間的通信。MQTT協(xié)議工作原理基于發(fā)布/訂閱模式，它允許設(shè)備之間通過(guò)中間代理服務(wù)器進(jìn)行通信，從而實(shí)現(xiàn)設(shè)備之間的數(shù)據(jù)交換。MQTT協(xié)議的工作原理可以分為三個(gè)主要部分：發(fā)布者、代理服務(wù)器和訂閱者。發(fā)布者是指發(fā)送消息的設(shè)備，訂閱者是指接收消息的設(shè)備，代理服務(wù)器則是連接發(fā)布者和訂閱者的中間件。在MQTT協(xié)議中，發(fā)布者將消息發(fā)布到代理服務(wù)器上，代理服務(wù)器將消息存儲(chǔ)在一個(gè)稱為主題(Topic) 的邏輯容器中。主題是一種標(biāo)識(shí)消息類(lèi)型的字符串，它被訂閱者用來(lái)過(guò)濾消息。訂閱者可以訂閱一個(gè)或多個(gè)主題，以接收與其相關(guān)的消息。當(dāng)發(fā)布者發(fā)布一條消息時(shí)，它將消息發(fā)送到代理服務(wù)器，并指定一個(gè)主題。代理服務(wù)器將消息存儲(chǔ)在與主題相關(guān)聯(lián)的隊(duì)列中，然后將消息發(fā)送給所有訂閱了該主題的訂閱者。訂閱者可以選擇接收所有消息，或者只接收特定類(lèi)型的消息。MQTT協(xié)議的工作原理還涉及到QoS(Quality of Service) 級(jí)別。QoS級(jí)別用于控制消息的可靠性和傳輸速度。MQTT協(xié)議支持三種QoS級(jí)別：0、1和2。QoS 0表示消息不需要確認(rèn)，QoS 1表示消息需要確認(rèn)，QoS 2表示消息需要確認(rèn)并且保證只被傳輸一次?？偟膩?lái)說(shuō)，MQTT協(xié)議的工作原理非常簡(jiǎn)單，它通過(guò)發(fā)布/訂閱模式實(shí)現(xiàn)設(shè)備之間的通信。MQTT協(xié)議的輕量級(jí)設(shè)計(jì)使得它非常適合于物聯(lián)網(wǎng)設(shè)備之間的通信，同時(shí)也使得它具有很好的可擴(kuò)展性和靈活性。
MQTT協(xié)議的優(yōu)點(diǎn)
-
低協(xié)議開(kāi)銷(xiāo)。MQTT的獨(dú)特功能是每個(gè)消息頭都可以縮短為2個(gè)字節(jié)。對(duì)于HTTP為每個(gè)新請(qǐng)求消息重新建立HTTP連接會(huì)產(chǎn)生可觀的開(kāi)銷(xiāo)。 MQ和MQTT使用的持久連接可以大大節(jié)省這種開(kāi)銷(xiāo)。 -
包容不穩(wěn)定的網(wǎng)絡(luò)。MQTT和MQ可以從諸如斷開(kāi)連接之類(lèi)的故障中恢復(fù)，無(wú)需進(jìn)一步的代碼要求。但是HTTP本身無(wú)法實(shí)現(xiàn)此目標(biāo)，并且客戶端必須重試編碼，這會(huì)增加身份問(wèn)題。 -
低功耗。MQTT專為低功耗目標(biāo)而設(shè)計(jì)。 HTTP設(shè)計(jì)未考慮此因素，這會(huì)增加功耗。 -
能為數(shù)百萬(wàn)個(gè)客戶端提供連接。在連接數(shù)百萬(wàn)個(gè)客戶端的情況下，在HTTP堆棧中維護(hù)數(shù)百萬(wàn)個(gè)并發(fā)連接需要大量工作才能提供支持。盡管這種支持是可行的，但大多數(shù)商業(yè)產(chǎn)品都經(jīng)過(guò)優(yōu)化以處理此訂單上的持久連接。 IBM提供了IBM MessageSight，這是一種單機(jī)架安裝服務(wù)器，已經(jīng)過(guò)測(cè)試，可以通過(guò)MQTT處理多達(dá)一百萬(wàn)個(gè)并發(fā)設(shè)備。相反，MQ不是為許多同時(shí)進(jìn)行的客戶設(shè)計(jì)的。 -
推送通知。您需要能夠及時(shí)向客戶發(fā)送通知。為此，您應(yīng)該使用常規(guī)的輪詢或推送方法。就電池，系統(tǒng)負(fù)載和帶寬而言，推送是最佳解決方案。 -
客戶端平臺(tái)的差異。 HTTP和MQTT客戶端都在許多平臺(tái)上實(shí)現(xiàn)。 MQTT的簡(jiǎn)單性可幫助您以最少的努力在其他客戶端上實(shí)施MQTT。 -
防火墻容錯(cuò)能力。某些公司防火墻將出站連接限制到某些預(yù)定義的端口，這些端口通常僅限于HTTP（端口80），HTTPS（端口443）等，HTTP在這種情況下顯然可以工作。 MQTT封裝在WebSockets連接中，并顯示為HTTP升級(jí)請(qǐng)求，因此可以在這種情況下運(yùn)行。
MQTT協(xié)議的缺點(diǎn)
-
SDK不夠多。如果沒(méi)有完整的SDK，則需要用于不同異構(gòu)設(shè)備的軟件SDK軟件包才能與MQTT服務(wù)器（例如MCU，Linux，Android，iOS，WEB）進(jìn)行通信，以實(shí)現(xiàn)互連和互操作性。 -
不支持文件和AV。在某些應(yīng)用場(chǎng)景中，需要傳輸?shù)男畔⒖赡懿幌抻谛枰ㄟ^(guò)AV與文件通信的指令，例如語(yǔ)音和視頻信號(hào)。 -
不支持與第三方HTTP集成。 MQTT協(xié)議優(yōu)于常規(guī)HTTP協(xié)議，但是基于傳統(tǒng)HTTP協(xié)議的WEB服務(wù)器仍在主流市場(chǎng)中占主導(dǎo)地位。這些服務(wù)器應(yīng)與MQTT協(xié)議互連，以降低升級(jí)成本。 -
不支持負(fù)載分配。負(fù)載分配服務(wù)器對(duì)于高并發(fā)性和防止惡意攻擊也是必不可少的。 -
不支持用戶管理界面。當(dāng)用戶分析設(shè)備行為數(shù)據(jù)時(shí)，這一點(diǎn)尤其重要。在工業(yè)4.0和大數(shù)據(jù)時(shí)代，這是不可避免的需求。 -
不支持離線消息。設(shè)備脫機(jī)后，不支持脫機(jī)消息來(lái)補(bǔ)償從MQTT服務(wù)器到設(shè)備的控制信息丟失。 -
不支持點(diǎn)對(duì)點(diǎn)通信，并且使用標(biāo)準(zhǔn)的MQTT協(xié)議。從理論上講，點(diǎn)對(duì)點(diǎn)通信可以通過(guò)相互訂閱來(lái)實(shí)現(xiàn)，但是邏輯相對(duì)復(fù)雜并且涉及設(shè)備安全性。當(dāng)設(shè)備B和設(shè)備C相同時(shí)-在主題的情況下，設(shè)備A無(wú)法知道消息是來(lái)自設(shè)備B還是來(lái)自設(shè)備C，并且消息很可能是被設(shè)備D竊聽(tīng)的。 -
不支持群組通信或群組管理，而是實(shí)現(xiàn)群組成員的管理。小組成員可以交換消息，如果一個(gè)設(shè)備由多個(gè)人控制或多個(gè)設(shè)備由一個(gè)人控制，則此功能特別有用。
開(kāi)發(fā)過(guò)程中MQTT遵循以下設(shè)計(jì)原則：
-
精簡(jiǎn)，不添加可有可無(wú)的功能。 -
發(fā)布/訂閱（Pub/Sub）模式，方便消息在傳感器之間傳遞。 - 允許用戶動(dòng)態(tài)創(chuàng)建
主題，零運(yùn)維成本。 - 把
傳輸量降到最低以提高傳輸效率。 - 把
低帶寬、高延遲、不穩(wěn)定的網(wǎng)絡(luò)等因素考慮在內(nèi)。 - 支持連續(xù)的會(huì)話控制。
- 理解客戶端計(jì)算能力可能很低。
- 提供服務(wù)質(zhì)量管理。
- 假設(shè)數(shù)據(jù)不可知，不強(qiáng)求傳輸數(shù)據(jù)的類(lèi)型與格式，保持靈活性。
