tcp/ip详解笔记（第8章 Traceroute）

布满荆棘的人生 2022-07-14 07:44 151阅读 0赞

概述：

为了了解计算机网络，我开始刷《tcp/ip详解》这部圣经，以此博客来记录阅读过程中的一些感悟，和习题的解答（主要），很可惜是从第八章开始，如果有机会，慢慢把前七章补完。

习题：

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

我总觉的自己看书的理解能力有问题，而且还较真，我所理解的这个问题的原意思是，IP收到，就是路由器收到了一个TTL为1的字段，然后TTL减1，TTL变为0，问接下来会发生什么。

![Center][]

这是原版的说法，他的意思应该是收到的时候就是TTL为0。

答案给的解释是，收到TTL字段为0的数据报，做减1测试后会把TTL设置为255，并且让数据报继续传输，正常情况路由器永远不会手奥TTL为0的数据报。

这个问题我还是不太理解，网上很多人都认为是丢弃这个数据包并且发送一个icmp给源端，我觉得也有道理。

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

traceroute是将发送时间记录在发送时的udp报文内，因为traceroute的udp报文包含20字节的ip首部，8字节的udp首部，12字节用户数据（序列号，TTL，发送时间），这时计算时间，只要当回送icmp端口不可达报文到达源端的时候将当时的时间减去udp报文中的发送时间就可以计算了

ping是将发送时间记录在icmp报文中做到的。等icmp回应报文到源端后，再由当前时间减去icmp报文中的时间就计算出了RTT。

8.3假设源主机和目的主机之间有三个路由器（R1,R2和R3）而中间的路由器（R2）在进入TTL字段为1时，将TTL字段减1，但却错误地将该ip数据报发往下一个路由。请描述会发生什么结果。在运行traceroute程序时会看到什么样的现象？

![Center 1][]

发往R1的ttl为1的udp报文正常，且回发的icmp端口不可达报文正常，所以输出的第行正常

发往R2的ttl为2的报文到达R2时，ttl变为1，将其减1后，又将ttl为0的报文给了R3，也就是说，R3收到了源端ip为左主机，目的ip为R3且ttl为0的udp报文，这个报文所指向的端口号又不存在，所以R3回送了一个端口不可达报文（不要被8.1误导了），所以第二行输出的是标记R3路由的行。

发往R3的tll为3的报文，整个过程没有路由器出错，所以结果正常着呢。

最后出现的结果就是第一行是标记R1，后两行都为标记R3的行。

8.4

8.5

netb返回的icmp报文ttl为255很正常，因为sun主机与netb是靠着slip链路链接的，但是bunch为253就不对了，sun与他之间明显应该是有两个路由，才会出现253这样的TTL，也就是说，输出的结果丢了一个路由，之后的意思和这个一样，不再熬述。

分析原因，可能是丢失的路由出错了，但是接收icmp的路由又正确的把ttl减去了。还有一种可能就是源端发送udp报文的路径和，路由器发送icmp报文的路径是不同的，这也非常的可能。

8.7

ping程序是将icmp回显请求报文的标识符字段设置成pid，icmp回显应答报文包含同样值的标识符字段。traceroute直接发送udp报文，也就是使用了端口号来标记。

8.8

ping程序将发送的时间记忆在icmp报文中，也就不需要ping程序等待来计算往返时间了。

traceroute返回的icmp报文中只有20字节的ip首部，8字节的udp首部（只包括了源端口和目的端口），所以无法记录时间，这时就需要traceroute程序来记忆时间了。

[Center]: /images/20220714/ee0c50e6271c43f7a5614a59ce42ff32.png
[Center 1]: /images/20220714/fe40400c45dc43c9ac4c26cb386de952.png

还没有评论，来说两句吧...