董梁玉， 雷曉衛(wèi)， 劉繼永

（1.機(jī)械科學(xué)研究總院， 北京 100089； 2.中機(jī)寰宇認(rèn)證檢驗(yàn)有限公司， 北京 100089；3.中機(jī)科（北京）車輛檢測工程研究院有限公司， 北京 100089）

0 引言

隨著時代的不斷發(fā)展，移動網(wǎng)絡(luò)與智能終端的普及，我們見證及感受著信息與通信科技對于我們生活方式的改變。 物聯(lián)網(wǎng)（IOT），是機(jī)械、互聯(lián)網(wǎng)、通信等不同領(lǐng)域融合的產(chǎn)物，萬物互聯(lián)已經(jīng)成為了必然趨勢。與傳統(tǒng)互聯(lián)網(wǎng)相比，物聯(lián)網(wǎng)下的各種智能終端由于其處理器性能、網(wǎng)絡(luò)帶寬以及連接穩(wěn)定性等各個方面有著不小的差異， 所以對物聯(lián)網(wǎng)相關(guān)的推送系統(tǒng)有著更高的性能要求。

本文通過對于目前市面上比較流行的物聯(lián)網(wǎng)信息推送協(xié)議優(yōu)缺點(diǎn)的的比較分析， 提出了一種基于MQTT 協(xié)議的物聯(lián)網(wǎng)推送平臺設(shè)計(jì)方案， 并對平臺主要模塊進(jìn)行了實(shí)現(xiàn)。第一部分是多種推送協(xié)議的對比分析。第二部分介紹了MQTT 協(xié)議的報文格式、協(xié)議特點(diǎn)與通訊流程。 第三部分是物聯(lián)網(wǎng)云平臺推送系統(tǒng)的總體架構(gòu)。 第四部分對信息推送系統(tǒng)的主要組件進(jìn)行設(shè)計(jì)與實(shí)現(xiàn)。 第五部分是所設(shè)計(jì)的推送系統(tǒng)在叉車可靠性強(qiáng)化試驗(yàn)遠(yuǎn)程監(jiān)控平臺中的使用案例分析。 第六部分對全文做出總結(jié)。

1 消息推送技術(shù)

目前在物聯(lián)網(wǎng)領(lǐng)域廣泛使用的信息推送協(xié)議主要有三類，分別是XMPP 協(xié)議、COAP 協(xié)議、MQTT 協(xié)議，下面進(jìn)行對比說明。

XMPP（Extensible Messaging and Presence Protocol）協(xié)議根據(jù)Jeremie Miller 所提出的Jabber 協(xié)議改進(jìn)而來，由IETF 制定，符合RFC2778 和RFC2779 規(guī)范。該協(xié)議成熟、強(qiáng)大、可靠、安全，可擴(kuò)展性強(qiáng)；但存在重復(fù)轉(zhuǎn)發(fā)，網(wǎng)絡(luò)流量較大的問題，網(wǎng)絡(luò)通信的過程中數(shù)據(jù)冗余率非常高，網(wǎng)絡(luò)流量的70%都消耗在了XMPP 協(xié)議層。 對于物聯(lián)網(wǎng)通信來言，大量智能設(shè)備工作環(huán)境、網(wǎng)絡(luò)環(huán)境復(fù)雜，省電、省流量是直接影響通信質(zhì)量的關(guān)鍵因素， 從這點(diǎn)來講，XMPP 并不適合作為物聯(lián)網(wǎng)通信協(xié)議[1]。

COAP（Constrained Application Protocol）協(xié) 議 的 設(shè) 計(jì)目標(biāo)就是在處理器性能不高， 網(wǎng)絡(luò)環(huán)境不穩(wěn)定的設(shè)備上實(shí)現(xiàn)數(shù)據(jù)傳輸。COAP 協(xié)議是對傳統(tǒng)的HTTP 協(xié)議進(jìn)行部分簡化所提出的。 并且相對于HTTP 協(xié)議而言，COAP 協(xié)議也做了一定程度的優(yōu)化：

（1）基于UDP 通信。 與其它基于TCP 的協(xié)議相比，省去了建立TCP 連接的性能開銷。

（2）為適應(yīng)低網(wǎng)速的環(huán)境，COAP 協(xié)議采用了將數(shù)據(jù)包頭部使用二進(jìn)制壓縮的方式。

（3）數(shù)據(jù)的發(fā)布和接收都是是異步進(jìn)行，這樣可以提高響應(yīng)速度。

MQTT 協(xié)議是一種由IBM 開發(fā)的輕量級物聯(lián)網(wǎng)傳輸協(xié)議。 之所以輕量級在于MQTT 協(xié)議為了用于物聯(lián)網(wǎng)數(shù)據(jù)傳輸而專門對其自身的報文格式以及信息處理機(jī)制做了一定的優(yōu)化， 能夠有效的降低物聯(lián)網(wǎng)信息傳輸?shù)臒o用帶寬損耗。

COAP 協(xié)議已經(jīng)針對于傳統(tǒng)的HTTP 協(xié)議進(jìn)行了改進(jìn)，相較于XMPP 協(xié)議也具有了數(shù)據(jù)包小，不過多占據(jù)帶寬的優(yōu)點(diǎn)。 但是與MQTT 協(xié)議相比而言，有如下缺點(diǎn)：

（1）MQTT 基于TCP 協(xié)議的，屬于長鏈接，服務(wù)端可以實(shí)時推送最新消息。COAP 協(xié)議基于UDP 協(xié)議，屬于無連接。 客戶端信息的獲取類似于傳統(tǒng)的HTTP 協(xié)議，只能由客戶端請求，無法進(jìn)行實(shí)時推送[2]。

（2）MQTT 協(xié)議基于發(fā)布/訂閱模型可以實(shí)現(xiàn)多對多通信，而COAP 協(xié)議只能實(shí)現(xiàn)點(diǎn)對點(diǎn)通信。

（3）當(dāng)設(shè)備處于網(wǎng)絡(luò)不穩(wěn)定環(huán)境下，MQTT 協(xié)議相比于COQP 協(xié)議可以自動進(jìn)行斷線重連。

綜上所述， 為了實(shí)現(xiàn)安全可靠的物聯(lián)網(wǎng)環(huán)境下的消息推送系統(tǒng)，MQTT 協(xié)議是當(dāng)前比較好的選擇。

2 MQTT 協(xié)議研究

2.1 MQTT 協(xié)議格式

MQTT 協(xié)議的控制報文可以用固定報頭、可變報頭，有效載荷等部分組成。 其中固定頭部部分僅僅占了2 個字節(jié)，內(nèi)容格如表1 所示。

表1 MQTT 消息固定報頭格式

其中Message Type 表示MQTT 控制報文消息傳輸?shù)念愋?。QoS level 有0、1、2 三種級別，代表著三種不同的服務(wù)質(zhì)量，傳輸時，隨著級別的增加，需要的系統(tǒng)開銷越大。Remaining Length 表示可變報頭與有效載荷部分總的長度，最大長度為256MB。 對于有效載荷部分而言，由于報文傳輸時，MQTT 協(xié)議對該部分不做任何限制，這也導(dǎo)致了在使用MQTT 協(xié)議時候能夠兼容所有的數(shù)據(jù)類型，這個特點(diǎn)對于物聯(lián)網(wǎng)來講至關(guān)重要。

2.2 MQTT 協(xié)議通訊流程

客戶端通過MQTT 協(xié)議相互通訊的流程如圖1 所示。 每一個客戶端既可以是消息的發(fā)布者也可以是消息的訂閱者。 消息發(fā)布者與消息訂閱者之間不直接傳輸數(shù)據(jù)，而是首先消息發(fā)布者向MQTT 代理發(fā)布topic 標(biāo)識的消息，消息代理進(jìn)行回復(fù)。同時消息代理把接收到的消息推送給帶有相同topic 消息標(biāo)識的訂閱者[3]。 本質(zhì)是一種異步通信的方式， 在最大程度上降低了消息發(fā)布者與訂閱者之間的時間、空間耦合度即：兩者之間不需要互相知道彼此準(zhǔn)確的IP 地址與端口號，甚至不用同時在線。 這一特點(diǎn)對于充滿未知變化的物聯(lián)網(wǎng)領(lǐng)域十分貼合。

圖1 MQTT 協(xié)議通訊的流程圖

3 平臺總體架構(gòu)設(shè)計(jì)

如圖2 所示， 物聯(lián)網(wǎng)推送系統(tǒng)整體框架采用分層設(shè)計(jì)的方式，整體分為感知層、平臺層、應(yīng)用層三個部分。 感知層是數(shù)據(jù)的采集終端， 通過不同類型的傳感器采集物聯(lián)網(wǎng)系統(tǒng)所需要的數(shù)據(jù)，并把數(shù)據(jù)發(fā)送給平臺層。平臺層可以分為三個部分，分別是：MQTT 消息處理系統(tǒng)、數(shù)據(jù)持久化系統(tǒng)以及服務(wù)于應(yīng)用層的各種交互信息處理系統(tǒng)。 MQTT 消息處理系統(tǒng)的又可以分為MQTT 消息核心處理模塊、身份驗(yàn)證模塊以及ACL 權(quán)限控制模塊。 數(shù)據(jù)持久化系統(tǒng)用于對物聯(lián)網(wǎng)推送系統(tǒng)的感知層數(shù)據(jù)的存儲，可以通過Redis 緩存和Mysql 持久化的結(jié)合的方式來實(shí)現(xiàn)。 應(yīng)用層可以采用HTML+CSS+JavaScript 架構(gòu)搭建，通過AJAX 請求以及MQTT 推送的方式在客戶端前臺頁面實(shí)現(xiàn)數(shù)據(jù)的實(shí)時顯示和實(shí)時處理功能。

圖2 平臺總體架構(gòu)圖

4 平臺層核心功能的實(shí)現(xiàn)

4.1 身份認(rèn)證登錄模塊設(shè)計(jì)

客戶端發(fā)起連接請求時，Mosca 服務(wù)器首先對用戶的賬號信息進(jìn)行格式驗(yàn)證， 格式驗(yàn)證通過后再結(jié)合數(shù)據(jù)庫對賬號信息的真實(shí)性進(jìn)行驗(yàn)證操作， 以決定是否接受這個連接請求。同時為了增加用戶信息的安全性，客戶端用戶賬號密碼是以MD5 加密的形式進(jìn)行存儲，這樣即使使數(shù)據(jù)庫發(fā)生泄漏，用戶重要信息也無法被破解。身份驗(yàn)證流程如圖3 所示。

圖3 身份驗(yàn)證流程圖

4.2 話題設(shè)計(jì)

話題（Topic）是MQTT 消息推送業(yè)務(wù)的核心，其設(shè)計(jì)的好壞直接影響著整個推送系統(tǒng)的性能和可擴(kuò)展性。 一個好的話題分配設(shè)計(jì)， 不僅能以最簡練的話題表示形式實(shí)現(xiàn)預(yù)期目標(biāo)， 并且可以以盡量小的改動實(shí)現(xiàn)整個系統(tǒng)業(yè)務(wù)的擴(kuò)展[4]。MQTT 的話題采用分層方式設(shè)計(jì)，各層主題之間采用正斜桿（“/”）作為分隔符。話題的分配方式如下：

（1）以rootid/sys/開頭作為系統(tǒng)發(fā)布的統(tǒng)計(jì)狀態(tài)信息。其中rootid 代表該物聯(lián)網(wǎng)推送平臺的ID。

（2）以rootid/msg/clientid/開頭作為客戶端發(fā)布話題的方式。 msg 表示是可用于其余客戶端訂閱的狀態(tài)信息。Clientid 代表發(fā)布該消息的客戶端ID。

（3）各個客戶端訂閱話題時，不能訂閱rootid/sys/下方的話題。

4.3 ACL 訪問權(quán)限設(shè)計(jì)

基于MQTT 協(xié)議的訂閱/發(fā)布模型，使得消息發(fā)送方和消息接收方在時間、空間最大程度上實(shí)現(xiàn)了解耦。但這同樣意味著消息的發(fā)布者所傳輸?shù)男畔⒖赡鼙环欠ㄏ⒔邮照哌M(jìn)行竊取， 合法消息接收者同樣可能接受非法消息發(fā)布者所傳輸?shù)男畔ⅲ?這對于整個物聯(lián)網(wǎng)推送系統(tǒng)來講是必須重視的問題[1]。每當(dāng)客戶端向MQTT 服務(wù)器發(fā)布或訂閱某個話題時， 服務(wù)端都需要對當(dāng)前用戶進(jìn)行ACL權(quán)限檢查。

Mosca 是一個Node.Js 版本的MQTT 代理， 下面使用Mosca 消息中間件并以訂閱話題時候權(quán)限檢查代碼為例進(jìn)行說明：

4.4 數(shù)據(jù)存儲模塊的設(shè)計(jì)

數(shù)據(jù)存儲模塊是物聯(lián)網(wǎng)推送系統(tǒng)中數(shù)據(jù)處理的核心模塊。 數(shù)據(jù)存儲模塊不僅需要數(shù)據(jù)庫具有快速讀寫的能力，還需要面對未來物聯(lián)網(wǎng)環(huán)境下高并發(fā)問題。面對以上問題可以采用分布式緩存與常規(guī)數(shù)據(jù)庫結(jié)合的方式進(jìn)行處理。 針對物聯(lián)網(wǎng)環(huán)境下高并發(fā)、海量數(shù)據(jù)存儲、復(fù)雜的設(shè)備關(guān)系等使用場景選用Redis 作為緩存數(shù)據(jù)庫試用，選擇傳統(tǒng)關(guān)系型數(shù)據(jù)庫Mysql 作為常規(guī)數(shù)據(jù)庫進(jìn)行設(shè)計(jì)。 綜上所述，本數(shù)據(jù)存儲模塊是以Redis 結(jié)合Mysql 來存儲處理數(shù)據(jù)，圖4 以讀取數(shù)據(jù)為例進(jìn)行程序流程說明。

圖4 數(shù)據(jù)庫讀取數(shù)據(jù)流程圖

5 系統(tǒng)實(shí)際應(yīng)用

“叉車可靠性強(qiáng)化試驗(yàn)遠(yuǎn)程監(jiān)控平臺”是作者目前正在參與開發(fā)的工程機(jī)械領(lǐng)域物聯(lián)網(wǎng)實(shí)時監(jiān)控平臺。 該平臺的整體框架如圖5 所示。

圖5 平臺整體框架圖

叉車的車載終端通過傳感器采集叉車可靠性強(qiáng)化試驗(yàn)過程中的狀態(tài)數(shù)據(jù)， 通過MQTT 網(wǎng)關(guān)將數(shù)據(jù)以話題為載體發(fā)送給物聯(lián)網(wǎng)消息推送平臺。 物聯(lián)網(wǎng)消息推送平臺會將接收到的數(shù)據(jù)推送給訂閱了該話題的瀏覽器端。 可以通過訂閱該話題的形式對叉車可靠性強(qiáng)化試驗(yàn)中的數(shù)據(jù)進(jìn)行實(shí)時顯示與處理。 叉車可靠性強(qiáng)化試驗(yàn)遠(yuǎn)程監(jiān)控平臺的實(shí)時監(jiān)控畫面如圖6 所示。

圖6 實(shí)時監(jiān)控效果圖

6 結(jié)語

本文理論結(jié)合實(shí)際，詳細(xì)闡述了物聯(lián)網(wǎng)云平臺推送系統(tǒng)的整體結(jié)構(gòu)、搭建原理和關(guān)鍵模塊的設(shè)計(jì)方案，并且結(jié)合在叉車可靠性強(qiáng)化試驗(yàn)遠(yuǎn)程監(jiān)控系統(tǒng)中的使用案例分析，驗(yàn)證了MQTT 作為一種輕量型消息發(fā)布/訂閱模型給物聯(lián)網(wǎng)推送領(lǐng)域帶來了極大的便利性與可靠性。 同時也為工程機(jī)械行業(yè)走向物聯(lián)網(wǎng)智能化、 自動化提出一些可行的參考。