【网络排查】巧用路由追踪命令tracert （1）

小稻虫

于 2024-10-10 11:45:31 发布

阅读量404

点赞数 11

文章标签：计算机网络

本文链接：https://blog.csdn.net/jjikyour/article/details/142789813

版权

windows主机使用tracert命令，而linux/mac主机使用traceroute命令

文章目录

一、 tracert命令的作用
二、与ping命令的不同
二、问题排查
1. 请求超时
2. 12列的时间比19列还长

一、 tracert命令的作用

小明的电脑通过浏览器连接到了百度网站，那么网络传输经过了哪些路由设备，这就是tracert命令能够告诉的。我们可以使用此命令来发现诸如瓶颈之类的问题：例如与服务器的连接可能滞后的原因和位置，一直存在于路由列表中的ip地址（如果是私有地址要格外关注）等等。

二、与ping命令的不同

操作主机：A 目标地址：bing.com（或者baidu.com）
当对bing.com等服务器执行ping操作时，主机A向目的地发送四个数据包，一旦到达目的地，它将把数据包返回给主机A。因此，如果主机A收到了全部或部分返回的数据包，则表明我们的计算机与目标位置之间存在常规连接，此外ping还会告诉我们数据包往返目的地所花费的时间（以毫秒为单位）。
打开“命令提示符”，输入"ping bing.com"，返回结果如下：

C:\>ping bing.com

正在 Ping bing.com [13.107.21.200] 具有 32 字节的数据:
来自 13.107.21.200 的回复: 字节=32 时间=134ms TTL=111
来自 13.107.21.200 的回复: 字节=32 时间=142ms TTL=111
来自 13.107.21.200 的回复: 字节=32 时间=118ms TTL=111
来自 13.107.21.200 的回复: 字节=32 时间=121ms TTL=111

13.107.21.200 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 118ms，最长 = 142ms，平均 = 128ms

tracert（或traceroute）会告诉我们更多信息。它不仅可以ping通最终目的地，还可以ping通到目的地的每个路由器，并且测量数据包从每个路由器和目的地获取的往返时间，让我们继续通过互联网跟踪从计算机到服务器的路由。
打开“命令提示符”，输入"tracert bing.com"，主机A将向到达目的地的每个路由器中发送三个数据包，并且每当数据包到达其路径上的路由器时，路由器都会将这三个数据包发送回主机A，并告诉我们有关该路由器的信息。它还会告诉我们三个数据包往返于每个路由器的往返时间（以毫秒为单位）。

C:\>tracert bing.com

通过最多 30 个跃点跟踪
到 bing.com [13.107.21.200] 的路由:

  1     1 ms    <1 毫秒   <1 毫秒 192.168.101.1
  2    48 ms    49 ms    38 ms  192.168.220.18
  3    48 ms    36 ms    48 ms  192.168.4.253
  4    98 ms    78 ms    73 ms  221.183.89.13
  5    88 ms    61 ms    73 ms  221.183.89.34
  6   115 ms    81 ms    88 ms  221.183.89.177
  7   116 ms   131 ms   118 ms  223.120.22.129
  8   127 ms   117 ms   112 ms  13.107.21.200

跟踪完成。

第一列告诉我们到达目的地的跃点数或步骤数，共计19跳。接下来的三列向我们展示了每个数据包到达每个点并返回主机A的往返时间。第一行的数据包只花了1ms，路径很短，因为在主机A的局域网内，第一跳是主机A所在家里的调制解调器路由器。但正如我们所看到的，一旦数据在Internet上发布，往返时间就会大大增加，而且，数据包必须传送到每个路由器。执行跟踪路由时要查看的主要内容之一是往返时间的一致性，理论上来讲，往返时间将逐渐增加，直到到达目的服务器bing.com，如上所示。但是网络环境错综复杂，数据包传输过程中难免出现一些问题，比如下面的例子。

二、问题排查

下述结果显示12列的时间比19列还长，并且其中有一些请求超时的行，下面我们来解释出现这些问题的原因。

C:\>tracert bing.com

通过最多 30 个跃点跟踪
到 bing.com [13.107.21.200] 的路由:

  1     1 ms    <1 毫秒   <1 毫秒 192.168.101.1
  2     *        *        *     请求超时。
  3    48 ms    49 ms    38 ms  192.168.220.18
  4    48 ms    36 ms    48 ms  192.168.4.253
  5     *        *        *     请求超时。
  6     *        *        *     请求超时。
  7     *        *        *     请求超时。
  8    98 ms    78 ms    73 ms  221.183.89.13
  9    88 ms    61 ms    73 ms  221.183.89.34
 10   115 ms    81 ms    88 ms  221.183.89.177
 11   116 ms   131 ms   118 ms  223.120.22.129
 12   138 ms   115 ms   106 ms  223.120.2.246
 13   139 ms   215 ms   117 ms  223.119.47.122
 14   169 ms   122 ms   114 ms  ae25-0.icr01.tyo31.ntwk.msn.net [104.44.235.96]
 15   172 ms   127 ms   109 ms  ae21-0.tyo01-96cbe-1a.ntwk.msn.net [104.44.236.174]
 16   175 ms   137 ms   183 ms  104.44.212.241
 17     *        *        *     请求超时。
 18     *        *        *     请求超时。
 19   127 ms   117 ms   112 ms  13.107.21.200

跟踪完成。

1. 请求超时

这表明该跳的路由器可能存在问题。也可能意味着路由器正常工作但未配置为返回traceroute答复，但路由器仍将数据包传递给下一个路由器。

2. 12列的时间比19列还长

网络拥塞和路径长度：数据包在网络中旅行时，可能会经过多个路由器和不同的网络连接。每个跃点都可能引入延迟，特别是当网络拥塞或路径较长时。在第12行，数据包可能正在通过一个较为繁忙或距离较远的网络路径。
处理延迟：每个路由器或交换机在转发数据包前都需要对其进行处理（如路由选择、安全检查等），这些处理也会引入一定的延迟。
物理距离：尽管数据包在网络中的旅行速度非常快（接近光速），但物理距离仍然是一个影响因素。第12行的跃点可能距离发送方更远，因此延迟更长。
网络架构优化：目标主机（如 bing.com）可能部署在优化了网络性能的环境中，如使用内容分发网络（CDN）来减少延迟和提高可用性。因此，尽管数据包在到达目标前经历了多个跃点，但一旦到达目标网络，由于网络架构的优化，延迟可能会减少。