TCP保活机制

KeepAlive初衷

1. 客户端和服务器需要了解什么时候终止进程或者与对方断开连接。
2. 应用进程之间没有任何数据交换,但仍然需要通过连接保持一个最小的数据流。

keepAlive是由一个保活计时器实现的。当计时器被激发,连接一端 将发送一个保活探测(简称保活)报文,另一端接收报文的同时会发送一个ACK作为响应。

TCP协议中实现KeepAlive但是保活机制存在争议。许多人认为,如果需要,这一功能也不应在TCP协议中提供, 而应在应用程序中实现。另一种观点认为,如果许多应用程序中都需要这一功能,那么在 TCP协议中提供的话就可以使所有的实现都包含这一功能。

描述

保活功能在默认情况下是关闭的。TCP连接的任何一端都可以请求打开这一功能。保活功能可以被设置在连接的一端、两端,或者两端都没有。有几个配置参数可以用来控制保活 功能的操作。如果在一段时间(称为保活时间, keepalive time)内连接处于非活动状态,开启保活功能的一端将向对方发送一个保活探测报文。如果发送端没有收到响应报文,那么经过一个已经提前配置好的保活时间间隔(keepalive interval),将继续发送保活探测报文,直到发送探测报文的次数达到保活探测数(keepalive probe),这时对方主机将被确认为不可到达,连接也将被中断。 保活探测报文为一个空报文段(或只包含1字节)。它的序列号等于对方主机发送的 ACK报文的最大序列号减1。因为这一序列号的数据段已经被成功接收,所以不会对到达的报文段造成影响,但探测报文返回的响应可以确定连接是否仍在工作。探测及其响应报文都不包含任何新的有效数据(它是“垃圾”数据),当它们丢失时也不会进行重传。

TCP保活功能工作过程中,开启该功能的一端会发现对方处于以下四种状态之一：

1. 对方主机仍在工作,并且可以到达。对方的TCP响应正常,并且请求端也知道对方 在正常工作。请求端将保活计时器重置(重新设定为保活时间值)。如果在计时器超时之前有应用程序通过该连接传输数据,那么计时器将再次被设定为保活时间值。
2. 对方主机已经崩溃,包括已经关闭或者正在重新启动。这时对方的TCP将不会响应。 请求端不会接收到响应报文,并在经过保活时间间隔指定的时间后超时。超时前,请求端会 持续发送探测报文,一共发送保活探测数指定次数的探测报文,如果请求端没有收到任何探 测报文的响应,那么它将认为对方主机已经关闭,连接也将被断开。
3. 客户主机崩溃并且已重启。在这种情况下,请求端会收到一个对其保活探测报文的响应,但这个响应是一个重置报文段,请求端将会断开连接。
4. 对方主机仍在工作,但是由于某些原因不能到达请求端(例如网络无法传输,而且可 圃 能使用ICMP通知也可能不通知对方这一事实)。这种情况与状态2相同,因为TCP不能区 分状态2与状态4,结果都是没有收到探测报文的响应。

请求端不必担心对方主机正常关闭然后重启(不同于主机崩溃)的情况。当系统关机时, 所有的应用进程也会终止(即对方的进程),这会使对方的TCP发送一个FIN。请求端接收 到FIN后,会向请求端进程报告文件结束,并在检测到该状态后退出。

保活机制的弊端

1. 在出现短暂的网络错误的时候，保活机制有可能会使一个好的连接断开；
2. 保活机制会占用不必要的带宽；

与TCP保活机制相关的攻击

1. 使系统长时间地维护不必要的会话资源
2. 是获得端系统隐藏的一些信息(虽然这些信息对于攻击者而言可能实用性有限)。

由于默认情况下TCP不会对保活报文进行加密,所以保活探测报文和确认报文都有可能被利用。然而,对于应用层的保活机制(例如ssh),这些报文都会被加密,所以也就不会出现上述情况。