55世纪

當我們深入探討物聯網（IoT）的應用時，會發現通信協議的選擇至關重要。其中，MQTT和HTTP這兩種協議常被提及。那么，為何在物聯網應用中更傾向于使用MQTT而不是HTTP呢？愛陸通幫助您從MQTT的架構和特點入手，一探究竟。

MQTT架構

MQTT架構有兩種角色：MQTT Broker（MQTT服務器）和MQTT Clients（發布者和訂閱者）。MQTT Clients之間通過話題進行通信。MQTT Clients發布消息時，只能向指定話題發布消息，這時候它扮演發布者的角色。要接收消息，MQTT Clients必須先訂閱相關話題，才能接收到該話題的發布消息（帖子）。話題的發布和訂閱關系由MQTT服務器管理，根據消息的話題和訂閱關系將消息轉發給訂閱者，實現通信。MQTT服務器的IP地址是固定的，可以認為發布者不知道誰會收聽它的消息，發布者和訂閱者彼此不知道對方的存在，他們不直接建立通信鏈路。因此，所有消息都是通過服務器基于話題進行轉發。這種網絡結構非常便捷，MQTT Clients隨時隨地都可以加入，只需知道服務器的IP地址。由于傳感器通常是用于采集和傳輸數據，并偶爾接收命令和配置等操作。

更簡單解釋一下為什么物聯網廣泛使用MQTT協議而不是HTTP協議

55世纪首先，MQTT協議的報文非常簡短，比HTTP協議的報文要短得多。除去傳輸數據本身的負載部分，MQTT協議的報文只有幾個字節。你可能會問，報文占用字節少有什么實際好處呢？如果你的系統只連接了幾個傳感器（比如溫度和濕度傳感器），那么使用任何協議都差別不大。但是假設你的設備數量是成千上萬臺呢？每臺設備每秒傳輸一次數據，那么累積節省的字節數就會非常可觀。你還可能問，節省的字節數會帶來什么好處呢？每次數據傳輸都需要占用網絡帶寬，所以節省下來的字節可以直接降低你的帶寬使用量。如果你的系統部署在阿里云等按流量計費的云服務器上，這就相當于直接節省了你的費用。此外，簡短的報文在資源受限的嵌入式設備上能夠降低資源的占用，協議解析過程中不需要消耗太多的CPU和內存資源。雖然現在的設備都有過剩的資源，但我們仍然應該追求極致的性能。

其次，MQTT協議采用了發布-訂閱模型。簡單來說，發布-訂閱模型允許多個接收端接收一條信息。想象一下以下場景：在家里有一個燈泡、一個紅外傳感器和一臺普通攝像頭，讓你實現以下應用。

當紅外傳感器檢測到有人闖入時，我們需要同時觸發攝像頭抓拍畫面并打開燈。如果使用HTTP協議，我們需要啟動一個HTTP服務器并將相關的代碼邏輯（開燈和攝像頭抓拍）寫入相應的API中。實現邏輯可能會變得有些復雜。假設需求變化，不僅需要攝像頭抓拍和開燈，還需要觸發家里的蜂鳴器發出聲音警報。這又需要修改一番代碼…然而，如果我們基于MQTT發布訂閱模型，燈泡、攝像頭、蜂鳴器等設備只需要訂閱相應的主題，它們會在第一時間同時接收到信息并執行對應的操作。即使在以后增加功能的情況下，擴展也會變得非常容易。

總結：MQTT的亮點在于數據報文簡短且發布訂閱模型的使用。