一、前言
TCP 协议自身有 KeepAlive 机制，为何基于它的通讯链接，仍然需要在应用层实现额外的心跳保活？本文将从移动端 IM 实践的角度说明，即使使用 TCP 协议，应用层的心跳保活仍旧必不可少。有关 TCP 协议的权威理论介绍，请参见《TCP/IP详解》。
移动端 IM 开发推荐文章：《新手入门一篇就够：从零开发移动端IM》
二、参考资料
《TCP/IP详解-第11章·UDP：用户数据报协议》
《TCP/IP详解-第17章·TCP：传输控制协议》
《TCP/IP详解-第18章·TCP连接的建立与终止》
《TCP/IP详解-第21章·TCP的超时与重传》
《通俗易懂-深入理解TCP协议（上）：理论基础》
《通俗易懂-深入理解TCP协议（下）：RTT、滑动窗口、拥塞处理》
《理论经典：TCP协议的3次握手与4次挥手过程详解》
《计算机网络通讯协议关系图（中文珍藏版）》
《NAT详解：基本原理、穿越技术（P2P 打洞）、端口老化等》
三、心跳保活
在使用 TCP 长连接的 IM 服务设计中，往往都会涉及到心跳。心跳一般是指某端（绝大多数情况下是客户端）每隔一定时间向对端发送自定义指令，以判断双方是否存活，因其按照一定间隔发送，类似于心跳，故被称为心跳指令。
有兴趣了解 IM/推送的心跳保活技术的文章，请参见：
《Android进程保活详解：一篇文章解决你的所有疑问》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
更多同类文章 ……
四、TCP 协议的 KeepAlive
为什么需要在应用层做心跳，难道 TCP 不是个可靠连接吗？我们不能够依赖 TCP 做断线检测吗？比如使用 TCP 的 KeepAlive 机制来实现。应用层心跳是目前的最佳实践吗？怎么样的心跳才是最佳实践。很多做移动端 IM 的同行，以前确实没有仔细考虑过这些问题，潜意识里想当然的认为这仅仅只是个简单的心跳而已啊。事实并非这么简单。
五、IM 中保持有效长连接的重要性
对于客户端而言，使用 TCP 长连接来实现业务的最大驱动力在于：在当前连接可用的情况下，每一次请求都只是简单的数据发送和接受，免去了 DNS 解析，连接建立等时间，大大加快了请求的速度，同时也有利于接受服务器的实时消息。但前提是连接可用。
如果连接无法很好地保持，每次请求就会变成撞大运：运气好，通过长连接发送请求并收到反馈。运气差，当前连接已失效，请求迟迟没有收到反馈直到超时，又需要一次连接建立的过程，其效率甚至还不如 HTTP。而连接保持的前提必然是检测连接的可用性，并在连接不可用时主动放弃当前连接并建立新的连接。
基于这个前提，必须要有一种机制用于检测连接可用性。同时移动网络的特殊性也要求客户端需要在空余时间发送一定的信令，避免连接被回收。详见微信和运营商的撕B（另一篇针对微信的信令风暴技术研究文章请见：《微信对网络影响的技术试验及分析》）。而对于服务器而言，能够及时获悉连接可用性也非常重要：一方面服务器需要及时清理无效连接以减轻负载，另一方面也是业务的需求，如游戏副本中服务器需要及时处理玩家掉线带来的问题。
六、TCP 的 KeepAlive 无法替代应用层心跳保活机制的原因
说了保持连接的重要性，那么回到具体实现上。为什么我们需要使用应用层心跳来做检测，而不是直接使用 TCP 的特性呢？
TCP 是一个基于连接的协议，其连接状态是由一个状态机进行维护，连接完毕后，双方都会处于 established 状态，这之后的状态并不会主动进行变化。这意味着如果上层不进行任何调用，一直使 TCP 连接空闲，那么这个连接虽然没有任何数据，但仍是保持连接状态，一天、一星期，甚至一个月，即使在这期间中间路由崩溃重启无数次。举个现实中经常遇到的栗子：当我们 ssh 到自己的 VPS 上，然后不小心踢掉网线，此时的网络变化并不会被 TCP 检测出，当我们重新插回网线，仍旧可以正常使用 ssh，同时此时并没有发生任何 TCP 的重连。
有人会说 TCP 不是有 KeepAlive 机制么，通过这个机制来实现不就可以了吗？但是事实上，TCP KeepAlive 的机制其实并不适用于此。Keep Alive 机制开启后，TCP 层将在定时时间到后发送相应的 KeepAlive 探针以确定连接可用性。一般时间为 7200s（详情请参见《TCP/IP详解》中第23章），失败后重试 10 次，每次超时时间 75s。显然默认值无法满足我们的需求，而修改过设置后就可以满足了吗？答案仍旧是否定的。
因为 TCP KeepAlive 是用于检测连接的死活，而心跳机制则附带一个额外的功能：检测通讯双方的存活状态。两者听起来似乎是一个意思，但实际上却大相径庭。
考虑一种情况，某台服务器因为某些原因导致负载超高，CPU 100%，无法响应任何业务请求，但是使用 TCP 探针仍旧能够确定连接状态，这就是典型的连接活着但业务提供方已死的状态，对客户端而言，这时的最好选择就是断线后重新连接其他服务器，而不是一直认为当前服务器是可用状态，一直向当前服务器发送些必然会失败的请求。
从上面可以知道，KeepAlive 并不适用于检测双方存活的场景，这种场景还得依赖于应用层的心跳。应用层心跳有着更大的灵活性，可以控制检测时机，间隔和处理流程，甚至可以在心跳包上附带额外信息。从这个角度而言，应用层的心跳的确是最佳实践。
七、心跳保活机制的实现方案参考
从上面可以得出结论，目前而言，应用层心跳的确是检测连接有效性，双方是否存活的最佳实践，那么剩下的问题就是怎么实现。
最简单粗暴做法当然是定时心跳，如每隔 30 秒心跳一次，15 秒内没有收到心跳回包则认为当前连接已失效，断开连接并进行重连。这种做法最直接，实现也简单。缺点是比较耗电和耗流量。以一个协议包 5 个字节计算，一天收发 2880 个心跳包，一个月就是 5 * 2 * 2880 * 30 = 0.8M 的流量，如果手机上多装几个 IM 软件，每个月只心跳就好几兆流量没了，更不用说频繁的心跳带来的电量损耗。
既然频繁心跳会带来耗电和耗流量的弊端，改进的方向自然是减少心跳频率，但也不能过于影响连接检测的实时性。基于这个需求，一般可以将心跳间隔根据程序状态进行调整，当程序在后台时（这里主要考虑安卓），尽量拉长心跳间隔，5 分钟、甚至 10 分钟都可以。
而当 App 在前台时则按照原来规则操作。连接可靠性的判断也可以放宽，避免一次心跳超时就认为连接无效的情况，使用错误积累，只在心跳超时 n 次后才判定当前连接不可用。当然还有一些小 trick 比如从收到的最后一个指令包进行心跳包周期计时而不是固定时间，这样也能够一定程度减少心跳次数。