互联网推送服务原理：长连接+心跳机制(MQTT协议)

在将这个之前我们先来了解一下 mqtt,MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。

MQTT协议是为大量计算能力有限，且工作在低带宽、不可靠的网络的远程传感器和控制设备通讯而设计的协议，它具有以下主要的几项特性：

1、使用发布/订阅消息模式，提供一对多的消息发布，解除应用程序耦合；

2、对负载内容屏蔽的消息传输；

3、使用 TCP/IP 提供网络连接；

4、有三种消息发布服务质量：

• “至多一次”，消息发布完全依赖底层 TCP/IP 网络。会发生消息丢失或重复。这一级别可用于如下情况，环境传感器数据，丢失一次读记录无所谓，因为不久后还会有第二次发送。
• “至少一次”，确保消息到达，但消息重复可能会发生。
• “只有一次”，确保消息到达一次。这一级别可用于如下情况，在计费系统中，消息重复或丢失会导致不正确的结果。

5、小型传输，开销很小（固定长度的头部是 2 字节），协议交换最小化，以降低网络流量；

6、使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制；[2] 

互联网推送消息的方式很常见，特别是移动互联网上，手机每天都能收到好多推送消息，经过研究发现，这些推送服务的原理都是维护一个长连接（要不不可能达到实时效果），但普通的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长连接，都是基于第二种的方式进行推送的。第三种方式由于运营商没有免费开放这种信令导致了这种推送在成本上是无法接受的，虽然这种推送的方式非常的稳定，高效和及时。

此外，消息推送还有这些实现方式：见下文，此处不再一一赘述。。。

采用MQTT协议实现Android消息推送

对于消息推送，一开始还真不知道什么方式比较好，一头雾水，现在回顾总结下资料。

http://zheye.org/asks/4d99a1aafd503c41d700000a
通过上面者也里面的回复，得到一些信息。
1.官方的C2DM，但是只支持android2.2及以上平台的，而且使用的google的服务器。
对于google服务器的问题，网友应该都清楚，天朝的大中华区局域网总是让它不时的给你断一下。

2.第三方的androidpn，和C2DM一样，都是基于XMPP扩展的，是一个开源的项目，据说不错。
http://sourceforge.net/projects/androidpn/
但是是基于长连接的，如果客户端数量大，特别像手机这种都是长期在线的设备，
会有两个问题，（1）服务器压力，（2）手机的电池不够用啊，电量卡卡卡的被你耗光了（需要优化网络机制）。

3.使用IBM 的MQTT协议实现push消息
地址：http://tokudu.com/2010/how-to-implement-push-notifications-for-android/
这是一个非常理想的解决方案，是基于tcp协议的，低带宽通信，而且国外友人已经测试，耗电量很多哦~

都是E文的，不习惯看E文的，也没关系，有一前辈给整理了一个中文的：
《Android推送通知指南》http://blog.csdn.net/joshua_yu/article/details/6563587
看了上面这些文章的内容，完成上面的例子，
然后看看源码，应该明白一些了。