MQTT協(xié)議工作原理
MQTT是一種輕量級的消息傳輸協(xié)議记某，常用于物聯(lián)網(wǎng)設備之間的通信。MQTT協(xié)議工作原理基于發(fā)布/訂閱模式啊犬，它允許設備之間通過中間代理服務器進行通信虎锚，從而實現(xiàn)設備之間的數(shù)據(jù)交換。MQTT協(xié)議的工作原理可以分為三個主要部分：發(fā)布者朴乖、代理服務器和訂閱者祖屏。發(fā)布者是指發(fā)送消息的設備，訂閱者是指接收消息的設備买羞，代理服務器則是連接發(fā)布者和訂閱者的中間件袁勺。在MQTT協(xié)議中，發(fā)布者將消息發(fā)布到代理服務器上畜普，代理服務器將消息存儲在一個稱為主題(Topic) 的邏輯容器中期丰。主題是一種標識消息類型的字符串，它被訂閱者用來過濾消息吃挑。訂閱者可以訂閱一個或多個主題钝荡，以接收與其相關的消息。當發(fā)布者發(fā)布一條消息時舶衬，它將消息發(fā)送到代理服務器埠通，并指定一個主題。代理服務器將消息存儲在與主題相關聯(lián)的隊列中逛犹，然后將消息發(fā)送給所有訂閱了該主題的訂閱者端辱。訂閱者可以選擇接收所有消息，或者只接收特定類型的消息虽画。MQTT協(xié)議的工作原理還涉及到QoS(Quality of Service) 級別舞蔽。QoS級別用于控制消息的可靠性和傳輸速度。MQTT協(xié)議支持三種QoS級別：0码撰、1和2渗柿。QoS 0表示消息不需要確認，QoS 1表示消息需要確認灸拍，QoS 2表示消息需要確認并且保證只被傳輸一次做祝±。總的來說鸡岗，MQTT協(xié)議的工作原理非常簡單，它通過發(fā)布/訂閱模式實現(xiàn)設備之間的通信编兄。MQTT協(xié)議的輕量級設計使得它非常適合于物聯(lián)網(wǎng)設備之間的通信轩性，同時也使得它具有很好的可擴展性和靈活性。
MQTT協(xié)議的優(yōu)點
-
低協(xié)議開銷狠鸳。MQTT的獨特功能是每個消息頭都可以縮短為2個字節(jié)揣苏。對于HTTP為每個新請求消息重新建立HTTP連接會產(chǎn)生可觀的開銷悯嗓。 MQ和MQTT使用的持久連接可以大大節(jié)省這種開銷。 -
包容不穩(wěn)定的網(wǎng)絡卸察。MQTT和MQ可以從諸如斷開連接之類的故障中恢復脯厨，無需進一步的代碼要求。但是HTTP本身無法實現(xiàn)此目標坑质，并且客戶端必須重試編碼合武，這會增加身份問題。 -
低功耗涡扼。MQTT專為低功耗目標而設計稼跳。 HTTP設計未考慮此因素，這會增加功耗吃沪。 -
能為數(shù)百萬個客戶端提供連接汤善。在連接數(shù)百萬個客戶端的情況下，在HTTP堆棧中維護數(shù)百萬個并發(fā)連接需要大量工作才能提供支持票彪。盡管這種支持是可行的红淡，但大多數(shù)商業(yè)產(chǎn)品都經(jīng)過優(yōu)化以處理此訂單上的持久連接。 IBM提供了IBM MessageSight降铸，這是一種單機架安裝服務器锉屈，已經(jīng)過測試，可以通過MQTT處理多達一百萬個并發(fā)設備垮耳。相反颈渊，MQ不是為許多同時進行的客戶設計的。 -
推送通知终佛。您需要能夠及時向客戶發(fā)送通知俊嗽。為此，您應該使用常規(guī)的輪詢或推送方法铃彰。就電池绍豁，系統(tǒng)負載和帶寬而言，推送是最佳解決方案牙捉。 -
客戶端平臺的差異竹揍。 HTTP和MQTT客戶端都在許多平臺上實現(xiàn)。 MQTT的簡單性可幫助您以最少的努力在其他客戶端上實施MQTT邪铲。 -
防火墻容錯能力芬位。某些公司防火墻將出站連接限制到某些預定義的端口，這些端口通常僅限于HTTP（端口80）带到，HTTPS（端口443）等昧碉，HTTP在這種情況下顯然可以工作。 MQTT封裝在WebSockets連接中，并顯示為HTTP升級請求被饿，因此可以在這種情況下運行四康。
MQTT協(xié)議的缺點
-
SDK不夠多。如果沒有完整的SDK狭握，則需要用于不同異構(gòu)設備的軟件SDK軟件包才能與MQTT服務器（例如MCU闪金，Linux，Android论颅，iOS毕泌，WEB）進行通信，以實現(xiàn)互連和互操作性嗅辣。 -
不支持文件和AV撼泛。在某些應用場景中，需要傳輸?shù)男畔⒖赡懿幌抻谛枰ㄟ^AV與文件通信的指令澡谭，例如語音和視頻信號愿题。 -
不支持與第三方HTTP集成。 MQTT協(xié)議優(yōu)于常規(guī)HTTP協(xié)議蛙奖，但是基于傳統(tǒng)HTTP協(xié)議的WEB服務器仍在主流市場中占主導地位潘酗。這些服務器應與MQTT協(xié)議互連，以降低升級成本雁仲。 -
不支持負載分配仔夺。負載分配服務器對于高并發(fā)性和防止惡意攻擊也是必不可少的。 -
不支持用戶管理界面攒砖。當用戶分析設備行為數(shù)據(jù)時缸兔，這一點尤其重要。在工業(yè)4.0和大數(shù)據(jù)時代吹艇，這是不可避免的需求惰蜜。 -
不支持離線消息。設備脫機后受神，不支持脫機消息來補償從MQTT服務器到設備的控制信息丟失抛猖。 -
不支持點對點通信，并且使用標準的MQTT協(xié)議鼻听。從理論上講财著，點對點通信可以通過相互訂閱來實現(xiàn)，但是邏輯相對復雜并且涉及設備安全性撑碴。當設備B和設備C相同時-在主題的情況下撑教，設備A無法知道消息是來自設備B還是來自設備C，并且消息很可能是被設備D竊聽的灰羽。 -
不支持群組通信或群組管理驮履，而是實現(xiàn)群組成員的管理。小組成員可以交換消息廉嚼，如果一個設備由多個人控制或多個設備由一個人控制玫镐，則此功能特別有用。
開發(fā)過程中MQTT遵循以下設計原則：
-
精簡怠噪，不添加可有可無的功能恐似。 -
發(fā)布/訂閱（Pub/Sub）模式，方便消息在傳感器之間傳遞傍念。 - 允許用戶動態(tài)創(chuàng)建
主題矫夷，零運維成本。 - 把
傳輸量降到最低以提高傳輸效率憋槐。 - 把
低帶寬双藕、高延遲、不穩(wěn)定的網(wǎng)絡等因素考慮在內(nèi)阳仔。 - 支持連續(xù)的會話控制忧陪。
- 理解客戶端計算能力可能很低。
- 提供服務質(zhì)量管理近范。
- 假設數(shù)據(jù)不可知嘶摊，不強求傳輸數(shù)據(jù)的類型與格式，保持靈活性评矩。
