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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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