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

速读原著-TCP/IP(IP源站选路选项)

作者头像
cwl_java
发布2020-03-08 18:47:19
1.2K0
发布2020-03-08 18:47:19
举报
文章被收录于专栏:cwl_Javacwl_Java

第8章 Traceroute程序

8.5 IP源站选路选项

通常I P路由是动态的,即每个路由器都要判断数据报下面该转发到哪个路由器。应用程序对此不进行控制,而且通常也并不关心路由。它采用类似 Tr a c e r o u t e程序的工具来发现实际的路由。 源站选路(source routing)的思想是由发送者指定路由。它可以采用以下两种形式: ? 严格的源路由选择。发送端指明 I P数据报所必须采用的确切路由。如果一个路由器发现源路由所指定的下一个路由器不在其直接连接的网络上,那么它就返回一个“源站路由失败”的I C M P差错报文。 ? 宽松的源站选路。发送端指明了一个数据报经过的 I P地址清单,但是数据报在清单上指明的任意两个地址之间可以通过其他路由器。

Tr a c e r o u t e程序提供了一个查看源站选路的方法,我们可以在选项中指明源站路由,然后检查其运行情况。

一些公开的Tr a c e r o u t e程序源代码包中包含指明宽松的源站选路的补丁。但是在标准版中通常并不包含此项。这些补丁的解释是“ Van Jacobson的原始Tr a c e r o u t e程序(1 9 8 8年春)支持该特性,但后来因为有人提出会使网关崩溃而将此功能去除。”对于本章中所给出的例子,作者将这些补丁安装上去,并将它们设置成允许宽松的源站选路和严格的源站选路。

图8 - 6给出了源站路由选项的格式。

在这里插入图片描述
在这里插入图片描述

这个格式与我们在图 7 - 3中所示的记录路由选项格式基本一致。不同之处是,对于源站选路,我们必须在发送I P数据报前填充I P地址清单;而对于记录路由选项,我们需要为 I P地址清单分配并清空一些空间,并让路由器填充该清单中的各项。同时,对于源站选路,只要为所需要的I P地址数分配空间并进行初始化,通常其数量小于 9。而对于记录路由选项来说,必须尽可能地分配空间,以达到 9个地址。

对于宽松的源站选路来说, c o d e字段的值是0 x 8 3;而对于严格的源站选路,其值为 0 x 8 9。l e n和p t r字段与7 . 3节中所描述的一样。

源站路由选项的实际称呼为“源站及记录路由”(对于宽松的源站选路和严格的源站选路,分别用L S R R和S S R R表示),这是因为在数据报沿路由发送过程中,对I P地址清单进行了更新。下面是其运行过程: ? 发送主机从应用程序接收源站路由清单,将第 1个表项去掉(它是数据报的最终目的地址),将剩余的项移到1个项中(如图8 - 6所示),并将原来的目的地址作为清单的最后一项。指针仍然指向清单的第 1项(即,指针的值为4)。

? 每个处理数据报的路由器检查其是否为数据报的最终地址。如果不是,则正常转发数据报(在这种情况下,必须指明宽松源站选路,否则就不能接收到该数据报)。 ? 如果该路由器是最终目的,且指针不大于路径的长度,那么( 1)由p t r所指定的清单中的 下一个地址就是数据报的最终目的地址;( 2)由外出接口(outgoing interface)相对应的I P地址取代刚才使用的源地址;( 3)指针加4。

可以用下面这个例子很好地解释上述过程。在图 8 - 7中,我们假设主机 S上的发送应用程序发送一份数据报给D,指定源路由为R1,R2和R3。

在这里插入图片描述
在这里插入图片描述

在上图中,#表示指针字段,其值分别是 4、8、1 2和1 6。长度字段恒为1 5(三个I P地址加上三个字节首部)。可以看出,每一跳I P数据报中的目的地址都发生改变。

当一个应用程序接收到由信源指定路由的数据时,在发送应答时,应该读出接收到的路由值,并提供反向路由。

Host Requirements RFC指明,T C P客户必须能指明源站选路,同时, T C P服务器必须能够接收源站选路,并且对于该 T C P连接的所有报文段都能采用反向路由。如果T C P服务器下面接收到一个不同的源站选路,那么新的源站路由将取代旧的源站路 由。

8.5.1 宽松的源站选路的t r a c e r o u t e程序示例

使用t r a c e r o u t e程序的- g选项,可以为宽松的源站选路指明一些中间路由器。采用该选项可以最多指定8个中间路由器(其个数是 8而不是9的原因是,所使用的编程接口要求最后的表目是目的主机)。

在图8 - 4中,去往N I C,即n i c . d d n . m i l的路由经过NASA Science Internet。在图8 - 8中,我们通过指定路由器 e n s s 1 4 2 . U T . w e s t n e t . n e t (192.31.39.21) 作为中间路由器来强制数据报通过N S F N E T:

在这里插入图片描述
在这里插入图片描述

在这种情况下,看起来路径中共有 1 6跳,其平均RT T大约是350 ms。而图8 - 4的通常选路则只有1 3跳,其平均RT T约为322 ms。默认路径看起来更好一些(在建立路径时,还需要考虑其他的一些因素。其中一些必须考虑的因素是所包含网络的组织及政治因素)。

前面我们说看起来有 1 6跳,这是因为将其输出结果与前面的通过 N S F N E T(图8 - 5)的示例比较,发现在本例采用宽松源路由,选择了 3个路由器(这可能是因为路由器对源站选路数据 报 产 生 I C M P超 时 差 错 报 文 上 存 在 一 些 差 错 )。 在 n e t b 和 b u t c h路 由 器 之 间 的g a t e w a y. t u c . n o a o . e d u路由器丢失了,同时,位于 G a b b y和e n s s 1 4 2 . U T. w e s t . n e t之间的We s t g a t e . Te l c o m . A r i z o n a . e d u和u u - u a . A Z . w e s t n e t . n e t两个路由器也丢失了。在这些丢失的路由器上可能发生了与接收到宽松的源站选路选项数据报有关的程序问题。实际上,当采用N S F N E T时,信源和N I C之间的路径有1 9跳。本章习题8 . 5继续对这些丢失路由器进行讨论。

同时本例也指出了另一个问题。在命令行,我们必须指定路由器 e n s s 1 4 2 . U T. w e s t n e t . n e t的点分十进制I P地址,而不能以其域名代替。这是因为,反向域名解析( 1 4 . 5节中描述的通过I P地址返回域名)将域名与 I P地址相关联,但是前向解析(即给出域名返回 I P地址)则无法做到。在D N S中,前向映射和反向映射是两个独立的文件,而并非所有的管理者都同时拥有这两个文件。因此,在一个方向是工作正常而另一个方向却失败的情况并不少见。

还有一种以前没有碰到过的情况是在 T T L字段为8的情况下,对于第一个 RT T,打印一个星号。这表明,发生超时,在 5秒内未收到本次探查的应答信号。

将本图与图8 - 4相比较,还可以得出一个结论,即路由器 n s n - F I X - p e . s u r a . n e t同时与N S F N E T和NASA Science Internet相连。

8.5.2 严格的源站选路的t r a c e r o u t e程序示例

在作者的t r a c e r o u t e程序版本中,- G选项与前面所描述的- g选项是完全一样的,不过此时是严格的源站选路而不是宽松的源站选路。我们可以采用这个选项来观察在指明无效的严格的源站选路时其结果会是什么样的。从图 8 - 5可以看出来,从作者的子网发往 N S F N E T的数据报的正常路由器顺序是 n e t b,g a t e w a y,b u t c h和g a b b y(为了便于查看,后面所有的输出结果中,均省略了域名后缀 . t u c . n o a o . e d u和. t e l c o m . a r i z o n a . e d u)。我们指定了一个严格源路由,使其试图将数据报从 g a t e w a y直接发送到g a b b y,而省略了b u t c h。

我们可以猜测到其结果会是失败的,正如图 8 - 9所给出的结果。

在这里插入图片描述
在这里插入图片描述

这里的关键是在于T T L字段为3的输出行中,RT T后面的! S。这表明t r a c e r o u t e程序接收到I C M P“源站路由失败”的差错报文:即图 6 - 3中t y p e字段为3,而c o d e字段为5。T T L字段为3的第二个 RT T位置的星号表示未收到这次探查的应答信号。这与我们所猜想的一样,g a t e w a y不可能直接发送数据报给g a b b y,这是因为它们之间没有直接的连接。

T T L字段为2和3的结果都来自于 g a t e w a y,对于T T L字段为2的应答来自g a t e w a y,是因为g a t e w a y接收到T T L字段为1的数据报。在它查看到(无效的)严格的源站选路之前,就发现T T L已过期,因此发送回 I C M P超时报文。T T L字段等于3的行,在进入g a t e w a y时其T T L字段为2,因此,它查看严格的源站选路,发现它是无效的,因此发送回 I C M P源站选路失败的差错报文。

图8 - 1 0给出了与本例相对应的 t c p d u m p输出结果。该输出结果是在 s u n和n e t b之间的S L I P链路上遇到的。我们必须在 t c p d u m p中指定- v选项以显示出源站路由信息。这样,会输出一些像数据报 I D这样我们并不需要的结果,我们在给出结果中将这些不需要的结果删除掉。同样,用S S R R表示“严格的源站及记录路由”。

首先注意到, s u n所发送的每个 U D P数据报的目的地址都是 n e t b,而不是目的主机(w e s t g a t e)。这一点可以用图8 - 7的例子来解释。类似地,- G选项所指定的另外两个路由器(g a t e w a y和g a b b y)以及最终目(w e s t g a t e)成为第一跳的S S R R选项。从这个输出结果中,还可以看出, t r a c e r o u t e程序所采用的定时时间(第 1 5行和1 6行之间的时间差)是5秒。

在这里插入图片描述
在这里插入图片描述

8.5.3 宽松的源站选路t r a c e r o u t e程序的往返路由

我们在前面已经说过,从A到B的路径并不一定与从B到A的路径完全一样。除非同时在两个系统中登录并在每个终端上运行 t r a c e r o u t e程序,否则很难发现两条路径是否不同。但是,采用宽松的源站选路,就可以决定两个方向上的路径。

这里的窍门就在于指定一个宽松的源站路由,该路由的目的端和宽松路径一样,但发送端为目的主机。例如,在s u n主机上,我们可以查看到发往以及来自b r u n o . c s . c o l o r a d o . e d u的结果如图8 - 11所示。

发出路径(T T L字段为1 ~ 11)的结果与返回路径( T T L字段为11 ~ 2 1)不同,这很好地说明了在Internet 上,选路可能是不对称的。

该输出同时还说明了我们在图 8 - 3中所讨论的问题。比较T T L字段为2和1 9的输出结果:它们都是路由器g a t e w a y . t u c . n o a o . e d u,但两个I P地址却是不同的。由于 t r a c e r o u t e程序以进入接口作为其标识,而我们从两条不同的方向经过该路由器,一条是发出路径( T T L字段为2),另一条是返回路径( T T L字段为1 9),因此可以猜想到这个结果。通过比较 T T L字段为3和1 8、4和1 7的结果,可以看到同样的结果。

在这里插入图片描述
在这里插入图片描述
本文参与?腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2020-03-05 ,如有侵权请联系 cloudcommunity@tencent.com 删除

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

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

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

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 第8章 Traceroute程序
    • 8.5 IP源站选路选项
      • 8.5.1 宽松的源站选路的t r a c e r o u t e程序示例
      • 8.5.2 严格的源站选路的t r a c e r o u t e程序示例
      • 8.5.3 宽松的源站选路t r a c e r o u t e程序的往返路由
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
http://www.vxiaotou.com