前言
一直吃不准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/
