基于消息隊列遙測傳輸的推送系統

姜 妮，張 宇，趙志軍

(1．中國科學院聲學研究所高性能網絡實驗室，北京100190;2．中國科學院大學，北京100049)

1 概述

隨著物聯網技術的發展和移動終端的普及，人們希望能夠隨時隨地方便地獲取信息和服務。用戶獲取信息的途徑主要有拉取(Pull)和推送(Push)2種，相比于Pull不斷輪詢查看是否有新數據，需要付出大量的網絡流量和系統資源，Push由服務器主動將不定時產生的新消息推送給用戶，更加及時、高效、省流量、省資源。考慮到移動終端內存有限、CPU計算能力弱、電池容量小、網絡流量資費昂貴等多方面因素，移動終端需要更加輕量、優化、智能的推送技術［1］。

雖然目前的消息推送方案很多，但均存在大大小小的問題，比如服務受限、需要收費、安全漏洞、個性化智能推送不足等。其中，安全漏洞和個性化智能推送不足的問題較為明顯。安全問題體現在:有些系統任何人知道消息服務器IP和端口就可以連接運行，進而攔截消息，惡意攻擊篡改;有些系統雖然加入了用戶名、密碼等身份認證，但這些信息很容易被攻克，無法有效保證消息不被篡改。對于分布式應用來說，發布或者訂閱的消息是否能夠安全及時地到達，并且在傳輸過程中使消息不丟失、不重復，保證消息的完整性和可靠性，對通信雙方都具有非常重要的作用［2-3］。個性化智能推送不足體現在:系統不會根據具體的性能要求和用戶需求的不同而采取合適的處理方法。例如無法根據消息的類型，用戶訂閱情況，傳輸的可靠性、及時性和高效性等要求的不同［4］，來智能選擇不同的通信模式，如點對點、發布/訂閱;無法根據不同用戶的個性化需求智能選擇不同的發送方式，如軟件、郵箱等。

本文提出一種安全智能的基于消息隊列遙測傳輸(Message Queuing Telemetry Transport，MQTT)的消息推送系統。MQTT由IBM開發，是一種開放、精簡、輕量級和容易實現的協議，有可能成為物聯網的重要組成部分。IBM和St．Jude醫療中心通過MQTT開發了一套Merlin系統，用于遠程醫療項目，Facebook發布的IOS應用，采用MQTT更新通知、消息和書簽等。此外，國內很多企業，諸如 Sohu，Cmstop均有使用MQTT作為Android手機客戶端與服務器端推送消息的協議。本文系統采用MQTT消息傳輸協議，該協議采用小型傳輸，耗電量小，大幅降低網絡流量，特別適合代價昂貴、計算和處理能力受限的移動終端上的應用［5-8］;安全方面加入安全認證機制，可以有效保證系統安全;個性化智能推送方面加入多樣化智能推送，滿足用戶的個性化需求和消息傳遞性能要求。

2 現有推送方案

2．1 谷歌Android云通訊

谷歌Android云通訊Google Cloud Messaging(GCM)for Android)［9］是 Google 為 Android 提供的推送服務，第三方應用服務器可利用該服務向自己的Android客戶端推送消息。客戶端首先將使用GCM功能的賬戶和程序名稱發送給GCM服務器來獲取注冊ID，并把注冊ID告訴自己的服務器，應用服務器通過訪問Google相關網站獲取Auth Token，并通過該Auth Token進行推送功能［10-11］。

但經過調研發現，這個服務存在很大的問題，推送服務受到版本限制(必須大于2．2版本)，該服務在國內不夠穩定，經常不可用，需要用戶綁定Google賬號，受限于Google。

2．2 蘋果推送通知服務

蘋果推送通知服務(Apple Push Notification Service，APNS)是蘋果公司在2009年發布 IOS 3．0時加入的新功能，該服務可以讓蘋果移動終端與其推送服務器建立一個認證，并保持一個IP的長連接［11］。蘋果服務器接收來自第三方的應用服務器的消息，并將消息推送到用戶的終端上，即使用戶的程序處于關閉狀態，蘋果終端也可以用 Apple Notification的方式(程序圖標、信息彈窗、聲音提示等)提示用戶［11］，與GCM類似，服務同樣受到限制。

2．3 黑莓郵件推送

黑莓Push Mail推送服務雖然很好，但是門檻高，需與移動運營商合作，尤其對于個人用戶，手續相當復雜，黑莓代理商不提供個人用戶的郵件服務器，需要與一家開通黑莓業務的企業掛靠，然后向移動申請開通郵件推送服務，耗時較長，并且價錢對于普通用戶高［12］。

2．4 第三方平臺

目前國內、國外有一些推送平臺可供使用，但是涉及到收費、保密、服務質量、擴展等問題，市場占有率并不高。

3 本文解決方案

3．1 安全設計

系統中加入安全認證機制，解決現有的消息推送系統存在安全漏洞這一問題。該機制主要分為兩步，即IP驗證模塊和數字簽名認證模塊。通過設置IP白名單來驗證用戶的合法性，可以阻擋絕大部分非法請求;通過數字簽名認證可以進一步保證系統信息的安全，防止信息在傳輸過程中遭到篡改以及非法的攻擊等。

在消息發布客戶端向消息服務器發起連接發布請求時，消息服務器需要對其進行安全認證，以決定是否接收該客戶端的連接請求，通過安全認證機制之后，才能使用消息推送服務，從而保證了消息推送系統的安全性，安全認證機制流程如圖1所示。

圖1 安全認證機制流程

安全認證步驟如下:

(1)發布者客戶端請求消息發送服務之前，先調用服務器提供的數字簽名認證服務生成密鑰對;

(2)發布者使用生成的私鑰加密生成數字簽名，并將公鑰、簽名以及數據發送給消息服務器，請求消息發布服務;

(3)消息服務器在接收到發布者客戶端的消息發布請求服務之后，先通過IP驗證模塊，判斷發布者是否合法，驗證通過則進行下一步，否則返回錯誤提示給消息發布者;

(4)消息服務器使用公鑰、簽名對數據驗證，驗證成功則進行后續的消息服務，并返回成功提示給消息發布者，否則返回錯誤提示給消息發布者。

3．2 個性化智能推送

系統中加入多樣化智能選擇機制，解決現有的消息推送系統缺乏個性化智能推送的問題，該機制包括智能選擇發送方式模塊和智能選擇通信模式模塊。通過智能選擇發送方式模塊，系統可以根據用戶的個性化需求智能選擇用戶需要的通信方式，如軟件、郵箱、短信等。通過智能選擇通信模式模塊，系統可以根據傳遞消息的類型、用戶訂閱情況等來判斷使用合適的通信模式，如點對點模式、發布/訂閱模式。

在消息發送前，需要對要發送的消息進行智能選擇，根據用戶的需求、消息的類型和消息的訂閱情況來智能選擇應用合適的消息發送方式和消息通信模式，多樣化智能推送機制判斷的依據包括消息是否標記過、接收端是否多、特定用戶是否指定、消息是否多等。多樣化智能選擇機制的流程如圖2所示。

圖2 多樣化智能推送機制流程

多樣化智能選擇步驟如下:

(1)當收到需要傳遞的消息時，先要進行智能選擇發送方式的判斷;

(2)看是否有標記發送方式，如果消息發送方已經標記了用何種發送方式，比如MQTT推送、郵件推送、短信推送等，消息服務器就按照發送方標識的發送方式進行發送;如果沒有標識以何種方式發送就默認MQTT推送;

(3)進行智能選擇通信模式的判斷;

(4)查看是否有標記通信模式，如果消息發布方已經標識采用什么樣的通信模式，那么消息服務器就按照發送方標識的通信模式進行傳遞;如果沒有標識通信模式，則繼續執行下一步;

(5)判斷是否是給特定用戶發送消息，如果是就采用PTP通信模式，并且將其在消息屬性中進行標記，以便下次再轉發消息時方便快捷;

(6)如果不是就繼續判斷消息是否多，消息的多少由用戶自己設定一個閾值，如果消息超過這個閾值，就將消息先存入待發送的消息隊列;如果消息較少沒有超過設定的閾值，就選擇用Pub/Sub通信模式進行消息推送并標記。

3．3 消息管理機制

消息管理機制包括消息隊列管理模塊、訂閱表管理模塊、消息匹配轉發模塊，通過這些模塊的配合實現消息的處理存儲轉發功能。

3．3．1 消息隊列管理模塊

實現異步通信的核心本質是隊列化，消息通過隊列進行存儲轉發的機制稱作隊列管理機制。隊列管理機制是消息隊列模式的具體實現，主要有發送隊列、接收隊列、延遲隊列的管理。發送隊列接收消息發布者發送的消息，指定消息源地址，以便根據需要回復該消息時使用;接收隊列是訂閱者的消息接收隊列，指定了消息發往的目的地，消息服務器根據該信息決定發往哪個訂閱者;延遲隊列的作用是，當消息無法發送出去時先保存到延遲發送隊列中，當與客戶端連接成功后再發送。

3．3．2 訂閱表管理模塊

該模塊負責管理和維護訂閱表信息，訂閱表記錄了訂閱主題及對應的客戶端訂閱信息［13-14］。

訂閱表管理模塊處理客戶端訂閱消息的算法流程如圖3所示。

圖3 訂閱消息流程

訂閱表管理模塊處理步驟如下:

(1)對于客戶端的訂閱消息，首先在訂閱表中查詢是否已經存在該訂閱主題，如果不存在該主題，則創建該主題，并創建該客戶端訂閱者信息節點，否則進行步驟(2);

(2)查詢該客戶是否已經訂閱了該主題的消息，如果已經訂閱該主題消息，則對訂閱者信息節點更新修改，否則增加該訂閱者信息節點。

訂閱表管理模塊處理客戶端取消訂閱消息的算法流程如圖4所示。

圖4 取消訂閱消息流程

訂閱表管理模塊處理步驟如下:

(1)對于客戶端取消訂閱消息，首先在訂閱表中查詢是否存在該訂閱主題，如果不存在則結束，否則進行步驟(2);

(2)查詢該客戶是否訂閱了此主題的消息，如果訂閱了，則刪除該客戶端訂閱節點，繼續進行步驟(3);

(3)如果刪除該客戶端訂閱節點后，該訂閱主題對應的客戶端訂閱節點為空，則刪除該訂閱主題。

3．3．3 消息匹配轉發模塊

系統通過該模塊接收消息發布者發布的消息，消息訂閱者的訂閱消息、取消訂閱消息，通過消息主題的交互匹配，將收到的消息正確地轉發給相應的訂閱者。

4 系統實現

4．1 系統架構設計

消息推送系統架構設計如圖5所示，主要包括3個部分:消息發布者，消息服務器，消息訂閱者。

圖5 系統架構

4．1．1 消息發布者

消息發布者相當于消息的生產者，應用程序每生產一條消息并不是直接交給消息接收者，而是交給消息服務器，由服務器決定將消息發送給哪些接收者。

4．1．2 消息訂閱者

消息訂閱者相當于消息的消費者，應用程序從收到消息開始，根據消息中的內容做出響應，并根據需要決定是否將結果反饋給消息服務器。消息的發布者與接收者的角色并不是固定的，基于異步通信機制的應用程序通常既是消息的發布者，又是消息的訂閱者。

4．1．3 消息服務器

消息服務器是整個消息推送系統的核心，也是整個系統的創新設計所在，主要包括安全認證機制、多樣化智能選擇機制和消息管理機制。安全認證機制能夠避免非法連接，防止信息在傳輸過程中遭到篡改以及非法的攻擊，有效保證系統安全;多樣化智能選擇機制包括智能選擇發送方式和智能選擇通信模式，分別用來智能選擇用戶需要的發送查看方式和消息傳遞需要的通信模式;消息管理機制主要負責消息隊列管理、訂閱表管理、消息主題匹配、消息存儲轉發等。

4．2 系統工作流程

上述系統架構的詳細工作流程如下:

(1)消息訂閱者連接到消息服務器，訂閱/取消自己的主題，按照訂閱主題監聽自己的消息隊列;

(2)消息發布者將要發送的數據打包成消息的形式發送給消息服務器，并給該消息設定一個主題;

(3)消息服務器通過安全認證機制驗證消息發布者的合法性，驗證通過進入下一步，否則消息推送服務停止;

(4)消息服務器通過多樣化智能選擇機制，選取合適的發送方式和通信模式;

(5)消息代理服務器通過消息管理機制進行主題匹配，并將相應主題的消息推送到訂閱了該主題的移動終端的消息隊列;

(6)消息訂閱者監聽的消息隊列有新消息，接收推送過來的新消息，并查看新消息。

5 測試結果與分析

5．1 測試環境

基于農業物聯網平臺的手機App軟件，是所在物聯網項目組開發的一款集農業物聯網平臺數據監測、反向控制、消息推送接收等功能于一體的手機應用，將它作為功能測試的終端，功能測試示意圖如圖6所示。采用的PC服務器配置情況為Windows 7操作系統，4核處理器，CPU為AMD Athlon(tm)II X4 645 Processor，內存 2 GB，硬盤容量 450 GB。

圖6 功能測試示意圖

5．2 功能測試

5．2．1 安全認證機制功能測試

選取未經消息服務器許可的PC客戶端訪問消息服務器，測試結果如圖7所示。選取PC的IP為192．168．64．102，雖然該 PC 客戶端知道消息服務器的 IP 為 192．168．64．131，端口號為 9095，但由于沒有通過消息服務器的安全認證機制，得到了服務器返回的“Permission denied”錯誤提示，因此該PC無法使用消息推送服務，從而證明安全認證機制能夠正常工作。

圖7 安全認證失敗

5．2．2 多樣化智能選擇機制功能測試

物聯網平臺發布三類消息，分別進行智能測試。

(1)群發消息:發送通知公告，界面如圖8所示，7月9日周三下午7:39手機終端收到了物聯網平臺推送過來的消息，消息主題“通知公告”，消息內容“來自物聯網平臺的農業資訊”。

圖8 通知公告消息

消息服務器上的部分數據結果如圖9所示，訂閱主題“通知公告”，消息內容:“來自物聯網平臺的農業資訊”，消息級別 QoS為1，“false”表明是實時發出的消息，消息服務器 IP 為192．168．64．131。

圖9 消息服務器上的部分數據

(2)特定用戶消息:分別給User1和User2 2個用戶發送不同的消息，界面如圖10、圖11所示，User1收到了“User 1的報警信息”;User 2收到了“User 2的報警信息”。

圖10 User1用戶消息

圖11 User2用戶消息

(3)其他發送方式:郵箱發送，郵箱界面如圖12所示，郵件的發件人為“消息服務管理系統”，收件人為本文作者的QQ郵箱，用戶名為“Jenny”，消息內容為“您好!這是一封來自農業物聯網平臺的郵件，請查收。”

圖12 郵件詳情信息

通過上述3類消息的測試結果，可以看出該消息推送系統能夠很好地按照消息的不同類型和用戶的個性化需求，智能選擇合適的消息通信模式和消息發送方式。

5．3 性能測試

為了確保消息服務器在負載逐漸增加情況下的性能，需要進行性能測試。通過在PC端實現客戶端程序，模擬大量用戶對服務器發起連接請求，鑒于服務器配置條件和時延需求，連接數分別為100，200，400，600，800，1 000，并在不同連接數情況下發送不同數量的消息，消息數分別為 10，100，200，300，400，500，推送成功率及服務器發送時間、接收時間結果如表1所示。

表1 消息推送性能測試結果

從表1中可以看到，在發送消息數一定的情況下，隨著連接數的增多，消息發送時間和接收時間略有增加，變化幅度不太明顯，可見連接數對系統性能影響較小;在連接數一定的情況下，隨著發送消息數量的增多，消息發送時間和接收時間不斷增加，尤其是發送時間增加幅度較大，可見消息數對系統性能影響較大，面對大數據交互時易造成服務器性能瓶頸。從總體來看，在局域網環境下，所有推送的成功率都達到了100%，當連接數為1 000，發送消息數為500時，發送時間和接收時間都在可接受范圍內，系統性能良好。

6 結束語

本文論述了一種基于MQTT安全智能的消息推送系統，通過與客戶端聯合，對不同平臺上的用戶進行高效、準確的消息推送，目前已應用于實際項目中，經過測試，系統運行良好，滿足大部分企業級應用的消息推送需求。

隨著物聯網系統的數據規模爆發式增長，大數據交互時消息服務器的性能瓶頸和單點失效的局限性越發明顯，嚴重影響了系統可用性［15］。因此，可以通過建立服務器集群，以加強服務器的穩定性和可靠性，并且支持更多的用戶;也可以通過構建高性能低功耗的云計算平臺，依托云計算和智能虛擬化等技術，實現靈活高效的計算資源調度，充分利用計算資源，從而改善服務器性能，增強系統可靠性，為最終用戶提供更加動態，高效和可靠的網絡體驗。對于企業中龐大的系統，當系統出現故障時，系統的恢復能力十分重要。考慮在消息推送系統中加入消息緩存機制，以確保系統出現突發故障或者非正常退出時，消息依然能夠安全可靠地傳送到目的地，并且不會重復傳送。

［1］ 顧正敏．一種面向Android平臺的輕量級推送技術研究與應用［D］．北京:北京大學，2013．

［2］ 姜夢蘭．基于消息中間件服務可靠性保障方案的研究與實現［D］．成都:電子科技大學，2010．

［3］ 馬 俊．基于消息中間件的Web Services的研究和實現［D］．大連:大連海事大學，2007．

［4］ 王廣澤．基于 Pub/Sub模式的智能消息中間件研究［J］．信息技術，2009，(5):171-173．

［5］ Lee S，Kim H，Hong Dong-kweon，et al．Correlation Analysis of MQTT Loss and Delay According to Qos Level［C］//Proceedings of International Conference on Information Networking．Washington D．C．，USA:IEEE Press，2013:714-717．

［6］ Behnel S，Fiege L，Muehl G，et al．On Quality of Service and Publish Subscribe［C］//Proceedings of the 26th IEEE International Conference on Distributed Computing Systems．Washington D．C．，USA:IEEE Press，2006:20．

［7］ Hunkeler U，Truong H L，Clark A S．MQTT-S-A Publish/Subscribe Protocol for Wireless Sensor Networks［C］//Proceedings of Conference on Communication Systems Software and Middleware．Washington D．C．，USA:IEEE Press，2008:791-798．

［8］ Collina M，Corazza G E，Vanelli-Coralli A．Introducing the QEST Broker:Scaling the IoT by Bridging MQTT and REST［C］//Proceedings of the 3rd International Symposium on PersonalIndoorand Mobile Radio Communications．Washington D．C．，USA:IEEE Press，2012:36-41．

［9］ Hansen J，Gronli T M，Ghinea G．Cloud to Device Push Messaging on Android:A Case Study［C］//Proceedings of International Conference on Advanced Information Networking and Applications Workshops．Washington D．C．，USA:IEEE Press，2012:1298-1303．

［10］ 張長學，張 偉，董智明．移動推送技術面面觀［J］．移動通信，2011，35(5):21-27．

［11］ 王克峰．基于Android的信息推送管理系統的設計和實現［D］．大連:大連理工大學，2012．

［12］ 游思佳，趙久成，伏京生．黑莓推送機制和聯通黑莓業務發展分析［J］．信息通信技術，2011，(6):75-79．

［13］ 杜 蕊．智能消息中間件的研究與應用［D］．哈爾濱:哈爾濱理工大學，2012．

［14］ 潘國偉，宋 瑋，王相南，等．發布/訂閱模式消息中間件在 SCADA系統中的應用［J］．電網技術，2008，32(18):77-80．

［15］ Bernstein P，Philip A．Middleware:A Model for Distributed Services［J］．Communications of the ACM，1996，39(2):86-97．