TCP/IP详解，卷1：协议，第八章：Traceroute程序

小结：Traceroute程序可以让我们看到IP数据报从一台主机传到另一台主机所经过的路由。
其操作很简单：开始时发送一个TTL字段为1的UDP数据报，然后将TTL字段每次加1，以确定路径中的每个路由器。每个路由器在丢弃UDP数据报时都返回一个ICMP超时报文，而最终目的主机则产生一个ICMP端口不可达的报文。

习题：
1.当IP将接受到的TTL字段减1，发现它为0时，将会发生什么结果？
答：如果一个输入数据报的TTL为0，做减一操作然后测试会将把TTL设置为255，并且让数据报继续传送。尽管一个路由器永远不会收到一个TTL为0的数据报，但这种情况确实会发生。

2.transerout程序是如何计算RTT的？将这种计算RTT的方法与ping相比较。
答：我们注意到traceroute在UDP数据报的数据部分存储了12个字节，其中包含了数据报发送的时间。然而，从图6－9可以看出ICMP只返回了出错的IP数据报的头8个字节，世纪上这事8个字节的UDP首部。因此，ICMP的差错报文没有返回traceroute存储的时间值。traceroute保存了它发送分组的时间，当收到一个ICMP应答时，取出当时的时间，把两个值相减就可以得到RTT。
回忆一下第7章中，ping在输出的ICMP回显请求中存储了时间，这个值被服务器回显了回来。这样即使分组返回时失序，ping也能打印出正确的RTT。

3.（本习题与下一道习题是基于traceroute程序过程中遇到的实际问题，它们来自于traceroute程序源代码注释）。假设源主机和目的主机之间有三个路由器（R1、R2和R3），而中间的路由器（R2）在进入TTL字段为1时，将TTL字段减1，但却错误地将该IP数据报发往下一个路由器。请描述会发生什么结果。在运行traceroute程序时会看到什么样的现象？
答：第1行输出是正确的，并且标识了R1，下一个探测分组启动时将TTL置为2，并且这个值被R1减为1。当R2收到这个分组时，把TTL从1减为0，但是错误地将它传递给了R3。R3看见进入的TTL是0就将超时的分组发送回来。这就意味着第2行输出（TTL为2）标识了R3，而不是R2。第3行输出正确地标识了R3。这个错误所表现出来的线索就是两个连续的输出行标识了同一个路由器。

4.同样，假设源主机和目的主机之间有三个路由器。由于目的主机上存在错误，因此，它总是将进入TTL值作为外出ICMP报文的TTL值。请描述这将发生什么结果，你会看到什么现象。
答：在这种情况下，TTL为1标识了R1，TTL为2标识了R2，TTL为3标识了R3，但是当TTL为4时，UDP数据报到达了目的地，其输入的TTL为1。ICMP端口不可达报文生成了，但它的TTL是1（错误地从进入的TTL复制而来）。这个ICMP报文到了R3，在那儿TTL被减1，报文被丢弃。没有生成一个ICMP超时报文，因为被丢弃的数据报时一个ICMP差错报文（端口不可达）。类似的现象也出现在TTL为5的探测分组，但这次输出的端口不可达报文以TTL2开始（进入的TTL），这个报文被传给R2，在那儿被丢弃。对应于TTL为6探测分组的端口不可达报文被传递给R1，在那儿被丢弃。最后，对应于TTL为7探测分组的端口不可达报文被送回了原地，到达时它的TTL为1（traceroute认为一个TTL为0或1的到达ICMP报文是有问题的，因此他在RTT后面打印了一个惊叹号）。总之，TTL为1、2和3的行正确的标识了R1、R2和R3，接下来的三行每个都包含三个超时，再接下来的TTL为7的行标识了目的地。

5.在图8－8运行例子中，我们可以在sun和netb之间的SLIP链路上运行tcpdump程序。如果指定－v 选项，就可以看到返回ICMP报文的TTL值。这样，我们可以看到进入netb、butch、Gabby和enssl142.UT.westnet.net的TTL值分别为255、253、252和249。这是否为我们判断是否存在丢失路由器提供了额外的信息？
答：它表明这些路由器都将一个ICMP报文的输出TTL设置为255，这种现象很常见。从netb输入的255的TTL值是我们想要的，而从butch输入的253的TTL值表明在butch和netb之间可能有一个未察觉的路由器。否则，在这个点上我们应该看到一个TTL值为254的输入报文。类似的，我们希望看到一个值为252而不是249的、来自enss142.UT.westnet.net的报文。这表明这些未察觉的路由器没有正确的处理向外输出的UDP数据报，但它们都对返回的ICMP报文正确的进行了TTL减1操作。
我们必须在查看输入的TTL时非常小心，因为有时候一个和我们想要的不同的值可能是由于返回的ICMP报文采用了一条于输出UDP数据报不同的路径。但是，在这个例子中证实了我们所怀疑的－当使用松 源路由选项时，确实存在traceroute没有发现的未察觉的路由器。

7.比较ping和traceroute程序在处理同一台主机上客户的多个实例的不同点。
答：ping的客户把ICMP回显请求报文（图7－1）的标识符字段设置为它的进程ID。
ICMP回显应答报文包含同样值的标识符字段。每个客户都要查看这个返回的标识符字段，并且只处理那些它发送过的报文。
traceroute客户将它的UDP源端口号设置为它的进程ID和32768的逻辑或。因为返回的ICMP报文总是包含产生错误的IP数据报的前8个字节（图6－9），这8个字节包括了完整的UDP首部，所以这个源端口号在ICMP差错报文中被返回。

8.比较ping和traceroute程序在计算往返时间上的不同点。
答：ping客户将ICMP回显请求报文的可选数据部分设置为分组发送的时间。这个可选的数据必须在ICMP回显应答中返回。这样使得即使分组返回时失序，客户也能计算出精确的回环时间。
tranceroute客户不能这样做，因为在ICMP差错报文中返回的只是UDP首部（图6－9）没有UDP数据。因此，traceroute必须记住它发送一个请求的时间，等待应答，然后计算两者的时间差。
这里显示了ping和traceroute的另一个不同点：ping每秒发送一个分组。而不管是否收到任何应答；traceroute发送一个请求，然后在发送下一个请求前等待一个应答或者一个超时。

9.我们已经说过，traceroute程序选取开始UDP目的主机端口号为33453，每发送一个数据报将此数加1。在1.9节中，我们说过暂时端口号通常是1024～5000之间的值，因此traceroute程序的目的主机端口号不可能是目的主机上所使用的端口号。在Solaris2.2系统中的情况也是如此吗？（提示：查看E.4节）
答：因为默认情况下Solaris2.2从32768开始使用临时的UDP端口，所以目的主机上的目的端口已经被使用的机会更大。