分层架构 IM 系统之 Entry 心跳算法

在前面的技术短文（分层架构 IM 系统之架构解读）中，我们已经非常明确入口层 Entry 的核心职责，即面向客户端提供 TCP 长连接的接入能力，并维护这些长连接。

Entry 怎么维护与客户端之间的长连接呢？常用的方式就是【心跳】，即客户端周期性地向服务端发送心跳包，告诉服务端，我客户端还活着。（在客户端数量非常少的情况下，服务端也可以向客户端周期性地发心跳）

大家有没有思考过心跳背后的原理是什么？为什么要用心跳呢？难道不发心跳，客户端与服务端之间的长连接就容易断掉吗？ 我在大学期间，和寝室舍友做过一个实验，见下图。

用网线直连两台电脑（Windows系统），写一个简单的 TCP Demo 程序，电脑 A 作为客户端向电脑 B 发起并建立 TCP 连接；连接建立后，什么都不做，包括 TCP 层的心跳周期也设置到月级别。大家猜测一下，一周以后，电脑 A 和电脑 B 之间的长连接还存在吗？

一周以后，电脑 A 上的 TCP Demo 程序开始发送数据，电脑 B 上的 TCP Demo 程序全部成功接收。实验结论：在上述场景中，无论过去多长时间，在没有任何心跳包的情况下，TCP 长连接会一直健康存在。通过这个小实验，也对 TCP 连接有了更本质的理解：所谓建立了 TCP 连接，实质上是客户端和服务端之间，相互为对方敞开了一个端口，只要是我这个端口发送给你的端口的数据，你一定会接受，反之亦然；只要客户端和服务端的进程一直存在，那么连接就会一直存在。

如此，在分层架构的 IM 系统中，Entry 为什么还需要心跳来维护与客户端的长连接呢？