我看到的几乎所有帖子都推荐以下文档：

使用 Traceroute 进行（正确）故障排除的实用指南

Traceroute 你能不能把你送进兔子洞，我会读整篇文章，事实上，我要再读一遍。

小心！

我强烈推荐Dareuja发布的Traceroute 指南。没有更完整的单一资源来解释结果（至少我知道）。

以下是我多年来从正确阅读输出中学到的一些技巧。如果您不熟悉 tracreaoute 的工作原理，则此线程中有一些很好的信息。

1. 了解流向路由器的流量与通过路由器的流量之间的区别

traceroute 中的每一行表示该特定路由器使用 TTL Expired 消息响应发起客户端所花费的时间（以毫秒 (ms) 为单位）。每跳通常会测试 3 次，因此您会得到 3 个不同的值。

链中的第 10 个路由器通过链中的第 9 个路由器接收到数据包。通常，TTL 过期响应在返回发起客户端的途中通过链中的第 9 个路由器传回（并非总是如此，但通常如此）。

无论哪种方式，在这个例子中，链中的第 10 个路由器正在处理发送给它的数据包（有点，我稍后会解释）。当链中的第 9 个路由器正在处理通过它发送的数据包时。

 9    97 ms    96 ms     *     be2113.ccr42.atl01.atlas.cogentco.com [154.54.24.222] 
10   142 ms   112 ms   114 ms  be2690.ccr22.iah01.atlas.cogentco.com [154.54.28.130] 

许多人查看您发布的输出以及第 9 跳第 3 次尝试中错过的响应，并声称第 9 跳存在问题。

但是没有，因为接下来发送的三个数据包（到第 10 跳）都通过第 9 跳，并且它们到达那里就好了。所以在路由器 9 处丢失响应没有问题。

但为什么错过了回应？好问题......以及下一个提示的主题：

2. 一个错过的回应通常不是值得关注的理由

如今，路由器供应商花费数百万美元来改进他们的硬件和软件，使路由器能够以近线速度接收和转发数据包。

当一个数据包通过这样的路由器时，它正在通过一个专门为超快速处理而构建的专门设计的通道。这通常称为数据平面。

当路由器必须对数据包做一些特殊的事情时，即简单地转发它之外，它必须传递到路由器的 CPU（或大脑，如果你愿意的话）。这种类型的流量必须由路由器的控制平面处理。

在所有情况下，路由器将更加努力地通过其数据平面传送数据包，就像处理发送到其控制平面的数据包一样。

因此，在 Traceroute 尝试时可能发生的情况是，该特定路由器可能正在处理通过它的数百万个其他数据包，并且不会打扰该过程以处理去往它的数据包。因此，数据包被简单地丢弃，并在跟踪路由中显示为丢失的跃点 *。

那么在阅读 traceroute 时你应该关心什么？好问题……继续阅读。

3.在典型的traceroute中你应该关心什么

Traceroute 最适合检测和确定端到端路径中存在延迟的位置。但延迟的单一峰值通常没有任何意义。例如：

 1     2 ms     2 ms     4 ms  gw.wireless.iqsalford.quintain.lan [10.222.208.1] 
 2    14 ms     8 ms     8 ms  gw-vlan1577.man-xmr.tcw.ask4.net [78.109.190.225] 
 3     6 ms     2 ms     3 ms  man-xmr-edge1-r1.tcw.ask4.net [81.23.63.237] 

您可以查看 hop 2 的第一个结果，看到跳转到 14ms 并认为这是一个很大的比例跳转。但是，如果您查看第 3 跳的响应时间，则会看到 6 毫秒、2 毫秒和 3 毫秒。好吧，这 3 次尝试中的每一次都在第 2 跳通过路由器，如果能够到达第 3 跳、第 1 跳和第 2 跳，并在 2/3/6 毫秒内全部返回，那么您就没有问题。

（注意，这不是最好的例子，因为 14ms 仍然很快，但它是提供的输出中最好的例子）。

您想要关注的是，如果您看到特定跃点的延迟持续增加，其中响应时间在跟踪路由的其余部分增加。

然而，有时延迟增加是意料之中的，而且完全正常。特别是当您穿越长 WAN 链接时。例如：

 6     8 ms    11 ms     8 ms  be2871.ccr42.lon13.atlas.cogentco.com [154.54.58.185] 
 7   148 ms    83 ms    88 ms  be2490.ccr42.jfk02.atlas.cogentco.com [154.54.42.85] 

在这里，您将从 LON 跳到 JFK，跨越大西洋。延迟的跳跃是预料之中的。如果此跃点位于距离较近的两个路由器之间，并且由于在跟踪路由的其余部分中持续增加的延迟，这将引起关注，并且是特定路由器延迟的良好指示。

您声称了解的有关 traceroute 的内容基本上是正确的。这是一个非常古老的工具，在某些方面，它并没有完全跟上现代网络协议和实践。Traceroute 可以成为您自己网络上的一个有用工具，您可以在其中知道应该期待什么，并且可以将其与结果进行比较。

当在您无法控制的网络上使用时，它的用处要小得多，因为某些中转 AS 会以与“真实”流量不同的方式对待它。事实上，您可能会摸不着头脑，因为某些流量实际上成功了，并且您使用 traceroute 试图找出其他流量可能出现的问题，结果却让 traceroute 完全失败。

通常，根据管理员配置，可能有路由器没有响应，或者它可能无法在 MPLS 之类的东西上很好地工作，在这种情况下，流量是交换而不是路由的。

根据 traceroute 的版本或类型，您可以获得非常不同的结果。至少，一些中转 AS 的 TCP 路由路由可能与 UDP 或 ICMP 不同，或者直接查找 traceroute 流量并故意将其转发到不同的路径。当您使用其他工具来模拟 traceroute 时，只需将更传统的数据放入您发送的数据包中，您就可以获得非常不同的结果。这个想法是为了防止外人试图发现 AS 的内部网络。