基于消息队列遥测传输的推送系统

姜 妮，张 宇，赵志军

(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．