董梁玉, 雷曉衛, 劉繼永
(1.機械科學研究總院, 北京 100089; 2.中機寰宇認證檢驗有限公司, 北京 100089;3.中機科(北京)車輛檢測工程研究院有限公司, 北京 100089)
隨著時代的不斷發展,移動網絡與智能終端的普及,我們見證及感受著信息與通信科技對于我們生活方式的改變。 物聯網(IOT),是機械、互聯網、通信等不同領域融合的產物,萬物互聯已經成為了必然趨勢。與傳統互聯網相比,物聯網下的各種智能終端由于其處理器性能、網絡帶寬以及連接穩定性等各個方面有著不小的差異, 所以對物聯網相關的推送系統有著更高的性能要求。
本文通過對于目前市面上比較流行的物聯網信息推送協議優缺點的的比較分析, 提出了一種基于MQTT 協議的物聯網推送平臺設計方案, 并對平臺主要模塊進行了實現。第一部分是多種推送協議的對比分析。第二部分介紹了MQTT 協議的報文格式、協議特點與通訊流程。 第三部分是物聯網云平臺推送系統的總體架構。 第四部分對信息推送系統的主要組件進行設計與實現。 第五部分是所設計的推送系統在叉車可靠性強化試驗遠程監控平臺中的使用案例分析。 第六部分對全文做出總結。
目前在物聯網領域廣泛使用的信息推送協議主要有三類,分別是XMPP 協議、COAP 協議、MQTT 協議,下面進行對比說明。
XMPP(Extensible Messaging and Presence Protocol)協議根據Jeremie Miller 所提出的Jabber 協議改進而來,由IETF 制定,符合RFC2778 和RFC2779 規范。該協議成熟、強大、可靠、安全,可擴展性強;但存在重復轉發,網絡流量較大的問題,網絡通信的過程中數據冗余率非常高,網絡流量的70%都消耗在了XMPP 協議層。 對于物聯網通信來言,大量智能設備工作環境、網絡環境復雜,省電、省流量是直接影響通信質量的關鍵因素, 從這點來講,XMPP 并不適合作為物聯網通信協議[1]。
COAP(Constrained Application Protocol)協 議 的 設 計目標就是在處理器性能不高, 網絡環境不穩定的設備上實現數據傳輸。COAP 協議是對傳統的HTTP 協議進行部分簡化所提出的。 并且相對于HTTP 協議而言,COAP 協議也做了一定程度的優化:
(1)基于UDP 通信。 與其它基于TCP 的協議相比,省去了建立TCP 連接的性能開銷。
(2)為適應低網速的環境,COAP 協議采用了將數據包頭部使用二進制壓縮的方式。
(3)數據的發布和接收都是是異步進行,這樣可以提高響應速度。
MQTT 協議是一種由IBM 開發的輕量級物聯網傳輸協議。 之所以輕量級在于MQTT 協議為了用于物聯網數據傳輸而專門對其自身的報文格式以及信息處理機制做了一定的優化, 能夠有效的降低物聯網信息傳輸的無用帶寬損耗。
COAP 協議已經針對于傳統的HTTP 協議進行了改進,相較于XMPP 協議也具有了數據包小,不過多占據帶寬的優點。 但是與MQTT 協議相比而言,有如下缺點:
(1)MQTT 基于TCP 協議的,屬于長鏈接,服務端可以實時推送最新消息。COAP 協議基于UDP 協議,屬于無連接。 客戶端信息的獲取類似于傳統的HTTP 協議,只能由客戶端請求,無法進行實時推送[2]。
(2)MQTT 協議基于發布/訂閱模型可以實現多對多通信,而COAP 協議只能實現點對點通信。
(3)當設備處于網絡不穩定環境下,MQTT 協議相比于COQP 協議可以自動進行斷線重連。
綜上所述, 為了實現安全可靠的物聯網環境下的消息推送系統,MQTT 協議是當前比較好的選擇。
MQTT 協議的控制報文可以用固定報頭、可變報頭,有效載荷等部分組成。 其中固定頭部部分僅僅占了2 個字節,內容格如表1 所示。

表1 MQTT 消息固定報頭格式
其中Message Type 表示MQTT 控制報文消息傳輸的類型。QoS level 有0、1、2 三種級別,代表著三種不同的服務質量,傳輸時,隨著級別的增加,需要的系統開銷越大。Remaining Length 表示可變報頭與有效載荷部分總的長度,最大長度為256MB。 對于有效載荷部分而言,由于報文傳輸時,MQTT 協議對該部分不做任何限制,這也導致了在使用MQTT 協議時候能夠兼容所有的數據類型,這個特點對于物聯網來講至關重要。
客戶端通過MQTT 協議相互通訊的流程如圖1 所示。 每一個客戶端既可以是消息的發布者也可以是消息的訂閱者。 消息發布者與消息訂閱者之間不直接傳輸數據,而是首先消息發布者向MQTT 代理發布topic 標識的消息,消息代理進行回復。同時消息代理把接收到的消息推送給帶有相同topic 消息標識的訂閱者[3]。 本質是一種異步通信的方式, 在最大程度上降低了消息發布者與訂閱者之間的時間、空間耦合度即:兩者之間不需要互相知道彼此準確的IP 地址與端口號,甚至不用同時在線。 這一特點對于充滿未知變化的物聯網領域十分貼合。

圖1 MQTT 協議通訊的流程圖
如圖2 所示, 物聯網推送系統整體框架采用分層設計的方式,整體分為感知層、平臺層、應用層三個部分。 感知層是數據的采集終端, 通過不同類型的傳感器采集物聯網系統所需要的數據,并把數據發送給平臺層。平臺層可以分為三個部分,分別是:MQTT 消息處理系統、數據持久化系統以及服務于應用層的各種交互信息處理系統。 MQTT 消息處理系統的又可以分為MQTT 消息核心處理模塊、身份驗證模塊以及ACL 權限控制模塊。 數據持久化系統用于對物聯網推送系統的感知層數據的存儲,可以通過Redis 緩存和Mysql 持久化的結合的方式來實現。 應用層可以采用HTML+CSS+JavaScript 架構搭建,通過AJAX 請求以及MQTT 推送的方式在客戶端前臺頁面實現數據的實時顯示和實時處理功能。

圖2 平臺總體架構圖
客戶端發起連接請求時,Mosca 服務器首先對用戶的賬號信息進行格式驗證, 格式驗證通過后再結合數據庫對賬號信息的真實性進行驗證操作, 以決定是否接受這個連接請求。同時為了增加用戶信息的安全性,客戶端用戶賬號密碼是以MD5 加密的形式進行存儲,這樣即使使數據庫發生泄漏,用戶重要信息也無法被破解。身份驗證流程如圖3 所示。

圖3 身份驗證流程圖
話題(Topic)是MQTT 消息推送業務的核心,其設計的好壞直接影響著整個推送系統的性能和可擴展性。 一個好的話題分配設計, 不僅能以最簡練的話題表示形式實現預期目標, 并且可以以盡量小的改動實現整個系統業務的擴展[4]。MQTT 的話題采用分層方式設計,各層主題之間采用正斜桿(“/”)作為分隔符。話題的分配方式如下:
(1)以rootid/sys/開頭作為系統發布的統計狀態信息。其中rootid 代表該物聯網推送平臺的ID。
(2)以rootid/msg/clientid/開頭作為客戶端發布話題的方式。 msg 表示是可用于其余客戶端訂閱的狀態信息。Clientid 代表發布該消息的客戶端ID。
(3)各個客戶端訂閱話題時,不能訂閱rootid/sys/下方的話題。
基于MQTT 協議的訂閱/發布模型,使得消息發送方和消息接收方在時間、空間最大程度上實現了解耦。但這同樣意味著消息的發布者所傳輸的信息可能被非法消息接收者進行竊取, 合法消息接收者同樣可能接受非法消息發布者所傳輸的信息, 這對于整個物聯網推送系統來講是必須重視的問題[1]。每當客戶端向MQTT 服務器發布或訂閱某個話題時, 服務端都需要對當前用戶進行ACL權限檢查。
Mosca 是一個Node.Js 版本的MQTT 代理, 下面使用Mosca 消息中間件并以訂閱話題時候權限檢查代碼為例進行說明:

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

圖4 數據庫讀取數據流程圖
“叉車可靠性強化試驗遠程監控平臺”是作者目前正在參與開發的工程機械領域物聯網實時監控平臺。 該平臺的整體框架如圖5 所示。

圖5 平臺整體框架圖
叉車的車載終端通過傳感器采集叉車可靠性強化試驗過程中的狀態數據, 通過MQTT 網關將數據以話題為載體發送給物聯網消息推送平臺。 物聯網消息推送平臺會將接收到的數據推送給訂閱了該話題的瀏覽器端。 可以通過訂閱該話題的形式對叉車可靠性強化試驗中的數據進行實時顯示與處理。 叉車可靠性強化試驗遠程監控平臺的實時監控畫面如圖6 所示。

圖6 實時監控效果圖
本文理論結合實際,詳細闡述了物聯網云平臺推送系統的整體結構、搭建原理和關鍵模塊的設計方案,并且結合在叉車可靠性強化試驗遠程監控系統中的使用案例分析,驗證了MQTT 作為一種輕量型消息發布/訂閱模型給物聯網推送領域帶來了極大的便利性與可靠性。 同時也為工程機械行業走向物聯網智能化、 自動化提出一些可行的參考。