如何实现高效的IM即时通讯长连接自适应心跳保活机制

Posted wecloud1314

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了如何实现高效的IM即时通讯长连接自适应心跳保活机制相关的知识,希望对你有一定的参考价值。

当要实现IM即时通讯聊天、消息推送等高实时性需求时,我们一般会选择长连接的通信方式。

而真正当实现长连接方式时,会遇到很多技术问题,比如最常见的长连接保活问题。


 

 

长连接的主要作是通过长时间保持双方连接,从而:
 

  • 1)提高通信速度;
  • 2)确保实时性;
  • 3)避免短时间内重复连接所造成的信道资源和网络资源的浪费。

PS:对于IM这类的开发者而言,通常大家都把HTTP协议称“短连接”、把直接基于TCP、UDP或WebSocket的socket称为“长连接”。

从上节可知,在使用长连接的情况下,双方的所有通信都建立在1条长连接上(比如1次TCP连接)。所以,长连接需要持续保持双方连接才可使得双方持续通信。

然而,实际情况是,长连接会存在断开的情况。

这些断开原因主要是:
 

  • 1)长连接所在进程被杀死(这主要说的是移动端);
  • 2)NAT超时;
  • 3)网络状态发生变化;
  • 4)其他不可抗因素(网络状态差、DHCP的租期等等 )。


下面,我将对每种原因进行分析。

1)原因1:进程被杀死

当进程被杀死后,长连接也会随之断开。进程被杀在Andriod端是最常见的问题

2)原因2:NAT 超时(重点关注)

特别注意:排除其他外因(网络切换、NAT超时、人为原因),TCP长连接在双方都不断开连接的情况上,本质上是不会自动中断的(也就是不需要心跳包来维持,可以验证一下:让2台电脑连上同1个Wifi,其中1台做服务器, 另1台做客户端连接服务器(无设置KeepAlive)。只要电脑、路由器不断网断电,那么,2台电脑的长连接是不会自动中断的)。

 

3)原因3:网络状态发生变化

当移动客户端网络状态发生变化时(如移动网络 & Wifi切换、断开、重连),也会使长连接断开。

4)原因4:其他不可抗因素

如网络状态差、DHCP的租期到期等等,都会使得长连接发生 偶然的断开。DHCP的租期到期:对于 android系统, DHCP到了租期后不会主动续约(继续使用过期IP),从而导致长连接断开。

高效维持长连接的解决方案

在了解长连接断开原因后,针对这些原因,此处给出我的高效维持长连接的解决方案

说得简单点,高效维持长连接的关键在于:
 

  • 1)保活:处于连接状态时要做到尽量不要断;
  • 2)重连:连接断了之后要能继续重连回来。

心跳保活机制

这是本文的重点,下节开始会详细解析

断线重连机制

原理就是:检测网络状态变化并及时判断连接的有效性。
具体实现:这个其实跟心跳保活机制是一套完整的逻辑,所以下面会在心跳保活机制中一起讲解。

主流IM的心跳机制分析和对比


对国、内外主流的移动IM产品(WhatsApp、Line、微信)进行了心跳机制的简单分析和对比。

心跳保活机制方案总体设计


下面,我将根据市面上主流的心跳机制,设计了一套心跳机制方案。

对于心跳机制方案设计的主要考虑因素是:
 

  • 1)要保证消息的实时性;
  • 2)要考虑耗费设备的资源(网络流量、电量、CPU等等)。


从上图可以看出,对于心跳机制方案设计的要点在于:
 

  • 1)心跳包的规格(内容 & 大小);
  • 2)心跳发送的间隔时间;
  • 3)断线重连机制 (核心 = 如何 判断长连接的有效性)。


在下面的方案设计中,将针对这3个问题给出详细的解决方案。即时通讯开发

心跳包的规格


为了减少流量并提高发送效率,需要精简心跳包的设计。

设计方案:

心跳包 = 1个携带少量信息 & 大小在10字节内的信息包

心跳发送的间隔时间


为了 防止NAT超时并减少设备资源的消耗(网络流量、电量、CPU等等),心跳发送的间隔时间是整个心跳机制方案设计的重点。

最常用的心跳间隔方案


一般,最直接且常用的心跳发送间隔时间设置方案多采用:“每隔估计 x 分钟发送心跳包1次”。其中,x <5分钟即可(综合主流移动IM产品,此处建议 x= 4分钟)。

自适应心跳间隔方案

1)如何自适应计算心跳间隔 从而使得心跳间隔 接近 当前NAT 超时时间?

答:不断增加心跳间隔时间进行心跳应答测试,直到心跳失败5次后,即可找出最接近 当前NAT 超时时间的心跳间隔时间。

注:只有当心跳间隔 接近 NAT 超时时间 时,才能最大化平衡 长连接不中断 & 设备资源消耗最低的问题。

2)如何检测 当前网络环境的NAT 超时时间 发生了变化 ?

答:当前发送心跳包成功 的最大间隔时间(即最接近NAT超时时间的心跳间隔) 发送失败5次后,则判断当前网络环境的NAT 超时时间 发生了变化。

注:在检测到 NAT 超时时间 发生变化后,重新自适应计算心跳间隔 从而使得心跳间隔 接近 NAT 超时时间

断线重连机制的实现


技术上来说:长连接的心跳保活依赖于心跳机制,在心跳机制起作用的情况下,适时启动断线重连机制,在心跳机制和断线重连机制的共同作用下才能实现真正的心跳保活。但为了让逻辑更清晰,我把断线重连机制跟心跳机制单独各作为一节来讲解。本节讲的是断片线重连机制。

该机制的核心在于:如何判断长连接的有效性。即:什么情况下视为长连接断线?

1)设计原则:

基本逻辑就是:判断长连接是否有效的准则 = 服务器是否返回心跳应答。

2)具体方案:

实现思路:通过计数计算,若连续5次发送心跳后,服务器都无心跳应答,则视为长连接无效。
 

开发者涨薪指南 48位大咖的思考法则、工作方式、逻辑体系

以上是关于如何实现高效的IM即时通讯长连接自适应心跳保活机制的主要内容,如果未能解决你的问题,请参考以下文章

iOS 即时通讯(二):心跳保活

基于TCP的移动端IM即时通讯开发仍然需要心跳保活

浅析IM即时通讯开发中TCP协议层KeepAlive保活机制

IM即时通讯开发用Netty实现心跳机制断线重连机制

开发im即时通讯如何用Netty实现心跳机制断线重连机制

不为人知的网络编程:彻底搞懂TCP协议层的KeepAlive保活机制