一个TCP连接建立，然后经过任意时间，且中间路由器可以崩溃和重启、电话线可以挂断再接通，而连接依然保持，只要两端主机没有被重启，这意味着两端不交换任何信息。然而许多时候一个服务器希望知道客户主机是否崩溃，许多实现提供的保活定时器可提供这种能力，rlogin和telnet服务器默认使用这个选项。
保活并不是TCP规范的一部分，理由如下：
1.出现短暂差错时（如中间路由器崩溃并重启时），可能释放掉一个非常好的连接。
2.耗费不必要的带宽。
3.分组计费时会在互联网上花掉更多钱。
许多人认为保活定时器应该由应用程序完成。
当个人计算机用户建立连接后，拔掉电源但没有注销时，会留下一个半打开的连接，此时服务器发送数据时会导致返回一个复位，但这是来自重新打开的客户端，如果客户已经消失，服务器上会留下一个永久等待的半打开连接，保活功能就是为了在服务端检测这种半打开的连接。
客户和服务器都能使用保活定时器，只要需要了解对方是否已经消失就可使用。
如果一个给定连接在两个小时内没有任何动作，则服务器向客户发送一个探查报文段，此时客户主机可能处于以下4个状态之一：
1.客户主机正常运行，并从服务器可达。此时客户的TCP响应正常，服务器就知道了对方正常工作。
2.客户主机已经崩溃，且已经关闭或正在重启。此时客户的TCP没有响应，服务器将在75秒后再次发送探查，共发送10个，如果没有收到一个响应，则服务器认为客户主机关机并终止连接。
3.客户主机崩溃，且已经重新启动。此时客户TCP会响应一个复位，使得服务器终止此连接。
4.客户主机正常运行，但从服务器不可达。这与状态2相同，TCP不能区分这两个状态。
第1种情况下，服务器的应用程序没有感觉到保活探查的发生，后3种情况下，服务器应用将收到来自它的TCP的差错报告，第2种情况下差错是“连接超时”之类的信息，第3种情况下差错是“连接被对方复位”，第4种情况看起来像是连接超时，也可根据是否收到与连接有关的ICMP差错来返回其他差错。
服务器不用关注客户主机正常关闭过程，系统被正常关闭时，所有应用进程被终止，这会使客户的TCP的在连接上发出一个FIN。
2小时的保活空闲时间可改变，但保活时间间隔是系统级变量，改变它会影响到所有使用该功能的用户。
另一端崩溃时保活定时器的例子：
tcpdump输出：
第4行开始是发送第1个保活探查的开端，发生在7200秒后，在第6行该保活探查报文段发送前，先观察到的是arp请求和应答，之后引出了接收端的响应（第7行），两小时后，第8~11行发生了同样的分组交换过程。
第6行和第10行的保活探查报文中的序号字段比下一个将要发送的序号小1（本例中，下一个应该发送的序号是14，但保活探查中发送的序号是13），但报文段中没有数据，因此tcpdump不能打印出序号字段，之后服务器对其进行响应，告诉客户下一个期望的序号是14。
一些基于4.2 BSD的旧实现不能对这些保活探查进行响应，除非报文段中包含数据。某些系统可配置成发送一个字节的无用数据来引出响应，这个无用数据是无害的，因为它不是所期望的序号的数据，接收方会将这个字节丢弃。某些系统在探查时先发送4.3 BSD格式的报文段（不包含数据），如果没有收到响应，切换成4.2 BSD格式的报文段再发一次。
拔掉电缆后，下一次的探查失败，失败的探查发生了十次，第12到21行中只出现了ARP请求，没有出现TCP报文段，因为主机没有响应ARP请求。交互式脚本返回给客户进程的差错码被TCP转换为连接超时，这正是实际所发生的。
另一端崩溃后又重新启动的保活探查的例子：
以下是去掉连接建立和窗口通告报文后的tcpdump的输出：
客户两小时后发送的第一个保活探查的响应是服务器的复位，客户进程随后打印出连接被对端复位。
另一端不可达时，保活探查的例子，这个例子中，客户没有崩溃，而是断开连接链路中的一个SLIP连接：
以下是去掉连接建立和窗口通告报文后的tcpdump输出的结果：
两小时后，发出的第一个保活探查是正常的（第4、5行），但在下一个探查前，断开SLIP链路，第6行的保活探查是来自路由器的ICMP网络不可达差错，这是一个软差错，差错的接收者没有终止这个连接，在发送主机最终放弃之前，一共发送了9个保活探查，每次发送间隔75秒，之后返回给应用一个没有到达主机的路由差错。
