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