TCP/IP详解卷1 读书笔记：第二十三章 TCP保活定时器

引言

如果T C P连接的双方都没有向对方发送数据，则在两个T C P模块之间不交换任何信息。这意味着我们可以启动一个客户与服务器建立一个连接，然后离去数小时、数天、数个星期或者数月，而连接依然保持。中间路由器可以崩溃和重启，电话线可以被挂断再连通，但是只要两端的主机没有被重启，则连接依然保持建立。

该情况容易出现半打开连接，即连接正常建立后，一方突然崩溃，而另一方无法得知。

 

保活并不是T C P规范中的一部分。 Host Requirements RFC提供了3个不使用保活定时器的理由：

(1)    在出现短暂差错的情况下，这可能会使一个非常好的连接释放掉；

(2)    它们耗费不必要的带宽；

(3)    在按分组计费的情况下会在互联网上花掉更多的钱。

然而，许多实现提供了保活定时器。保活定时器是一个有争论的功能。许多人认为如果需要，这个功能不应该在 T C P中提供，而应该由应用程序来完成。

 

描述

保活功能就是试图在服务器端检测到这种半开放的连接。

保活功能主要是为服务器应用程序提供的。服务器应用程序希望知道客户主机是否崩溃，从而可以代表客户使用资源。

 

我们称使用保活选项的一端为服务器，而另一端则为客户。并没有什么使客户不能使用这个选项，但通常都是服务器设置这个功能。如果双方都特别需要了解对方是否已经消失，则双方都可以使用这个选项。即，根据需要，通信双方都可以使用保活选项，以启动保活定时器。

如果一个给定的连接在两个小时之内没有任何动作，则服务器就向客户发送一个探查报文段（我们将在随后的例子中看到这个探查报文段看起来像什么）。客户主机必须处于以下 4个状态之一。

(1)    客户主机依然正常运行，并从服务器可达。客户的 T C P响应正常，而服务器也知道对方是正常工作的。服务器在两小时以后将保活定时器复位。如果在两个小时定时器到时间之前有应用程序的通信量通过此连接，则定时器在交换数据后的未来 2小时再复位。

(2)    客户主机已经崩溃，并且关闭或者正在重新启动。在任何一种情况下，客户的 T C P都没有响应。服务器将不能够收到对探查的响应，并在 7 5秒后超时。服务器总共发送 1 0个这样的探查，每个间隔 7 5秒。如果服务器没有收到一个响应，它就认为客户主机已经关闭并终止连接。

(3)    客户主机崩溃并已经重新启动。这时服务器将收到一个对其保活探查的响应，但是这个响应是一个复位，使得服务器终止这个连接。

(4)    客户主机正常运行，但是从服务器不可达。这与状态 2相同，因为T C P不能够区分状态4与状态2之间的区别，它所能发现的就是没有收到探查的响应。

 

在第1种情况下，服务器的应用程序没有感觉到保活探查的发生。 T C P层负责一切。这个过程对应用程序都是透明的，直至第 2、 3或4种情况发生。在这三种情况下，服务器应用程序将收到来自它的 T C P的差错报告（通常服务器已经向网络发出了读操作请求，然后等待来自客户的数据。如果保活功能返回一个差错，则该差错将作为读操作的返回值返回给服务器）。在第2种情况下，差错是诸如“连接超时”之类的信息，而在第 3种情况则为“连接被对方复位”。第4种情况看起来像是连接超时，也可根据是否收到与连接有关的 I C M P差错来返回其他的差错。在下一节中我们将观察这
4种情况。

 

四种情况

 

另一端崩溃






第一个框中，客户在第1、 2和3行向服务器发送“Hello, world”并得到回显；

第二个框中，是建立连接一直没有数据往来，两个小时后，接收端的保活定时器，发起探查报文，收到回复说明连接完好。由于一直无数据往来，ARP表项中并无相关记录，因此先发了一个ARP请求，然后将探测报文发出。又过了两个小时，再次发起探测（Keep-Alive报文），连接仍完好。

第三个框中，又过了两个小时，接收端发起探测，但这时连接不行了，发起ARP没有响应，查不到IP，也就发不出探测报文。但保活定时器仍正常工作，连续执行了10次探测。

 

另一端崩溃并重新启动



我们建立了连接，并从客户发送 9个字节的数据到服务器（第 1 ~ 3行）。两个小时之后，客户发送第1个保活探查，其响应是一个来自服务器的复位。客户应用进程打印出“连接被对端复位”的差错，这是有意义的。

 

另一端不可达



第 1 ~ 3行证实连接是有效的。两个小时之后的第 1个保活探查是正常的（第 4、 5行），但是在两个小时后发生下一个探查之前，我们断开在路由器s u n和n e t b之间的S L I P连接（拓扑结构参见封）。

第6行的保活探查引发一个来自路由器 s u n的I C M P网络不可达的差错。正如我们在第2 1 . 1 0节描述的那样，对于主机 s l i p上接收的T C P而言，这只是一个软差错（TCP会忽略该错误，并进行超时重传，直到尝试最多次数。但该差错会被记录下来，在尝试最多次数后，将该差错报告给应用程序）。它报告收到了一个I
C M P差错，但是差错的接收者并没有终止这个连接。在发送主机最终放弃之前，一共发送了9个保活探查，间隔为 7 5秒。这时返回给应用进程的差错产生了一个不同的报文：“没有到达主机的路由”。我们在图6 - 1 2看到这对应于I C M P网络不可达的差错。

 

 

注意

对于一条TCP连接，如果一个中间设备给发送方回复了远端主机不可达，那么发送方会忽略掉该报文，认为网络只是暂时的不可达，而不是将TCP连接关闭。

如果是对于目标主机发来的主机不可达或端口不可达的处理，TCP会关闭该连接。