移动信息推送技术介绍_V0.1.0

移动信息推送技术介绍日期：2012-03-17
发布清单
步骤类型：批准，审核，告知，归档，其它（请说明）文档修改记录
目录
1概述 (4)
1.1推送实现技术 (4)
1.1.1客户端轮询方式实现push效果 (4)
1.1.2客户端保持IP长连接方式 (5)
1.1.3WAP 推送 (5)
1.2推送的价值 (7)
2主流推送技术平台介绍 (7)
2.1OMA Email Notification(EMN)技术 (7)
2.2Android Cloud to Device Messaging(C2DM)技术 (10)
2.3Apple Push Notification Service (APNS)技术 (11)
2.4BlackBerry Push Service（BES）技术 (14)
2.5Microsoft Push Notification Service (MPNS)技术 (15)
3现有推送技术方案评价 (16)
1概述
自从1998年推出无线应用协议(WAP)后，该协议得到了包括Nokia、Motorola、Ericssion 等多家大公司在内的业界的广泛支持。

各公司除尽快的推出自己的产品，以期占有市场外，还在不遗余力的进行着协议的扩充和新应用的开发工作。

推送(PUSH)，这项在Internet中曾一度引起过轰动的技术，在同移动通信相结合后，再次被认为有着良好的应用前景。

随着时代的发展，智能手机正在深刻地改变着人们使用手机的习惯，移动互联网无处不在，给众多开发人员和公司业务发展提供了一个很好的机遇。

所谓推送（push）技术是一种基于客户服务器机制，由服务器主动的将信息发往客户端的技术，其传送的信息通常是用户所事先预定的。

同传统的拉技术（PULL）相比，两者最为主要的区别在于前者的是由服务器主动发送信息，而后者则是由客户机主动请求信息。

其优势在于信息的主动性和及时性，可随时将信息推送到用户面前。

在固定互联网中，用户对信息准确性、可靠性的要求远胜于对其及时性的要求，因此拉取方式得到了更广泛的应用。

与传统pc方式访问互联网相比，移动终端的操作便利性和浏览器的用户体验较差，且对流量和耗电量更加敏感，因此对推送方式有更强烈的需求。

因此，推送技术开始被越来越多的应用和平台所关注。

推送一次也越来越多的被人们提及和讨论。

但是，因为推送本事是一类技术的统称，有多种具体的实现方式。

在实际中也发现对推送技术有一些误解。

本文试图阐述各主流推送技术机制，分析各自特点，并对推送技术的发展提供参考和建议。

1.1推送实现技术
1.1.1 客户端轮询方式实现push效果
最早出现的基于客户端轮询(Polling)实现类似push效果，对Email，新闻，天气等实时性要求不太高的应用，最简单、最自然的思路就是客户端周期性自动连接服务器执行查询、读取数据等任务。

如Android平台上的一些咨询类Widget、国内商用的尚邮软件都是采用这样的方式。

这种方案以较简单、灵活的方式，为用户提供类似推送的体验。

但是，周期性联网并连接服务器，对手机的电量和流量消耗都是很大的考验，特别是Polling比较频繁或终端上同时运行多个此类应用的时候。

同时，当服务器无法更新数据时，polling也会消耗较多无意义的流量和电量。

严格来讲，周期性polling方案与推送无关，但从用户体验的角度来说，在一定程度上提供了类似推送的效果。

1.1.2 客户端保持IP长连接方式
在实际应用中，还有一种常见的推送方式，即通过客户端软件与服务器维持一个持续的TCP/IP连接来实现推送。

实现客户端IP推送的关键就是要求终端保持相对稳定的IP地址，且客户端软件始终运行并侦听特定的socket端口，从而实现信息的准实时推送。

一般GPRS或CDMA/WCDMA网络均宣称支持终端设备“永远在线”。

但实际应用中，一个长时间空闲的无线数据连接会被网络接入设备断开，以节省网络资源。

此外，使用像中国移动CMWAP这种接入点，终端获取的是内网IP，与公网地址的数据交互都需要依靠网关的NAT服务进行地址转换，这同样是有时限的，过期无效。

针对这种情况，一些应用软件会以定期向服务器发送“心跳包”的方式，尽量保持数据连接，并维持一个固定的IP地址。

对于普通手机终端，这种方式消耗的流量和电量比较大，且客户端软件始终运行。

如果有多个应用同时运行，则对流量和电量的要求更为可观。

因此，这种方式更适合于一些运行单一任务且对耗电量不敏感的专用终端，如无线数传模块、对实时性要求很高的监测设备等。

其特点总结如下：
基于IP长连接
TCP/UDP，主流基于TCP
处理移动网络的不稳定性，借助心跳或者连接管理实现
Active Sync，借助私有技术，基于HTTP或动态心跳实现
1.1.3 WAP 推送
WAP推送是一种在实际中广泛应用的推送方式。

其总体架构如下图所示：
Figure 1-WAP Push总体架构图
如上图所示，WAP Push主要包括推送发起者（PI），推送代理网关（PPG）及客户端（Client）三个网元。

其中Push OTA部分有两种可能的承载方式：WSP（Wireless Session Protocol）和HTTP。

OTA-HTTP方式要求终端具有固定的IP地址并要求“永远在线”，推送内容以IP包封装，并以TCP/IP协议推送到手机端。

目前实际应用的WAP Push几乎都是以短信承载Push OTA方式的，工作流程如下图所示。

Figure 2-WAP Push工作流程图
短信承载OTA实际上就是给手机发送一条特殊格式的短信，通过在短信的相关字段啊设置特殊标识，是手机能够辨认出这是一条Push短信，并能进行相应处理。

下面的图展示了一款支持WAP Push的手机在接受到普通短信和Push 短信后的不同界面的比较。

Figure 3-普通短信与WAP推送短信比较图
WAP Push最常见的应用场合就是作为无线增值应用的推广方式，即将某一WAP网站或业务链接通过短信发送到手机上，这样用户就能通过短信中列出的链接直接访问该业务。

WAP Push实现特点总结如下：
✓充分利用移动网络已有设施，几乎适合任何移动网络终端，省电，并且有基于OMA WAP Push架构的国际规范（如OMA Email Notification）
✓信息量较少，相应慢，用户体验较差
✓信息种类受限制
✓需要与移动运营商合作
✓应用要求拦截短信，不够完全，且对开发者不太友好
✓不支持WIFI
1.2推送的价值
从用户体验来说，有如下价值：
∙即时响应
∙单任务平台
∙业务驱动
从实用角度看，省电省流量：
∙电量消耗推送大约是轮询(Polling)的10-15分钟所耗电量
∙数据流量能节省只要一半
∙节省数据流量同时也意味着节电
2主流推送技术平台介绍
2.1OMA Email Notification(EMN)技术
无线应用协议在1.2版本的规范中定义了推送技术，提出了一套完整的从服务器到客户端的协议规范，其体系结构图如图一所示。

Figure 4- WAP 推送技术体系结构图
基本的工作过程如下：当有消息要推送到客户时，PI首先根据消息的内容和性质构造推送消息，通过PAP协议向PPG发出推送请求，PPG收到请求后进行一些必要的处理工作(包括压缩、协议转换、安全认证等)，然后通过P-OTA协议将推送内容传送给客户端。

客户端收到推送消息后，根据消息内容和服务类型同用户进行交互。

WAP的推送协议中针对不同的用户需求定义了服务指示和服务加载两种服务，可根据推送消息的性质选择使用。

从实现的角度看，一般PI是运行于Internet端的一台独立的服务器，负责收集推送信息和发起推送请求。

由于PPG和客户端间的通信是由运行于WSP之上的P-OTA协议完成，所以PPG 通常是和WAP网关集成在一起。

在客户端，为了能够随时收到来自PPG的推送消息，必须在后台始终运行一个推送消息监听程序。

另外，由于面向连接的推送请求需要在客户端和服务器端有激活的WSP会话，而WSP连接的建立无法由服务器端发起，所以在客户端中引入了会话初始化程序，以监听来自服务器的会话建立请求，建立并激活WSP会话。

WAP Push的另一种典型应用方式就是邮件通知。

在Internet中，电子邮件系统已相当的普遍，但是收发电子邮件通常还是限制在固定的PC机完成，信息的及时性大打折扣。

虽然GSM的短消息功能也可提供邮件功能，但是信息量小 (160个字符) ，类型单一 (仅限于文本) ，远不能满足用户的需要。

为提供一种标准的方式通知移动终端新邮件到达，OMA（Open Mobile Architecture）组织制定了EMN（Email Notification）规范。

根据此规范，一个完整的收信流程如下图所示。

Figure 5-OMA EMN规范中的收信流程图
整个邮件系统由以下几部份组成：
∙邮件服务器（Email Server）：该部份即位于Internet中的普通的邮件服务器，负责用户邮件的收发工作。

其中的POP3邮件代理部分，该部份使用POP3协议与邮件服务器进行通信，并负责推送消息的发起，是整个系统运行的核心组成部份。

它维护着一个用户数据库，记录所有登记该服务的用户的信息，包括电子邮件地址、POP3服务器地址、账号、配置、手机号码等，采用轮询的机制通过Internet定期检查各邮件服务器，如发现某用户有新邮件，则取得邮件的部份信息(如收发人、时间、主题等)作为指示内容，并以PI的地址作为URI，共同构成服务指示消息，然后依据该用户的手机号对移动设备寻址，使用PAP协议向PPG提出推送请求。

∙推送代理网关：PPG收到推送消息后对信息进行鉴权，包括消息是否来自合法的推送服务器，用户是否登记，消息格式是否符合DTD语法等。

对于合法信息利用WBXML 格式进行压缩，然后通过P-OTA协议传送给对应用户的手机。

∙移动设备：包括邮件应用程序和服务加载器，服务加载器负责监控推送消息的到达，当收到合法的推送消息时，以振动或响铃的方式通知用户新邮件的到达，并将指示消息中邮件头部信息显示给用户。

这时候，用户可选择立即启动服务或是推迟服务。

系统的工作流程如下：
1.用户从PC客户端（或移动客户端）发送邮件到邮件服务器；
2.邮件服务器通过Push RAP协议向推送代理服务器发送推送通知；
3. PPG将EMN信息发送到终端（通过Push OTA方式，典型的情况是通过短信）；
4.终端启动邮件客户端；
5.客户端根据通知内容，自动开始收取邮件；
6.收取完成后，提示用户新邮件到达。

2.2Android Cloud to Device Messaging(C2DM)技术
Android Cloud to Device Messaging (C2DM) 是一个能够帮助开发者从服务器端发送数据到运行在Android手机上的程序的服务。

这个服务提供了一个简单，轻量级的机制使得服务器端可以告诉移动端的程序与服务器端建立直接的联系，来获取更新的程序或者用户的数据。

C2DM 服务可以处理所有的消息队列的问题并且可以把消息发送到目标机器上运行的目标程序。

C2DM 创造了一个良好的机会，允许使用多种 Google 开发工具来创建一种简单但相当实用的应用类型。

该技术方案包含如下特征：
∙Android 2.2开始引入
∙注册 ID
∙消息有效载荷可以达到1KB
∙不能保证消息的分发和消息的顺序
∙没有递送状态报告
∙国内使用可能需要翻墙
∙限制了sender发送消息的总数和sender发送消息到某个手机的总数
Google是云计算的倡导者，而Android系统由Google主导开发，因此Android系统必不可少的加入云计算应用。

云计算的核心是Web应用，Android系统基于Webkit内核的浏览器使得手机设备作为云终端具有良好的表现力。

C2DM目前就是提出了比较好的“云”端与移动终端的交互式通信方案。

Figure 6-Android 平台C2DM工作流程图
上图C2DM框架涉及的生命周期流程，主要工作过程如下：
∙启用C2DM：一个Android应用程序运行在移动设上，并注册了以用来接收消息。

∙发送消息：第三方应用服务器将消息发送到该设备。

∙接收消息：一个Android应用程序收到来自C2DM服务器消息。

过程流程详细描述如下：
1)注册：终端上程序首次运行时，向C2DM服务器发送注册请求，报告本程序期望接受
的消息发送者的id（如邮件地址）及本程序的id。

服务器为程序分配注册id，随后程
序将得到的注册id通知自己的应用服务器（app server）。

2)发送消息：应用服务器发送消息到C2DM服务器。

如果目标终端在线，C2DM推送消
息，否则将其暂存早消息队列中。

终端接收到消息后，利用Android的intent机制，
唤醒相应的程序进行处理。

3)接受消息：在Android设备上，由系统负责接收推送来的信息并经行解析。

随后，系
统广播一个intent，使消息对应的程序被唤醒，并对消息进行处理。

2.3Apple Push Notification Service (APNS)技术
Apple公司在2009年发布了iOS 3.0，其中一个新功能就是APNS。

在这一体系中，终端设备通过与推送服务器建立持续的IP连接，将来自第三方应用服务器的提示信息推送到iPhone、iPad和iPod Touch等终端上。

该技术包含以下特征：
∙基于XMPP
∙Device Token
∙消息有效载荷可以达到64KB
∙警告信息/标记（Alert message/badge）支持国际化
∙沙箱环境
在推送信息到达时，即使相应的应用程序处于关闭状态，终端也会提示用户。

提示信息可以是程序图标上的数字标记、信息弹框或声音提醒，如下图所示：
Figure 7-信息推送终端提示样例
Figure 8- APNS deviceToken流程图
APNS平台利用deviceToken作为终端标识。

当终端（iPhone）首次连接APNS时，得到一个唯一的deviceToken。

终端将此token告知第三方应用的后台服务器（Provider）。

然后应用就可凭借此token获取Provider提供的信息。

在Device第一次连接APNs时，由APNs生成的经过加密的连接认证信息。

在以后的连接中，无论时Provider到APNs还是APNs到Device 都需要 deviceToken作为认证。

从某种角度来看，deviceToken类似于手机号码，可使APNS 服务器找到推送目标客户端软件所在的终端。

其交互流程如下步骤所示：
1.安装带有推送服务程序的iPhone(device)连接苹果推送服务器(ANPS)以获取
deviceToken
2.APNS将生成的deviceToken发送给连接上来的当前device
3.Device提供获得deviceToken给Client App
4.Client App把deviceToken发送给Provider以绑定当前device
Figure 9-APNS总体推送流程
上图显示了APNS总体推送流程。

流程描述如下：
∙安装带有推送服务程序的iPhone(device)连接苹果推送服务器(ANPS)以获取deviceToken
∙Device连接Provider提供deviceToken
∙Provider把需要push的消息生成Notification信息
∙Provider把要push的消息推送到APNS
∙APNS把消息推送到手机
应用服务器（Provider）负责发起一次推送过程。

在需要推送时将信息发送到APNS，然后由APNS将信息推送到终端设备上。

APNS还具有存储转发能力，即如果终端处于离线状态，APNS将暂存信息，并在终端上线后转发。

以iPhone上的QQ为例。

用户在iPhone上登录Push版QQ时，QQ程序把deviceToken和QQ号码发送到QQ服务器。

当有新消息时，QQ服务器查看该消息中的目标QQ号码，并查询到对应的目标终端的deviceToken，并把token连同消息发送给APNS。

APNS收到后，根据token查询到终端目前的IP地址。

如果终端不在线，则先存储，等终端上线后推送；如果终端在线，则立即推送消息。

2.4BlackBerry Push Service（BES）技术
在移动设备中，基于标准TCP/IP协议的数据推送方式也在很多场合得到采用，其中最久负盛名的平台就是RIM公司BlackBerry（黑莓）手机的Push Mail。

它可根据用户的预先设定，随时将新邮件推送到手持设备。

其包含如下特征：
∙基于黑莓私有网络
∙设备PIN或Email地址
∙信息有效载荷可以达到8KB
∙端口概念
∙点对点/广播/多播
∙取消/超时控制，状态查询/递送报告
Figure 10-黑莓Push Mail系统总体结构
上图表示黑莓Push Mail系统总体架构，其中包括Push发起方、BlackBerry基础架构及黑莓终端。

其中各步骤含义为：
1.内容提供者（服务器端应用）发送Push请求给BlackBerry基础架构，其中包括被
Push的终端设备清单，以及Push数据；
2.BlackBerry基础架构返回确认信息，并将推送请求加入队列；
3.BlackBerry基础架构将数据Push给指定的终端；
4.终端在收到数据后，返回确认；
5.BlackBerry基础架构将响应发送给内容提供者；
6.服务器端应用返回已读通知。

下图显示了一个实际运营的BlackBerry业务系统。

Figure 11-黑莓推业务运营系统架构图
每次终端附着到移动数据网络后，就发送注册请求包到Registration Server，Server返回响应，其中包含了Relay服务器的地址。

随后终端发送设备信息到NIA（Network Interface
Adapter，是BlackBerry基础设施中与某一特定运营商接口的专用服务器），再由NIA转发给Relay服务器。

最后，Relay通过NIA和无线网络发送确认包到终端。

这其中的关键是，BlackBerry终端会首先注册到移动运营商的网络，且运营商设备会将终端信息转发给BlackBerry的设备。

注册成功后，终端和Relay设备间始终保持IP连接，
BlackBerry服务器知道每个邮件账号所对应的终端IP地址。

此后，当用户的邮件服务器接收到新邮件，BES/BIS随即将邮件转换为适合无线传输的数据包，转发给Relay平台，Relay平台直接将其发送到收件账号所对应的IP地址。

这样就实现了准实时的邮件推送功能。

从2009年起，RIM向第三方开放了其Push功能API，并提供服务器端和客户端的SDK。

这样，第三方黑莓应用也可以集成RIM Push功能。

2.5Microsoft Push Notification Service (MPNS)技术
作为微软公司新推出的智能手机平台，Windows Phone同样支持消息推送机制。

简化的推
送流程如下图所示。

Figure 12-Windows Phone推送通知流程示意图
Windows Phone的消息推送机制，与iOS的APNS和Android的都基本类似，其核心是由终端与推送服务器间保持持续的IP连接，并在服务器侧和终端侧都提供专门的接口，供第三方应用调用，以使第三方应用实现实时推送的功能。

该技术平台由如下特征：
∙使用于Windows Phone 7
∙通道 URI
∙Tile/Toast/Raw Notification
∙回调 URI
3现有推送技术方案评价
综上所述，在移动通讯系统中，“推送”泛指一种应用展现效果，包括几种不同的实现方式，各自有不同的适用场合。

WAP Push在实际应用中主要通过发送特殊格式的短信，激活终端上的浏览器浏览某个网址。

其优势是节省电量和数据流量，且能实现真正实时的推送。

但其实现需要与运营商合作，且推送内容种类有限。

对于IP推送，较简单的方法是客户端设定时间间隔，周期性地主动与服务器连接，以向用户提供类似推送的体验。

对流量和耗电量都比较敏感的移动终端来说，他可以在对信息实时性要求不高的场合有一定的应用。

客户端保持固定的IP连接方式，可以看作周期性查询方式的极限情况。

这种方式中，客户端较频繁的与服务器交互，以保持连接始终处于活跃状态。

这种方式可实现真正实时的推送，但耗
费的数据流量和电量都相当可观，且客户端始终需要运行。

因此适用与运行单一任务、功耗不敏感的场合。

如果终端能维持一个IP连接，供终端上所有应用推送共同使用，则可有效解决客户端IP推送的弱点。

事实上，目前各主流智能手机操作系统的推送机制，正好符合这种思路。

从以上对智能平台的分析可以看出，BlackBerry、Android和Windows Phone的推送实现整体结构非常类似。

智能终端厂商设立专门的服务器负责完成推送任务，第三方应用服务器只需要将推送请求发送到推送服务器即可。

在终端侧，终端通过与推送服务器的持续通信保持固定IP地址，并监听约定的端口。

服务器消息推送到终端后，终端将其分派到相应的应用程序进行处理。

各平台推送体系在安全机制、具体实现方式上有各自特色。