MQTT （Message Queuing Telemetry Transport，消息隊列遙測傳輸） 是一種標準化的發布/訂閱消息傳輸協議，設計于1999年，最初是為了在衛星之類的物體上使用。它是一個非常輕量級的協議，由于對帶寬需求很低，從而成為了 M2M 通信或物聯網應用的理想選擇，現在已經成為這類場景最常見的協議之一。
本文會對該協議及一些使用范例做以簡介，雖然沒打算寫成 MQTT 的綜合性參考指南，但會提供足夠的信息，讓開發人員了解到如何安裝運行這一協議。如果想要更深入地了解，可以參考 HiveMQ 所發布的系列文章。
發布/訂閱
發布/訂閱，通常也被成為 pub-sub 模式是 MQTT 的核心，除了基于同一個消息代理的發布者和訂閱者之外，還有一些其它節點圍繞著該消息代理呈星型拓撲分布。這個模型與標準的客戶端/服務器迥然不同，一開始看似有些奇怪，但它提供的去耦能力在很多情況下都有巨大的優勢。
客戶端可以發布或訂閱特定的主題（topic，有些類似信息主題），根據使用它們的消息代理來決定誰會收到信息。MQTT 的主題有特定的語法，使用斜杠（/）作為分隔符，整體呈層次結構，非常類似 URL 中的路徑格式，因此廚房中的溫度傳感器也許會發布到類似“sensors/temperature/home/kitchen”這樣的主題。
我們看一個例子：想象一下有一個網絡，將全世界的溫度傳感器連接起來，提供氣象服務。所有這些傳感器保持與某個消息代理中間件相連接，每隔10分鐘報告一次當前的溫度。他們基于自身位置按照下面的格式向特定主題發布信息：
sensors/temperature/{country}/{city}/{street name}
那么在倫敦貝克街（Baker Street）的某個傳感器就向“sensors/temperature/uk/london/baker_street”發布一條包含當前溫度的信息。
圖1 MQTT 示例拓撲
氣象服務需要保證歷史溫度數據庫的數據最新，因此創建了訂閱到 MQTT主題的數據庫服務，數據庫服務會在收到最新溫度信息時發出提示。不過這里存在一個問題：數據庫服務需要了解到全世界所有的溫度傳感器，而將每個傳感器訂閱到獨立的主題會非常復雜，幸好 MQTT 有相應的解決方案：通配符（wildcards）。
通配符
在 MQTT 中有兩個可用的通配符，分別是+和#，+表示匹配單一層級中的任意主題，#表示匹配任意數量的層次。因此在全球溫度數據庫中可能會有訂閱到 sensors/temperature/# 的服務，它能從全世界的任何一個傳感器接收溫度讀數。但如果英國政府想要在自己的溫度服務中利用這些數據，只要訂閱到 sensors/temperature/uk/# ，就可以限制范圍，只接受英國的傳感器讀數。如果某個服務想要接收某個特定位置所有類型的傳感器數據，可以使用類似這樣的格式：
sensors/+/uk/london/bakerstreet_
正如你所見，這是一個極優秀的模塊化系統，添加新的傳感器與數據庫只是小事一樁。而且該系統在性能方面也很優秀，MQTT 消息代理可以高度并行化并采用事件驅動，從而使得單個消息代理可以輕易擴展到每秒處理數萬條信息的級別。
服務質量（QoS）
MQTT 的設計初衷是為了在不可靠的網絡中運作良好，為不同的場景提供了三個級別的服務質量，允許客戶端指定自己想要的可靠性級別。
QoS Level 0：至多一次
這是最簡單的級別，無需客戶端確認，其可靠性與基礎網絡層 TCP/IP 一致。
QoS Level 1：至少一次，有可能重復
確保至少向客戶端發送一次信息，不過也可發送多次；在接收數據包時，需要客戶端返回確認消息（ACK 包）。這種方式常用于傳遞確保交付的信息，但開發人員必須確保其系統可以處理重復的數據包。
QoS Level 2：只有一次，確保消息只到達一次
這是最不常見的服務質量級別，確保消息發送且僅發送一次。這種方法需要交換4個數據包，同時也會降低消息代理的性能。由于相對比較復雜，在 MQTT 實現中通常會忽略這個級別，請確保在選擇數據庫或消息代理前檢查這個問題。
圖2 在 MQTT 中的服務質量水平劃分
“臨終遺囑”信息
該協議提供了檢測方式，利用KeepAlive機制在客戶端異常斷開時發現問題。因此當客戶端電量耗盡、崩潰或者網絡斷開時，消息代理會采取相應措施。
客戶端會向任意點的消息代理發送“臨終遺囑”（LWT）信息，當消息代理檢測到客戶端離線（連接并未關閉），就會發送保存在特定主題上的 LWT 信息，讓其它客戶端知道該節點已經意外離線。
安全性
MQTT（及通常的物聯網設備）的安全性是一個相當大的主題，之后我們會詳加描述，不過在本文中僅涉及兩個主要的安全性功能：身份驗證與加密。
身份驗證是通過在 MQTT 連接包中發送用戶名與密碼來實現，幾乎所有消息代理與客戶端在實現時都支持這一功能。但由于信息太容易被攔截，為了避免，應當盡可能地使用安全傳輸層協議（TLS）。
協議本身未提供加密功能，但由于 MQTT 是在 TCP 上層運行的，我們可以很容易地利用 TLS 來提供加密連接。但這確實增加了發送與接收信息的計算復雜性，不但在約束系統中會造成問題，還會影響消息代理的性能。稍后我們會就這個問題進行更多討論。
消息代理軟件
有許多不同方式實現的可用消息代理，最常見的系統包括：
Mosquitto —— 這是最早在生產環境中可用的消息代理之一，以 C 語言編寫，提供多種配置與高性能。
Mosca —— 以 Node.js 編寫，可嵌入 Node 應用或以獨立可執行文件的形式運行。由于配置簡單并具有可擴展性，它也是我們最喜歡的消息代理，具有高性能的優點。
RSMB —— IBM 對 MQTT 協議的實現，也是最不常用的選項之一，不過它是一個用C語言編寫的成熟系統。
HiveMQ —— HiveMQ 是一種相對較新的消息代理，面向企業環境，在博客上有很多關于 MQTT 不錯的信息。
客戶端庫
幾乎包含了所有流行語言的客戶端庫，想要具體了解的話，Paho 項目會是你的最佳選擇。這個項目隸屬于 Eclipse，旨在提供各種語言盡可能多樣化的 MQTT 客戶端實現參考。這是個很好的資源，包含以C、Java、Python、Javascript等語言編寫的可用客戶端。
結論
MQTT 是一個理想的協議，它在物聯網與 M2M 通信中的應用是無限的。如果你需要輕量級的消息傳輸系統，那么它會是很好的選擇，而且在未來幾年中很可能會流行起來。希望本文能幫助讀者對 MQTT 做以了解。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://m.guhuozai8.cn/
本文標題：MQTT協議及其在物聯網中的應用
本文網址：http://m.guhuozai8.cn/html/consultation/10839319384.html
相關文章
