第23章 TCP的保活定时器
23.2 描述
在这个描述中，我们称使用保活选项的一端为服务器，而另一端则为客户。并没有什么使客户不能使用这个选项，但通常都是服务器设置这个功能。如果双方都特别需要了解对方是否已经消失，则双方都可以使用这个选项（在 2 9章我们将看到N F S使用T C P时，客户和服务器都设置了这个选项。但在第 2 6章讲到Te l n e t和R l o g i n时，只有服务器设置了这个选项，而客户则没有）。
如果一个给定的连接在两个小时之内没有任何动作，则服务器就向客户发送一个探查报文段（我们将在随后的例子中看到这个探查报文段看起来像什么）。客户主机必须处于以下 4个状态之一。
- 客户主机依然正常运行，并从服务器可达。客户的 T C P响应正常，而服务器也知道对方是正常工作的。服务器在两小时以后将保活定时器复位。如果在两个小时定时器到时间之前有应用程序的通信量通过此连接，则定时器在交换数据后的未来 2小时再复位。
- 客户主机已经崩溃，并且关闭或者正在重新启动。在任何一种情况下，客户的 T C P都没有响应。服务器将不能够收到对探查的响应，并在 7 5秒后超时。服务器总共发送 1 0个这样的探查，每个间隔 7 5秒。如果服务器没有收到一个响应，它就认为客户主机已经关闭并终止连接。
- 客户主机崩溃并已经重新启动。这时服务器将收到一个对其保活探查的响应，但是这个响应是一个复位，使得服务器终止这个连接。
- 客户主机正常运行，但是从服务器不可达。这与状态 2相同，因为T C P不能够区分状态4与状态2之间的区别，它所能发现的就是没有收到探查的响应。
服务器不用关注客户主机被关闭和重新启动的情况（这指的是一个操作员的关闭，而不是主机崩溃）。当系统被操作员关闭时，所有的应用进程也被终止（也就是客户进程），这会使客户的T C P在连接上发出一个 F I N。接收到F I N将使服务器的T C P向服务器进程报告文件结束，使服务器可以检测到这个情况。
在第1种情况下，服务器的应用程序没有感觉到保活探查的发生。 T C P层负责一切。这个过程对应用程序都是透明的，直至第 2、3或4种情况发生。在这三种情况下，服务器应用程序将收到来自它的 T C P的差错报告（通常服务器已经向网络发出了读操作请求，然后等待来自客户的数据。如果保活功能返回一个差错，则该差错将作为读操作的返回值返回给服务器）。在第2种情况下，差错是诸如“连接超时”之类的信息，而在第 3种情况则为“连接被对方复位”。第4种情况看起来像是连接超时，也可根据是否收到与连接有关的 I C M P差错来返回其他的差错。在下一节中我们将观察这 4种情况。
一个被人们不断讨论的关于保活选项的问题就是两个小时的空闲时间是否可以改变。通常他们希望该数值可以小得多，处在分钟的数量级。正如我们在附录 E看到的，这个值通常可以改变，但是在该附录所描述的所有系统中，保活间隔时间是系统级的变量，因此改变它会影响到所有使用该功能的用户。
Host Requirements RFC提到一个实现可提供保活的功能，但是除非应用程序指明要这样，否则就不能使用该功能。而且，保活间隔必须是可配置的，但是其默认值必须不小于两个小时。
