移动应用的消息推送与MQTT协议
朱艳
摘要：随着智能设备的快速普及和移动应用的迅猛发展，已进入移动互联网时代。消息推送是移动应用的一个显著特征，是移动互联网时代的基础设施。苹果和谷歌都提供消息推送服务，但并不能满足企业级移动应用的推送要求。MQTT协议是由IBM提出的面向物联网的通讯协议，其简洁，高效，可靠等特征非常适合用于构建消息推送服务。文章讨论了使用MQTT协议构建消息推送服务的必要性和适用性，并指出了在具体实现上应注意的一些关键问题，同时给出了相关建议。
关键词：移动应用；消息推送；MQTT
1消息推送是移动应用的基础功能
现今已经从互联网时代快速进入到了移动互联网时代。根据相关资料，早在2014年，智能手机和平板电脑的销售量就已经超过了传统Pc的销售量，而且这一趋势还在不断加强，以智能手机为主的移动设备仍然在高速增长。
信息化系统建设也相应地转向移动设备，传统的基于桌面浏览器的应用系统日渐式微，移动应用（APP）已成为主流趋势。以前的热门网站不再受到人们的追捧，取而代之的是运行在手机上的各种APP0一个显著的例子是微信和QQ，同样由腾讯公司开发的社交应用，两者分别代表了移动互联网和传统互联网，微信的历史只有短短的4-5年，但其活跃用户数已经远超历史悠久的QQ。在企业内部，政府部门、事业单位内部，也纷纷调整其信息化建设，向移动应用方向倾斜，移动化已成为共识。
移动应用作为一种新的应用类型，与传统基于桌面的浏览器/服务器（Browser/Server）架构相比较，在应用场景，交互方式，开发技术等方面都有所不同。对于使用者而言，移动应用将其从电脑前解放了出来，使用者可以在任何时间，任意地点打开移动应用，浏览自己所需要的信息，或者进行相应的操作，只需设备联网即可。这种便利性使得移动应用迅速受到使用者的欢迎。而且，由于移动设备随身携带，并一直保持网络连接状态，移动应用能够做到主动的消息推送和提醒，而无需使用者不时打开应用去查看，实现了信息主动找人。
消息推送是移动应用的基础功能，是移动互联网时代的重要基础设施，是移动应用区别于传统应用的一个重要特征和优势，可以说，没有消息推送的移动应用就不能称之为移动应用。
2现有推送服务及问题
根据移动操作系统的不同，当前移动领域主要分为两个体系：苹果公司的iOS系统和由谷歌公司主导的Andriod系统。这两大阵营都意识到了移动消息推送在移动应用建设上的基础性地位，并提供了相应的推送服务，供开发者或企业用户调用。但是，无论是苹果还是谷歌的推送服务，都存在服务质量，安全性，处理容量等问题，特别是对于企业、政府等高端用户而言，这些推送服务都无法满足实际需要。
2.1苹果推送通知服务（APNS，Apple Push NotificationService）
苹果为全球范围的lOS设备提供推送通知服务。当服务的提供方（Provider）希望给某个设备上的应用推送消息时，需要调用苹果APNS提供的推送服务，将目标设备（设备令牌）和消息内容（有效载荷）传递给APNS服务，APNS会负责找到相应的目标设备，并将消息传递给该设备；该设备收到消息后，会将消息传给相应的应用APP，由APP处理消息，提醒用户。其处理过程在苹果的开发者网站有详细描述如图1所示。
从实际使用情况看，APNS服务比较稳定，一般情况下消息也能被及时传递，基本能够满足一般性消费类移动应用的需要。但是，对于具有更高消息推送要求的企业级市场，APNS就显得力不从心，具有以下问题。
（1）不保证消息到达。如果移动设备暂时无法联网，服务的提供方也可以推送消息，苹果会负责暂时保存该消息；当设备再次可用时，保存的消息会被推送。但是，苹果只会为同一个设备保留最近的一条消息。如果在设备持续无法联网的情况下，服务提供方再次推送消息，会导致上一条推送消息的丢失，而且不会告知。这对于普通消费型应用问题不大，但对于企业级应用则不然，特别是对于某些重要性很高，而且推送消息很频繁的移动应用而言，随意丢弃消息是不可接受的。
（2）不保证消息传递时效。APNS服务宣称会尽快传递消息，但不保证多长时间内可以传递到，不能要求限时到达。而且，它没有消息优先级的设置，所有的消息都按照同样的优先级传递，不能对消息区别对待。
（3）消息大小有限制。如果移动设备的操作系统不是最新的iOS 8，那么推送消息内容不能超过256字节，只能用来传递一些最简单的消息。企业级应用中，这么小的数据量几乎是无法使用的。如果将移动设备升级到iOS 8，最大推送字节数会增加到2000字节。很多情况下，这一数值也无法满足企业级移动应用的要求。
（4）发送频率受控。苹果官方对单位时间内允许推送的消息数没有限定，但在实际使用时发现，如果与推送服务器建立的网络连接数过多，或者推送消息的频率过于密集，都会导致苹果拒绝服务，无法推送。
（5）不支持消息回执。最终用户有没有收到消息？如果客户端收到了，具体是什么时间点收到的？这种需求对于企业应用很常见，但APNS并没有提供类似的消息回执机制。
（6）无法控制数据安全。虽然APNS提供了相应的数据传输安全机制，确保在传输过程中的安全，但数据毕竟是经过苹果的服务器传递，而且，如果设备不在线，消息还会在苹果的服务器上保存。这对于一些对数据敏感性有要求的组织或机构而言是不允许的。某些要求严格的企业，甚至会要求移动设备全部使用VPN专有网络，所有的互联网服务都不允许访问，这种情况TAPNS就更无法使用了。
2.2谷歌云推送（GcM，Google Cloud Messaging forAndroid）
与苹果类似，谷歌也为Android设备提供了一个公共的消息推送服务，其架构如图2所示。与APNS类似，第三方应用需要推送消息时，只需要连接到一个GCM服务器，调用消息推送服务，就可以将消息传递到指定的移动设备，并唤起相应的移动应用。
谷歌云推送在功能上较APNS有不少增强，支持包括消息回执功能，send-to-sync消息机制等，其最大可推送的消息内容也较苹果的大，为4000字节。
但是，现实的情况是，由于网络原因，谷歌的推送服务在国内根本无法访问，无法访问谷歌的GCM服务器，谷歌的GCM服务器也无法与我们的移动手机建立推送连接。而且，消息推送需要手机与服务器两者的相互配合，手机端必须具备相应的GCM接收服务，才能接收到推送的消息，但由于Android手机厂商的分裂状态，几乎每个手机厂商都会用自己的推送服务替代原有的GCM接收服务，这就导致即使GcM月艮务器可以访问，手机端也无法接收到消息。除非能全部限定所有的移动设备为同一家供应商，否则也无法使用手机厂商提供的推送服务。而现实中，几乎不存在这种设备完全由同一个厂商供应的可能性。
需要说明的是，基于谷歌一贯的开放策略，GCM也是一个开放性的标准，任何人或企业都可以直接使用谷歌提供的推送云服务，也可以自行根据GCM服务端的标准规范实现私有的GCM推送服务。不过，GCM在消息通讯协议上只有HTTP和XMPP两种选择，这两种协议无论从传输效率，可靠性角度，还是从安全的角度看，都不是最适合移动应用的协议。
综上所述，消息推送作为一个新的技术话题，在协议规范和技术标准方面都还没有形成业界标准，苹果和谷歌作为业界领先的两大企业，虽然提供了针对各自平台的推送服务，但都存在不同程度的问题，特别是对于企业级高端用户而言。
构建消息推送服务是一个系统工程，需要进行完备的架构设计。这其中，推送协议的选择至关重要，不同的协议会直接影响推送的速度，服务质量和用户满意度。
3MQTT协议
消息队列遥测传输（MQTT，Message QueuingTelemetry Transport）协议是IBM公司提出的开放协议，最初的设想是应用于大量计算能力有限的传感器等微型设备，其工作的网络带宽低且不稳定，但又需要保证网络节点之间的可靠通讯。
该协议目前已经被结构化信息标准促进组织（OASIS）接受，并将其建议为物联网消息传递协议的首选标准。MQTT已经成为物联网领域的事实标准，IBM公司已经成功将其应用于智能实验室、远程医疗中心等项目，并推出了MessageSight等MQTT中间件产品，其它企业和机构也相继跟进，发布支持MOTT协议的开源/商业产品，或采用MQTT协议构建相关应用。伴随着物联网的迅猛发展，MQTT协议未来的发展不可限量。
由于物联网传感器等设备的计算能力和电量都非常有限，因此MQTT的设计理念从一开始就是简单，轻量，节省电力，这正好满足了移动应用的一个重要诉求。当前电池储能技术的发展远远不能满足智能手机的发展需要，使用智能手机用户最痛苦的事情就是手机耗电太快，手机的电量甚至不能支持完8小时的工作时间。但如果要保证消息及时到达，手机就必须时刻保持与服务器的连接，并定期与其通讯，检查是否有新消息。MQTT协议非常精简，额外的数据传输量非常小，可以在最大限度节省电力，同时也节省网络流量。这是选择MQTT构建消息推送服务的最大原因。
MOTT协议的消息头固定为2个字节，当前只使用了第一个字节，第二个字节保留。第一个字节共8个bit位，前4位为控制类型，可取值为16种，按照功能可以分为连接类，订阅类，保持活动类几种，后4位携带每种控制类型的特有信息如表1所示。
作为对比，让我们来看看最常见的HTTP协议的消息头，如图3所示为访问百度主页（www.baidu.com）时，HTTP请求所提交的消息头信息，其数据量超过300字节，是MQTT协议（2个字节）的150倍。而且，这只是一个比较小的HTTP消息头，如果用户多次访问同一网站，会有不断增长的Cookie信息，消息头的内容会更多。
为了实现及时推送，手机需要周期性给服务器发送请求（心跳），以保持与消息推送服务器的连接不中断。假设手机每30秒发送一次心跳，每天就需要发送2880次，如果采用MQTT协议，只需5k的通讯流量，而如果采用HTTP方式，则需要的流量为864k，其高下一目了然。而手机需要消耗的电力与需要传输的数据量直接相关。
除了短小精悍，节约带宽，节省电量消耗，MQTT协议还具有其它的特性，非常适合用于构建移动应用的消息推送服务。
（1）保证服务质量。MQTT提供三种消息传输的服务质量保障水平，用户可以根据实际需要进行选择：
QoS0：至多传递一次。消息有可能会丢失。这种服务质量下，消息传递的速度最快，但不能保证消息的可靠到达。通常适用于网络环境差，而且不在意单次数据丢失的情况，例如GPS数据的采集。
QoS1：至少传递一次。可以确保消息被可靠传递到目标，但可能会有消息被重复传递。这种服务质量权衡了传输效率和消息可靠性，最常被采用。
QoS2：确定只传递一次。消息不会被丢失，也不会被重复传递。这种服务质量被用来保证最高的消息传递服务质量。
（2）连接中断通知。与物联网类似，手机的网络质量远不能与连接网线的台式机相比，当我们发生位移时，或者进入电梯，地下室等区域时，手机经常会发生基站切换，网络信号消失，连接中断等情况。MQTT协议可以很好地适应这种不稳定的网络环境，并且保证数据的可靠传输。而且，当发生网络异常中断时，MQTT还支持遗嘱机制，将网络中断事件通知给指定的目标对象。
（3）信息广播机制。MQTT采用发布/订阅机制来传递信息，多个手机终端可以订阅同一个主题；服务端只需要针对主题发布信息，所有订阅者都可以收到，而无需对逐个手机发送，简单高效。例如，股票价格信息，不同的人可以订阅关注同一个股票的价格信息，当该股票的价格发生变化时，服务端只需发布一次最新价格，所有的订阅者都会收到同样消息。
4其它问题
在采用MQTT协议构建移动应用的消息推送服务时，也应当了解MQTT的不足，并妥善处理如下问题。
4.1避免客户端越权订阅
MQTT采用发布/订阅模式处理消息传递，消息是针对主题传递，而不是目标客户端。客户端只要进行订阅，就可以收到消息。理论上，如果某个客户端订阅了根主题，就可以收到所有人的消息，这是不可接受的。
可以启用MQTT的用户认证机制，只有经过认证的用户才可以订阅主题，但这只能防止非认证用户的恶意订阅，对于认证通过的用户则不起作用。
彻底的解决方法需要在服务端进行控制，不允许用户订阅其没有权限的主题。另外，一些MQTT产品对此也有处理，例如，IBM的MessageSight产品就支持点对点和发布/订阅两种方式，而使用点对点方式时，任意订阅都不起作用。
4.2处理iOS后台服务运行
ios系统对于后台服务的长时间运行有很多限制，MQTT要求与服务端—直保持连接，在iOS系统下不容易做到。当移动APP在前台运行时，MQTT可以建立并保持与推送服务器的连接，但是，一旦移动APP被推入后台，所有的活动，包括连接都会被中断。
iOS允许某些应用在后台保持运行，但需要经过苹果的-审核，而且服务端还需要定期给移动设备发送数据以保持网络连接，相对而言较为繁琐。
另4中解决方式是将MQTT推送与APNS相结合，当MQTT连接被中断时，推送改为使用APNS通道。当有新消息需要推送时，推送服务器发送一个APNS的提示消息（没有具体消息内容），然后由APNS消息激活移动应用，唤起MQTT月艮务，再通过MQTT渠道具体的推送消息内容。这种方式只将APNS作为一个旁路提醒通道，不传递消息内容，保证了数据的安全性。
4.3可扩展的MQTT服务端
消息推送需要移动设备与推送服务器保持长连接，这与传统应用不同。传统的B/s应用是短连接模式，客户端向服务端发起请求，服务端处理完成后返回结果给客户端，然后释放连接。如果不考虑业务逻辑处理对服务器资源的使用，单个服务器可以轻松支持几十万，甚至上百万的用户访问。但是，如果拿一台普通的服务器当做消息推送服务器，单台服务器的连接能力大约在2万到10万之间，如果要保证稳定的服务能力，客户端的连接数通常不允许超过5万。IBM的MessageSight可以支持100万的客户端连接。但不论其数值多少，单台服务器的处理能力总有极限。
如果要推送的设备数量超过了单台的处理能力，就需要考虑服务端集群。MQTT在服务端的集群扩展方面没有规定，需要自行设计实现水平扩展架构。
