通过 长时间保持双方连接,从而:
TCP
连接);所以,长连接 需要 持续保持双方连接 才可使得双方持续通信
NAT
超时DHCP
的租期等等 )下面,我将对每种原因进行分析
当进程被杀死后,长连接也会随之断开
NAT
超时、人为原因),TCP
长连接在双方都不断开连接的情况上,本质上是不会自动中断的Wifi
(其中1台做服务器, 另1台做客户端连接服务器(无设置KeepAlive
);只要电脑、路由器不断网断电,那么,2台电脑的长连接是不会自动中断的。当移动客户端网络状态发生变化时(如移动网络 & Wifi切换、断开、重连),也会使长连接断开
如网络状态差、DHCP
的租期到期等等,都会使得长连接发生 偶然的断开
DHCP
的租期到期:对于Android
系统,DHCP
到了租期后不会主动续约 & 继续使用过期IP,,从而导致长连接 断开
其实,说得简单点:高效维持长连接的关键在于
整体概括如下:
这是本文的重点,下节开始会详细解析
对国、内外主流的移动IM
产品(WhatsApp
、Line
、微信)进行了心跳机制的简单分析 & 对比,具体请看下图
下面,将根据市面上主流的心跳机制,设计 一套心跳机制方案
在下面的方案设计中,将针对这3个问题给出详细的解决方案。
为了减少流量 & 提高发送效率,需要精简心跳包的设计
主要从心跳包的内容 & 大小入手,设计原则具体如下
心跳包 = 1个携带少量信息 & 大小在10字节内的信息包
为了 防止NAT
超时 & 减少设备资源的消耗(网络流量、电量、CPU等等),心跳发送的间隔时间 是 整个 心跳机制方案设计的重点。
心跳发送间隔时间的设计原则如下
x
分钟发送心跳包1次其中,x <5分钟即可。(综合主流移动IM产品,此处建议 x= 4分钟)
下面,我将详细讲解 自适应心跳间隔时间 的设计方案
1.如何自适应计算心跳间隔 从而使得心跳间隔 接近 当前NAT
超时时间?
答:不断增加心跳间隔时间进行心跳应答测试,直到心跳失败5次后,即可找出最接近 当前
NAT
超时时间的心跳间隔时间。具体请看下图:
注:只有当心跳间隔 接近 NAT
超时时间 时,才能最大化平衡 长连接不中断 & 设备资源消耗最低的问题。
2.如何检测 当前网络环境的NAT
超时时间 发生了变化 ?
答:当前发送心跳包成功 的最大间隔时间(即最接近NAT超时时间的心跳间隔) 发送失败5次后,则判断当前网络环境的
NAT
超时时间 发生了变化。具体请看下图:
注:在检测到 NAT
超时时间 发生变化后,重新自适应计算心跳间隔 从而使得心跳间隔 接近 NAT
超时时间
该机制的核心在于, 如何 判断长连接的有效性
即,什么情况下视为 长连接 断线?
通过计数计算
在网上流传着一些用于判断长连接是否有效的方案,具体介绍如下
至此,关于心跳保活机制已经讲解完毕。
其中,标识 “灰色” 的判断流程参考上文描述
如,长连接本身不可用(此时重连多少次也没用)
很多人认为,TCP
协议自身就有KeepAlive
机制,为何基于它的通讯链接,仍需 在应用层实现额外的心跳保活机制?
TCP KeepAlive
机制 的作用 是检测连接的有无(死活),但无法检测连接是否有效。“连接有效”的定义 = 双方具备发送 & 接收消息的能力
先来看看KeepAlive
机制 是什么
KeepAlive
的机制 不可 替代心跳机制 的具体原因如下:
KeepAlive
机制只是操作系统底层的一个被动机制,不应该被上层应用层使用KeepAlive
机制检查出来的死连接时,是不会主动通知上层应用的,只能通过调用相应IO
操作的返回值中发现KeepAlive
机制无法代替心跳机制,需要在应用层 自己实现心跳机制以检测长连接的有效性,从而高效维持长连接