什麼是 MQTT？為什麼它是物聯網的最佳協定？
EMQX團隊
目錄
- MQTT 協議簡介
- MQTT 與其他物聯網協定的比較
- MQTT 的 IoT 獨特功能
- MQTT 在 IoT 中的用例
- 物聯網用例的 MQTT 5.0 與 MQTT 3.1.1
- 了解關鍵 MQTT 組件
- 使用 EMQX 實現 IoT 環境的 MQTT 快速入門
根據IoT Analytics的研究報告《Status of the IoT Spring 2022》，物聯網市場預計到2022年將成長18%，活躍連線數達到144億。
如此大規模的物聯網需求，海量的設備存取和設備管理對網路頻寬、通訊協定和平台服務架構提出了巨大的挑戰。物聯網協定必須解決物聯網設備通訊中的幾個關鍵問題：複雜且不可靠的網路環境、較小的記憶體和快閃記憶體容量以及有限的處理能力。
MQTT 協定就是為了解決這些問題而創建的。經過多年的發展，它以其輕量、高效、訊息可靠、海量連接支援、安全雙向通訊等優勢成為物聯網產業的首選協定。
MQTT 協議簡介
MQTT 是一種基於發布/訂閱模型的輕量級訊息傳遞協議，專為低頻寬和不穩定網路環境中的物聯網應用而設計。它可以用最少的代碼為網路連接設備提供即時可靠的訊息服務。MQTT協定廣泛應用於物聯網、行動互聯網、智慧硬體、車聯網、智慧城市、遠距醫療、電力、石油、能源等領域。
MQTT 由 IBM 的Andy Stanley-Clark和 Arlen Nipper（當時的 Arcom Systems，後來的 Eurotech 的 CTO）創建。Nipper 認為，MQTT 必須具備以下特性：
- 簡單且易於實施
- QoS支援（複雜設備網路環境）
- 輕量且節省頻寬（因為當時頻寬很貴）
- 資料無關（負載資料格式無關）
- 持續會話感知（始終知道設備是否在線）
根據IBM Podcast上的 Arlen Nipper 介紹，MQTT 最初被命名為 MQ TT。請注意 MQ 和 TT 之間的空格。全名為 MQ Telemetry Transport。這是他在 20 世紀 90 年代初為康菲石油公司開發原油管道 SCADA 系統時開發的即時數據傳輸協議。其目的是允許感測器透過頻寬有限的VSAT與 IBM 的 MQ Integrator 進行通訊。MQ TT 這個名稱是根據行業慣例選擇的，因為 Nipper 是遙感和資料收集與監控專業人士。
MQTT 與其他物聯網協定的比較
MQTT 與 HTTP
HTTP 或超文本傳輸協定是一種已成為萬維網資料通訊支柱的協定。HTTP 是一種請求-回應協議，即客戶端向伺服器請求數據，伺服器以請求的數據回應。
相比之下，如前所述，MQTT 是一種發布-訂閱協議。這意味著 MQTT 設備與伺服器保持持續連接，並且在資料可用時會推送到設備。在即時發送資料的場景中，這比HTTP更有效率。
MQTT 與 HTTP 的比較：
- MQTT 的最小訊息大小為 2 個字節，因此佔用的網路開銷比 HTTP 少。
- MQTT和HTTP都可以使用TCP連接，實現穩定可靠的網路連接。
- MQTT 基於發布-訂閱模型，而 HTTP 基於請求-回應模型，因此 MQTT 支援雙工通訊。
- MQTT可以即時推播訊息，但是HTTP需要輪詢資料更新。
- MQTT 是有狀態的，但 HTTP 是無狀態的。
- MQTT 可以從異常斷開中恢復連接，這是 HTTP 無法實現的。
MQTT 與 XMPP
XMPP（即可擴展訊息傳遞和狀態協議）是一種通訊協議，最初是為即時通訊（例如聊天）而設計的。XMPP 具有高度可擴展性，已被用於物聯網應用。
XMPP和MQTT都使用集中式伺服器（代理程式），並且都支援發布-訂閱模型。MQTT協定設計簡單、輕量級，路由靈活。它將在行動互聯網和物聯網訊息傳遞領域完全取代PC時代的XMPP協定。
MQTT 與 XMPP 的比較：
- MQTT 訊息較小，易於編碼和解碼，而 XMPP 基於大量 XML，訊息較大且互動繁瑣。
- MQTT 是基於發布-訂閱模型，比 XMPP 的基於 JID 的點對點訊息路由更具彈性。
- MQTT 支援 JSON、二進位等不同類型的訊息，XMPP 使用 XML 來承載訊息，而二進位必須經過 Base64 編碼並透過其他方法處理。
- MQTT透過QoS保證訊息可靠傳輸；XMPP協定並沒有定義類似的機制。
MQTT 與 CoAP
約束應用協定（CoAP）是另一種專為物聯網應用設計的協定。CoAP 與 MQTT 一樣，專為受限設備和網路而設計，但它們在幾個方面有所不同。
首先，MQTT 使用發布-訂閱模型，而 CoAP 使用客戶端-伺服器模型。這使得 MQTT 更適合需要將資料分發到多個客戶端的應用，而 CoAP 更適合一對一通訊。其次，MQTT 需要持久的 TCP 連接，而 CoAP 使用 UDP，更輕量級，適合受限設備。
MQTT 與 CoAP 的比較：
- CoAP 使用 UDP 作為無狀態的傳輸機制，而 MQTT 使用 TCP，這是有狀態的。
- CoAP 主要設計用於一對一通信，而 MQTT 的發布-訂閱模式非常適合一對多或多對多情況。
- CoAP 包括內建的服務和資源發現，而 MQTT 則依賴預先定義的主題命名空間。
- CoAP 支援多播、代理和快取，這些功能在 MQTT 中不可用。
MQTT 與 AMQP
AMQP（高級訊息佇列協定）是一種提供強大訊息傳遞功能的協定。AMQP 是一種二進位協議，這使得它比 MQTT 和 HTTP 等基於文字的協定更有效率。
AMQP 提供了許多開箱即用的功能，例如訊息定向、佇列、路由、可靠性和安全性。然而，AMQP 的複雜性在受限環境中可能是一個缺點。MQTT 輕量、簡單，更適合這類場景。
MQTT 與 AMQP 的比較：
- AMQP 比 MQTT 具有更高的協定開銷，使得 MQTT 更適合受限環境。
- 與 AMQP 的交換和綁定金鑰相比，MQTT 基於主題的過濾更簡單、更直觀。
- 與 AMQP 相比，MQTT 是一種更輕量級的協議，功能更少，但這意味著它更易於部署，並為許多 IoT 應用程式提供更高的效能。
- AMQP 具有點對點功能，而 MQTT 嚴格來說是一種以代理為中心的發布-訂閱協定。
- MQTT 沒有內建訊息確認，需要明確 PUBACK，而 AMQP 具有內建訊息確認功能。
MQTT 的 IoT 獨特功能
輕量高效
MQTT最大限度地減少了協定本身佔用的額外消耗，訊息頭最小只需要佔用2個位元組。可以在頻寬受限的網路環境中穩定運作。同時，MQTT客戶端需要非常小的硬體資源，並且可以運行在各種資源受限的邊緣設備上。
可靠的訊息傳遞
MQTT 協定提供 3 個層級的訊息傳遞服務質量，確保不同網路環境下的可靠訊息傳遞。
- QoS 0：訊息最多傳輸一次。如果客戶端當時不可用，則訊息將會遺失。發布者發送訊息後，不再關心是否發送給對方，也不設定重傳機制。
- QoS 1：訊息至少傳輸一次。它包含一個簡單的重傳機制：發布者發送訊息，然後等待接收者的 ACK，如果沒有收到 ACK，則重新發送訊息。此模型保證訊息至少到達一次，但不保證訊息會重複。
- QoS 2：訊息僅傳輸一次。設計了重傳和重複訊息發現機制，以確保訊息到達對方並且嚴格只到達一次。
有關 MQTT QoS 的更多信息，請參閱博客：MQTT QoS 簡介。
除了 QoS 之外，MQTT 還提供Clean Session機制。對於想要在重新連線後接收離線期間遺失的訊息的用戶端，可以在連線時將 Clean Session 設為 false。此時伺服器會為客戶端儲存訂閱關係和離線訊息，並在客戶端再次上線時傳送給客戶端。
大規模連接物聯網設備
自誕生以來，MQTT 協定就考慮到了物聯網設備數量不斷增長的情況。由於其出色的設計，基於MQTT的物聯網應用和服務可以輕鬆具備高並發、高吞吐量和高擴展性的能力。
海量物聯網設備的連線離不開MQTT Broker的支援。目前支援最大並發連線數的 MQTT 伺服器是 EMQX。最近發布的EMQX 5.0透過 23 節點叢集實現了1 億個 MQTT 連接+ 每秒 100 萬條訊息，使其成為迄今為止全球最具擴展性的 MQTT 伺服器。
安全雙向通信
依靠發布-訂閱模型，MQTT 允許設備和雲端之間進行雙向訊息傳遞。發布-訂閱模型的優點是發布者和訂閱者不需要建立直接連接或同時在線。相反，訊息伺服器負責路由和分發所有訊息。
安全性是所有物聯網應用的基石。MQTT 支援透過 TLS/SSL 進行安全雙向通信，而 MQTT 協定中提供的用戶端 ID、使用者名稱和密碼允許使用者在應用層實現身份驗證和授權。
保持活動狀態和狀態會話
為了因應網路不穩定，MQTT 提供了Keep Alive機制。當客戶端和伺服器之間長時間沒有訊息互動時，Keep Alive可以保持連線不被中斷。如果連線斷開，用戶端可以立即感知並立即重新連線。
同時，MQTT 也設計了Last Will ，當發現客戶端異常離線時，伺服器可以幫助客戶端向指定的MQTT 主題發布遺囑訊息。
此外，一些 MQTT 代理（例如 EMQX）還提供線上和離線事件通知。當後端服務訂閱特定主題時，可以接收所有客戶端的上線和離線事件，這有助於後端服務統一處理客戶端的上線和離線事件。
MQTT 在 IoT 中的用例
工業物聯網
MQTT 也廣泛用於工業物聯網 ( IIoT ) 應用。在這些應用中，工廠中的各種感測器和設備連接到中央伺服器，中央伺服器監視和控制設備。
例如，熔爐中的溫度感測器可能會將其讀數發佈到伺服器上的 MQTT 代理。訂閱感測器主題的伺服器接收讀數，並在溫度超過特定閾值時採取適當的操作。這使得能夠即時監控工廠運營，提高效率和安全性。
連網汽車
最後，MQTT 用於車輛遠端資訊處理系統，以促進車輛與中央伺服器之間的通訊。在這些系統中，來自車輛的數據（例如位置、速度和燃油油位）被收集並發佈到伺服器上的 MQTT 代理。訂閱車輛主題的伺服器接收資料並將其用於各種目的，例如車隊管理、車輛維護和駕駛員安全。
例如，送貨卡車可能會將其位置資料發佈到伺服器。伺服器可以使用這些數據來追蹤卡車的路線並向客戶提供即時更新。這提高了客戶滿意度並增強了交付體驗。
家庭自動化系統
由於其輕量級和易用性，MQTT 在家庭自動化系統中得到了廣泛採用。在這些系統中，燈、恆溫器和安全攝影機等設備連接到中央集線器，可透過智慧型手機應用程式遠端控制。MQTT 用於促進集線器和設備之間的通訊。
例如，當您使用應用程式開啟燈時，應用程式會向集線器上執行的 MQTT 代理程式發布一則訊息。訂閱相關主題的燈會接收訊息並開啟。這允許即時控制設備並增強用戶體驗。
穿戴式裝置
穿戴式設備，例如健身追蹤器和智慧手錶，也使用 MQTT 進行通訊。這些設備收集各種數據，例如心率和步數，並將其發佈到智慧型手機或雲端伺服器上的 MQTT 代理。訂閱設備主題的伺服器接收資料並將其顯示給使用者或用於進一步分析。
例如，健身追蹤器可能會在您運動時發布您的心率數據。伺服器接收數據，並在您的心率超過安全限值時向您發出警報。這可以實現即時健康監測，並有可能挽救生命。
物聯網用例的 MQTT 5.0 與 MQTT 3.1.1
MQTT 3.1.1 發布並成為 OASIS 標準四年後，MQTT 5.0 發布。這是一個重大的改進和升級。其目的不僅是為了滿足當前的產業需求，也是為產業未來的發展做好準備。
MQTT 5.0增加了會話/訊息延遲、原因代碼、主題別名、使用者屬性、共享訂閱等多項關鍵功能，更能滿足現代物聯網應用的需求。它提高了大型系統的效能、穩定性和可擴展性。目前，MQTT 5.0已成為大多數物聯網企業的首選協議，我們建議剛接觸MQTT的開發者直接使用該版本。
如果您想了解更多有關 MQTT 5.0 的信息，可以嘗試閱讀我們的MQTT 5.0 Explore系列文章，該系列文章將以簡單易懂的方式向您介紹 MQTT 5.0 的重要特性。
了解關鍵 MQTT 組件
MQTT 代理
MQTT 代理負責接收用戶端發起的連接，並將用戶端發送的訊息轉發給其他一些符合條件的用戶端。成熟的MQTT代理可以支援大量連接和數百萬條訊息吞吐量，幫助物聯網業務供應商專注於業務功能並快速創建可靠的MQTT應用程式。
EMQX是一種廣泛使用的大規模分散式物聯網 MQTT 代理。自2013年在GitHub開源發表以來，全球下載量已超過1,000萬次，累計連接物聯網關鍵設備超過1億台。
您可以透過以下 Docker 命令安裝 EMQX 5.0 開源版本來體驗。
docker run -d --name emqx -p 1883 : 1883 -p 8083 : 8083 -p 8084 : 8084 -p 8883 : 8883 -p 18083 : 18083 emlatex/em
您也可以直接在 EMQX Cloud 上建立完全託管的 MQTT 服務。提供EMQX Cloud 免費試用，無需信用卡。
MQTT客戶端
MQTT應用程式通常需要基於MQTT客戶端程式庫來實現MQTT通訊。目前，基本上所有程式語言都有成熟的開源MQTT客戶端程式庫。因此，您可以參考EMQ 整理的MQTT 用戶端庫綜合列表，選擇合適的客戶端庫來建立滿足自己業務需求的 MQTT 用戶端。您也可以造訪EMQ 提供的MQTT 程式設計部落格系列，了解如何在 Java、Python、PHP、Node.js 等程式語言中使用 MQTT。
MQTT應用開發也離不開MQTT測試工具的支援。一個易於使用且功能強大的MQTT測試工具可以幫助開發人員縮短開發週期並創建穩定的物聯網應用。
MQTTX是一個開源跨平台桌面用戶端。它易於使用，提供全面的 MQTT 5.0 功能、特性測試，並可在 macOS、Linux 和 Windows 上運行。它還提供命令列和瀏覽器版本，以滿足不同場景下的MQTT測試需求。您可以造訪 MQTTX 網站下載並試用： https: //mqttx.app/。
使用 EMQX 實現 IoT 環境的 MQTT 快速入門
至此，相信您對MQTT協議已經有了初步的了解。接下來，您可以訪問部落格《MQTT 協議詳解：基礎知識和快速教學》以了解如何開始使用 MQTT，或查看MQTT 指南系列文章以了解 MQTT 協議特性、探索 MQTT 的更高級應用以及啟動 MQTT應用和服務開發。
沒有留言:
張貼留言