物聯(lián)網(wǎng)是對傳統(tǒng)互聯(lián)網(wǎng)的擴展和擴展。用戶終端從傳統(tǒng)計算機擴展到任何設(shè)備,其中該設(shè)備先通過各種傳感器收集信息,然后再通過計算設(shè)備收集信息、交換和交流網(wǎng)絡(luò)信息。之所以出現(xiàn)MQTT協(xié)議,是因為移動互聯(lián)網(wǎng)目前尚處于起步階段,無法提供可靠的網(wǎng)絡(luò)保證。
MQTT是基于TCP/IP協(xié)議棧構(gòu)建的異步通信消息協(xié)議,是一種輕量級的發(fā)布/訂閱信息傳輸協(xié)議。MQTT在時間和空間上,將消息發(fā)送者與接受者分離,可以在不可靠的網(wǎng)絡(luò)環(huán)境中進行擴展。
適用于設(shè)備硬件存儲空間有限或網(wǎng)絡(luò)帶寬有限的場景。物聯(lián)網(wǎng)平臺支持設(shè)備使用MQTT協(xié)議接入MQTT的特點是可以保持長連接,具有一定的實時性,云端向設(shè)備端發(fā)送消息,設(shè)備端可以在最短的時間內(nèi)接收到并作出響應(yīng),所以MQTT更適合需要實時控制的場合,更適合執(zhí)行器。要保持長連接,那么就要時不時地發(fā)送心跳包,這就不會省電了。所以低功耗的場合并不適合MQTT。MQTT的長連接需要建立在TCP的基礎(chǔ)上,TCP協(xié)議的復(fù)雜性決定了對設(shè)備的要求是比較高一些的,相比UDP。
特點
MQTT協(xié)議是為大量計算能力有限,且工作在低帶寬、不可靠的網(wǎng)絡(luò)的遠程傳感器和控制設(shè)備通訊而設(shè)計的協(xié)議,它具有以下主要的幾項特性:
使用發(fā)布/訂閱消息模式,提供一對多的消息發(fā)布,解除應(yīng)用程序耦合;
對負載內(nèi)容屏蔽的消息傳輸;
使用 TCP/IP 提供網(wǎng)絡(luò)連接;
有三種消息發(fā)布服務(wù)質(zhì)量:QoS(定閱等級),分0、1、2三個等級,簡單來說是等級越高越可靠。
“至多一次”(QoS0):消息發(fā)布完全依賴底層 TCP/IP 網(wǎng)絡(luò)。會發(fā)生消息丟失或重復(fù)。這一級別可用于如下情況,環(huán)境傳感器數(shù)據(jù),丟失一次讀記錄無所謂,因為不久后還會有第二次發(fā)送。即是推送之后就完事了,至于對方有沒有收到,收到是什么,數(shù)據(jù)有沒有丟失,都不管。
“至少一次”(QoS1):確保消息到達,但消息重復(fù)可能會發(fā)生。即使你收到推送后,你還得返回一個puback給對方,告訴對方收到了,不然對方會以為你沒收到,隔一段時間后重新給你推送,直到你給對方返回一個Puback為止。
“只有一次”(QoS2):確保消息到達一次。這一級別可用于如下情況,在計費系統(tǒng)中,消息重復(fù)或丟失會導(dǎo)致不正確的結(jié)果?! ?/p>
小型傳輸,開銷很小(固定長度的頭部是2字節(jié)),協(xié)議交換最小化,以降低網(wǎng)絡(luò)流量;
使用 Last Will 和 Testament 特性通知有關(guān)各方客戶端異常中斷的機制。
Last Will:即遺言機制,用于通知同一主題下的其他設(shè)備發(fā)送遺言的設(shè)備已經(jīng)斷開了連接。
Testament:遺言機制,功能類似于Last Will。
MQTT客戶端可以注冊一個典型的遺愿遺囑消息,如果它們斷開連接,由代理發(fā)送。這些消息可以用于向訂閱者發(fā)出信號,當設(shè)備斷開連接時。
優(yōu)點
1.MQTT的獨特功能是每個消息頭都可以縮短為2個字節(jié)。對于HTTP,為每個新請求消息重新建立HTTP連接會產(chǎn)生可觀的開銷。 MQ和MQTT使用的持久連接可以大大減少這種開銷。
2.包容不穩(wěn)定的網(wǎng)絡(luò),MQTT和MQ可以從諸如斷開連接之類的故障中恢復(fù),無需進一步的代碼要求。但是,HTTP本身無法實現(xiàn)此目標,并且客戶端必須重試編碼,這會增加身份問題。
3.低功耗MQTT專為低功耗目標而設(shè)計。 HTTP設(shè)計未考慮此因素,這會增加功耗。
4.在連接數(shù)百萬個客戶端的情況下,在HTTP堆棧中維護數(shù)百萬個并發(fā)連接需要大量工作才能提供支持。盡管這種支持是可行的,但大多數(shù)商業(yè)產(chǎn)品都經(jīng)過優(yōu)化以處理此訂單上的持久連接。 IBM提供了IBM MessageSight,這是一種單機架安裝服務(wù)器,已經(jīng)過測試,可以通過MQTT處理多達一百萬個并發(fā)設(shè)備。相反,MQ不是為許多同時進行的客戶設(shè)計的。
5.推送通知。您需要能夠及時向客戶發(fā)送通知。為此,您應(yīng)該使用常規(guī)的輪詢或推送方法。就電池,系統(tǒng)負載和帶寬而言,推送是最佳解決方案。
6.客戶端平臺的差異。 HTTP和MQTT客戶端都在許多平臺上實現(xiàn)。 MQTT的簡單性可幫助您以最少的努力在其他客戶端上實施MQTT。
7.防火墻容錯能力。某些公司防火墻將出站連接限制到某些預(yù)定義的端口,這些端口通常僅限于HTTP(端口80),HTTPS(端口443)等,HTTP在這種情況下顯然可以工作。 MQTT封裝在WebSockets連接中,并顯示為HTTP升級請求,因此可以在這種情況下運行。
缺點
實際上,MQTT被廣泛使用,可以在幾乎任何大型硬件和互聯(lián)網(wǎng)公司中找到,例如Facebook,BP,阿里巴巴,百度。
由于MQTT本身的技術(shù)優(yōu)勢,越來越多的公司選擇MQTT作為物聯(lián)網(wǎng)產(chǎn)品通信的標準協(xié)議。結(jié)果,工程師逐漸意識到MQTT協(xié)議的功能需要大規(guī)模商業(yè)化進行改進。例如:
1.如果沒有完整的SDK,則需要用于不同異構(gòu)設(shè)備的軟件SDK軟件包才能與MQTT服務(wù)器(例如MCU,Linux,Android,IOS,WEB)進行通信,以實現(xiàn)互連和互操作性。
2.不支持文件和AV。在某些應(yīng)用場景中,需要傳輸?shù)男畔⒖赡懿幌抻谛枰ㄟ^AV與文件通信的指令,例如語音和視頻信號。
3.不支持與第三方HTTP集成。 MQTT協(xié)議優(yōu)于常規(guī)HTTP協(xié)議,但是基于傳統(tǒng)HTTP協(xié)議的WEB服務(wù)器仍在主流市場中占主導(dǎo)地位。這些服務(wù)器應(yīng)與MQTT協(xié)議互連,以降低升級成本。
4.不支持負載分配。負載分配服務(wù)器對于高并發(fā)性和防止惡意攻擊也是必不可少的。
5.不支持用戶管理界面。當用戶分析設(shè)備行為數(shù)據(jù)時,這一點尤其重要。在工業(yè)4.0和大數(shù)據(jù)時代,這是不可避免的需求。
6.設(shè)備脫機后,不支持脫機消息來補償從MQTT服務(wù)器到設(shè)備的控制信息丟失。
7.不支持點對點通信,并且使用標準的MQTT協(xié)議。從理論上講,點對點通信可以通過相互訂閱來實現(xiàn),但是邏輯相對復(fù)雜并且涉及設(shè)備安全性。當設(shè)備B和設(shè)備C相同時-在主體的情況下,設(shè)備A無法知道消息是來自設(shè)備B還是來自設(shè)備C,并且消息很可能是被設(shè)備D竊聽的。
8.不支持群組通信或群組管理,而是實現(xiàn)群組成員的管理。小組成員可以交換消息,如果一個設(shè)備由多個人控制或多個設(shè)備由一個人控制,則此功能特別有用。