服务端是如何主动推送信息到客户端的？

@Hugo 的答案更是只是传统的拉取消息模式(Pull)，不能算是推送(Push)。

总结下题主的问题：

服务端主动推送到客户端是怎么一个过程

目前服务端给客户端推送，普遍做法是客户端与服务端维持一个长连接，客户端定时向服务端发送心跳以维持这个长连接。当有新消息过来的时候，服务端查出该消息对应的TCP Channel的ID并找到对应的通道进行消息下发。

这只是最基本的通讯模型，在此之上，有衍生出针对消息的发布/订阅模型，客户端可以订阅某一个Topic，服务端根据Topic找到对应的Channel进行批量的消息下发。所有的客户端隐式的订阅的all这个opic，所以『类似中国移动给全网信号内所有手机发消息的模式』亦可以理解『广播消息』，即给all这个Topic发消息。

在此基础上，又要几个开源的协议来帮你定义这个事情，比较有名的如MQTT协议(刚好这几天我看到MQTT协议的中文翻译，分享给大家)，Github上搜索MQTT可以找到对应的开源的协议实现项目，有兴趣可以自行搜索。

现在的APP是如何使用消息推送的

实际上，主流的移动平台都已经有系统级的推送产品，Android上有GCM，iOS上有APNS，WinPhone有MPNS。但因为某些你懂的原因，GCM在国内处于不可用状态，所以国内的移动应用采用另外一种做法---在后台运行一个Service，维持应用于服务端的TCP长连接，以达到实时消息送达的效果。

但是在移动端如何稳定的维持长连接是一件非常复杂的事情，前面说了，客户端通过定时发送心跳信号(Heartbeat)以维持与服务端的长连接，但是，如果心跳的频率太频繁，移动设备耗电增加，心跳间隔太久又可能使得连接被断开。并且普遍认为移动设备处于一个多变的网络环境中，WIFI,2G,4G切换，基站切换都会引起网络变动，在不同网络环境下的心跳频率，与网络变动的重连动作，都需要大量的数据统计分析总结出来。

这仅仅是客户端的难题，在如今移动应用动辄成百上千的用户量的情况下，如何维护如此多的长连接，如果应对大规模的消息下发以及后续针对下发消息的各种统计动作都是技术难点。

再者，现在应用一般都是全平台的，发送一条消息，应该同时发送给Android，iOS, WinPhone，Android端走自建的TCP长连接通道，iOS与WinPhone走自家的系统推送通道。那么意味着你服务端要维护这三套推送系统。

显然对于小团队，要独自建立一套消息推送系统的难度非常大，所以市场上涌现出很多优秀的推送产品，帮开发者聚合这些推送方式，并提供统一的推送接口。国外如 Urban Airship, Parse等, 国内有JPush，百度云推送，信鸽，LeanCloud等。(比较遗憾的是，非常优秀的Parse已经被Facebook宣布停止开发，并将于1年后关闭)

现在除了体量非常大的公司自建推送系统外，一般普通公司都是使用第三方推送服务，以上所有的第三方推送服务，基础功能都是免费的，如果有条件的话，建议可以集成多家服务，A/B测试对比下推送效果，本人从事与以上某推送公司，在此就不评价各家产品好坏了，关于推送相关的问题可以私信问我 :)

Other

如果感(dian)兴(zan)趣的人多的话，我可以分享下推送方面的相关案例。