文章目录
一、TCP KeepAlive 初衷
交互双方建立 TCP 连接，但并不是一直都有数据交互，有些连接在数据交互完毕后会被立即释放，有些则不会，那么在长时间无数据交互的情况下，双方都有可能发生主机宕机、网络异常等各种意外，当这些意外发生后，连接并未来得及被正常释放，另一方在不知道对端异常的情况下会一直维护这个连接，长时间的积累会占用过多的系统资源，尤其是服务端，为了避免资源浪费，于是就有了 TCP「保活」机制
从 NAT 角度理解 TCP KeepAlive 的必要性
网络基础 - NAT 篇有提到过转换表(如下)，其中，202.244.174.37:1025/1026 的 1025/1026 是临时分配的端口
由于端口数量有限([0, 65535])，再加上维护转换表需要额外开销，因此不能无休止地向转换表中增加记录，对于过期的记录，需要将其删除
如何判断哪些是过期记录？
一段时间内无活动的连接，其对应记录就是过期的，NAT 路由器应定时检查转换表中的非活动连接，并将其丢弃，注意，这个丢弃的动作并不会告知该连接的任何一方
问题来了，如果一个客户端应用因业务需要必须与服务端维持长连接，那么该连接在长时间没有任何数据交互的情况下，NAT 路由器会将其对应记录从转换表中删除，客户端和服务端对此是毫无感知的，连接被丢弃后，服务端再也收不到客户端发送的数据包，显然客户端也收不到服务端的数据推送
一个具体的例子来感受下这个问题的严重性：
某财务应用，使用者需花费十几分钟甚至几十分钟在客户端填写大量的表单数据，填好后点击 “提交” 按钮
结果，这个时候由于 NAT 路由器早已将连接对应记录从转换表中删除，报文无法到达服务端，应用故障产生，这直接导致使用者所有的工作需要重新来过，给使用者带来极大的不便和损失
针对上述问题，TCP 层的解决办法是通过「保活」机制维持长连接，让 NAT 路由器认为该连接是活动的，从而避免被 “干掉”
二、TCP KeepAlive 工作原理
开启 TCP「保活」机制的一方会启动一个计时器，当这个计时器为 0 时，也就是经过 tcp_keepalive_time 时间后，一个探测报文便会被发出，该报文是一个纯 ACK 报文(RFC 1122 规定，不包含任何数据，或者包含 1 个无意义的字节(例如 0x0))，其序列号是上一个报文序列号 - 1，所以探测报文不在窗口控制范围内
开启了 TCP「保活」机制的一方需要考虑以下几种情况：
- 对端进程正常运行
当探测报文发出后，对端会正常响应，TCP 保活计时器会被重置 - 对端主机宕机并重启
当探测报文发出后，对端是可以响应的，但因重启后没有该连接的有效信息，最终返回 RST 报文 - 对端主机宕机(注意不是进程崩溃，进程崩溃后，Linux 内核在回收进程资源时会发送 FIN 报文，而主机宕机是无法感知的)，或者对端由于网络等其他原因导致报文不可达
当探测报文发出后，石沉大海，没有响应，连续几次达到保活探测次数后，则认为当前的 TCP 连接已经死亡，由 Linux 内核通知进程
三、TCP KeepAlive 具体使用
TCP「保活」机制默认是关闭的(设置不合理的话，可能会因为短暂的网络波动而断开健康的 TCP 连接)，若想使用，需设置套接字选项 SO_KEEPALIVE
Linux 内核有对应的参数可以设置保活时间、保活探测的时间间隔和保活探测的次数，以下均为默认值：
- /proc/sys/net/ipv4/tcp_keepalive_time=7200
- /proc/sys/net/ipv4/tcp_keepalive_intvl=75
- /proc/sys/net/ipv4/tcp_keepalive_probes=9
也就是说，最多需要经过 (tcp_keepalive_time + tcp_keepalive_intvl * tcp_keepalive_probes)s 才能发现「死亡」连接
当然，也可以通过套接字选项 TCP_KEEPIDLE、TCP_KEEPINTVL 和 TCP_KEEPCNT 分别重置保活时间、保活探测的时间间隔和保活探测的次数，详见实战 - 抓包 TCP KeepAlive 探测报文(附代码示例)
四、TCP Keepalive 和 HTTP Keep-Alive 有什么区别？
- TCP KeepAlive 是为了探测连接的对端是否存活
- HTTP Keep-Alive 是为了让 TCP 连接活得久一点，以便发起多个 HTTP 请求时能复用同一个 TCP 连接，提高通信效率