前言

一直吃不准tracert命令输出的为什么有3个时间，tracert /?只给出了命令本身的参数，没说结果怎么看。在网上搜了一下，发现排在前几面的CSDN文章讲得并不准确。而微软官网上对这个命令也是语焉不详。只好到洋站上搜索，结果略靠谱，原文是英文的这里整理一下，方便回顾。

举一个例子

看windows系统的tracert命令输出样例。
例如：

C:\Users\hotro>tracert www.example.com

通过最多 30 个跃点跟踪
到 www.example.com [93.184.216.34] 的路由:

  1     2 ms     2 ms     2 ms  rock-laptop [192.168.36.254]
  2     *        *        *     请求超时。
  3     4 ms     5 ms     5 ms  101.68.85.49
  4   444 ms     7 ms     4 ms  124.160.233.73
  5    15 ms    11 ms    20 ms  101.71.244.101
  6     *       33 ms    33 ms  219.158.14.5
  7    38 ms    37 ms    33 ms  219.158.18.70
  8    39 ms    36 ms    40 ms  219.158.3.30
  9   182 ms   183 ms   180 ms  219.158.98.58
 10   176 ms   180 ms   176 ms  sjo-b21-link.ip.twelve99.net [62.115.170.60]
 11   180 ms   179 ms   180 ms  sjo-b23-link.ip.twelve99.net [62.115.125.160]
 12   254 ms   235 ms   269 ms  verizon-ic325098-sjo-b21.ip.twelve99-cust.net [62.115.155.87]
 13   262 ms   264 ms   197 ms  ae-65.core1.sab.edgecastcdn.net [152.195.84.131]
 14   222 ms   259 ms   282 ms  93.184.216.34

跟踪完成。

注：可以按CTRL+C结束路由追踪。有时最后几行会以结尾，因为防火墙禁止路由追踪的数据包；这完全是正常现象。

输出的第一行

tracert首先输出的内容，描述了命令将做什么。它列出了目标系统(www.example.com)，目标IP地址（93.184.216.34)，以及追踪过程将通过的跃点个数上限（30）。

输出的后续行

接下来输出是单个跃点（一般对应一个路由器）的信息，从发送处到终点的路径。值得一提的是，跃点个数并不是影响延时的重要因素。最重要的是数据包所经过的物理距离，及其在ISP（互联网服务提供商）之间是如何传输的。

经过的路由

本例中，通过了这些路由：

浙江省杭州市联通
广东省广州市联通骨干网
北京市北京联通
瑞典斯德哥尔摩 Telia
美国加利福尼亚圣何塞
终点：美国 EdgeCast网络公司CDN节点

数据包穿行线路

数据包从杭州出发，直线距离超过15000公里。但光纤有时并不会和公路或者航线重合。一般说来光纤线路更长。需要特别注意的是，上面列出的只是单程，返程可能走完全不同的路线。

逐行解读

先看第10个跃点，以熟悉每个跃点所展示的信息。这一行包括了跃点序号、3次往返耗时（Round Trip Time，缩写为RTT)的测量值，跃点所到达的系统名称和IP地址

序号	RTT1	RTT2	RTT3	域名[IP地址]
10	176 ms	180 ms	176 ms	sjo-b21-link.ip.twelve99.net [62.115.170.60]

序号：从发送端到目标端的路径上的跃点顺序号
RTT（往返时延）：数据包到达跃点然后返回到发送端所耗费的时间，以毫秒为单位。tracert命令缺省对每个跃点发送3个，因此每个跃点的输出行包括3个往返耗时。RTT有时也被用作延时。影响RTT很重要的一个因素就是跃点之间的物理距离。
如果RTT的位置出现了星号（*），表明数据包在期望的时间窗口内没有返回。
- 一个或两个星号出现在单个跃点上，并不一定表明数据包丢失了。许多互联网路由器有意丢弃ping和路由追踪的数据包，但并不影响使用这些路由器的应用程序。这一招称为ICMP（网控协议）限流术，用来使路由器免遭拒绝服务（DoS)攻击。
- 3个星号后紧跟“请求超时”信息，可能是多个因素所致，详见下节“请求超时”章节。
域名：系统的完整域名（FQDN）。域名通常指明了路由器的物理位置。如果输出的内容中没有包含域名，说明域名没有找到，这并不意味着是个问题。
IP地址：路由器或域名所绑定的主机的网络协议（IP）地址。

“请求超时”

开头的“请求超时”信息

“请求走进”信息出现在路由追踪结果的开头，是很常见的，可以忽略。一般是设备不响应ICMP或路由追踪的请求，如跃点2的输出。

 2     *        *        *     请求超时。

结尾的“请求响应”信息

可能有几种原因导致这种情况：

目标位置的防火墙或其他安全设备对请求进行了屏蔽。即使终点的防火墙对路由追踪请求进行了屏蔽，还是可以采用其他协议（如http）到达目标。
从目标系统返回可能有问题。记住，往返耗时是度量从发送端至目标端，然后返回的时间。向前和返回常常会使用不同的路线。如果在返回路由上存在问题，也并不一定出现在输出内容中。
可能在该系统或下一个系统中存在连接问题

RTT（往返时延）解读

怎样才能从往返耗时中看出端倪呢？需要观察输出的全过程。
以下讲几种可能的苗头，可能明察秋毫于一瞥之间；但也可能只是杯弓蛇影庸人自扰。请接着往下看

RTT/时延可接受吗？

理论上讲，RTT值小于150ms将不会影响网络应用。很多应用在延时远高于150ms的时候也跑得挺欢，但150ms可以当成合理的上限，通常情况下是低于100ms的。
网络传输延时，主要受限两端的物理光纤距离。如果两地相隔好几千里，受到光速的限制，100-120ms的延时是可以接受的。

本例中，200ms到达1.5万公里之外的，也算可以接受。列个公式算一下，走真空的单程耗时：1.5万公里 ÷ 光速30万公里/秒 = 1/20秒=50ms。说的是光直接从杭州出发，穿过真空，到达美国再马上折返，需要100毫秒。考虑使用光纤传输数据时，是通过管道内壁折射完成的，实际走的距离比光纤本身要长，折算下来每秒只能走20万公里左右。也就是说，1.5/20*2，得花150毫秒。

光纤中传输原理

中间跃点高延时

中间跃点延时高，并不一定是有问题。tracert的数据包可能优先级低，可能被丢弃或者延时传输，特别是互联网主交换节点。本例中从中国（北京）到欧洲（瑞典）的时延比较高，就可能是这种原因导致的。

9 182 ms 183 ms 180 ms 219.158.98.58

从中间跃点到最终跃点，时延没什么增长

有时几个跃点间的时延差不多相同，这可能没什么问题。可能是多协议标签切换（MPLS）网络下出现的。

  1     2 ms     2 ms     2 ms  rock-laptop [192.168.36.254]
  2     2 ms     2 ms     2 ms  rock-laptop [192.168.99.1]
  3     4 ms     4 ms     5 ms  101.68.85.49
  4     5 ms     *        5 ms  124.160.233.73
  5    16 ms    12 ms    20 ms  101.71.244.101
  6     *        *        *     请求超时。
  7    38 ms    34 ms    35 ms  219.158.18.70
  8    41 ms    35 ms    37 ms  219.158.3.30
  9   183 ms   181 ms   179 ms  219.158.98.58
 10   176 ms   175 ms   177 ms  sjo-b21-link.ip.twelve99.net [62.115.170.60]
 11   275 ms   180 ms   180 ms  sjo-b23-link.ip.twelve99.net [62.115.125.160]
 12   188 ms   186 ms   186 ms  verizon-ic325098-sjo-b21.ip.twelve99-cust.net [62.115.155.87]
 13   198 ms   177 ms   167 ms  ae-65.core1.sab.edgecastcdn.net [152.195.84.131]
 14   184 ms   190 ms   187 ms  93.184.216.34

有没有从中间跃点开始，时延递增

如果从中间跃点开始，时延稳步递增，可能说明网络有点不对劲。如果在中间跃点出现了大量的不响应或者星号，也可能网络层存在问题。
这些是可以报告的迹象，稳定的时延递增通常说明网络拥堵，需要多方协作进行解决。有时可能与互联网服务提供商（ISP，也就是宽带接入服务的电信、移动公司）有关。
象下面这个就有问题，从第7个跃点开始，网络延时就开始跳涨，直到最后完全失速。

H:\>tracert www.example2.com 

Tracing route to example2.com [192.168.32.15] 
over a maximum of 30 hops: 

  1    <1 ms    <1 ms    <1 ms  192.168.0.1 
   2     *        *        *     Request timed out. 
   3     6 ms     5 ms     6 ms  68.85.162.74 
   4    13 ms     8 ms     9 ms  pos-0-3-0-0-cr01.newyork.ny.ibone.comcast.net [68.86.90.57] 
   5    95 ms   100 ms     9 ms  xe-10-1-0.edge1.NY.exampleISP1.net [10.78.169.45] 
   6    10 ms     8 ms     9 ms  ae-33-89.car3.NY.exampleISP1.net [10.68.16.133] 
   7   893 ms     * ms   799 ms  nyc-edge-03-inet.example2.com 192.168.33.4 
   8   809 ms   808 ms     * ms  nyc-core-01.inet.example2.com [192.168.33.10] 
   9   985 ms   947 ms   983 ms  alt-core-03.inet.example2.com [192.168.32.11] 
  10  1028 ms  1010 ms   953 ms  192.168.32.15 

Trace complete.

参考：

英文内容来源：https://help.mgcld.com/hc/en-us/articles/215645258-Reading-Tracert-Data

不需要flash或插件的纯网页测试工具：http://test.ustc.edu.cn/

光纤中的传输速度：https://www.guokr.com/article/436847/

看懂tracert数据