MQTT協(xié)議,在物聯(lián)網中有廣泛應用,是對傳統(tǒng)互聯(lián)網的擴展和擴展。用戶終端從傳統(tǒng)計算機擴展到任何設備,通過各種傳感器收集信息,再通過計算設備收集信息、交換和交流網絡信息。MQTT協(xié)議的出現(xiàn),是因為移動互聯(lián)網目前尚處于起步階段,無法提供可靠的網絡保證。
MQTT協(xié)議優(yōu)點
1.MQTT的獨特功能是每個消息頭都可以縮短為2個字節(jié)。對于HTTP,為每個新請求消息重新建立HTTP連接會產生可觀的開銷。 MQ和MQTT使用的持久連接可以大大減少這種開銷;
2.包容不穩(wěn)定的網絡,MQTT和MQ可以從諸如斷開連接之類的故障中恢復,無需進一步的代碼要求。但是,HTTP本身無法實現(xiàn)此目標,并且客戶端必須重試編碼,這會增加身份問題;
3.低功耗MQTT專為低功耗目標而設計。HTTP設計未考慮此因素,這會增加功耗;
4.在連接數(shù)百萬個客戶端的情況下,在HTTP堆棧中維護數(shù)百萬個并發(fā)連接,需要大量工作才能提供支持。盡管這種支持是可行的,但大多數(shù)商業(yè)產品都經過優(yōu)化以處理此訂單上的持久連接。 IBM提供了IBM MessageSight,這是一種單機架安裝服務器,已經過測試,可以通過MQTT處理多達一百萬個并發(fā)設備。相反,MQ不是為許多同時進行的客戶設計的;
5.推送通知。能夠及時向客戶發(fā)送通知,以常規(guī)的輪詢或推送方法。從電池、系統(tǒng)負載、帶寬而言,推送是最佳解決方案;
6.客戶端平臺的差異。 HTTP和MQTT客戶端都在許多平臺上實現(xiàn)。 MQTT的簡單性可幫助以最少的努力在其他客戶端上實施MQTT;
7.防火墻容錯能力。某些公司防火墻將出站連接限制到某些預定義的端口,這些端口通常僅限于HTTP(端口80),HTTPS(端口443)等,HTTP在這種情況下顯然可以工作。 MQTT封裝在WebSockets連接中,并顯示為HTTP升級請求,因此可以在這種情況下運行;
MQTT協(xié)議缺點
實際上,MQTT被廣泛使用,可以在幾乎任何大型硬件和互聯(lián)網公司中找到,例如Facebook、BP、阿里巴巴、百度。由于MQTT本身的技術優(yōu)勢,越來越多的公司選擇MQTT作為物聯(lián)網產品通信的標準協(xié)議。結果,工程師逐漸意識到MQTT協(xié)議的功能需要大規(guī)模商業(yè)化進行改進。例如:
1.如果沒有完整的SDK,則需要用于不同異構設備的軟件SDK軟件包才能與MQTT服務器(例如MCU,Linux,Android,IOS,WEB)進行通信,以實現(xiàn)互連和互操作性;
2.不支持文件和AV。在某些應用場景中,需要傳輸?shù)男畔⒖赡懿幌抻谛枰ㄟ^AV與文件通信的指令,例如語音和視頻信號;
3.不支持與第三方HTTP集成。 MQTT協(xié)議優(yōu)于常規(guī)HTTP協(xié)議,但是基于傳統(tǒng)HTTP協(xié)議的WEB服務器仍在主流市場中占主導地位。服務器應與MQTT協(xié)議互連,以降低升級成本;
4.不支持負載分配。負載分配服務器對于高并發(fā)性和防止惡意攻擊也是必不可少的;
5.不支持用戶管理界面。當用戶分析設備行為數(shù)據(jù)時,這一點尤其重要。在工業(yè)4.0和大數(shù)據(jù)時代,這是不可避免的需求。
6.設備脫機后,不支持脫機消息來補償從MQTT服務器到設備的控制信息丟失;
7.不支持點對點通信,并且使用標準的MQTT協(xié)議。從理論上講,點對點通信可以通過相互訂閱來實現(xiàn),但是邏輯相對復雜并且涉及設備安全性。當設備B和設備C相同時-在主體的情況下,設備A無法知道消息是來自設備B還是來自設備C,并且消息很可能是被設備D竊聽的;
8.不支持群組通信或群組管理,而是實現(xiàn)群組成員的管理。小組成員可以交換消息,如果一個設備由多個人控制或多個設備由一個人控制,則此功能特別有用;