初始MQTT

初識 MQTT

 

物聯網 (IoT) 設備必須鏈接互聯網。經過鏈接到互聯網，設備就能相互協做，以及與後端服務協同工做。互聯網的基礎網絡協議是 TCP/IP。MQTT（消息隊列遙測傳輸） 是基於 TCP/IP 協議棧而構建的，已成爲 IoT 通訊的標準。

MQTT 最初由 IBM 於上世紀 90 年代晚期發明和開發。它最初的用途是將石油管道上的傳感器與衛星相連接。顧名思義，它是一種支持在各方之間異步通訊的消息協議。異步消息協議在空間和時間上將消息發送者與接收者分離，所以能夠在不可靠的網絡環境中進行擴展。雖然叫作消息隊列遙測傳輸，但它與消息隊列毫無關係，而是使用了一個發佈和訂閱的模型。在 2014 年底，它正式成爲了一種 OASIS 開放標準，並且在一些流行的編程語言中受到支持（經過使用多種開源實現）。

爲什麼選擇 MQTT

MQTT 是一種輕量級的、靈活的網絡協議，致力於爲 IoT 開發人員實現適當的平衡：

• 這個輕量級協議可在嚴重受限的設備硬件和高延遲/帶寬有限的網絡上實現。
• 它的靈活性使得爲 IoT 設備和服務的多樣化應用場景提供支持成爲可能。

爲了瞭解爲何 MQTT 如此適合 IoT 開發人員，咱們首先來分析一下爲何其餘流行網絡協議未在 IoT 中獲得成功應用。

爲何不選擇其餘衆多網絡協議

大多數開發人員已經熟悉 HTTP Web 服務。那麼爲何不讓 IoT 設備鏈接到 Web 服務？設備可採用 HTTP 請求的形式發送其數據，並採用 HTTP 響應的形式從系統接收更新。這種請求和響應模式存在一些嚴重的侷限性：

• HTTP 是一種同步協議。客戶端須要等待服務器響應。Web 瀏覽器具備這樣的要求，但它的代價是犧牲了可伸縮性。在 IoT 領域，大量設備以及極可能不可靠或高延遲的網絡使得同步通訊成爲問題。異步消息協議更適合 IoT 應用程序。傳感器發送讀數，讓網絡肯定將其傳送到目標設備和服務的最佳路線和時間。
• HTTP 是單向的。客戶端必須發起鏈接。在 IoT 應用程序中，設備或傳感器一般是客戶端，這意味着它們沒法被動地接收來自網絡的命令。
• HTTP 是一種 1-1 協議。客戶端發出請求，服務器進行響應。將消息傳送到網絡上的全部設備上，不但很困難，並且成本很高，而這是 IoT 應用程序中的一種常見使用狀況。
• HTTP 是一種有許多標頭和規則的重量級協議。它不適合受限的網絡。

出於上述緣由，大部分高性能、可擴展的系統都使用異步消息總線來進行內部數據交換，而不使用 Web 服務。事實上，企業中間件系統中使用的最流行的消息協議被稱爲 AMQP（高級消息排隊協議）。可是，在高性能環境中，計算能力和網絡延遲一般不是問題。AMQP 致力於在企業應用程序中實現可靠性和互操做性。它擁有龐大的特性集，但不適合資源受限的 IoT 應用程序。

除了 AMQP 以外，還有其餘流行的消息協議。例如，XMPP（Extensible Messaging and Presence Protocol，可擴展消息和狀態協議）是一種對等即時消息 (IM) 協議。它高度依賴於支持 IM 用例的特性，好比存在狀態和介質鏈接。與 MQTT 相比，它在設備和網絡上須要的資源都要多得多。

那麼，MQTT 爲何如此輕量且靈活？MQTT 協議的一個關鍵特性是發佈和訂閱模型。與全部消息協議同樣，它將數據的發佈者與使用者分離。

發佈和訂閱模型

MQTT 協議在網絡中定義了兩種實體類型：一個消息代理和一些客戶端。代理是一個服務器，它從客戶端接收全部消息，而後將這些消息路由到相關的目標客戶端。客戶端是可以與代理交互來發送和接收消息的任何事物。客戶端能夠是現場的 IoT 傳感器，或者是數據中心內處理 IoT 數據的應用程序。

1. 客戶端鏈接到代理。它能夠訂閱代理中的任何消息 「主題」。此鏈接能夠是簡單的 TCP/IP 鏈接，也能夠是用於發送敏感消息的加密 TLS 鏈接。
2. 客戶端經過將消息和主題發送給代理，發佈某個主題範圍內的消息。
3. 代理而後將消息轉發給全部訂閱該主題的客戶端。

由於 MQTT 消息是按主題進行組織的，因此應用程序開發人員能靈活地指定某些客戶端只能與某些消息交互。例如，傳感器將在 「sensor_data」 主題範圍內發佈讀數，並訂閱 「config_change」 主題。將傳感器數據保存到後端數據庫中的數據處理應用程序會訂閱 「sensor_data」 主題。管理控制檯應用程序能接收系統管理員的命令來調整傳感器的配置，好比靈敏度和採樣頻率，並將這些更改發佈到 「config_change」 主題。（參閱圖 1。）

圖 1. IoT 傳感器的 MQTT 發佈和訂閱模型

點擊查看大圖

同時，MQTT 是輕量級的。它有一個用來指定消息類型的簡單標頭，有一個基於文本的主題，還有一個任意的二進制有效負載。應用程序可對有效負載採用任何數據格式，好比 JSON、XML、加密二進制或 Base64，只要目標客戶端可以解析該有效負載。