速读原著-TCP/IP(保活举例)

2020-03-13 09:40:03 浏览数 (1)

第23章 TCP的保活定时器

23.3 保活举例

现在详细讨论前一节提到的第 2、3和4种情况。我们将在使用这个选项的情况下检查所交换的分组。

23.3.1 另一端崩溃

首先观察另一端崩溃且没有重新启动的情况下所发生的现象。为模拟这种情况,我们采用如下步骤: • 在客户(主机b s d i上运行的s o c k程序)和主机s v r 4上的标准回显服务器之间建立一个连接。客户使用- K选项使能保活功能。 • 验证数据可以通过该连接。 • 观察客户T C P每隔2小时发送保活分组,并观察被服务器的 T C P确认。 • 将以太网电缆从服务器上拔掉直到这个例子完成,这会使客户认为服务器主机已经崩溃。 • 我们预期服务器在断定连接已中断前发送 1 0个间隔为7 5秒的保活探查。

这里是客户端的交互输出结果:

图2 3 - 1显示的是t c p d u m p的输出结果(已经去掉了连接建立和窗口通告)。

客户在第1、2和3行向服务器发送“Hello, world”并得到回显。第4行是第一个保活探查,发生在两个小时以后( 7 2 0 0秒)。在第6行的T C P报文段能够发送之前,首先观察到的是一个A R P请求和一个A R P应答。第6行的保活探查引出来自另一端的响应(第 7行)。两个小时以后,在第7和8行发生了同样的分组交换过程。

如果能够观察到第6和第1 0行的保活探查中的所有字段,我们就会发现序号字段比下一个将要发送的序号字段小 1(在本例中,当下一个为 1 4时,它就是1 3)。但是因为报文段中没有数据,t c p d u m p不能打印出序号字段(它仅能够打印出设置了 S Y N、F I N或R S T标志的空数据的序号)。正是接收到这个不正确的序号,才导致服务器的 T C P对保活探查进行响应。这个响应告诉客户,服务器下一个期望的序号是 1 4。

一些基于4 . 2 B S D的旧的实现不能够对这些保活探查进行响应,除非报文段中包含数据。某些系统可以配置成发送一个字节的无用数据来引出响应。这个无用数据是无害的,因为它不是所期望的数据(这是接收方前一次接收并确认的数据),因此它会被 接收方丢弃。其他一些系统在探查的前半部分发送4.3BSD格式的报文段(不包含数据),如果没有收到响应,在后半部分则切换为4.2BSD格式的报文段。

接着我们拔掉电缆,并期望两个小时的再一次探查失败。当这下一个探查发生时,注意到从来没有看到电缆上出现 T C P报文段,这是因为主机没有响应 A R P请求。在放弃之前,我们仍可以观察到客户每隔 7 5秒发送一个探查,一共发送了 1 0次。从交互式脚本可以看到返回给客户进程的差错码被T C P转换为“连接超时”,这正是实际所发生的。

23.3.2 另一端崩溃并重新启动

在这个例子中,我们可以观察到当客户崩溃并重新启动时发生的情况。最初的环境与前一个例子相似,但是在我们验证连接有效之后,我们将服务器从以太网上断开,重新启动,然后再连接到网络上。我们希望看到下一个保活探查产生一个来自服务器的复位,因为现在服务器不知道关于这个连接的任何信息。这是交互会话的过程:

图2 3 - 2显示的是t c p d u m p的输出结果(已经去掉了连接建立和窗口通告)。

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

23.3.3 另一端不可达

在这个例子中,客户没有崩溃,但是在保活探查发送后的 1 0分钟内无法到达,可能是一个中间路由器已经崩溃,或一条电话线临时出现故障,或发生了其他一些类似的情况。

为了仿真这个例子,我们从主机 s l i p经过一个拨号 S L I P链路与主机 v a n g o g h . c s . b e r k e l e y . e d u建立一个连接,然后断掉链路。这里是交互输出的结果:

图2 3 - 3显示了在路由器b s d i上收集到的t c p d u m p输出结果(已经去掉了连接建立和窗口通告)。

我们与以前一样开始讨论这个例子:第 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而言,这只是一个软差错。它报告收到了一个I C M P差错,但是差错的接收者并没有终止这个连接。在发送主机最终放弃之前,一共发送了9个保活探查,间隔为 7 5秒。这时返回给应用进程的差错产生了一个不同的报文:“没有到达主机的路由”。我们在图6 - 1 2看到这对应于I C M P网络不可达的差错。

0 人点赞