有几个细节：
1.局域网的路由是相对稳定的，因此用traceroute打印出来的响应时间相差不大 。而假如用来跟踪广域网的路由，由于广域网的路由信息是动态变化的，而且并不能确定是发送路径耗时还是返回路径耗时较多，因此时间与路由信息只能做为参考 。
2.TTL 的选择 。假如把TTL设得足够大，是不是一定可以打印出所有路由，比如一个数据包经过300个路由器才到达目的端 。当然在现有网络环境下不太可能出现要经过这么多路由的情况 。而TTL信息在IP数据报中只有一个字节，也就是最多能设定到255（256以后又重新从0开始） 。设定这个信息的目的，就是防止一些僵而不化的数据报在网络漫上无目的的游荡而不消失 。数据报每经过一个路由器，路由器就把TTL减1（或在该路由器被处理前经过的秒数），总有一个时候会被减到1，然后路由器会把它丢弃 。
3.traceroute的是以收到“端口不可达”为标志来结束的 。前提是发出的UDP数据报中要求的端口在目的主机上没有进程在使用 。而假如目的主机上正好有进程在使用这个端口，接收这个包并按正常方式处理，这样traceroute就收不到“端口不可达”的错误了 。为了避免出现这种情况，UDP数据报的端口很高（书中的实现是初始值33435，以后每发送一次再加1，端口号最大可以到65535） 。普通程序一般不会使用这些高端口 。问题是假如真的存在这种情况时，traceroute会怎么处理？而似乎Solaris系统可能会使用高端口，这时又怎么样 。
4. 在发送过程中，要经过许多的路由，到达目的主机前，可能还要经过网关，防火墙，以及其他例如IDS的过滤，发送包能不能到达目的主机还是个问题 。而即使到达了，发送的ICMP信息能不能返回也是个问题 。因为沿途经过的关卡太多，遇上黑洞路由器，不转发这些信息的话，那就一点办法也没有了 。
书中还提到原来的traceroute里有一个选项，可以指定数据包经过的路由器 。假如是宽路由，则只要经过指定的路由即可 。而假如是严路由，则必须按指定的顺序经过指定的路由器 。因为这个选项可能导致某个固定的路由处理信息太多，在公布的源码里已经取消了 。但是可以找到补丁，还是可以用起来的 。从比较的结果看，似乎指定路由器反而不如让路由器采用默认路由处理得快 。而对于严路由来说，要成功就要更难一些，因为并不一定你指定的路由器正好有条目到接下来的路由器 。
这一章的习题比较复杂，找不到网络环境可以实验，而照原理分析看不出究竟 。源码没有，假如真的有，现在的水平估计也看不出什么东西来 。先不求甚解吧，看下一遍的时候可能就知道了 。
推荐阅读
- 利用H.323协议实现视讯业务的扩展
- 图 新手入门：了解网络应用与网络协议
- 四 透析ICMP协议: 应用篇ping(RAW Socket)
- 全面分享:网络协议标准规范大全一
- 全面分享:网络协议标准规范大全二
- 二 透析ICMP协议: Windows Socket简介
- 三 透析ICMP协议: 应用篇ping(ICMP.dll)
- 图 分享关于EIGRP协议几个问题分析
- 上海贝尔阿尔卡特时间协议仪
- 西门子楼宇与康宁光缆系统签署合作协议