详解IM网关连接检测的原理与实现

在长连接技术领域，实时探测连接是否正常，是一件既重要又复杂的事情。本文以开源项目SONA为例，详解长连接网关的连接检测的原理与实现，帮助读者理解相关技术，快速上手实践。本文最后附上开源项目地址。

---

前言

Sona 平台是一个搭建语音房产品的全端解决方案，包含了房间管理、实时音视频、房间IM、长连接网关等能力。其中最基础核心的就是长连接网关。

在长连接网关中，如何判断一个连接是否正常，是一个比较头疼的问题。连接的双方在连接空闲状态时，如果任意一方意外崩溃、宕机、网线断开或路由器故障，另一方无法得知TCP连接已经失效，除非继续在此连接上发送数据导致错误返回。很多时候，这不是我们需要的。我们希望服务器端和客户端都能够及时有效地检测到连接失效，然后优雅地完成一些清理工作。

如何及时有效地检测到一方的非正常断开，有两种技术可以运用。一种是由TCP协议层实现的Keepalive，另一种是由应用层自己实现的心跳包。

---

一、TCP Keepalive

TCP默认并不开启Keepalive功能，因为开启Keepalive功能需要消耗额外的宽带和流量，尽管这微不足道，但在按流量计费的环境下增加了费用，另一方面，Keepalive设置不合理时可能会因为短暂的网络波动而断开健康的TCP连接。并且，默认的Keepalive超时需要7200 秒，即2小时，探测次数为5次。

对于实用的程序来说，2小时的空闲时间太长。因此，我们需要手工开启Keepalive功能，设置SO_KEEPALIVE选项并设置相关参数，就可开启tcp协议的心跳机制

如果是基于 Netty 开发的话，使用如下方式即可

TCP Keepalive 虽然使用起来很方便，但是实际项目中一般都不会依靠它，而是业务心跳 + TCP KeepAlive 一起使用，互相作为补充。主要是因为：

1. KeepAlive 的开关是在应用层开启的，但是具体参数（如重试测试，重试间隔时间）的设置却是操作系统级别的，位于操作系统的 /etc/sysctl.conf 配置中，这对于应用来说不够灵活。

2. KeepAlive 的保活机制只在链路空闲的情况下才会起到作用，