为什么traceroute比ping需要更长的时间？

怎么解释呢？

C:\Documents and Settings\Administrator>tracert google.com

Tracing route to google.com [64.233.189.104]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2     7 ms    <1 ms    <1 ms  reserve.cableplus.com.cn [218.242.223.209]
  3   108 ms   135 ms   163 ms  211.154.70.10
  4     *        *        *     Request timed out.
  5     2 ms     *        1 ms  211.154.64.114
  6     1 ms     1 ms     1 ms  211.154.72.185
  7     1 ms     1 ms     1 ms  202.96.222.77
  8     2 ms     1 ms     2 ms  61.152.81.145
  9     1 ms     2 ms     1 ms  61.152.86.54
 10     1 ms     1 ms     1 ms  202.97.33.238
 11     2 ms     2 ms     2 ms  202.97.33.54
 12     2 ms     1 ms     2 ms  202.97.33.5
 13    33 ms    33 ms    33 ms  202.97.61.50
 14    34 ms    34 ms    34 ms  202.97.62.214
 15    34 ms   186 ms    37 ms  209.85.241.56
 16    35 ms    35 ms    44 ms  66.249.94.34
 17    34 ms    34 ms    34 ms  hkg01s01-in-f104.1e100.net [64.233.189.104]

Trace complete.

因此平均时间应为：1 + 7 + 108 + 2 + 1 + 1 + 2 + 1 + 1 + 2 + 2 + 33 + 34 + 34 + 35 + 34 + 34 + 35 + 34，比 ping

C:\Documents and Settings\Administrator>ping google.com

Pinging google.com [64.233.189.104] with 32 bytes of data:

Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241
Reply from 64.233.189.104: bytes=32 time=34ms TTL=241

Ping statistics for 64.233.189.104:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 34ms, Maximum = 34ms, Average = 34ms

您不能将所有这些数字加在一起。这是google路径上每个跃点的ping时间。因此，从路径上看，每条腿的距离越来越远，您会发现ping时间有所不同。如果您查看tracert中的最后一次ping时间（34毫秒），则发出ping时收到的时间（34毫秒）是相同的。Tracert程序并不比ping慢。

我建议您阅读一下traceroute的工作原理：http :
//en.wikipedia.org/wiki/Traceroute

您可以看到ping就像从纽约开车到旧金山一样。大概要花200个小时（从瑞士出发，并不熟悉美国的距离）

但是司机必须回纽约告诉你他在旧金山。您看一下手表，现在您可以算出他花了400个小时才走完了路程。现在，Ping就是这样做的。Traceroute的作用是：告诉您的司机他应该从纽约开车到San Franciso，并且每次他在十字路口上时，他都应该回来告诉您它的名称。所以他在路上，头几个十字路口在纽约。因此，他开车回头告诉您十字路口的名字非常快。但是，当他走得更远时，他将需要更长的时间才能回到你身边。等等...

因此，如果算上所有的驾驶时间，他要报告所有的十字路口要比他不得不开车去旧金山要花费更长的时间。希望这可以为您解决一些问题...

实际上，这基本上是由于PING通过网络向DNS和其他网络设备发送了ICMP请求。

但是，Traceroute会发送很多带有TTL的小包装，而这些包装确实很短。

例如，当您尝试从座位上加入www.google.com时，traceroute将patquet发送到www.google.com，并将TTL设置为1，然后等待第一次遇到网络的设备的答复。

然后，Traceroute在屏幕上显示第一个网络设备的IP，之后将进行相同的操作，但是这次将TTL设置为2等。

最终，Traceroute等待了大约一半以上的时间，因为在每次发送时，它都在等待网络设备的应答。

Traceroute总是告诉您到达目的地的平均值，而不是时间的累加，也就是说，使用ping和时为34毫秒traceroute。

如果traceroute按照您的建议进行操作，则其输出将非常不可读。

如果您只对目的地的响应时间感兴趣，那么就ping足够了，traceroute它适合您在到达目的地的路线上调试某些东西时使用。此外，您与目标之间的所有跃点都是路由器，并且在大多数情况下，路由器会优先执行操作，即先路由数据包，然后再响应ping或traceroute（即第一种情况，回答icmp echo reply，在第二种情况下icmp time exceeded回答），并且回答的速度通常较慢（当他们完全回答时）

对于后代来说，由于没有正确的答案，所以不清楚。

-

跟踪路由中显示的每次时间都是从您的机器（或执行跟踪路由的机器...）到该特定节点的总时间。

换句话说，第二个节点上显示的时间不是节点1和2之间花费的时间，而是源，第一个节点和第二个节点放在一起的总时间。

因此，平均而言，每个节点上显示的时间应大致与您“直接”对特定节点执行ping操作时获得的时间相匹配（实际上并没有比traceroute更直接……通常会遵循相同的路径在网上）。

请记住，有一个“滞后尖峰”。查找任何延迟源的最准确方法是使用批处理文件（如果在Windows上）重复运行traceroute（如果您在Windows上），并查找在任何给定时间具有高编号的最近（编号最小的）节点。

-

对于批处理文件，打开记事本并键入以下三行：

:start
tracert -d www.google.com
goto start

然后另存为“ Trace.bat”，但在保存之前请确保将保存对话框上的文件类型更改为“所有文件”，否则仍将另存为文本文件。

打开后，它将不断运行traceroutes（至Google）。选择窗口后，可以按ctrl + c停止它。

-

当然，您可以通过将“ www.google.com”更改为您想要的任何地址来更改跟踪路由的运行位置。

如果希望查看已解析的主机名，也可以删除“ -d”选项，但是由于从DNS服务器获取每个节点的主机名，这将使traceroute花费更长的时间（但是这本身不会更改实际结果） ）。

最后，如果您发现一个节点的时间很长，并且只想运行到该特定节点的路由，以防其他节点出现问题，则可以将“ www.google.com”更改为该节点的IP地址或主机名，或者您可以使用-h选项指定要搜索的节点数，即...

:start
tracert -d -h 5 www.google.com
goto start

因为tracert使用UDP数据包，所以像ping一样使用ICMP包。在Linux下，可以traceroute -I选择执行ICMP跟踪路由。

在您的测试中，traceroute和ping中连接到Google的时间相同：34ms。中间的所有路由器都有自己的应答时间，但不影响最终传输时间。

http://en.wikipedia.org/wiki/Traceroute在Traceroute上进行了全部解释

您可以通过禁用反向dns查找来提高traceroute的性能，但通常会失败：tracert -d www.google.com