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

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

   
  

---

一、 tracert命令的作用

小明的电脑通过欣赏器连接到了百度网站，那么网络传输颠末了哪些路由装备，这就是tracert命令能够告诉的。我们可以利用此命令来发现诸如瓶颈之类的题目：例如与服务器的连接可能滞后的缘故起因和位置，不停存在于路由列表中的ip地点（假如是私有地点要格外关注）等等。
二、与ping命令的不同

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

1. C:\>ping bing.com
3. 正在 Ping bing.com [13.107.21.200] 具有 32 字节的数据:
4. 来自 13.107.21.200 的回复: 字节=32 时间=134ms TTL=111
5. 来自 13.107.21.200 的回复: 字节=32 时间=142ms TTL=111
6. 来自 13.107.21.200 的回复: 字节=32 时间=118ms TTL=111
7. 来自 13.107.21.200 的回复: 字节=32 时间=121ms TTL=111
9. 13.107.21.200 的 Ping 统计信息:
10.     数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
11. 往返行程的估计时间(以毫秒为单位):
12.     最短 = 118ms，最长 = 142ms，平均 = 128ms

复制代码

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

1. C:\>tracert bing.com
3. 通过最多 30 个跃点跟踪
4. 到 bing.com [13.107.21.200] 的路由:
6.   1     1 ms    <1 毫秒   <1 毫秒 192.168.101.1
7.   2    48 ms    49 ms    38 ms  192.168.220.18
8.   3    48 ms    36 ms    48 ms  192.168.4.253
9.   4    98 ms    78 ms    73 ms  221.183.89.13
10.   5    88 ms    61 ms    73 ms  221.183.89.34
11.   6   115 ms    81 ms    88 ms  221.183.89.177
12.   7   116 ms   131 ms   118 ms  223.120.22.129
13.   8   127 ms   117 ms   112 ms  13.107.21.200
15. 跟踪完成。

复制代码

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

下述结果显示12列的时间比19列还长，并且其中有一些哀求超时的行，下面我们来表明出现这些题目的缘故起因。

1. C:\>tracert bing.com
3. 通过最多 30 个跃点跟踪
4. 到 bing.com [13.107.21.200] 的路由:
6.   1     1 ms    <1 毫秒   <1 毫秒 192.168.101.1
7.   2     *        *        *     请求超时。
8.   3    48 ms    49 ms    38 ms  192.168.220.18
9.   4    48 ms    36 ms    48 ms  192.168.4.253
10.   5     *        *        *     请求超时。
11.   6     *        *        *     请求超时。
12.   7     *        *        *     请求超时。
13.   8    98 ms    78 ms    73 ms  221.183.89.13
14.   9    88 ms    61 ms    73 ms  221.183.89.34
15. 10   115 ms    81 ms    88 ms  221.183.89.177
16. 11   116 ms   131 ms   118 ms  223.120.22.129
17. 12   138 ms   115 ms   106 ms  223.120.2.246
18. 13   139 ms   215 ms   117 ms  223.119.47.122
19. 14   169 ms   122 ms   114 ms  ae25-0.icr01.tyo31.ntwk.msn.net [104.44.235.96]
20. 15   172 ms   127 ms   109 ms  ae21-0.tyo01-96cbe-1a.ntwk.msn.net [104.44.236.174]
21. 16   175 ms   137 ms   183 ms  104.44.212.241
22. 17     *        *        *     请求超时。
23. 18     *        *        *     请求超时。
24. 19   127 ms   117 ms   112 ms  13.107.21.200
26. 跟踪完成。

复制代码

1. 哀求超时

这表明该跳的路由器可能存在题目。也可能意味着路由器正常工作但未设置为返回traceroute回复，但路由器仍将数据包传递给下一个路由器。
2. 12列的时间比19列还长

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