移动互联网消息推送原理：长链接+心跳机制(MQTT协议)

　　互联网推送消息的方式很常见，特别是移动互联网上，手机天天都能收到好多推送消息，通过研究发现，这些推送服务的原理都是维护一个长链接（要不不可能达到实时效果），但普通的socket链接对服务器的消耗太大了，因此才会出现像MQTT这种轻量级低消耗的协议来维护长链接，那么要如何维护长链接呢:

  　　在写以前，咱们首先了解一下为何Android维护长链接须要心跳机制，首先咱们知道，维护任何一个长链接都须要心跳机制，客户端发送一个心跳给

服务器，服务器给客户端一个心跳应答，这样就造成客户端服务器的一次完整的握手，这个握手是让双方都知道他们之间的链接是没有断开，客户端是在线

的。若是超过一个时间的阈值，客户端没有收到服务器的应答，或者服务器没有收到客户端的心跳，那么对客户端来讲则断开与服务器的链接从新创建一个

链接，对服务器来讲只要断开这个链接便可。那么在智能手机上的长链接心跳和在Internet上的长链接心跳有什么不一样的目的呢？缘由就在于智能手机使用的

是移动无线网络，那么咱们在讲长链接以前咱们首先要了解无线移动网络的特色。

1. 无线移动网络的特色

        当一台智能手机连上移动网络时，其实并无真正链接上Internet，运营商分配给手机的IP实际上是运营商的内网IP，手机终端要链接上Internet还必须经过运营

商的网关进行IP地址的转换，这个网关简称为NAT(NetWork Address Translation)，简单来讲就是手机终端链接Internet 其实就是移动内网IP，端口，外网IP之间

相互映射。至关于在手机终端在移动无线网络这堵墙上打个洞与外面的Internet相连。原理图以下：(来源网络)

　　GGSN(GateWay GPRS Support Note 网关GPRS支持节点)模块就实现了NAT功能，因为大部分的移动无线网络运营商为了减小网关NAT映射表的负荷，如

果一个链路有一段时间没有通讯时就会删除其对应表，形成链路中断，正是这种刻意缩短空闲链接的释放超时，本来是想节省信道资源的做用，没想到让互联网

的应用不得以远高于正常频率发送心跳来维护推送的长链接。这也是为何会有以前的信令风暴，微信摇收费的传言，由于这类的应用发送心跳的频率是很短的，

既形成了信道资源的浪费，也形成了手机电量的快速消耗。

　　2. android系统的推送和iOS的推送有什么区别

        首先咱们必须知道，全部的推送功能必须有一个客户端和服务器的长链接，由于推送是由服务器主动向客户端发送消息，若是客户端和服务器之间不存在一

个长链接那么服务器是没法来主动链接客户端的。于是推送功能都是基于长链接的基础是上的。

        IOS长链接是由系统来维护的，也就是说苹果的IOS系统在系统级别维护了一个客户端和苹果服务器的长连接，IOS上的全部应用上的推送都是先将消息推送

到苹果的服务器而后将苹果服务器经过这个系统级别的长连接推送到手机终端上，这样的的几个好处为：1.在手机终端始终只要维护一个长链接便可，并且因为

这个长连接是系统级别的不会出现被杀死而没法推送的状况。2.省电，不会出现每一个应用都各自维护一个本身的长链接。3.安全，只有在苹果注册的开发者才能

够进行推送，等等。

       android的长链接是由每一个应用各自维护的，可是google也推出了和苹果技术架构类似的推送框架，C2DM,云端推送功能，可是因为google的服务器不在中

国境内，其余的缘由你懂的。因此致使这个推送没法使用，android的开发者不得不本身去维护一个长连接，因而每一个应用若是都24小时在线，那么都得各自维

护一个长链接，这种电量和流量的消耗是可想而知的。虽然国内也出现了各类推送平台，可是都没法达到只维护一个长链接这种消耗的级别。

　　3. 推送的实现方式

　　一：客户端不断的查询服务器，检索新内容，也就是所谓的pull 或者轮询方式

　　二：客户端和服务器之间维持一个TCP/IP长链接，服务器向客户端push

　　三：服务器又新内容时，发送一条相似短信的信令给客户端，客户端收到后从服务器中下载新内容，也就是SMS的推送方式

　　苹果的推送系统和googleC2DM推送系统其实都是在系统级别维护一个TCP/IP长链接，都是基于第二种的方式进行推送的。第三种方式因为运营商没有免费开放

这种信令致使了这种推送在成本上是没法接受的，虽然这种推送的方式很是的稳定，高效和及时。

若是想了解android中各类推送方式请参考这个连接：http://www.cnblogs.com/hanyonglu/archive/2012/03/04/2378971.html  这篇博客已经介绍的很是好了。

 转自：http://blog.csdn.net/clh604/article/details/20167263