手机每天都会接收到很多各种app推送的新闻或者实时聊天消息。那么这种消息推送是如何实现的呢。其实从原理上来讲,这些推送服务都是通过维护一个长连接来时刻保持与服务端的通信,从而能够实时的接收到新消息推送,但是普通的socket连接对各方面资源的消耗占用都很大,所以才会出现例如IBM提出的MQTT(Message Queuing Telemetry Transport,消息队列遥测传输)这种协议。MQTT是一种基于发布/订阅(publish/subscribe)模式的”轻量级”通讯协议,该协议构建于TCP/IP协议上,由IBM在1999年发布。MQTT最大优点在于,可以以极少的代码和有限的带宽,为连接远程设备提供实时可靠的消息服务。作为一种低开销、低带宽占用的即时通讯协议,使其在物联网、小型设备、移动应用等方面有较广泛的应用。那么所谓的长连接消息推送是如何实现的呢。
实现长连接的方式主要有:
客户端不断轮询服务器,检索新内容,也就是所谓的pull方式。
客户端和服务器之间维护一个TCP/IP长连接,服务器向客户端不断的push。
当服务器有新内容时,发送一条类似短信的信令给客户端,客户端收到后从服务器中主动下载新内容,也就是SMS的推送方式。
苹果的推送系统和google的C2DM推送系统其实都是在系统级别维护一个TCP/IP长连接,都是基于第二种的方式进行推送的。第三种方式由于运营商没有免费开放这种信令导致了这种推送在成本上不能被接受,虽然这种推送的方式非常的稳定和高效。
接下来我们了解一下android维护长连接为什么需要心跳机制。首先维护任何一个长连接都需要心跳机制,客户端发送一个心跳给服务器,服务器给客户端一个心跳应答,这样就形成客户端服务器的一次完整的握手,这个握手是让双方都知道他们之间的连接是没有断开,客户端是在线的。如果超过一个时间的阈值,客户端没有收到服务器的应答,或者服务器没有收到客户端的心跳,那么对客户端来说则断开与服务器的连接重新建立一个连接,对服务器来说只要断开这个连接即可。
但是在智能手机上的长连接心跳是通过无线移动网络进行连接的,接下来我们简单的介绍一下无线移动网络的特点:当一台智能手机连上移动网络时,其实并没有真正连接上Internet,运营商分配给手机的IP其实是运营商的内网IP,手机终端要连接上Internet还必须通过运营商的网关进行IP地址的转换,这个网关简称为NAT(NetWork Address Translation),简单来说就是手机终端连接Internet 其实就是移动内网IP,端口,外网IP之间相互映射。相当于在手机终端在移动无线网络这堵墙上打个洞与外面的Internet相连。
GGSN(GateWay GPRS Support Note 网关GPRS支持节点)模块就实现了NAT功能,由于大部分的移动无线网络运营商为了减少网关NAT映射表的负荷,如果一个链路有一段时间没有通信时就会删除其对应表,造成链路中断,正是这种刻意缩短空闲连接的释放超时,原本是想节省信道资源的作用,没想到让互联网的应用不得以远高于正常频率发送心跳来维护推送的长连接。这也是为什么会有之前的信令风暴,微信收费的传言,因为这类的应用发送心跳的频率是很短的,既造成了信道资源的浪费,也造成了手机电量的快速消耗。
接下来我们介绍一下android系统的推送和IOS的推送有什么区别:
首先我们必须知道,所有的推送功能必须有一个客户端和服务器的长连接,因为推送是由服务器主动向客户端发送消息,如果客户端和服务器之间不存在一个长连接那么服务器是无法来主动连接客户端的。因而推送功能都是基于长连接的基础是上的。
IOS长连接是由系统来维护的,也就是说苹果的IOS系统在系统级别维护了一个客户端和苹果服务器的长链接,IOS上的所有应用上的推送都是先将消息推送到苹果的服务器然后将苹果服务器通过这个系统级别的长链接推送到手机终端上,这样的的几个好处为:1.在手机终端始终只要维护一个长连接即可,而且由于这个长链接是系统级别的不会出现被杀死而无法推送的情况。2.省电,不会出现每个应用都各自维护一个自己的长连接。3.安全,只有在苹果注册的开发者才能够进行推送,等等。
android的长连接是由每个应用各自维护的,但是google也推出了与苹果技术架构相似的推送框架,C2DM,云端推送功能,但是由于google的服务器不在中国境内,其他的原因你懂的。所以导致这个推送无法使用,android的开发者不得不自己去维护一个长链接,于是每个应用如果都24小时在线,那么都得各自维护一个长连接,这种电量和流量的消耗是可想而知的。虽然国内也出现了各种推送平台,但是都无法达到只维护一个长连接这种消耗的级别。