MQTT協(xié)議與傳統(tǒng)的HTTP協(xié)議對(duì)比，它們倆優(yōu)勢(shì)在哪里呢？

HTTP是應(yīng)用最為廣泛和流行的協(xié)議。但是MQTT在過(guò)去的幾年里迅速取得了進(jìn)展。在討論物聯(lián)網(wǎng)開(kāi)發(fā)的時(shí)候，開(kāi)發(fā)者必須在這兩者之間作出選擇。

MQTT集中于數(shù)據(jù)，而HTTP集中于文檔。HTTP是一個(gè)用于客戶端-服務(wù)器計(jì)算的請(qǐng)求-響應(yīng)協(xié)議，它并非總是為移動(dòng)設(shè)備而優(yōu)化。在這些術(shù)語(yǔ)中，MQTT的主要優(yōu)勢(shì)是：輕量級(jí)(MQTT以字節(jié)數(shù)組的形式傳輸數(shù)據(jù))和發(fā)布/訂閱模型，這使得MQTT非常適合資源有限的設(shè)備，并且有助于節(jié)約電池。另外，發(fā)布/訂閱模型使客戶能夠相互獨(dú)立，從而提高整個(gè)系統(tǒng)的可靠性。在一個(gè)客戶機(jī)失敗的情況下，整個(gè)系統(tǒng)可以繼續(xù)正常工作。

MQTT優(yōu)勢(shì)還是比較多的，具體如下：

1、低協(xié)議開(kāi)銷，MQTT 的獨(dú)特之處在于，它的每消息標(biāo)題可以短至 2 個(gè)字節(jié)。MQ 和 HTTP 都擁有高得多的每消息開(kāi)銷。對(duì)于 HTTP，為每個(gè)新請(qǐng)求消息重新建立 HTTP 連接會(huì)導(dǎo)致重大的開(kāi)銷。MQ 和 MQTT 所使用的永久連接顯著減少了這一開(kāi)銷。

2、對(duì)不穩(wěn)定網(wǎng)絡(luò)的容忍，MQTT 和 MQ 能夠從斷開(kāi)等故障中恢復(fù)，而且沒(méi)有進(jìn)一步的代碼需求。但是，HTTP 無(wú)法原生地實(shí)現(xiàn)此目的，需要客戶端重試編碼，這可能增加冪等性問(wèn)題。

3、低功耗，MQTT 是專門(mén)針對(duì)低功耗目標(biāo)而設(shè)計(jì)的。HTTP 的設(shè)計(jì)沒(méi)有考慮此因素，因此增加了功耗。

4、數(shù)百萬(wàn)個(gè)連接的客戶端，在 HTTP 堆棧上，維護(hù)數(shù)百萬(wàn)個(gè)并發(fā)連接，需要做許多的工作來(lái)提供支持。盡管可以實(shí)現(xiàn)此支持，但大多數(shù)商業(yè)產(chǎn)品都為處理這一數(shù)量級(jí)的永久連接而進(jìn)行了優(yōu)化。IBM 提供了 IBM MessageSight，這是一個(gè)單機(jī)架裝載服務(wù)器，經(jīng)過(guò)測(cè)試能處理多達(dá) 100 萬(wàn)個(gè)通過(guò) MQTT 并發(fā)連接的設(shè)備。相反，MQTT不是為大量并發(fā)客戶端而設(shè)計(jì)的。

5、推送通知，您需要能夠及時(shí)地將通知傳遞給客戶。為此，必須采用某種定期輪詢或推送方法；從電池、系統(tǒng)負(fù)載和帶寬角度講，推送是最佳解決方案。

我們的企業(yè)可能需要在沒(méi)有第三方中介的情況下發(fā)送敏感的信息。這降低了特定于操作系統(tǒng)的解決方案（比如 Apple iOS、Google Play 通知）作為主要傳輸機(jī)制的價(jià)值。

HTTP 只允許使用一種稱為COMET 的方法，使用持久的 HTTP 請(qǐng)求來(lái)執(zhí)行推送。從客戶端和服務(wù)器的角度講，此方法都很昂貴。MQ 和 MQTT 都支持推送，這是它們的一個(gè)基本特性。

6、客戶端平臺(tái)差異，HTTP 和 MQTT 客戶端都已在大量平臺(tái)上實(shí)現(xiàn)。MQTT 的簡(jiǎn)單性有助于以極少的精力在額外的客戶端上實(shí)現(xiàn) MQTT。

7、防火墻容錯(cuò)，一些企業(yè)防火墻將出站連接限制到一些已定義的端口。這些端口通常被限制為 HTTP（80 端口）、HTTPS（443 端口）等。HTTP 顯然可以在這些情況下運(yùn)行。MQTT 可封裝在一個(gè) WebSockets 連接中，顯示為一個(gè) HTTP 升級(jí)請(qǐng)求，從而允許在這些情況下運(yùn)行。MQTT不允許采用這種模式。

與HTTP相比，MQTT協(xié)議保證了高傳輸速率。服務(wù)質(zhì)量分三個(gè)層次：

A、至多一次：盡力保證交貨。

B、至少一次：確保郵件至少被發(fā)送一次，但信息也可以不止一次的傳遞。

C、碰巧一次：保證每條信息只被另一方接收一次。

事實(shí)上，MQTT的應(yīng)用非常之廣泛，幾乎現(xiàn)在隨便找一家大型的硬件、互聯(lián)網(wǎng)企業(yè)，都可以找到MQTT的身影，例如智能電表、電表網(wǎng)關(guān)、水表網(wǎng)關(guān)等等。

由于MQTT本身的各項(xiàng)技術(shù)優(yōu)勢(shì)，越來(lái)越多的企業(yè)傾向于選用MQTT作為物聯(lián)網(wǎng)產(chǎn)品通訊的標(biāo)準(zhǔn)協(xié)議，也因此，工程師們漸漸發(fā)現(xiàn)MQTT協(xié)議要想大規(guī)模商用，也有一些有待完善的功能。比如：

1、沒(méi)有齊備的SDK，不同的異構(gòu)終端，需要有對(duì)應(yīng)的與MQTT服務(wù)器通信的軟件SDK包，比如MCU、Linux、Android、IOS、WEB等之間要實(shí)現(xiàn)互聯(lián)互通必然需要不同的SDK包。

2、不支持File和AV，有些應(yīng)用場(chǎng)景，需要傳輸?shù)男畔⒖赡懿粌H僅限于指令，比如聲音信號(hào)和視頻信號(hào)，這些需要通過(guò)File和AV來(lái)實(shí)現(xiàn)通信。

3、不支持與第三方HTTP的集成，雖然MQTT協(xié)議優(yōu)于普通的HTTP協(xié)議，但是基于傳統(tǒng)的HTTP協(xié)議的WEB服務(wù)器仍然占主流市場(chǎng)，那么這些服務(wù)器要實(shí)現(xiàn)與MQTT協(xié)議的互聯(lián)互通，以降低升級(jí)成本也尤為關(guān)鍵。

4、不支持負(fù)載均衡，為防止高并發(fā)和惡意攻擊，負(fù)載均衡服務(wù)器也必不可少。

5、不支持用戶管理接口，用戶在進(jìn)行設(shè)備的行為數(shù)據(jù)分析的時(shí)候，顯得尤為重要，這又是工業(yè)4.0、大數(shù)據(jù)時(shí)代的必然需求。

6、不支持離線消息，彌補(bǔ)設(shè)備離線以后，MQTT服務(wù)器對(duì)設(shè)備的控制信息丟失的問(wèn)題。

7、不支持點(diǎn)對(duì)點(diǎn)通信，采用標(biāo)準(zhǔn)的MQTT協(xié)議，理論上可以通過(guò)相互訂閱的方式實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)通信，但是邏輯相對(duì)復(fù)雜，并且對(duì)設(shè)備的安全性方面存在擔(dān)憂。當(dāng)設(shè)備B和設(shè)備C在同一主題的情況下，設(shè)備A無(wú)法知道是設(shè)備B還是設(shè)備C發(fā)送的消息，也有可能消息被設(shè)備D竊聽(tīng)。

8、不支持群通信和群管理，實(shí)現(xiàn)了對(duì)群組成員的管理，群組成員之間能互通消息，這在一個(gè)設(shè)備被多人控制，或者多個(gè)設(shè)備被一人控制的這種場(chǎng)景下，尤為有用。

以上問(wèn)題阻礙了MQTT技術(shù)在國(guó)內(nèi)市場(chǎng)的進(jìn)一步發(fā)展，畢竟對(duì)于單個(gè)的公司或者工程師而言，想要解決它們需要耗費(fèi)大量的資源和時(shí)間，并且穩(wěn)定性的驗(yàn)證也需要一個(gè)較長(zhǎng)的時(shí)間周期。HTTP是有價(jià)值和可擴(kuò)展的，但MQTT更適合于被稱為物聯(lián)網(wǎng)開(kāi)發(fā)的情況。

文章來(lái)源于網(wǎng)絡(luò)，如有問(wèn)題，請(qǐng)聯(lián)系小編進(jìn)行整改！