windows主机使用tracert命令,而linux/mac主机使用traceroute命令
文章目录
一、 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=11113.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] 的路由:
11 ms <1 毫秒 <1 毫秒 192.168.101.1
248 ms 49 ms 38 ms 192.168.220.18
348 ms 36 ms 48 ms 192.168.4.253
498 ms 78 ms 73 ms 221.183.89.13
588 ms 61 ms 73 ms 221.183.89.34
6115 ms 81 ms 88 ms 221.183.89.177
7116 ms 131 ms 118 ms 223.120.22.129
8127 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] 的路由:
11 ms <1 毫秒 <1 毫秒 192.168.101.1
2 * * * 请求超时。
348 ms 49 ms 38 ms 192.168.220.18
448 ms 36 ms 48 ms 192.168.4.253
5 * * * 请求超时。
6 * * * 请求超时。
7 * * * 请求超时。
898 ms 78 ms 73 ms 221.183.89.13
988 ms 61 ms 73 ms 221.183.89.34
10115 ms 81 ms 88 ms 221.183.89.177
11116 ms 131 ms 118 ms 223.120.22.129
12138 ms 115 ms 106 ms 223.120.2.246
13139 ms 215 ms 117 ms 223.119.47.122
14169 ms 122 ms 114 ms ae25-0.icr01.tyo31.ntwk.msn.net [104.44.235.96]15172 ms 127 ms 109 ms ae21-0.tyo01-96cbe-1a.ntwk.msn.net [104.44.236.174]16175 ms 137 ms 183 ms 104.44.212.241
17 * * * 请求超时。
18 * * * 请求超时。
19127 ms 117 ms 112 ms 13.107.21.200
跟踪完成。
1. 请求超时
这表明该跳的路由器可能存在问题。也可能意味着路由器正常工作但未配置为返回traceroute答复,但路由器仍将数据包传递给下一个路由器。
2. 12列的时间比19列还长
- 网络拥塞和路径长度:数据包在网络中旅行时,可能会经过多个路由器和不同的网络连接。每个跃点都可能引入延迟,特别是当网络拥塞或路径较长时。在第12行,数据包可能正在通过一个较为繁忙或距离较远的网络路径。
- 处理延迟:每个路由器或交换机在转发数据包前都需要对其进行处理(如路由选择、安全检查等),这些处理也会引入一定的延迟。
- 物理距离:尽管数据包在网络中的旅行速度非常快(接近光速),但物理距离仍然是一个影响因素。第12行的跃点可能距离发送方更远,因此延迟更长。
- 网络架构优化:目标主机(如 bing.com)可能部署在优化了网络性能的环境中,如使用内容分发网络(CDN)来减少延迟和提高可用性。因此,尽管数据包在到达目标前经历了多个跃点,但一旦到达目标网络,由于网络架构的优化,延迟可能会减少。
版权归原作者 小稻虫 所有, 如有侵权,请联系我们删除。