traceroute命令在Linux中用于映射信息包从其源到目的地的过程。 traceroute的一个用途是定位整个网络中何时发生数据丢失，这可能表示节点已关闭。
由于记录中的每一跳都反映了原始PC与目标目标之间的新服务器或路由器，因此查看traceroute扫描结果还可以识别可能对网络流量产生负面影响的慢点。
这个怎么运作
评估网络流量遵循的特定路由（或找到丢弃数据包的恶意网关）会带来一些故障排除挑战。 Traceroute使用IP协议 生活的时间 字段，用于沿着到目标主机的路径从每个网关请求ICMP TIME_EXCEEDED响应。
执行traceroute命令时必须包含的唯一参数是目标的主机名或IP地址。
Traceroute语法和开关
跟踪路由 -dFInrvx -F first_ttl -G 网关 -一世 我面对 -m max_ttl -p 港口 -q nqueries -s SRC_ADDR -t TOS -w 等待时间 -z pausemsecs 主办 packetlen
虽然以上是为了在命令行中工作而必须写出traceroute命令的方法，但是可以通过指定一个或多个可选开关来更改命令的性能或输出。
- -F： 设置第一个传出探测包中使用的初始生存时间。
- -F： 设置“不分段”位。
- -d： 启用套接字级调试。
- -G： 指定松散的源路由网关（最多8个）。
- -一世： 指定网络接口以获取传出探测包的源IP地址。这通常仅适用于多宿主主机。 （见-s 标志为另一种方式这样做。）
- -一世： 使用ICMP ECHO而不是UDP数据报。
- -m： 设置传出探测包中使用的最大生存时间（最大跳数）。默认值为30跳（与TCP连接相同的默认值）。
- -n： 以数字方式而不是符号和数字方式打印跳跃地址（为路径上找到的每个网关保存名称服务器地址到名称查找）。
- -p： 设置探针中使用的基本UDP端口号（默认为33434）。 Traceroute希望没有任何东西在监听UDP端口 基础 至 base + nhops - 1 在目标主机上（因此将返回ICMP PORT_UNREACHABLE消息以终止路由跟踪）。如果某些内容正在侦听默认范围内的端口，则此选项可用于选择未使用的端口范围。
- -r： 绕过正常的路由表并直接发送到连接网络上的主机。如果主机不在直接连接的网络上，则会返回错误。此选项可用于通过没有路由的接口ping本地主机（例如，在接口被删除之后） 路由 （8C））。
- -s： 使用以下IP地址（通常以IP号码，而不是主机名）作为传出探测数据包中的源地址。在多宿主主机（具有多个IP地址的主机）上，此选项可用于强制源地址不是探测数据包发送的接口的IP地址。如果IP地址不是本机的接口地址之一，则返回错误并且不发送任何内容。 （见-一世 标志为另一种方式这样做。）
- -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探针时，最后一跳通常需要校验和（-一世），因此在使用ICMP时总是计算它们。
- -z： 设置探针之间暂停的时间（以毫秒为单位）（默认为0）。某些系统（如Solaris和Cisco的路由器）限制icmp消息。与此一起使用的良好值是500（例如，1/2秒）。
解释结果
Traceroute通过启动具有小TTL（生存时间）的UDP探测包然后侦听来自网关的ICMP“超过时间”回复来概述IP数据包跟随到Internet主机的路径。我们以1的TTL开始我们的探测并且增加1直到我们得到ICMP“端口不可达”（这意味着数据包到达其目的地）或达到最大尝试值，默认为30跳并且可以随之改变该-m 旗。
执行traceroute时，它会在每个TTL设置发送三个探测器，然后在控制台上打印一行显示TTL，网关地址和每个探测的往返时间。如果探测答案来自不同的网关，则打印每个响应系统的地址。如果在五秒钟的超时间隔内没有响应（用-w flag），为该探针打印一个星号。
为了防止目标主机被UDP探测包处理所淹没，目标端口被设置为该设备不太可能使用的值。如果目标中的网络或服务使用该端口，请使用该更改值-p 旗。
示例使用和输出将返回类似于此示例的结果：
yak 71％traceroute nis.nsf.net。 traceroute到nis.nsf.net（35.1.1.48），最大30跳，38字节包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女士 ！ 39毫秒！ 39毫秒！
请注意，有12个“网关”（13个是最终目的地），后半部分丢失。真正发生的是服务器命名 RIP （运行Sun OS 3.5的Sun-3）正在使用我们到达的数据报中的TTL作为其ICMP回复中的TTL。因此，回复将在返回路径上超时（没有通知发送给任何人，因为ICMP没有发送给ICMP），直到我们使用至少两倍路径长度的TTL进行探测 - 换句话说，rip实际上只有七个跳了一下。
以TTL为1返回的回复是存在此问题的线索。 Traceroute打印出一个“！”在TTL小于或等于1的时间之后。由于供应商提供了大量过时的（DEC的Ultrix，Sun 3.x）或非标准（HPUX）软件，因此希望经常看到这个问题，并注意选择目标探测主机。
其他可能的注释在时间之后！H, N！， 要么P！ （主机，网络或协议无法访问），！小号 （源路由失败），！F- （需要分片 - 显示RFC1191路径MTU发现值），！X （行政禁止通信），！V （主机优先违规），！C （优先截止有效），或! （ICMP无法访问的代码）。这些代码由RFC1812定义，取代RFC1716。如果几乎所有的探测器都会导致某种无法访问的主机，则traceroute会放弃并退出。
该程序旨在用于网络测试，测量和管理。它主要用于手动故障隔离。由于它可能会对网络造成负载，因此在正常操作或自动脚本中使用traceroute是不明智的。
