[科普中国]-推送技术

概述

在客户机/服务器的应用程序中，推送技术能够向客户机传送数据而无需其发出请求，例如发送电子邮件。相比较而言，万维网却是基于拉技术(Pull Technology)，因此客户机浏览器必须事先向网页发出请求，所需信息才能被传送过来。传播媒介都属于推技术的应用范畴，因为不管是否有人接收，他们的信息都照发不误。

一般应用推送服务通常是在事先表达喜好的信息。这就是所谓的发布/订阅模型。一个客户端可能“订阅”的各种信息“通道”。每当新的内容可以在这些渠道之一，服务器会推出的信息给用户。

同步会议和即时消息是推动服务的典型例子。邮件和聊天，有时文件推到了只要他们是由信息服务受到了用户。同行都分散的对等程序（如废物），并集中程序（如IRC或XMPP协议）允许推送文件，这意味着发送者发起数据传输,而不是接受者。

电邮也是一个推动系统：SMTP协议的基础上，它是一个推动协议（见PushMail）。不过，最后一步，从邮件服务器到桌面计算机通常使用的POP3或IMAP像拉协议。现代电子邮件客户端走这一步似乎瞬间通过反复投票的邮件服务器，经常检查新邮件了。 IMAP协议包括IDLE命令，它允许服务器告诉客户端新邮件到达时。原来的黑莓是第一推技术流行的例子了在无线方面的电子邮件。

另一种普及型互联网推送技术为pointcast公司网络，该网络在1990年代获得了知名度。它传递新闻和股市数据。 Netscape和微软自己的软件集成到它在浏览器大战的高度，但后来逐渐消失，并在与RSS（一拉技术）2000年代取代。

其他用途的Web应用，包括推动市场数据发布（股票行情），在线聊天/消息系统（网上聊天），拍卖，网上博彩和游戏，运动的结果，监测主机和传感器网络监控1。

典型实现服务器HTTP服务器推送（也称为HTTP streaming）是一个从Web服务器发送数据到Web浏览器的机制。 HTTP服务器推送可以通过几种机制来实现。

一般来说，Web服务器在响应后，就终止了到客户端的数据连接。推送则是指该网站的服务器连接是一直保持打开的，这样如果接收到事件时，可以立即将响应发送到一个或多个客户端。或者将数据放入队列，直到客户端的下一个请求来到时，响应就被客户端接收。大多数Web服务器通过CGI提供这一功能（例如非解析头在Apache脚本）。

另一种机制是与一种特殊的MIME类型，称为多重/的X -混合取代，这是由Netscape在1995年。 Web浏览器将其解释为改变每当服务器就像推一个新版本的文件到客户端感受到这一点。它仍然支持由Firefox，Opera和Safari的今天，但传统上由微软忽略。可以应用到HTML文件，也为串流影像的摄像头应用。

1.0 Web应用程序的WHATWG建议包括一种机制来推送内容给客户端。 9月1日，2006年，Opera网络浏览器执行了这项新的实验技术的功能称为“服务器发送的事件。”人们现在正作为HTML5的一部分规范化。另一个HTML5的相关部分是WebSockets API，它允许Web服务器和客户端通信通过一个全双工TCP连接。

Java pushlet原本是一个pushlet开发Java Web应用程序，虽然同样的技术可以在其他web框架，以及聘请的技术。在这种技术中，服务器需要持久HTTP连接响应的优势，永远离开了“开放”（即它永远不会终止反应），将有效地愚弄“装入”模式继续浏览器的初始页面加载后，通常是完整的。然后，服务器发送的JavaScript片段定期更新网页内容，从而实现推动能力。通过使用这一技术并不需要在客户端的Java小应用程序或其他插件保持开放的连接到服务器。该客户端将自动通知由服务器推向新的事件。一个严重的缺点，这种方法，然而，缺乏控制在浏览器中的服务器超时。一个页面刷新总是必要的，如果在浏览器上超时结束时发生。

Long pollingLong polling是一种传统的轮询技术的变化，并允许一个信息推送仿真从服务器到客户端。随着Long polling，客户端请求从一个类似的方式到正常的投票服务器的信息。但是，如果服务器没有发送一空，而不是任何反应为客户提供的信息，服务器保存请求，并等待一些信息可用。一旦信息变得可用（或之后一个合适的超时），一个完整的响应被发送到客户端。然后，客户端通常会立即重新从服务器请求信息，因此服务器将几乎总是有一个可用的等待请求，它可以使用，以期在响应事件的数据。在web / AJAX的背景下，Long polling也被称为Comet programming。

Long polling本身并不是一种推送技术，但可以根据实际情况推动使用。

Flash XMLSocket relays这种技术是由Cbox等聊天应用，使得XMLSocket对象使用一个单像素的Adobe Flash电影。在JavaScript的控制，客户端建立一个服务器上的一个单向传递TCP连接。中继服务器不读取这个插座什么，而是立即向客户机发送一个唯一的标识符。接下来，客户端发出一个HTTP请求到Web服务器，包括它这个标识符。 Web应用程序可以然后推给了继电器的服务器，它在闪光灯插座继电器他们的本地接口的客户端的消息。这种方法的优点是它赞赏自然读写不对称，是许多Web应用程序，包括聊天典型，因此它提供了高效率。由于它不接受即将离任的插座上的数据，中继服务器不需要轮询都传出TCP连接，从而能够容纳数千的并发连接打开数万。在此模型中，规模限制是TCP协议栈底层的服务器操作系统。

其它Comet一词已被用于描述应用到Ajax的Web应用程序推技术。这是用于Web技术的结合，如HTTP服务器推送和Long polling（见上文）作为总称。

XMPP是通常用于推送应用程序以及，特别是PubSub的扩展。苹果公司使用其移动我推支持这项技术。

波什是一项长期的HTTP技术在XMPP使用，但可以在网络上使用。该规范（XEP - 0124：双向，在同步的HTTP（波什）流）条规定：本规范定义了一个传输协议，它模仿了一个长寿命，双向两个实体之间的TCP（如客户端和服务器）连接的语义通过有效地使用，而不需要频繁轮询或使用多个分块同步响应HTTP请求/响应对。23

手机推送手机推送服务的原理很简单，就是通过建立一条手机与服务器的连接链路，当有消息需要发送到手机时，通过此链路发送即可。 推送服务的使用流程虽然略有差别但是大致都和IOS的APNS相似

1、首先是应用程序注册消息推送。

2、 IOS跟APNS Server要deviceToken。应用程序接受deviceToken。

3、应用程序将deviceToken发送给PUSH服务端程序。

4、 服务端程序向APNS服务发送消息。

5、APNS服务将消息发送给iPhone应用程序Push sevrice方案评价标

评价标准推送方案的公认评价采取4s标准：1.Safe(安全) 2. Stable（稳定） 3.Save（省电省流量省成本） 4.Slim（体积小）

Safe (安全)推送方案应支持透传及各种加密方案，保障信息传递安全。

推送方案的ID系统应该独立于已有的网站或服务的ID系统，这样保障用户在不同手机上登录后的信息投递准确性，避免因为取消绑定事件失败因网络传输而造成的信息误投送。

Stable（稳定）稳定包括两个部分一个是服务器端的稳定性，一个是手机端的稳定性。

服务端稳定性，因为使用长连接方案，对服务器的开销和要求很大，推送方案对服务器开发要求很高，海量线程连接下的服务器稳定性是非常具有挑战性的。一般的评判标准包括：

- 同时在线时峰值 （一般按照百万并发连接时服务器稳定性评测）

- 高并发时消息平均延迟时间（一般按照1分钟处理1百万条信息评测）

- 服务稳定性 （一般要求全年99.9%以上可用，有备份，有负载均衡等）

鉴于服务器稳定的开发难度很大，小团队不建议自己开发，建议使用稳定的第三方推送方案，如个推，蝴蝶等。

手机端的稳定性，主要是因为中国的复杂网络状况及手机型号适配情况造成手机长时间稳定联网较困难，所以稳定性非常重要，一般的评判标准包括：

- 每日联网23.5小时以上用户比例 （表征联网稳定性）

- 消息发送后9小时内收到率 （表征到达率）

一般来说，推送方案要做网络的分运营商，分省，分机型适配，自己开发工作量较大

3.Save（节省）

省电应注意CPU休眠，一般用服务缩短待机时间百分比评判

省流量应注意协议的修改和冗余数据包的处理，一般用空载待机月流量评判

省成本应考虑单服务器承载同时连接数，可承载同时连接数越多成本越低，业内 顶尖水平为个推的单服务器50万连接

4.Slim（体积小）

推送服务应该体积尽量小，不影响主程序的大小和复杂度，一般以小于300K为宜。

陷阱初步看来，实现一个推送系统并不是特别复杂，然后实际上，尤其是针对Android移动终端来说，仍然有相当多的技术问题需要克服。

电源管理

Android系统为了最大程度降低手机功耗、延长待机时间，在电源管理方面做了非常大量的底层工作，对电池的使用到了精打细算的地步。然而Android系统在电源管理方面做出的这些努力，很轻易地就能被不守规矩的应用程序消耗殆尽。个推SDK服务作为需要长期后台稳定运行的程序，在电源管理方面能够做到取之有度，日均耗电量能够控制在40mAh左右，对用户日常手机使用几乎没有影响。

网络稳定性

在国内移动运营商网络条件下，地区差异、时间段差异、运营商差异都比较明显，使得手机上实现稳定的联网困难重重。为了在各种网络条件下，都能实现稳定联网和流量消耗的兼顾平衡，个推研发了能够根据网络状况动态调整心跳间隔的自适应算法，以最小的网络代价实现最稳定的联网质量。目前个推SDK空载流量消耗每月仅有0.8M-1.2M，不会对用户的钱袋造成损失。

性能问题

为了实现千万SDK同时连接到服务端，同时又能控制系统运营成本，推送平台需要具备平行可扩展能力，以及较高的接入服务器性能。目前个推系统通过内核调优、代码优化、层级架构设计等技术手段，已经实现单击200w稳定在线，理论上支持无限平行扩展，并且经得起实践考验，正在在线上为超过千万的用户提供稳定的推送服务4。