前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >速读原著-TCP/IP(保活举例)

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

作者头像
cwl_java
发布2020-03-13 09:40:03
5590
发布2020-03-13 09:40:03
举报
文章被收录于专栏:cwl_Javacwl_Java

第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网络不可达的差错。

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2020-03-12 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 第23章 TCP的保活定时器
    • 23.3 保活举例
      • 23.3.1 另一端崩溃
      • 23.3.2 另一端崩溃并重新启动
      • 23.3.3 另一端不可达
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档