长连接、心跳和断线重连
06月22日 18:38:53天涯遍地是小草阅读数 7938
一、概述
目前IM软件有一个基本的功能就是长在线,即只要有网络就保持登录,然而,网络状态是无法预测的,所以IM软件经常会有”离线“状态,尤其是手机客户端。长在线这个功能依赖断线重连完成。
通常,网络不稳定是造成不能长时间在线的主要原因,还有比如:服务器强制注销客户端、次客户端被主客户端踢。目前的qq和飞信都有断线重连机制。有时候IM软件自动完成登录,有时候需要用户手动登录。所以,断线重连是一个广泛的概念。可以这么理解:除了从登录界面进去的登录,都可以称之为断线重连。
断线重连的定义
使得IM软件能够长在线,或者短时间内掉线,用户无感知。
广义断线重连:用户已经成功登录IM客户端,用户将程序放到后台、或者手机重启,IM软件再次进入前台,软件应帮助用户实现自动登录。
狭义的断线重:客户端的网络状况是不可预知的,可能从2G切换到3G或者WiFi,或者又切换到2G,甚至“飞行模式”(iOS设备)。客户端要及时对网络的变化做出反应,即尝试进行登录。
总之:断线重连,一般是网络原因引起的,目的是让IM软件维持在线。
实现方法
IM客户端始终尽可能的保持连接跟服务器的连接,客户端维护登录状态,以便断线重连。从逻辑层次上来说,断线重连的逻辑是基于登录的逻辑的,首次登录成功后,都有可能有断线重连。断线重连,实质上分为两步:一、使客户端断线;二、让客户端重连服务器。一般来说这两步是一个有前后顺序,完整的过程。
(一)使客户端断线,即让客户端处于“未连接”状态。以下情况将触发这个事件:
1.网络切换,如从WiFi切换到4G,网络事件。
2.网络连接失败、网络不可用。
3.心跳失败、心跳超时,失败统称心跳失败。
4.IM软件后台运行即将结束。
(二)让客户端重连服务器,客户端根据以下几种情况实现重连服务器。
1.ios系统“网络可用”的通知
2.IM软件切换到前台,用户触发事件。
3.网络切换,如从WiFi切换到4G,网络事件。
4.心跳失败的事件。
5.客户端重新启动事件。
断线重连的场景可以总结为下面几个:
1.重新启动(自动登录)
属于广义的断线重连,需要提前加载用户缓存,保证用户到达主界面后能看到历史信息。
2.网络错误,网络切换
网络连接失败有很多种,不同的场景,客户端要使用不同的逻辑处理。
3.心跳失败
心跳超时,失败统称心跳失败。这个案例说明当前客户端——服务器连接已经损坏,或者当前用户身份有变化。心跳失败后首先将客户端离线,然后进行断线重连操作,避免心跳失败和网络错误事件一并发生,造成两次登录。
4.网络可达或者切换到前台
为了避免重复登录,当IM软件处于“登录成功”、“连接中”或者“已注销”的几个状态的时候,客户端忽略“网络可达或者切换到前台”的事件。
心跳
IM基本的底层逻辑中有“心跳”概念,即客户端定时向Server发一个信令包,表示客户端还“活”着。注意,是客户端发起的。心跳是一个拟人的比喻,跟人的心跳相似。那么心跳终止了会发生什么事情呢?分为两种情况:Server主动断开socket,客户端主动断开socket。
1.Server主动断开socket
Server只是接收客户端发起的心跳。假如,Server长时间没有收到客户端的心跳,Server认为客户端已经“死了”,主动断开这个连接。此时客户端可能就是假在线了。
2.客户端断开socket
客户端对待心跳,要比Server麻烦一些。客户端要关注两个值:
心跳间隔值,即客户端多长时间发一次心跳?
心跳的超时时间。客户端发送一次心跳,如果长时间得不到Server应答,代表网络糟糕。客户端需要断开socket,主动离线。
很明显,第二点就是客户端主动断开的情况,一般情况下,超时时间为60秒。
网上也有争论:到底是否需要心跳,微信是没有心跳的,qq和飞信有心跳。也有专家说心跳包已经影响到移动网络,因为心跳是定时频繁发送。
心跳失败的断线重连
下面是“心跳失败”引起的断线重连的流程图
信令风暴
互联网应用的心跳包除了宣告终端在线外,还有一项重要的任务,就是提供终端的即时地址,方便应用服务器的寻址。
有了互联网应用的心跳机制,应用服务器可以及时下发(Push)用户相关的信息,比如微信中的短消息、图片或者语音等。心跳包也会带来很多副作用,比如终端更为费电,还可能给移动通信网络带来信令风暴。
看起来很完美的心跳机制,为什么会给移动网络带来信令风暴呢?原来,移动通信网络中由于用户众多、资源稀缺,每个用户都是动态占用资源,比如IP地址以及无线信道。每次发送心跳包,都需要移动通信网络为用户分配资源,分配的过程体现在信令的发送和接收上。一次心跳包的发送过程,牵涉的信令多达几十条。
随着互联网APP的普及,大量的终端周期性地发送心跳包,效果类似于IP网络中的DDOS,必然对移动通信网络设备带来冲击,造成拥塞等情况,这种现象就是信令风暴。
二、安卓和ios的长连接+心跳
互联网推送消息的方式很常见,特别是移动互联网上,手机每天都能收到好多推送消息,经过研究发现,这些推送服务的原理都是维护一个长连接(要不不可能达到实时效果),但普通的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中各种推送方式请参考这个链接:Android实现推送方式解决方案这篇博客已经介绍的非常好了。