概述：
为了了解计算机网络，我开始刷《tcp/ip详解》这部圣经，以此博客来记录阅读过程中的一些感悟，和习题的解答（主要），很可惜是从第八章开始，如果有机会，慢慢把前七章补完。
习题：
8.1当IP将收到的TTL字段减1，发现它为0时，将会发生什么结果。
我总觉的自己看书的理解能力有问题，而且还较真，我所理解的这个问题的原意思是，IP收到，就是路由器收到了一个TTL为1的字段，然后TTL减1，TTL变为0，问接下来会发生什么。
这是原版的说法，他的意思应该是收到的时候就是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程序时会看到什么样的现象？
发往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程序来记忆时间了。
