学步园

第8章 Traceroute程序

8.1   引言

由Van Jacobson编写的 Traceroute程序是一个能更深入探索TCP/IP协议的方便可用的工具。 尽管不能保证从源端发往目的端的两份连续的  IP数据报具有相同的路由，但是大多数情况下是这样的。Traceroute程序可以让我们看到 IP数据报从一台主机传到另一台主机所经过的路由。 Traceroute程序还可以让我们使用 IP源路由选项。

使用手册上说：“程序由SteveDeering 提议，由Van Jacobson 实现，并由许多其他人 根据C.Philip Wood, Tim Seaver及Ken Adelman等人提出的令人信服的建议或补充意见进行调试。”

8.2   Traceroute程序的操作

在7.3节中，我们描述了 IP记录路由选项（ RR）。为什么不使用这个选项而另外开发一个 新的应用程序？有三个方面的原因。首先，原先并不是所有的路由器都支持记录路由选项， 因此该选项在某些路径上不能使用（ Traceroute程序不需要中间路由器具备任何特殊的或可选 的功能）。

其次，记录路由一般是单向的选项。发送端设置了该选项，那么接收端不得不从收到的 IP 首部中提取出所有的信息，然后全部返回给发送端。在 7.3节中，我们看到大多数 Ping服务器的 实现（内核中的 ICMP回显应答功能）把接收到的 RR清单返回，但是这样使得记录下来的 IP地 址翻了一番（一来一回）。这样做会受到一些限制，这一点我们在下一段讨论（ Traceroute程序 只需要目的端运行一个 UDP模块—其他不需要任何特殊的服务器应用程序）。

最后一个原因也是最主要的原因是， IP首部中留给选项的空间有限，不能存放当前大多 数的路径。在IP首部选项字段中最多只能存放9个IP地址。在原先的ARPANET中这是足够的， 但是对现在来说是远远不够的。

Traceroute程序使用 ICMP报文和IP首部中的TTL字段（生存周期）。TTL字段是由发送端 初始设置一个8bit 字段。推荐的初始值由分配数字 RFC指定，当前值为 64 。较老版本的系统 经常初始化为15或32。我们从第7章中的一些ping程序例子中可以看出，发送 ICMP回显应答 时经常把 TTL设为最大值 255。

每个处理数据报的路由器都需要把TTL的值减1或减去数据报在路由器中停留的秒数。由于大多数的路由器转发数据报的时延都小于1秒钟，因此TTL最终成为一个跳站的计数器，所 经过的每个路由器都将其值减1。

RFC 1009 [Braden and Postel 1987]指出，如果路由器转发数据报的时延超过1秒，那 么它将把TTL值减去所消耗的时间（秒数）。但很少有路由器这么实现。新的路由器需求文档RFC[Almquist 1993]为此指定它为可选择功能，允许把TTL看成一个跳站计数器。

TTL字段的目的是防止数据报在选路时无休止地在网络中流动。例如，当路由器瘫痪或者两个路由器之间的连接丢失时，选路协议有时会去检测丢失的路由并一直进行下去。在这段时间内，数据报可能在循环回路被终止。 TTL字段就是在这些循环传递的数据报上加上一个生存上限。

当路由器收到一份IP数据报，如果其TTL字段是0或1，则路由器不转发该数据报（接收到这种数据报的目的主机可以将它交给应用程序，这是因为不需要转发该数据报。但是在通常情况下，系统不应该接收 TTL字段为0的数据报）。相反，路由器将该数据报丢弃，并给信源机发一份ICMP“超时”信息。Traceroute程序的关键在于包含这份ICMP信息的IP报文的信源 地址是该路由器的IP地址。

我们现在可以猜想一下Traceroute程序的操作过程。它发送一份TTL字段为1的IP数据报给 目的主机。处理这份数据报的第一个路由器将  TTL值减1，丢弃该数据报，并发回一份超时

IC M P 报文。这样就得到了该路径中的第一个路由器的地址。然后  Tr a c e r o u t e 程序发送一份 TTL值为2的数据报，这样我们就可以得到第二个路由器的地址。继续这个过程直至该数据报到达目的主机。但是目的主机哪怕接收到TTL值为1的IP数据报，也不会丢弃该数据报并产生一份超时 ICMP报文，这是因为数据报已经到达其最终目的地。那么我们该如何判断是否已经到达目的主机了呢？

Traceroute程序发送一份UDP数据报给目的主机，但它选择一个不可能的值作为UDP端口 号（大于 30 000 ），使目的主机的任何一个应用程序都不可能使用该端口。因为，当该数据报到达时，将使目的主机的UDP模块产生一份“端口不可达”错误（见  6.5节）的ICMP报文。 这样，Traceroute程序所要做的就是区分接收到的ICMP报文是超时还是端口不可达，以判断什么时候结束。

Traceroute程序必须可以为发送的数据报设置TTL字段。并非所有与TCP/IP接口的 程序都支持这项功能，同时并非所有的实现都支持这项能力，但目前大部分系统都支 持这项功能，并可以运行 Traceroute程序。这个程序界面通常要求用户具有超级用户权限，这意味着它可能需要特殊的权限以在你的主机上运行该程序。

8.3  局域网输出

现在已经做好运行 Traceroute程序并观察其输出的准备了。我们将使用从svr4到slip， 经路由器 bsdi的简单互联网（见内封面）。bsdi和slip之间是9600 b/s的SLIP链路。

输出的第 1个无标号行给出了目的主机名和其 IP地址，指出traceroute程序最大的TTL字段 值为 30。40字节的数据报包含20字节IP首部、8字节的 UDP首部和12字节的用户数据（12字节 的用户数据包含每发一个数据报就加 1的序列号，送出TTL的副本以及发送数据报的时间）。

输出的后面两行以TTL开始，接下来是主机或路由器名以及其 IP地址。对于每个TTL值，发 送3份数据报。每接收到一份ICMP报文，就计算并打印出往返时间。如果在5秒种内仍未收到3 份数据报的任意一份的响应，则打印一个星号，并发送下一份数据报。在上述输出结果中，TTL字段为1的前3份数据报的ICMP报文分别在20 ms 、10 ms 和10 ms 收到。TTL字段为2的3份数

据报的ICMP报文则在120 ms后收到。由于TTL字段为2到达最终目的主机，因此程序就此停止。

往返时间是由发送主机的traceroute程序计算的。它是指从 traceroute程序到该路 由器的总往返时间。如果我们对每段路径的时间感兴趣，可以用TTL字段为N+1所打印出来的 时间减去 TTL字段为N的时间。

图8-1给出了 tcpdump的运行输出结果。正如我们所预想的那样，第1个发往bsdi的探测数据报的往返时间是 20ms 、而后面两个数据报往返时间是 10 ms 的原因是发生了一次 ARP交换。tcpdump结果证实了确实是这种情况。

图8-1   从svr4到slip的traceroute程序示例的tcpdump输出结果

目的主机UDP端口号最开始设置为33435，且每发送一个数据报加 1。可以通过命令行选 项来改变开始的端口号。UDP数据报包含12个字节的用户数据，我们在前面 traceroute程序输出的 40字节数据报中已经对其进行了描述。

后面 tcpdump打印出了TT L 字段为 1 的IP 数据报的注释 [ttl 1]。当TT L值为0或1时， tcpdump打印出这条信息，以提示我们数据报中有些不太寻常之处。在这里可以预见到  TTL 值为 1；而在其他一些应用程序中，它可以警告我们数据报可能无法到达其最终目的主机。我们不可能看到路由器传送一个TTL值为0的数据报，除非发出该数据报的该路由器已经崩溃。

因为bsdi路由器将 TTL值减到 0，因此我们预计它将发回“传送超时”的ICMP报文。即 使这份被丢弃的 IP报文发送往 slip，路由器也会发回 ICMP报文。

有两种不同的ICMP“超时”报文（见6.2节的图6-3），它们的 ICMP报文中code字段不同。 图8-2给出了这种 ICMP差错报文的格式。

类型                         代码(0或1)                              检     验     和

未用(必须为0)

8字节

IP首部(包括选项)＋原始IP数据报中数据的前8字节

图8-2   ICMP超时报文

我们所讨论的ICMP报文是在 TTL值等于0时产生的，其code字段为0。 主机在组装分片时可能发生超时，这时，它将发送一份“组装报文超时”的                                                                                  ICMP报文

（我们将在 11.5节讨论分片和组装）。这种差错报文将 code字段置 1。

图8-1的第 9~14行对应于 TTL为2的3份数据报。这3份报文到达最终目的主机，并产生一份ICMP端口不可达报文。

计算出SLIP链路的往返时间是很有意义的，就象我们在7.2节中所举的Ping例子，将链路 值设置为1200b/s一样。发送出的UDP数据报共42个字节，包括12字节的数据、8字节UDP首 部、 20字节的IP首部以及（至少）2字节的SLIP帧（2.4节）。但是与 Ping不一样的是，返回的 数据报大小是变化的。从图 6-9可以看出，返回的 ICMP报文包含发生差错的数据报的 IP 首部 以及紧随该 IP首部的 8字节数据（在 traceroute程序中，即
UDP首部）。这样，总共就是 20

+ 8 + 20 + 8 + 2，即58字节。在数据速率为 960 b/s 的情况下，预计的RTT就是（42 + 58/960），即104 ms。这个值与 svr4上所估算出来的 110ms 是吻合的。

图8-1 中的源端口号（42804）看起来有些大。traceroute程序将其发送的UDP数据报 的源端口号设置为  U n i x 进程号与32 7 6 8 之间的逻辑或值。对于在同一台主机上多次运行traceroute程序的情况，每个进程都查看ICMP返回的UDP首部的源端口号，并且只处理那 些对自己发送应答的报文。

关于 traceroute程序，还有一些必须指出的事项。首先，并不能保证现在的路由也是将来所要采用的路由，甚至两份连续的IP数据报都可能采用不同的路由。如果在运行程序时，路由发生改变，就会观察到这种变化，这是因为对于一个给定的  TTL，如果其路由发生变化， traceroute程序将打印出新的 IP地址。

第二，不能保证 ICMP报文的路由与 traceroute程序发送的UDP数据报采用同一路由。 这表明所打印出来的往返时间可能并不能真正体现数据报发出和返回的时间差（如果  UDP数 据报从信源到路由器的时间是1秒，而ICMP报文用另一条路由返回信源用了 3秒时间，则打印 出来的往返时间是4秒）。

第三，返回的 ICMP报文中的信源 IP地址是 UDP数据报到达的路由器接口的 IP地址。这与 IP记录路由选项（ 7.3节）不同，记录的 IP地址指的是发送接口地址。由于每个定义的路由器 都有2个或更多的接口，因此，从A主机到B主机上运行traceroute程序和从 B主机到A主机 上运行 traceroute程序所得到的结果可能是不同的。事实上，如果我们从  slip主机到 svr4上运行 traceroute程序，其输出结果变成了：

这次打印出来的bsdi主机的 IP地址是 140.252.13.66，对应于 SLIP接口；而上次的地址是

140.252.13.35，是以太网接口地址。由于 traceroute程序同时也打印出与IP地址相关的主 机名，因而主机名也可能变化（在我们的例子中， bsdi上的两个接口都采用相同的名字）。

考虑图 8-3的情况。它给出了两个局域网通过一个路由器相连的情况。两个路由器通过一 个点对点的链路相连。如果我们在左边LAN的一个主机上运行traceroute程序，那么它将 发现路由器的 IP地址为 if1和if3。但在另一种情况下，就会发现打印出来的IP地址为if4和if2。 if2和if3有着同样的网络号，而另两个接口则有着不同的网络号。

网络1

网络2

路由器1                                            路由器2

网络3

图8-3    traceroute 程序打印出的接口标识

最后，在广域网情况下，如果 traceroute程序的输出是可读的域名形式，而不是 IP地址形式，那么会更好理解一些。但是由于 traceroute程序接收到 ICMP报文时，它所获得的 唯一信息就是IP地址，因此，在给定 IP地址的情况下，它做一个“反向域名查看”工作来获得域名。这就需要路由器或主机的管理员正确配置其反向域名查看功能（并非所有的情况下 都是如此）。我们将在 14.5节描述如何使用DNS将一个IP地址转换成域名。

8.4   广域网输出

前面所给出的小互联网的输出例子对于查看协议运行过程来说是足够了，但对于像全球互联网这样的大互联网来说，应用traceroute程序就需要一些更为实际的东西。

图8-4是从sun主机到 NIC (Network Information Center)的情况。

图8-4   从sun 主机到nic.ddn.mil 的traceroute 程序

由于运行的这个例子包含文本，非DDN站点（如，非军方站点）的NIC已经从

nic.ddn.mil转移到rs.internic.net，即新的“InterNIC”。

一旦数据报离开tuc.noao.edu网，它们就进入了telcom.arizona.edu网络。然后这些数据报进入 NASAScience Internet，nsn.nasa.gov。TTL字段为6和7的路由器位于JPL(Jet Propulsion Laboratory)上。TTL字段为11所输出的 sura.net网络位于 Southeastern Universities Research Association
Network上。TTL字段为12的域名GSI是GovernmentSystems, Inc., NIC的运营者。TTL字段为6的第2个RTT（590）几乎是其他两个RTT值（234和262）的两倍  。它表明 IP路由的动态变化。在发送主机和这个路由器之间发生了使该数据报速度变慢的事件。同样，

我们不能区分是发出的数据报还是返回的 ICMP差错报文被拦截。

TTL字段为 3的第1个RTT探测值（ 204）比 TTL字段为 2的第1个探测值（ 233）值还小。由

于每个打印出来的 RTT值是从发送主机到路由器的总时间，因此这种情况是可能发生的。图8-5的例子是从 sun主机到作者出版商之间的运行例子。

图8-5   从sun.tuc.noao.edu 主机到aw.com 的traceroute 程序

在这个例子中，数据报离开 telcom.arizona.edu网络后就进行了地区性的网络 westnet.net (TTL字段值为 6和7)。然后进行了由AdvancedNetwork & Services运营的 NSFNET主干网， t3.ans.net，（T3是对于主干网采用的45Mb/s 电话线的一般缩写。）最后的网络是alter.net，即aw.com与互联网的连接点。

8.5   IP源站选路选项

通常IP路由是动态的，即每个路由器都要判断数据报下面该转发到哪个路由器。应用程序对此不进行控制，而且通常也并不关心路由。它采用类似 Traceroute程序的工具来发现 实际的路由。

源站选路 (source routing)的思想是由发送者指定路由。它可以采用以下两种形式：

•  严格的源路由选择。发送端指明IP数据报所必须采用的确切路由。如果一个路由器发现源路由所指定的下一个路由器不在其直接连接的网络上，那么它就返回一个“源站路由失败”的 ICMP差错报文。

• 宽松的源站选路。发送端指明了一个数据报经过的IP地址清单，但是数据报在清单上指明的任意两个地址之间可以通过其他路由器。

Traceroute程序提供了一个查看源站选路的方法，我们可以在选项中指明源站路由，然后 检查其运行情况。

一些公开的 Traceroute程序源代码包中包含指明宽松的源站选路的补丁。但是在标 准版中通常并不包含此项。这些补丁的解释是“VanJacobson的原始Traceroute程序

（1988年春）支持该特性，但后来因为有人提出会使网关崩溃而将此功能去除。”对于

本章中所给出的例子，作者将这些补丁安装上去，并将它们设置成允许宽松的源站选路和严格的源站选路。

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

39字节

4字节          4字节           4字节                                           4字节

图8-6   IP首部源站路由选项的通用格式

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

对于宽松的源站选路来说， code字段的值是 0x83；而对于严格的源站选路，其值为 0x89。

len和ptr字段与 7.3节中所描述的一样。 源站路由选项的实际称呼为“源站及记录路由”（对于宽松的源站选路和严格的源站选路，

分别用 LSRR和SSRR表示），这是因为在数据报沿路由发送过程中，对 IP地址清单进行了更新。 下面是其运行过程：

•发送主机从应用程序接收源站路由清单，将第 1个表项去掉（它是数据报的最终目的地址），将剩余的项移到1个项中（如图8-6所示），并将原来的目的地址作为清单的最后一 项。指针仍然指向清单的第 1项（即，指针的值为4）。

• 每个处理数据报的路由器检查其是否为数据报的最终地址。如果不是，则正常转发数据报（在这种情况下，必须指明宽松源站选路，否则就不能接收到该数据报）。

• 如果该路由器是最终目的，且指针不大于路径的长度，那么(   1)由 ptr所指定的清单中的 下一个地址就是数据报的最终目的地址；( 2)由外出接口 (outgoinginterface) 相对应的 IP 地址取代刚才使用的源地址；( 3)指针加 4。

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

图8-7   IP源路由示例

在上图中，#表示指针字段，其值分别是4、8、12和16。长度字段恒为15（三个IP地址加 上三个字节首部）。可以看出，每一跳IP数据报中的目的地址都发生改变。

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

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

8.5.1   宽松的源站选路的traceroute程序示例

使用traceroute程序的 -g选项，可以为宽松的源站选路指明一些中间路由器。采用该选项可以最多指定8个中间路由器（其个数是8而不是9的原因是，所使用的编程接口要求最后的表目是目的主机）。

在图8-4中，去往 NIC，即nic.ddn.mil的路由经过 NASA Science Internet。在图8-8中， 我们通过指定路由器 enss142.UT.westnet.net (192.31.39.21) 作为中间路由器来强制数 据报通过 NSFNET：

图8-8   采用宽松源站选路通过NSFNET到达nic.ddn.mil 的traceroute 程序

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

前面我们说看起来有 16跳，这是因为将其输出结果与前面的通过 NSFNET（图 8-5）的示 例比较，发现在本例采用宽松源路由，选择了 3个路由器（这可能是因为路由器对源站选路数据报 产 生 I C M P 超 时 差 错 报 文 上存 在一 些 差 错 ）。 在 n e t b 和 bu 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 和en s s 1 4 2 . U T. w e s t . n e t 之间的 Westgate.Telcom.Arizona.edu和uu-ua.AZ.westnet.net两个路由器也丢失了。在这些丢失的路由器上可能发生了与接收到宽松的源站选路选项数据报有关的程序问题。实际上，当采用NSFNET时，信源和 NIC之间的路径有19跳。本章习题8.5继续对这些丢失路由器进行讨论。

同时本例也指出了另一个问题。在命令行，我们必须指定路由器enss142.UT.westnet.net的点分十进制 IP地址，而不能以其域名代替。这是因为，反向域名解析（14.5节中描述的通过IP

地址返回域名）将域名与 IP地址相关联，但是前向解析（即给出域名返回  IP地址）则无法做

到。在 DNS中，前向映射和反向映射是两个独立的文件，而并非所有的管理者都同时拥有这 两个文件。因此，在一个方向是工作正常而另一个方向却失败的情况并不少见。

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

将本图与图 8-4相比较，还可以得出一个结论，即路由器 nsn-FIX-pe.sura.net同时与NSFNET和NASA Science Internet相连。

8.5.2   严格的源站选路的traceroute程序示例

在作者的 traceroute程序版本中，- G选项与前面所描述的- g选项是完全一样的，不 过此时是严格的源站选路而不是宽松的源站选路。我们可以采用这个选项来观察在指明无效的严格的源站选路时其结果会是什么样的。从图8-5可以看出来，从作者的子网发往NSFNET 的数据报的正常路由器顺序是 netb，gateway，butch和gabby（为了便于查看，后面所 有的输出结果中，均省略了域名后缀 .tuc.noao.edu和.telcom.arizona.edu）。我们指定了一个严格源路由，使其试图将数据报从
gateway直接发送到 gabby，而省略了butch。我们可以猜测到其结果会是失败的，正如图 8-9所给出的结果。

图8-9   采用严格源站路由失败的traceroute程序

这里的关键是在于 TTL字段为 3的输出行中， RTT后面的 !S。这表明 traceroute程序接收到 ICMP“源站路由失败”的差错报文：即图 6-3中type字段为3，而code字段为5。TTL字段 为 3 的第二个 RT T 位置的星号表示未收到这次探查的应答信号。这与我们所猜想的一样，gateway不可能直接发送数据报给 gabby，这是因为它们之间没有直接的连接。

TTL字段为2和3的结果都来自于gateway，对于 TTL字段为2的应答来自gateway，是因 为gateway接收到TTL字段为1的数据报。在它查看到（无效的）严格的源站选路之前，就发现TTL已过期，因此发送回ICMP超时报文。TTL字段等于3的行，在进入gateway时其 TTL字段为2，因此，它查看严格的源站选路，发现它是无效的，因此发送回  ICMP源站选路失败 的差错报文。

图8-10给出了与本例相对应的 tcpdump输出结果。该输出结果是在 sun和netb之间的SLIP链路上遇到的。我们必须在 tcpdump中指定- v选项以显示出源站路由信息。这样，会 输出一些像数据报 ID这样我们并不需要的结果，我们在给出结果中将这些不需要的结果删除 掉。同样，用 SSRR表示“严格的源站及记录路由”。

首先注意到，sun所发送的每个 U D P 数据报的目的地址都是  netb，而不是目的主机

(westgate)。这一点可以用图 8-7的例子来解释。类似地，-  G选项所指定的另外两个路由器

（gateway和gabby）以及最终目 (westgate)成为第一跳的 SSRR选项。从这个输出结果中，还可以看出， traceroute程序所采用的定时时间（第 15行和 16行

之间的时间差）是5秒。

图8-10   失败的严格源站选路traceroute 程序的tcpdump 输出结果

8.5.3   宽松的源站选路traceroute程序的往返路由

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

这里的窍门就在于指定一个宽松的源站路由，该路由的目的端和宽松路径一样，但发送端为目的主机。例如，在 sun主机上，我们可以查看到发往以及来自 bruno.cs.colorado.edu的 结果如图8-11所示。

发出路径（TTL字段为1~11）的结果与返回路径（TTL字段为11~21）不同，这很好地说 明了在 Internet 上，选路可能是不对称的。

该输出同时还说明了我们在图8-3中所讨论的问题。比较TTL字段为2和19的输出结果：它 们都是路由器gateway.tuc.noao.edu，但两个 IP地址却是不同的。由于traceroute程

序以进入接口作为其标识，而我们从两条不同的方向经过该路由器，一条是发出路径（   TTL

字段为 2），另一条是返回路径（TTL字段为19），因此可以猜想到这个结果。通过比较TTL字 段为3和18、4和17的结果，可以看到同样的结果。

图8-11  显示非对称路径的traceroute 程序

8.6   小结

在一个 TCP/IP网络中， traceroute程序是不可缺少的工具。其操作很简单：开始时发送一个TTL字段为1的UDP数据报，然后将TTL字段每次加1，以确定路径中的每个路由器。 每个路由器在丢弃 UD P 数据报时都返回一个 I C M P 超时报文2，而最终目的主机则产生一个 ICMP端口不可达的报文。

我们给出了在 LAN和WAN上运行 traceroute程序的例子，并用它来考察IP源站选路。 我们用宽松的源站选路来检测发往目的主机的路由是否与从目的主机返回的路由一样。

习题

8.1  当IP将接收到的 TTL字段减1，发现它为 0时，将会发生什么结果？

8.2  traceroute程序是如何计算RTT的？将这种计算RTT的方法与 ping相比较。

8.3  （本习题与下一道习题是基于开发 traceroute程序过程中遇到的实际问题，它们来自于traceroute程序源代码注释）。假设源主机和目的主机之间有三个路由器（ R1、R2 和R3），而中间的路由器（R2）在进入 TTL字段为1时，将TTL字段减1，但却错误地将该 IP数据报发往下一个路由器。请描述会发生什么结果。在运行 traceroute程序时会看 到什么样的现象？

8.4 同样，假设源主机和目的主机之间有三个路由器。由于目的主机上存在错误，因此，它总是将进入TTL值作为外出ICMP报文的TTL值。请描述这将发生什么结果，你会看到什么现象。