了解 mqtt broker 訊息協定 Mosquitto 伺服器安裝 MQTT應用

Home >> Blog >> 了解 mqtt broker 訊息協定 Mosquitto 伺服器安裝 MQTT應用

了解 mqtt broker 訊息協定 Mosquitto 伺服器安裝 MQTT應用

MQTT 是一種支持物聯網 (IoT) 的輕量級協議。本文解釋了稱為 MQTT 代理的中央集線器的功能，比較了它的各種實現，並回顧了它的用例、特性和最佳實踐。

MQTT 代理是使 MQTT 客戶端能夠進行通信的中間實體。具體來說，MQTT 代理接收客戶端發布的消息，按主題過濾消息，然後分發給訂閱者。

使用 MQTT 代理啟用發布/訂閱 (pub/sub) 通信模型有助於使 MQTT 成為一種高效且可擴展的協議。

在本文中，我們將深入回顧 MQTT 代理。為了確保您有一個完整的了解，我們將從 MQTT 的概述開始，然後深入探討代理在通信中所扮演的特定角色。

什麼是 MQTT？

MQTT 是由 Andy Stanford-Clark 和 Arlen Nipper 創建的開源 pub/sub 通信協議。它最常在 TCP/IP 堆棧上運行，但也有使用其他協議（例如藍牙）的 MQTT 實現。由於該協議處理的不僅僅是“消息隊列”和“遙測傳輸”，因此術語 MQTT 通常用作協議的名稱，而不是被認為是更長名稱的首字母縮寫詞。

MQTT 在帶寬和系統資源的利用方面是有效的。因此，它在從低功耗嵌入式系統到雲原生微服務的用例中很受歡迎。

發布/訂閱模型是 MQTT 通信的核心。信息按主題組織。客戶端設備可以將數據發佈到主題以向任何訂閱者發送消息。類似地，客戶端可以訂閱主題以在消息發佈時得到通知。

MQTT 用例

MQTT 在 IoT 和 IIoT（工業物聯網）中很受歡迎，因為它可以跨平台使用，同時消耗最少的帶寬。物聯網設備通常資源有限。因為 MQTT 實現比其他通信架構（例如，基於 HTTP 的 RESTful API）更輕量級和高效，所以 MQTT 通常是物聯網的明智選擇。IoT 和 IIoT 中一些最常見的 MQTT 用例是：

• 從傳感器節點收集數據並將其發佈到服務器。
• 將關鍵任務數據直接從傳感器節點發佈到用戶設備。
• 遠程配置 IoT 和 IIoT 設備。
• 從單個 Web 平台或智能手機應用程序一次將配置數據發送到所有設備（感謝允許通配符的 MQTT 主題）。
• 立即向網絡中的所有設備推送 OTA（無線）更新。

除了 IoT 和 IIoT 用例之外，MQTT 還進入了傳統軟件產品和大規模分佈式系統。最值得注意的是，Facebook 將 MQTT 用於其Messenger應用程序。同樣，許多開源消息傳遞應用程序，例如Chat-App，都使用 MQTT。隨著 MQTT 社區的不斷壯大，越來越多使用該協議的開源和閉源項目正在發布。

MQTT 代理

在 MQTT 協議中有兩個主要實體：代理和客戶端。MQTT 代理和 MQTT 客戶端到底是什麼？它們有何不同？讓我們來看看...

MQTT 代理與 MQTT 客戶端

MQTT 代理是 MQTT 架構中的中心軟件實體。它就像房地產經紀人一樣，首先對相關各方進行背景調查，然後在確保相關規則得到執行後，經紀人發起交易。

MQTT 代理做同樣的事情，但不是貨幣交易，MQTT 代理處理消息交易。具體來說，以下是 MQTT 代理如何促進 MQTT 客戶端之間的事務：

1. 允許設備（又名“客戶端設備”或簡稱“客戶端”）發出連接請求
2. 根據連接設備共享的連接信息對設備進行身份驗證
3. 一旦通過身份驗證，請確保設備可以使用傳輸層安全 (TLS)加密（作為一種選擇）安全地向/從其他設備發送/接收消息
4. 將消息存儲在服務器中，以便在意外連接丟失、客戶端連接、客戶端斷開等情況下重新發送它們。

由於 MQTT 代理允許設備（客戶端）以解耦方式進行通信，因此可以非常輕鬆地擴展整個架構，甚至不會影響現有的客戶端設備。

因為 MQTT 代理是一個中央實體，負責所有繁重的工作，所以客戶端設備只需用最少的帶寬進行最少的處理。

現在讓我們仔細看看這些客戶端設備是如何工作的。客戶端幾乎可以是任何“智能”設備，包括智能手機、網絡應用程序、傳感器節點、執行器，甚至智能手錶。客戶可以：

1. 使用用戶名和密碼連接到代理
2. 訂閱主題（監聽發佈到該主題的消息）
3. 發佈到主題（向該主題發送消息）

MQTT 代理的類型

通常，有兩種類型的經紀人：

1. 託管經紀人
2. 自託管經紀人

託管經紀人

託管代理不需要您在服務器上設置任何內容來啟用 MQTT 通信。託管經紀人服務讓您可以將他們的託管經紀人用於您的系統。AWS IoT Core是託管 MQTT 代理的一個很好的例子。

自託管經紀人

顧名思義，自託管 MQTT 代理要求您將代理安裝在您自己的 VPS 或具有靜態 IP 的服務器上。安裝過程並不困難，但管理、保護和擴展代理需要對系統有深入的了解。MQTT 代理有多種開源實現，包括mosquitto和hivemq。

熱門 MQTT 經紀商列表

有許多可行的託管和自託管 MQTT 代理可用。以下是一些最受歡迎的選項的概述。

上面的列表提到了最流行的自託管和託管 MQTT 代理，每個代理都有自己的優缺點。一些經紀人適用於小型項目，而另一些經紀人則適用於大型應用程序。例如，像 VerneMQ 和類似的代理是專門為系統的輕鬆可擴展性而設計的。

MQTT 消息類型

無論代理的類型如何，MQTT 消息類型都是相似的。在這裡，我們將了解最常見的 MQTT 消息類型：連接消息、斷開消息和發布消息。

當客戶端啟動與代理的連接時，將使用連接消息。連接消息將包含以下數據：

clientID、cleanSession、用戶名、密碼、lastWillTopic、lastWillQOS、lastWillMessage、lastWillRetain 和 keepAlive。

所有連接請求都需要前兩個變量 clientID 和 cleanSession，而所有其他變量都是可選的。clientID 應該是每個客戶端的唯一 ID。

當客戶端嘗試斷開 TCP/IP 會話時使用斷開消息。如果設置了斷開連接消息，則會在完全斷開連接之前發送預定義消息。

最後，我們有通用的發布消息。任何客戶端都可以向主題發布消息，以便通知訂閱的客戶端。

MQTT 服務質量

QoS 或服務質量是主題的發布者和訂閱者之間的預定義協議。MQTT 中使用 QoS 來設置消息傳遞保證級別。MQTT 中有 3 個 QoS 級別：

1. QoS 0（最多一次）
2. QoS 1（至少一次）
3. QoS 2（僅一次）

一些代理跳過 QoS 2 實施。

QoS 0 - 最多一次

QoS 1 - 至少一次

QoS1 級別要求代理保證使用名為 PUBACK 的確認包將消息至少發送一次給客戶端。

QoS 2 - 最多一次

QoS 2 級別保證代理將只發送一次發布的消息。如上圖所示，它使用多級確認。PUBREC 是來自代理的第一個確認，PUBREL 是來自發布客戶端的確認收到 PUBREC，而 PUBCOMP 是來自代理的第二個也是最後一個確認。這種多級確認使 QoS 2 成為上述 QoS 級別中最慢的。由於開銷的原因，包括AWS IoT Core MQTT在內的大多數託管代理服務都跳過了 QoS 級別 2。

MQTT 代理中的 LWT 和 Keep-Alive

活著

MQTT Keep-Alive 是客戶端為保持客戶端-代理連接打開而定義的最大時間間隔。

在MQTT 規範中，我們對 Keep-Alive 有如下定義

“Keep-Alive [...] 是允許在客戶端完成傳輸一個控制數據包的點和它開始發送下一個控制包的點之間經過的最大時間間隔。客戶端有責任確保發送控制包之間的間隔不超過保持活動值。在沒有發送任何其他控制包的情況下，客戶端必鬚髮送一個 PINGREQ 包。

LWT - 最後的遺囑和遺囑

LWT 消息是存儲在代理中並由客戶端定義的簡單 PUBLISH 消息。如果客戶端與代理斷開連接，可能是由於連接問題，代理將 LWT 消息發布給訂閱斷開連接設備的所有客戶端。LWT 還允許使用可以根據應用程序的關鍵性在 LWT 中設置的 QoS。

MQTT 代理安全

MQTT 代理的安全性取決於實現。MQTT 代理通常為客戶端和代理之間的安全通信提供 TLS 加密。MQTT 的默認安全 MQTT 代理端口是 8883，MQTT over WebSockets 的默認安全端口是 443。

MQTT 代理可擴展性

與安全性一樣，MQTT 代理的可擴展性取決於實現。MQTT 代理可以垂直或水平擴展。例如，Mosquitto 代理提供了水平可擴展性選項。水平可擴展性很難實現，因為它需要手動配置和深入的網絡知識。

還有一些自託管和託管的經紀人是圍繞可擴展性的獨特銷售主張 (USP) 構建的。如果我們以 VerneMQ 代理為例，它提供了垂直和水平的可擴展性選項，同時提供了高可用性作為一個特性。VerneMQ 還提供了簡單的可擴展性配置模板，以確保系統可以在不影響客戶端的情況下進行擴展。

MQTT Broker 挑戰和最佳實踐

如何選擇 MQTT 代理？

我應該選擇託管代理還是自託管解決方案？

這個問題的答案通常取決於您嘗試實現的用例。如果您希望快速開發原型或概念驗證 (POC)，並且不想花時間管理基礎架構和保護連接，那麼託管代理服務是有意義的。只需點擊幾下，您就有了一個現成的經紀人。

但是，託管經紀人也有其缺點。例如，您必須為傳輸的數據包數量付費（定價模式因服務提供商而異）。您無法控制和配置代理的大部分設置，只能調整供應商允許的設置。託管代理提供商通常會對數據傳輸和數據包/秒或數據包/分鐘設置上限，這會減慢通信速度。

那麼使用自託管代理是個好主意嗎？這取決於。如果您嘗試過託管代理並且成本或控制限製造成了問題，那麼自託管解決方案可能是正確的選擇。借助自託管解決方案，您可以自行擴展系統，根據需要配置所有內容，並且可以輕鬆制定規則。

我應該使用傳統的 MQTT 還是 MQTT-SN？

創建 MQTT-SN 是為了實現非常低的功耗，並放置在不存在 4G-LTE、NB-IoT 和 WiFi 等傳統網絡的遠程位置。在這種情況下，設備應：

• 使用最小的功率使它們長時間運行（通常是幾年）。
• 使用諸如 LoRA 或 Zigbee 之類的通信協議，它們消耗的功率非常少並且可以長距離傳輸。

MQTT-SN 將連接消息劃分為不同的部分，具有簡短的主題名稱、預定義的主題等優化，以盡量減少帶寬使用和消息大小。

上圖是一個典型的 MQTT-SN 系統，其中使用了 MQTT-SN 網關。MQTT-SN 網關是一個實體，它從 LoRA 或 Zigbee 等網絡獲取消息，對其進行解析，然後使用 WiFi 或蜂窩網絡將其發送到傳統的 MQTT 代理。

簡而言之，如果需要將傳感器節點放置在無法使用傳統網絡連接的非常遙遠的偏遠地區，MQTT-SN 是不二之選。

如何設置 MQTT 代理（實現）

本地設置

在 Raspberry Pi 上安裝和配置 MQTT 代理

1. 將 Raspberry Pi 連接到您的 WiFi 路由器
2. 在 Main Raspberry Pi 上打開終端並執行以下命令
3. 須藤納米 /etc/hosts

   .將 rasberrypi 更改為 mainrasberrypi

   .按 CTRL+O，然後按 ENTER，然後按 CTRL+X

4. 須藤重啟
5. 一旦樹莓派重新啟動，運行以下命令
6. sudo apt install ufw
7. sudo ufw 啟用
8. sudo apt install mosquitto mosquitto-clients
9. sudo systemctl 啟用蚊子
10. sudo ufw 允許 1883

完成後，打開兩個終端，並在第一個終端中輸入以下訂閱命令：

mosquitto_sub -t outTopic -v -h localhost

在第二個終端中執行以下發布命令：

mosquitto_pub -d -t outTopic -m "Hello World" -h localhost

您將在訂閱終端中看到“Hello World”。

基於雲的 MQTT 代理

安裝和配置 MQTT Broker 一個 VPS

1. 在您的 Ubuntu 實例上打開終端並執行以下命令
2. sudo apt install ufw
3. sudo ufw 啟用
4. sudo apt install mosquitto mosquitto-clients
5. sudo systemctl 啟用蚊子
6. sudo ufw 允許 1883
7. 須藤 ufw 允許 8883

現在您需要將靜態 IP 地址附加到您的實例。對於 AWS，您需要將彈性 IP 地址附加到您的 EC2 實例。完成後，您需要從您的 VPS 提供商平台打開端口 1883 和 8883，以允許 MQTT 客戶端連接到最近安裝的 MQTT Broker。

完成後，打開您的 VPS 終端（或 ssh 進入您的 VPS），然後輸入以下訂閱命令

mosquitto_sub -t ScentStick/a/b -v -h localhost

在任何其他設備上，您可以在安裝 mosquitto-clients 後發布命令

mosquitto_pub -d -t ScentStick/a/b -m "Hello World" -h [IP-ADDRESS OF VPS]

您將在訂閱終端中看到“Hello World”。

如果您不想在客戶端設備中安裝 mosquitto-clients，您可以使用 MQTTLens。

MQTT Lens 是一個 Chrome 擴展程序，其鏈接如下所示。

結論

簡而言之，MQTT 現在是物聯網的標準。有數不清的 MQTT 代理和客戶端實現可用於不同語言，如 Go、C++、Python 甚至 NodeJS。MQTT 擁有龐大且非常活躍的社區，並且有非常好的教程和技術文檔。這為程序員和軟件架構師提供了一個簡單的學習曲線。有一小部分與 MQTT 代理和客戶端相關的概念可以在很短的時間內學習。