推送服务，是指将浏览器主动查询信息改为服务器主动发送信息。
定义
推送技术的基础思想是将浏览器主动查询信息改为服务器主动发送信息。 服务器发送一批数据，浏览器显示这些数据，同时保证与服务器的连接。当服务器需要再次发送一批数据时，浏览器显示数据并保持连接。以后，服务器仍然可以发送批量数据，浏览器继续显示数据，依次类推。
优势
push 和 pull 这两种技术手段非常不同，但目的几乎一致，都是为了给最终用户方便的提供最新信息。
在客户端拖曳技术中，服务器发送一批数据，在HTTP响应或文档头标记中插入指令，让浏览器“在5秒内再次装入这些数据”或“10秒内前往某URL装入数据”。当指定的时间达到时，客户端就按照服务器的指示去做，或者刷新当前数据，或者调入新的数据。
在服务器推送技术中，HTTP 连接一直保持着，直到服务器知道自己已结束发送数据并发送一个结束信号，或者客户端中断连接。而在客户端拖曳技术中，并不保持HTTP连接，相反，客户端被告知何时建立新连接，以及建立连接是获取什么数据。
在
服务器推送中，奇妙之处在于“multipart/mixed”格式的 MIME，它能够使一个
报文（或HTTP响应）包含许多
数据项、在客户端拖曳中，奇妙之处在于HTTP响应头标（或等效的HTML元素），它能告知客户端在指定的延时时间后执行何种动作。
服务器推送通常效率要比客户端拖曳效率高，因为它不必为后续数据建立新的连接。由于始终保持连接，即使没有数据传输时也是这样，因此服务器必须愿意分配这些TCP/IP端口，对于TCP/IP端口数有限的服务器这将是一个严重的问题。客户端拖曳效率低，因为这必须每次为传送数据建立新的连接。但是它不必始终保持连接。
在实际情况中，建立HTTP连接通常需要花费相当多的时间，多达一秒甚至更多。因此从性能上考虑，
服务器推送对于最终用户更有吸引力，特别是对于需要经常更新信息的情况下。
服务器推送相对客户端拖曳的另一点优势是，服务器推送相对比较容易控制。而客户端拖曳要与服务器建立连接，服务器为了处理将客户端拖曳请求与特定的最终用户匹配等情况，需要使用相当麻烦的算法。
在服务器推送中，多个响应中连接始终保持，使服务器可在任何时间发送更多的数据。一个明显的好处是服务器完全能够控制更新数据的时间和频率。另外，这种方法效率高，因为始终保持连接。缺点是保持连接状态会浪费服务器端的资源。
服务器推送还比较容易中断。
手机推送
服务简介
手机推送服务是指服务器定向将信息实时送达手机的服务。与常见的轮询方式（伪推送）相比区别主要在于两点，一是长联网，二是到达实时性。
推送服务是长联网的一般到达手机的延迟在0.1-0.5秒左右，而轮询方式（伪推送）不是长联网的，达到延迟时间则根据轮询时间的不同为1-10分钟，也有延迟1小时或一天的情况。
一般来说，自黑莓，苹果和安卓采用标准长联网推送方式后，手机推送服务就特指能够实时到达的形式。
服务原理
手机推送服务的原理很简单，就是通过建立一条手机与服务器的连接链路，当有消息需要发送到手机时，通过此链路发送即可。
推送服务的使用流程虽然略有差别但是大致都和IOS的APNS相似
1、首先是应用程序注册消息推送。
2、 IOS跟APNS Server要deviceToken。应用程序接受deviceToken。
3、应用程序将deviceToken发送给PUSH服务端程序。
4、 服务端程序向APNS服务发送消息。
5、APNS服务将消息发送给iPhone应用程序。
推送实现方式
Android 推送服务实现方式
方案1
使用C2DM服务
简介：使用C2DM服务（Google Cloud Messaging）Google推出的云消息服务，即第二代的G2DM。
优点：Google提供的服务、原生、简单，无需实现和部署服务端。
缺点：Android版本限制（必须大于2.2版本），该服务在国内不够稳定、需要用户绑定Google账号，受限于Google。
方案2
使用XMPP协议
简介：使用XMPP协议（Openfire + Spark + Smack）基于XML协议的通讯协议，前身是Jabber，目前已由IETF
国际标准化组织完成了标准化工作。
优点：协议成熟、强大、可扩展性强、目前主要应用于许多聊天系统中，且已有开源的Java版的开发实例androidpn。
缺点：协议较复杂、冗余（基于XML）、费流量、费电，部署硬件成本高。
方案3
使用MQTT协议
简介：轻量级的、基于代理的“发布/订阅”模式的消息传输协议。
优点：协议简洁、小巧、可扩展性强、省流量、省电，目前已经应用到企业领域，且已有C++版的服务端组件rsmb。
缺点：不够成熟、实现较复杂、服务端组件rsmb不开源，部署硬件成本较高。
方案4
使用第三方推送服务
简介：通过嵌入SDK使用第三方提供的推送服务，目前主流的有
个推，PUBNUB，蝴蝶等
优点：稳定，成熟，节省开发和探索时间，相对自己开发成本低，推送管理界面及统计程序完善。
缺点：有程序嵌入顾虑
IOS推送实现方式
推荐使用APNS服务，稳定，方便，美中不足是没有推送到达的回执和统计，不方便产品运营。如对此方面有需求可以使用 个推 等第三方推送服务解决
Win-Phone
使用MPNS（Microsoft 推送通知服务），相应速度不错，但推送不带状态，很多功能无法实现。
推送方案评价标准
推送方案的公认评价采取4s标准：1.Safe(安全) 2. Stable（稳定） 3.Save（省电省流量省成本） 4.Slim（体积小）
Safe (安全)
推送方案应支持透传及各种加密方案，保障信息传递安全。
推送方案的ID系统应该独立于已有的网站或服务的ID系统，这样保障用户在不同手机上登录后的信息投递准确性，避免因为取消绑定事件失败因网络传输而造成的信息误投送。
Stable（稳定）
稳定包括两个部分一个是服务器端的稳定性，一个是手机端的稳定性。
服务端稳定性，因为使用长连接方案，对服务器的开销和要求很大，推送方案对服务器开发要求很高，海量线程连接下的服务器稳定性是非常具有挑战性的。一般的评判标准包括：
- 同时在线时峰值 （一般按照百万并发连接时服务器稳定性评测）
- 高并发时消息平均延迟时间（一般按照1分钟处理1百万条信息评测）
- 服务稳定性 （一般要求全年99.9%以上可用，有备份，有负载均衡等）
鉴于服务器稳定的开发难度很大，小团队不建议自己开发，建议使用稳定的第三方推送方案，如
个推，蝴蝶等。
手机端的稳定性，主要是因为中国的复杂网络状况及手机型号适配情况造成手机长时间稳定联网较困难，所以稳定性非常重要，一般的评判标准包括：
- 每日联网23.5小时以上用户比例 （表征联网稳定性）
- 消息发送后9小时内收到率 （表征到达率）
一般来说，推送方案要做网络的分运营商，分省，分机型适配，自己开发工作量较大
Save
省电应注意CPU休眠，一般用服务缩短待机时间百分比评判
省流量应注意协议的修改和冗余数据包的处理，一般用空载待机月流量评判
省成本应考虑单服务器承载同时连接数，可承载同时连接数越多成本越低，业内 顶尖水平为个推的单服务器50万连接
Slim（体积小）
推送服务应该体积尽量小，不影响主程序的大小和复杂度，一般以小于300K为宜。