解释
Traceroute 概述了 IP 数据包到达 Internet 主机的路径，方法是启动具有小 TTL 的 UDP 探测数据包，然后侦听来自网关的 ICMP“超时”回复。
以 1 的 TTL 开始探测并增加 1，直到我们获得 ICMP“端口无法访问”（这意味着数据包到达其目的地）或者达到最大尝试次数，默认为 30 跳，可以更改为 -米旗。
当 traceroute 执行时，它会在每个 TTL 设置下发送三个探测，然后向控制台打印一行显示 TTL、网关地址和每个探测的往返时间。
如果探测应答来自不同的网关，则打印每个响应系统的地址。
如果 traceroute 在五秒内没有收到响应（用 -w 标志更改），它会为该探测打印一个星号。
为了防止 UDP 探测包处理使目标主机不堪重负，traceroute 将目标端口设置为设备不太可能使用的值。
如果目标上的网络或者服务使用该端口，请使用 -p 标志更改值。
Traceroute 语法和开关
Ubuntu 中的跟踪路由语法。
Traceroute 遵循以下通用语法：
traceroute [ -dFInrvx ] [ -f first_ttl ] [ -g gateway ] [ -i iface ] [ -m max_ttl ] [ -p port ] [ -q nqueries ] [ -s src_addr ] [ -t tos ] [ -w waittime ] [ -z pausemsecs ] host [ packetlen ]
我们可以通过指定一个或者多个可选开关来更改命令的性能或者输出。
| 开关 | 解释 |
|---|---|
| -f | 设置第一个传出探测数据包中使用的初始生存时间。 |
| -F | 设置“不要碎片”位。 |
| -d | 启用套接字级调试。 |
| -g | 指定松散源路由网关（最多 8 个）。 |
| -i | 指定网络接口以获取传出探测数据包的源 IP 地址。这通常仅在多宿主主机上有用。 （另一种方法请参见 -s 标志。） |
| -I | 使用 ICMP ECHO 而不是 UDP 数据报。 |
| -m | 设置传出探测数据包中使用的最大生存时间（最大跳数）。默认值为 30 跳（与 TCP 连接使用的默认值相同）。 |
| -n | 以数字而非符号和数字方式打印跃点地址（为路径上找到的每个网关保存名称服务器地址到名称查找）。 |
| -p | 设置探测中使用的基本 UDP 端口号（默认为 33434）。 Traceroute 希望目标主机上的 base + nhops - 1 UDP 端口上没有任何内容侦听（因此将返回 ICMP PORT_UNREACHABLE 消息以终止路由跟踪）。如果某些东西正在侦听默认范围内的端口，则此选项可用于选择未使用的端口范围。 |
| -r | 绕过正常的路由表并直接发送到连接网络上的主机。如果主机不在直接连接的网络上，则返回错误。此选项可用于通过没有路由通过的接口 ping 本地主机（例如，在接口被 routed(8C) 丢弃后）。 |
| -s | 使用以下 IP 地址（通常以 IP 号而不是主机名的形式给出）作为传出探测数据包的源地址。在多宿主主机（具有多个 IP 地址的主机）上，此选项可用于强制源地址与发送探测数据包的接口的 IP 地址不同。如果 IP 地址不是本机的接口地址之一，则返回错误并且不发送任何内容。 （请参阅 -i 标志以获取另一种执行此操作的方法。） |
| -t | 将探测数据包中的服务类型设置为以下值（默认为零）。该值必须是 0 到 255 范围内的十进制整数。此选项可用于查看不同类型的服务是否会导致不同的路径。 （如果您运行的不是 4.4bsd，这可能是学术性的，因为像 telnet 和 ftp 这样的普通网络服务不允许您控制 TOS。）并非 TOS 的所有值都是合法或者有意义的——请参阅 IP 规范以了解定义。有用的值可能是“-t 16”（低延迟）和“-t 8”（高吞吐量）。 |
| -v | 详细输出。列出了除 TIME_EXCEEDED 和 UNREACHABLEs 之外的收到的 ICMP 数据包。 |
| -w | 设置等待探测响应的时间（以秒为单位）（默认为 5 秒）。 |
| -x | 切换 IP 校验和。通常，这会阻止 traceroute 计算 IP 校验和。在某些情况下，操作系统可以覆盖部分传出数据包，但不会重新计算校验和；因此，在某些情况下，默认值是不计算校验和，而使用 -x 会导致计算它们。请注意，在使用 ICMP ECHO 探测 (-I) 时，最后一跳通常需要校验和，因此在使用 ICMP 时总是会计算它们。 |
| -z | 设置在探测之间暂停的时间（以毫秒为单位）（默认为 0）。某些系统，例如 Solaris 和 Cisco 的路由器，会限制 icmp 消息的速率。与此一起使用的一个很好的值是 500（例如，1/2 秒）。 |
跟踪路由traceroute的工作原理
traceroute 命令映射信息包从源到目的地的旅程。
traceroute 的一种用途是在整个网络中发生数据丢失时进行定位，这可能意味着某个节点已关闭。
由于记录中的每个跃点都反映了原始 PC 和预期目标之间的新服务器或者路由器，因此查看 traceroute 扫描的结果可以确定可能对网络流量产生不利影响的慢点。
traceroute示例
[yak 71]% traceroute nis.nsf.net. traceroute to nis.nsf.net (35.1.1.48), 30 hops max, 38 byte packet 1 helios.ee.lbl.gov (128.3.112.1) 19 ms 19 ms 0 ms 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 39 ms 5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 39 ms 39 ms 39 ms 6 128.32.197.4 (128.32.197.4) 40 ms 59 ms 59 ms 7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 59 ms 8 129.140.70.13 (129.140.70.13) 99 ms 99 ms 80 ms 9 129.140.71.6 (129.140.71.6) 139 ms 239 ms 319 ms 10 129.140.81.7 (129.140.81.7) 220 ms 199 ms 199 ms 11 nic.merit.edu (35.1.1.48) 239 ms 239 ms 239 ms
第二行和第三行是一样的。
该结果与第二跳系统 lbl-csam.arpa 上的错误内核有关，该内核转发具有零 TTL 的数据包（4.3 BSD 的分布式版本中的错误）。
由于 NSFNet (129.140) 不为其 NSS 提供地址到名称的转换，我们必须猜测数据包在跨国的路径。
静默网关示例
[yak 72]% traceroute allspice.lcs.mit.edu. traceroute to allspice.lcs.mit.edu (18.26.0.115), 30 hops max 1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 19 ms 19 ms 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 19 ms 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 19 ms 39 ms 39 ms 5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 20 ms 39 ms 39 ms 6 128.32.197.4 (128.32.197.4) 59 ms 119 ms 39 ms 7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 39 ms 8 129.140.70.13 (129.140.70.13) 80 ms 79 ms 99 ms 9 129.140.71.6 (129.140.71.6) 139 ms 139 ms 159 ms 10 129.140.81.7 (129.140.81.7) 199 ms 180 ms 300 ms 11 129.140.72.17 (129.140.72.17) 300 ms 239 ms 239 ms 12 * * * 13 128.121.54.72 (128.121.54.72) 259 ms 499 ms 279 ms 14 * * * 15 * * * 16 * * * 17 * * * 18 ALLSPICE.LCS.MIT.EDU (18.26.0.115) 339 ms 279 ms 279 ms
请注意，距离 12、14、15、16 和 17 跳的网关或者不发送 ICMP“超时”消息，或者发送的 TTL 太小而无法到达我们。
第 14 行到第 17 行正在运行不发送“超时”消息的 MIT C 网关代码。
上例中的静默网关 12 可能是 4.[23]BSD 网络代码及其衍生版本中的错误的结果：运行 4.3 代码及更早版本的机器使用原始数据报中保留的任何 TTL 发送无法访问的消息。
对于网关，剩余的 TTL 为零，ICMP“超时”保证不会返回给我们。
目标系统静默网关示例
当这个错误出现在目标系统上时，它的行为稍微有趣一些：
1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 39 ms 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 39 ms 19 ms 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 19 ms 5 ccn-nerif35.Berkeley.EDU (128.32.168.35) 39 ms 39 ms 39 ms 6 csgw.Berkeley.EDU (128.32.133.254) 39 ms 59 ms 39 ms 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 rip.Berkeley.EDU (128.32.131.22) 59 ms ! 39 ms ! 39 ms !
请注意，存在 12 个“网关”（其中 13 个是最终目的地），并且缺少其中的后半部分。
真正发生的事情是名为 rip（运行 Sun OS 3.5 的 Sun-3）的服务器使用来自我们到达的数据报的 TTL 作为其 ICMP 回复中的 TTL。
因此，回复将在返回路径上超时（不会向任何人发送通知，因为不会为 ICMP 发送 ICMP），直到我们使用至少两倍于路径长度的 TTL 进行探测——换句话说，rip 实际上只有 7跳远。
返回的 TTL 为 1 的回复是此问题存在的线索。
Traceroute 打印一个 !如果 TTL 小于或者等于 1，则在时间之后。
由于供应商提供了很多过时的（DEC 的 Ultrix、Sun 3.x）或者非标准 (HPUX) 软件，预计会经常看到此问题并小心选择探针的目标主机。
时间之后的其他可能的注释是 !H 、!N 或者 !P（主机、网络或者协议不可达）、!S（源路由失败）、!F（需要分段——显示 RFC1191 路径 MTU 发现值）、 !X（管理上禁止通信）、!V（违反主机优先级）、!C（有效的优先级截止）或者 ! （ICMP 不可达代码）。
这些代码由 RFC1812 定义，它取代了 RFC1716.
如果几乎所有的探测都导致某种无法访问的主机，traceroute 将放弃并退出。
该程序旨在用于网络测试、测量和管理。
它应该主要用于手动故障隔离。
由于它可能对网络造成负载，因此在正常操作期间或者从自动化脚本中使用 traceroute 是不明智的。
使用 Traceroute 进行故障排除
评估网络流量遵循的特定路由（或者找到丢弃数据包的恶意网关）提出了几个故障排除挑战。
Traceroute 使用 IP 协议的生存时间字段来请求来自沿路径到目标主机的每个网关的 ICMP TIME_EXCEEDED 响应。
执行 traceroute 命令时必须包含的唯一参数是目标的主机名或者 IP 地址。
使用 traceroute 跟踪数据包的去向