TCP连接在建立连接后，只要两端主机没有被重启，即使是一个空闲的连接也可以保持连接很长时间，中间路由器可以重启、崩溃，链路可以被挂断再联通。这意味着两个应用进程-----客户进程或服务器进程-----都没有使用应用级的定时器来检测非活动状态，而这种非活动状态可以导致应用进程中的任何一个终止其活动。 然而，许多时候一个服务器希望知道客户主机是否崩溃并关机或者崩溃又重新启动。许多实现提供的保活定时器可以提供这种能力。
保活并不是T C P规范中的一部分。 Host Requirements RFC提供了3个不使用保活定时器的理由：
(1) 在出现短暂差错的情况下，这可能会使一个非常好的连接释放掉；
(2) 它们耗费不必要的带宽;
(3)在按分组计费的情况下会在互联网上花掉更多的钱。然而，许多实现提供了保活定时器。
保活功能主要是为服务器应用程序提供的。服务器应用程序希望知道客户主机是否崩溃，从而可以代表客户使用资源。 一种说明保活功能存在的必要性的例子是：如果一台个人计算机在关闭时，仅仅关闭了电源而没有注销，那么便会留下一个半开放的连接。虽然我们知道通过一个半开放连接发送数据会导致返回一个复位，但那是在来自正在发送数据的客户端。如果客户端已经消失了，使得在服务器上留下一个半开放连接，而服务器又在等待来自客户的数据，则服务器将永远等待下去，造成了不必要的服务器资源浪费。保活功能就是试图在服务器端检测到这种半开放的连接。
如果一个给定的连接在两个小时之内没有任何动作，则服务器就向客户发送一个探查报文段。客户主机必须处于以下 4个状态之一：
1) 客户主机依然正常运行，并从服务器可达。客户的 T C P响应正常，而服务器也知道对方是正常工作的。服务器在两小时以后将保活定时器复位。如果在两个小时定时器到时间之前有应用程序的通信量通过此连接，则定时器在交换数据后的未来 2小时再复位。
2) 客户主机已经崩溃，并且关闭或者正在重新启动。在任何一种情况下，客户的 T C P都没有响应。服务器将不能够收到对探查的响应，并在 7 5秒后超时。服务器总共发送 1 0个这样的探查，每个间隔 7 5秒。如果服务器没有收到一个响应，它就认为客户主机已经关闭并终止连接。
3) 客户主机崩溃并已经重新启动。这时服务器将收到一个对其保活探查的响应，但是这个响应是一个复位，使得服务器终止这个连接。
4) 客户主机正常运行，但是从服务器不可达。这与状态 2相同，因为T C P不能够区分状态4与状态2之间的区别，它所能发现的就是没有收到探查的响应。
服务器不用关注客户主机被关闭和重新启动的情况（这指的是一个操作员的关闭，而不是主机崩溃） 。当系统被操作员关闭时，所有的应用进程也被终止（也就是客户进程） ，这会使客户的 T C P在连接上发出一个 F I N。接收到F I N将使服务器的 T C P向服务器进程报告文件结束，使服务器可以检测到这个情况。
TCP的保活机制在某些应用场合看起来是不必要的， 但是也有其独特的应用场合，就像是拥有大量不活跃的连接的一台服务器，如果没有一些机制来帮助服务器清理坏掉的连接，最终的结果可能是导致服务器崩溃或者资源耗尽引起重启等，此外，还有一种独立于 T C P的保活定时器之外的应用定时器，可以实现应用级的探查。