第23章 TCP的保活定时器
23.1 引言
许多T C P / I P的初学者会很惊奇地发现可以没有任何数据流通过一个空闲的 T C P连接。也就是说，如果T C P连接的双方都没有向对方发送数据，则在两个T C P模块之间不交换任何信息。例如，没有可以在其他网络协议中发现的轮询。这意味着我们可以启动一个客户与服务器建立一个连接，然后离去数小时、数天、数个星期或者数月，而连接依然保持。中间路由器可以崩溃和重启，电话线可以被挂断再连通，但是只要两端的主机没有被重启，则连接依然保持建立。
这意味着两个应用进程—客户进程或服务器进程—都没有使用应用级的定时器来检测非活动状态，而这种非活动状态可以导致应用进程中的任何一个终止其活动。回想在第1 0 . 7节末尾曾提到过的B G P每隔3 0秒就向对端发送一个应用的探查，就是独立于 T C P的保活定时器之外的应用定时器。
然而，许多时候一个服务器希望知道客户主机是否崩溃并关机或者崩溃又重新启动。许多实现提供的保活定时器可以提供这种能力。
保活并不是T C P规范中的一部分。Host Requirements RFC提供了3个不使用保活定时器的理由： (1) 在出现短暂差错的情况下，这可能会使一个非常好的连接释放掉； (2) 它们耗费不必要的带宽； (3) 在按分组计费的情况下会在互联网上花掉更多的钱。然而，许多实现提供了保活定时器。保活定时器是一个有争论的功能。许多人认为如果需要，这个功能不应该在 T C P中提供，而应该由应用程序来完成。这是应当认真对待的一些问题之一，因为在这个论题上有些人表达出了很大的热情。
在连接两个端系统的网络出现临时故障的时候，保活选项会引起一个实际上很好的连接终止。例如，如果在一个中间路由器崩溃并重新启动时发送保活探查，那么 T C P会认为客户的主机已经崩溃，而实际上所发生的并非如此。
保活功能主要是为服务器应用程序提供的。服务器应用程序希望知道客户主机是否崩溃，从而可以代表客户使用资源。许多版本的 R l o g i n和Te l n e t服务器默认使用这个选项。
一个说明现在需要使用保活功能的常见例子是当个人计算机用户使用 T C P / I P向一个使用Te l n e t的主机注册时。如果在一天结束时，他们仅仅关闭了电源而没有注销，那么便会留下一个半开放的连接。在图1 8 - 1 6中，我们看到通过一个半开放连接发送数据会导致返回一个复位，但那是在来自正在发送数据的客户端。如果客户已经消失了，使得在服务器上留下一个半开放连接，而服务器又在等待来自客户的数据，则服务器将永远等待下去。保活功能就是试图在服务器端检测到这种半开放的连接。
23.4 小结
正如我们在前面提到的，对保活功能是有争议的。协议专家继续在争论该功能是否应该归入运输层，或者应当完全由应用层来处理。
在连接空闲两个小时后，在一个连接上发送一个探查分组来完成保活功能。可能会发生 4种不同的情况：对端仍然运行正常、对端已经崩溃、对端已经崩溃并重新启动以及对端当前无法到达。我们使用一个例子来观察每一种情况，并观察到在最后三个条件下返回的不同差错。在前两个例子中，如果没有提供这种功能，并且也没有应用层的定时器，则客户将永远无法知道对端已经崩溃或崩溃并重新启动。可是在最后一个例子中，两端都没有发生差错，只是它们之间的连接临时中断。我们在使用保活时必须关注这个限制。
