技术探秘——如何保持网络通信长连接？对于 IM 这类的开发者而言，通常大家都把 HTTP 协议称 “短连接”、把直接基于 ​​TCP​​、​​UDP​​ 或 ​​WebSocket​​

技术探秘——如何保持网络通信长连接？对于 IM 这类的开发者而言，通常大家都把 HTTP 协议称 “短连接”、把直接基于 ​​TCP​​、​​UDP​​ 或 ​​WebSocket​​

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

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

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

这些断开原因主要是：

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

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

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

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

高效维持长连接的关键在于：

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

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

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

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

对于心跳机制方案设计的要点在于：

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

设计方案：

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

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

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

特别注意：

1）KeepAlive 机制只是操作系统底层的一个被动机制，不应该被上层应用层使用；2）当系统关闭一个由 KeepAlive 机制检查出来的死连接时，是不会主动通知上层应用的，只能通过调用相应 IO 操作的返回值中发现。

小结一下就是：KeepAlive 机制无法代替心跳机制，需要在应用层 自己实现心跳机制以检测长连接的有效性，从而高效维持长连接。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。