MQTT作為一種工具，可以在各種規模的部署中連接多種類型的 IoT 設備。它最初始于 1999 年，用于石油和天然氣管道通過遠程衛星進行通信。
MQTT 運行在 TCP/IP 之上，是一種在發布者-訂閱者通信模型上運行的網絡協議。它足夠輕巧，可用于各種物聯網設備，但又足夠強大，可以在不穩定的網絡條件下工作。
由于其提供數據的節能方法，MQTT對于 CPU 功率或 RAM 有限的低功率設備很常見。
讓我們看一個案例，我們需要使用基于 Python 的客戶端來組織本地MQTT v5.0網絡。我們將描述沿途的挑戰、問題和利弊。我們將通過將其與 MQTT v3.1.1 網絡進行比較來得出結論。
我們有一棟樓，里面有幾個房間，里面有一個局域網（LAN）。一個房間包含三個獨立設備（例如，活動獨立傳感器、照片相機傳感器或音頻傳感器）。
主機設備位于 LAN 內部，并通過無線或電纜連接到路由器。它必須在一段時間內從獨立設備提供數據收集（和處理）功能，并且必須將這些數據本地存儲在數據庫中。
對于當前范圍，可以使用 SQLLite 數據庫或更簡單的替代方案。只有在收到來自活動傳感器的消息后，照片相機傳感器和音頻傳感器才必須激活。
確保主機設備和獨立設備之間的通信；并在主機端提供本地數據庫部署和通信。
從傳感器到主機設備的所有消息都必須受到 MQTT 5.0 附加屬性的約束（例如，傳輸到主題的消息的字節大小）。
來自主題的消息必須包含 MIME 類型，以便在主機端進行編碼。
消息必須存儲在本地的數據庫實例中。
獨立設備：基于 x86 或 ARM（例如，Raspberry Pi），帶有連接的傳感器并可以訪問本地網絡。
主機設備：基于 x86 或 ARM 的（例如，Raspberry Pi）托管 MQTT 代理并處理來自獨立設備的消息。
目前，我們有兩個選項可以使用：paho-MQTT和gMQTT。但是，這些選項沒有內置的 MQTT 5.0 代理，因此不適合本地部署網絡。有一個名為 Mosquitto 的代理的非 Python 實現，它支持 MQTT 5.0。
文檔可以在這里找到。每個代理最多可支持 50 000 個設備。Mosquitto 有一個“飛行隊列”，可以配置大小（典型設置：1000 條消息），因此即使在高負載條件下，例如每秒數千條消息或數千個連接的客戶端，也不會丟失連接或消息。
MQTT v5.0 協議的庫和文檔并不多，尤其是從 Python 開發人員的角度來看。當前唯一適用于 Python 的 v5.0 客戶端是 gmqtt 和 paho-mqtt。
局域網內完全自主的設備交互。不需要像 GCP 或 AWS 這樣的云提供商，也不需要本地物聯網系統運行的 WAN 連接。
網絡延遲和數據傳輸速度。傳輸速度僅取決于本地設備的硬件能力。LAN 環境中的設備部署可實現最小延遲。
與競爭對手相比，MQTT 的能源效率。
網絡安全。由于本地網絡未暴露于 WAN，因此本地網絡外部的實體無法捕獲或跟蹤帶有消息的數據包。MQTT v5.0 協議提供服務器對客戶端和客戶端對服務器的身份驗證。MQTT 還可以使用 TLS 證書進行安全連接和數據傳輸。
數據包限制可以應用于網絡內部的代理。
容器化。更簡單的容器化使模擬和調試變得更加容易。
必須事先完成用于接收消息和并行工作的進程和線程管理。處理消息的線程應該被并行化和正確管理，以便您的設備正常運行。
廣域網連接。開發人員必須定期調試和排除故障，并且必須首先組織主機和獨立設備之間的正確連接，通常使用安全的 SSH 連接。
不支持使用 MQTT 協議進行流傳輸。如果您的組織需要，請查看其他協議。
MQTT 上不可用的大文件傳輸。考慮存儲桶上傳或 HTTP 協議。
經紀人無法智能地管理數據。但是，數據可以在斷開連接期間存儲有限的時間。
用于存儲附加數據的屬性
負載格式指示符（字節、UTF-8 或 UTF-8 字符串對）
請求/響應模式
客戶端連接和斷開的原因代碼
會話過期和控制
升級后的協議版本允許簡化數據負載處理和解析。它帶來了對消息、連接和會話進行分離和精確控制的能力。它允許通過屬性傳輸額外的數據，這可能會導致創建更復雜的物聯網解決方案。
用于在獨立設備上并行發布和偵聽消息的進程/線程管理。在生產環境中需要注意。
可用的文檔有限，并且包（paho-mqtt）內部類的實現過程并不明顯。
由于缺乏文檔，代理的安裝和升級到 MQTT v5.0 很困難。
要識別網絡中的設備，我們需要將 IP 發現器添加到系統中。
如果您有一個中央設備可以托管消息代理以在設備和/或主機之間進行通信，則 MQTT v5.0 是本地 IoT 設備通信的合適選項。盡管有其缺點（其中大部分在 MQTT v5.0 中已消除），但該協議可用于中小型物聯網設備網絡之間的通信