MQTT屬于一種輕量級的消息傳輸協(xié)議，其協(xié)議頭相當(dāng)簡潔。正常情況下，MQTT的固定頭部僅有2個字節(jié)，用來標(biāo)識消息類型、QoS（服務(wù)質(zhì)量）等級等基本信息。在某些特定的消息類型里，也許會存在可變頭部與消息體，不過整體結(jié)構(gòu)較為緊湊。

  然而HTTP協(xié)議的消息頭則相對復(fù)雜一些。即便是最簡單的HTTP請求，例如“GET”請求，其頭部信息也包含請求方法、URL、協(xié)議版本、主機信息、用戶代理等諸多字段。一般而言，一個基本的HTTP頭部大小可能會達到幾百字節(jié)。

下面我們就來說說這兩者在物聯(lián)網(wǎng)應(yīng)用中的具體差異。

一、傳輸模式

  MQTT運用發(fā)布/訂閱模式。設(shè)備充當(dāng)發(fā)布者（Publisher），把數(shù)據(jù)發(fā)布至特定的主題（Topic），而訂閱者（Subscriber）只需訂閱自身感興趣的主題，就能接收相關(guān)數(shù)據(jù)。在此種模式下，數(shù)據(jù)傳輸基于事件驅(qū)動。只要存在訂閱這些主題的應(yīng)用程序或者設(shè)備，就能夠?qū)崟r接收數(shù)據(jù)。并且，在設(shè)備狀態(tài)無變化時，無需發(fā)送額外的數(shù)據(jù)，從而減少了不必要的網(wǎng)絡(luò)流量。

2、HTTP

  HTTP屬于典型的請求/響應(yīng)模式?？蛻舳耍ㄒ话銥槲锫?lián)網(wǎng)設(shè)備或者用戶端應(yīng)用）要向服務(wù)器發(fā)送請求，服務(wù)器依據(jù)請求內(nèi)容予以響應(yīng)。這表明每次獲取或者更新數(shù)據(jù)，都需要完整的請求 - 響應(yīng)流程。服務(wù)器收到請求后返回設(shè)備的狀態(tài)信息。若要頻繁獲取設(shè)備狀態(tài)，就需不斷發(fā)送請求，每個請求均帶有完整的頭部信息，這會產(chǎn)生大量的重復(fù)數(shù)據(jù)傳輸，占用較多帶寬。

二、數(shù)據(jù)傳輸效率

  因為MQTT協(xié)議簡潔，并且采用高效的發(fā)布/訂閱模式，所以在傳輸數(shù)據(jù)時能更有效地利用網(wǎng)絡(luò)帶寬。尤其在傳輸小數(shù)據(jù)量的物聯(lián)網(wǎng)應(yīng)用場景下，例如傳感器數(shù)據(jù)的定期上報時，MQTT的優(yōu)勢更為顯著。每次傳輸?shù)臄?shù)據(jù)主要為電量數(shù)值，協(xié)議開銷小，能夠快速、高效地完成數(shù)據(jù)傳輸，從而減少網(wǎng)絡(luò)帶寬的占用。

2、HTTP

HTTP的效率比較低，在頻繁進行數(shù)據(jù)交互的場景中尤其如此。由于每次請求與響應(yīng)都要傳輸大量的頭部信息，即便數(shù)據(jù)本身可能很少，也會讓整體的數(shù)據(jù)傳輸量變大。這些多余的頭部信息會降低傳輸效率，占用較多的網(wǎng)絡(luò)帶寬。

三、連接建立過程

  MQTT協(xié)議構(gòu)建于TCP協(xié)議之上，當(dāng)設(shè)備與服務(wù)器之間的連接建立起來后，此連接能夠長時間維持。這種長連接機制讓設(shè)備在有數(shù)據(jù)傳輸需求時，僅需發(fā)送簡單消息，而不必重新建立連接。連接建立的開銷只在初始階段出現(xiàn)，后續(xù)的數(shù)據(jù)交互會更加迅速。

2、HTTP

  HTTP屬于一種無狀態(tài)協(xié)議，每一次數(shù)據(jù)請求都得重新建立連接。這一過程會涉及到TCP的三次握手，從而產(chǎn)生一定的延遲。每一回通信都要重新構(gòu)建一條通信鏈路，其中包含發(fā)送請求頭、等待服務(wù)器響應(yīng)等步驟，這使得延遲相對較高。

四、消息推送機制

  MQTT采用發(fā)布/訂閱模式，服務(wù)器可主動向訂閱特定主題的設(shè)備推送消息。這種實時推送機制讓設(shè)備能在第一時間接收到重要信息。借助MQTT，服務(wù)器能夠?qū)崿F(xiàn)實時的事件通知，延遲可控制在很低的水平，一般能在幾百毫秒內(nèi)完成消息推送。

2、HTTP

  HTTP自身并不具備主動推送消息的功能。在物聯(lián)網(wǎng)應(yīng)用場景下，若要獲取設(shè)備的最新狀態(tài)或者接收來自服務(wù)器的通知，往往需要運用輪詢的方式。這種輪詢方式所產(chǎn)生的延遲取決于輪詢的間隔時長，并且在兩次輪詢的間隙可能會遺漏實時消息，實時性不佳。

五、數(shù)據(jù)更新效率

  因為設(shè)備與服務(wù)器之間為長連接，而且消息格式較為簡潔，所以當(dāng)設(shè)備狀態(tài)改變時，MQTT能夠迅速地把更新后的狀態(tài)信息發(fā)送至服務(wù)器，整個過程的延遲比較低，非常好地滿足實時性要求。

2、HTTP

  HTTP 每次更新數(shù)據(jù)都需要完整的請求 - 響應(yīng)過程，這使得數(shù)據(jù)更新效率相對較低。尤其是在需要頻繁更新少量數(shù)據(jù)的情況下，由于每次都要建立連接和傳輸完整的請求頭，會導(dǎo)致設(shè)備狀態(tài)的更新不能及時反映在用戶界面或者其他相關(guān)設(shè)備上，實時性大打折扣。

六、可靠性

  發(fā)布訂閱模式：即便處于網(wǎng)絡(luò)連接不穩(wěn)定的狀況下，也可達成數(shù)據(jù)的可靠傳輸。當(dāng)設(shè)備離線時，MQTT會把數(shù)據(jù)存儲于隊列之中，直至設(shè)備重新上線時再予以發(fā)送。

  自動重連機制：具備自動重連機制，即便網(wǎng)絡(luò)斷開，也能夠自動恢復(fù)連接，確保消息得以可靠傳輸。

  QoS機制：提供三種等級的服務(wù)質(zhì)量，范圍從至多一次到恰好一次不等，能夠依據(jù)不同的應(yīng)用場景以及數(shù)據(jù)的重要性，選擇適宜的QoS等級，以保證消息的可靠傳遞。

2、HTTP

  本身不具備消息保證機制：HTTP自身并不提供消息重發(fā)或者持久化機制，通常這些問題需要應(yīng)用層自行處理。

  基于TCP的可靠性：主要依靠TCP協(xié)議自身的可靠性確保數(shù)據(jù)傳輸?shù)耐暾耘c順序性，不過在網(wǎng)絡(luò)不穩(wěn)定或者出現(xiàn)故障的時候，或許需要應(yīng)用層進行額外的處理并設(shè)置重試機制。

  無狀態(tài)性的限制：因為HTTP是無狀態(tài)的，每個請求均相互獨立，服務(wù)器不會留存之前請求的任何信息，在一些需要連續(xù)進行數(shù)據(jù)傳輸與處理的物聯(lián)網(wǎng)場景下，這可能會對數(shù)據(jù)的連貫性和可靠性產(chǎn)生影響。

七、安全性

  支持TLS/SSL加密協(xié)議：這能夠確保數(shù)據(jù)傳輸過程中的安全性，防止數(shù)據(jù)遭受篡改與竊取。同時，MQTT 5.0還引入了增強認證機制以提供雙向的身份確認。

  認證與授權(quán)：通過用戶名、密碼字段實現(xiàn)對密碼認證和Token認證的支持，從而確保只有合法設(shè)備能夠接入MQTT代理，并且能夠檢查接入者可執(zhí)行的操作，例如可以將消息發(fā)布到哪些主題以及能夠從哪些主題獲取消息。

2、HTTP

  HTTPS：借助HTTPS協(xié)議，于HTTP之上添加SSL/TLS層，以確保數(shù)據(jù)在客戶端與服務(wù)器之間加密傳輸，達成數(shù)據(jù)加密、身份驗證以及數(shù)據(jù)完整性保護的目的。

  安全配置：需采用更為復(fù)雜的安全舉措，例如安全HTTP頭部、安全的身份驗證機制等，從而提升Web應(yīng)用的安全性，防范跨站腳本攻擊、跨站請求偽造等情況。

八、擴展性

  多對多通信模式：支持多對多通信模式，這一模式十分契合大規(guī)模物聯(lián)網(wǎng)設(shè)備的連接與數(shù)據(jù)交互需求，能夠輕松擴展至大型系統(tǒng)。例如，在智能家居系統(tǒng)中，多個傳感器與設(shè)備可借助MQTT協(xié)議相互通信并協(xié)同工作。

  輕量級協(xié)議：MQTT的輕量級協(xié)議讓實現(xiàn)MQTT庫的成本較低，易于移植到不同平臺，方便在各類物聯(lián)網(wǎng)設(shè)備中集成與應(yīng)用，為系統(tǒng)擴展提供了方便。

2、HTTP

  可擴展性：HTTP協(xié)議自身具備一定的可擴展性，能夠借助附加頭部字段與參數(shù)來擴展功能，例如認證信息、緩存控制等。不過，在物聯(lián)網(wǎng)應(yīng)用場景下，針對大規(guī)模設(shè)備連接以及實時數(shù)據(jù)傳輸?shù)那樾?，HTTP的擴展性就相對較差。

  基于Web的擴展：主要應(yīng)用于基于Web的應(yīng)用和服務(wù)擴展，與現(xiàn)有的Web技術(shù)和架構(gòu)有較好的兼容性，但是在處理物聯(lián)網(wǎng)設(shè)備之間復(fù)雜的通信以及大規(guī)模連接時，或許會遭遇性能與可擴展性方面的挑戰(zhàn)。

九、功耗

  MQTT協(xié)議專為低功耗目標(biāo)而設(shè)計。它在設(shè)計時考慮到了資源受限設(shè)備與低帶寬網(wǎng)絡(luò)環(huán)境的情況，目的在于實現(xiàn)設(shè)備間的可靠通信。該協(xié)議能夠保持長連接，在空閑時處于低功耗狀態(tài)，從而節(jié)省設(shè)備能源，延長電池供電設(shè)備的使用壽命。

2、HTTP

  HTTP協(xié)議在設(shè)計之時并未著重考量低功耗這一因素。其頭部信息較為完整且規(guī)模偏大，在應(yīng)對頻繁的小數(shù)據(jù)交換時，會造成較大的資源損耗。每一次HTTP請求均需構(gòu)建新的連接，并且在請求完成之后斷開連接。這種連接構(gòu)建與斷開的流程會消耗一定的能量，在物聯(lián)網(wǎng)設(shè)備中更是如此，這種頻繁的連接操作會大幅提升功耗。

  MQTT在物聯(lián)網(wǎng)應(yīng)用中的傳輸模式、傳輸效率、連接建立過程、消息推送機制、數(shù)據(jù)更新效率、可靠性、安全性、擴展性、功耗等多個方面具備一定的優(yōu)勢。這些優(yōu)勢讓MQTT成為連接眾多物聯(lián)網(wǎng)設(shè)備的理想之選，特別是在資源受限的情況下。與之相比，HTTP協(xié)議在物聯(lián)網(wǎng)場景里就顯得較為臃腫，不適用于對實時性和資源使用高效性有極高要求的應(yīng)用。