8.3 局域网输出
最后更新于:2022-04-02 05:23:28
现在已经做好运行Traceroute程序并观察其输出的准备了。我们将使用从svr4到slip,经路由器bsdi的简单互联网(见内封面)。bsdi和slip之间是9600 b/s的SLIP链路。
![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-04-13_570df0eec7649.png)
输出的第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的探测数据报的往返时间是20 ms、而后面两个数据报往返时间是10 ms的原因是发生了一次ARP交换。tcpdump结果证实了确实是这种情况。
![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-04-13_570df0eedfded.png)
目的主机UDP端口号最开始设置为33435,且每发送一个数据报加1。可以通过命令行选项来改变开始的端口号。UDP数据报包含12个字节的用户数据,我们在前面traceroute程序输出的40字节数据报中已经对其进行了描述。
后面tcpdump打印出了TTL字段为1的IP数据报的注释[ttl 1]。当TTL值为0或1时,tcpdump打印出这条信息,以提示我们数据报中有些不太寻常之处。在这里可以预见到TTL值为1;而在其他一些应用程序中,它可以警告我们数据报可能无法到达其最终目的主机。我们不可能看到路由器传送一个TTL值为0的数据报,除非发出该数据报的该路由器已经崩溃。
因为bsdi路由器将TTL值减到0,因此我们预计它将发回“传送超时”的ICMP报文。即使这份被丢弃的IP报文发送往slip,路由器也会发回ICMP报文。
有两种不同的ICMP“超时”报文(见6.2节的图6-3),它们的ICMP报文中code字段不同。
图8-2给出了这种ICMP差错报文的格式。
![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-04-13_570df0ef091b2.png)
我们所讨论的ICMP报文是在TTL值等于0时产生的,其code字段为0。主机在组装分片时可能发生超时,这时,它将发送一份“组装报文超时”的ICMP报文(我们将在11.5节讨论分片和组装)。这种差错报文将code字段置1。
图8-1的第9 ~ 14行对应于TTL为2的3份数据报。这3份报文到达最终目的主机,并产生一份ICMP端口不可达报文。
计算出SLIP链路的往返时间是很有意义的,就象我们在7.2节中所举的Ping例子,将链路值设置为1200 b/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上所估算出来的110 ms是吻合的。
图8-1中的源端口号(42804)看起来有些大。traceroute程序将其发送的UDP数据报的源端口号设置为Unix进程号与32768之间的逻辑或值。对于在同一台主机上多次运行traceroute程序的情况,每个进程都查看ICMP返回的UDP首部的源端口号,并且只处理那些对自己发送应答的报文。
关于traceroute程序,还有一些必须指出的事项。首先,并不能保证现在的路由也是将来所要采用的路由,甚至两份连续的IP数据报都可能采用不同的路由。如果在运行程序时,路由发生改变,就会观察到这种变化,这是因为对于一个给定的TTL,如果其路由发生变化,traceroute程序将打印出新的IP地址。
第二,不能保证ICMP报文的路由与traceroute程序发送的UDP数据报采用同一路由。
这表明所打印出来的往返时间可能并不能真正体现数据报发出和返回的时间差(如果UDP数据报从信源到路由器的时间是1秒,而ICMP报文用另一条路由返回信源用了3秒时间,则打印出来的往返时间是4秒)。
第三,返回的ICMP报文中的信源IP地址是UDP数据报到达的路由器接口的IP地址。这与I P记录路由选项(7.3节)不同,记录的IP地址指的是发送接口地址。由于每个定义的路由器都有2个或更多的接口,因此,从A主机到B主机上运行traceroute程序和从B主机到A主机上运行traceroute程序所得到的结果可能是不同的。事实上,如果我们从slip主机到
svr4上运行traceroute程序,其输出结果变成了:
![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-04-13_570df0ef1ef17.png)
这次打印出来的bsdi主机的IP地址是140.252.13.66,对应于SLIP接口;而上次的地址是140.252.13.35,是以太网接口地址。由于tracerout e程序同时也打印出与IP地址相关的主机名,因而主机名也可能变化(在我们的例子中, bsdi上的两个接口都采用相同的名字)。
考虑图8-3的情况。它给出了两个局域网通过一个路由器相连的情况。两个路由器通过一个点对点的链路相连。如果我们在左边LAN的一个主机上运行traceroute程序,那么它将发现路由器的IP地址为if1和if3。但在另一种情况下,就会发现打印出来的IP地址为if4和if2。
if2和if3有着同样的网络号,而另两个接口则有着不同的网络号。
![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-04-13_570df0ef31a64.png)
最后,在广域网情况下,如果traceroute程序的输出是可读的域名形式,而不是IP地址形式,那么会更好理解一些。但是由于traceroute程序接收到ICMP报文时,它所获得的唯一信息就是IP地址,因此,在给定IP地址的情况下,它做一个“反向域名查看”工作来获得域名。这就需要路由器或主机的管理员正确配置其反向域名查看功能(并非所有的情况下
都是如此)。我们将在14.5节描述如何使用DNS将一个IP地址转换成域名。
';