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