在使用Tracert和TTL修复网络连接问题中，我阐述了Tracert可以帮助诊断本地主机以及远程网络的主机的连接问题。在该文中，我探讨如何发送基本的Tracert命令。因此，在本文中我将继续探讨如何解析结果。

　　为了演示，我对www.espn.com上执行了一个Tracert。我选择这个特定站点的唯一原因是因为它是我所知道的少数不阻挡Internet Control Message Protocol (ICMP)流量的网站之一。

　　我们可以在下面看到跟踪路由输出。在本文接下来的部分都会使用这个输出：

　　C:UsersAdministrator>TRACERT www.espn.com

　　跟踪到www.espn.com [199.181.132.250]的最多30跳的路由：

　　1     2 ms     1 ms    <1 ms  147.100.100.100
 
　　2    10 ms    10 ms     9 ms  208.104.224.1
 
　　3     9 ms     9 ms     9 ms  208.104.1.13

　　4     9 ms     8 ms     9 ms  208.104.0.13
 
　　5    10 ms     9 ms    10 ms  208.104.0.1
 
　　6    11 ms    14 ms    10 ms  165.166.125.193
 
　　7    11 ms    10 ms    11 ms  gig-1-1-3.core01.ncchrl.infoave.net [165.166.22.61]
 
　　8    31 ms    31 ms    30 ms  64.200.130.17
 
　　9    38 ms    39 ms    40 ms  hrndva1wcx2-pos15-3-oc48.wcg.net [64.200.240.213]

　　10    31 ms    31 ms    31 ms  64.200.249.170

　　11    31 ms    30 ms    31 ms  4.68.110.5

　　12    48 ms    35 ms    35 ms  vlan99.csw4.Washington1.Level3.net [4.68.17.254]
 
　　13    32 ms    31 ms    33 ms  ae-92-92.ebr2.Washington1.Level3.net [4.69.134.157]
 
　　14    60 ms    53 ms    54 ms  ae-2.ebr3.Chicago1.Level3.net [4.69.132.69]
 
　　15    86 ms    71 ms    70 ms  ae-3.ebr2.Denver1.Level3.net [4.69.132.61]
 
　　16   137 ms   103 ms   102 ms  ae-2.ebr2.Seattle1.Level3.net [4.69.132.53]
 
　　17    95 ms    95 ms    95 ms  ae-23-52.car3.Seattle1.Level3.net [4.68.105.36]
 
　　18    94 ms    95 ms    95 ms  WALT-DISNEY.car3.Seattle1.Level3.net [4.71.152.22]
 
　　19     *        *        *     Request timed out.
 
　　20    97 ms    95 ms    98 ms  199.181.132.250

　　Trace complete.

　　请看上面的跟踪结果，我们注意到每一行的输出都包含几个不同的信息。在每一行的最左边的第一个信息是跳数。正如我在前面的文章中所阐述的，Tracert是通过发送一个PING请求到一个特定的主机上来进行工作的。首先，请求的存活时间（TTL）值设置为1。这样就可以确保在第一跳之后请求就会失败。关于跳的信息会显示出来，接着，ICMP请求会再次被发送，但这次TTL值是设置为2。这个过程会不断地重复，并且每次TTL值都增加1，直到最后到达特定主机。这样，Tracert就可以报告到达远程主机需要请求多少跳。请看上面输出的最后一行，我们可以看到它的开始数字是20。这是因为需要20跳才可以到达特定主机。

　　每一行上接下来的三个信息显示到达特定行所指的路由器或者主机时间长度。从这个列表看来，我们注意到时间连结大体上都随着跳数增加而增加。其中有两个内容是我们为了知道显示的连接时间所确实需要知道的。

　　第一，每一跳都有三个单独的时间长度。正如我在前面提到的，Tracert是基于发送多个ICMP请求的概念的。之前，我们在这一系列文章中使用的是PING命令，我们可以看到PING命令总是返回4个不同的值来作为测量数据包丢失的一种方法。这个概念也同样适用于Tracert，只是请求所需要的时间长度是测量三次而不是四次。

　　第二，关于响应次数我们还需要了解的是星号显示请求超时了。它可能或者不可能表示出现一个问题，这取决于星号是如何出现的。如果我们查看一下上面的输出中的第19跳时，我们注意到这里3个响应值都以星号出现。当我们看到3个连续的星号时，它通常意味着这一跳中所PING的设备上配置了拒绝ICMP数据包的防火墙。这将导致每个记时器超时，并且最后的一列将简单地显示“请求超时”的字样。

　　然而，记住，虽然经常出现这样的情况，但是这并不是唯一的一种情形。当设备出现问题而无法访问时，Tracert同样显示3个星号。当然，这就出现这样一个问题：我们该如何判断一个站点是阻塞ICMP数据包还是连接失败呢？回答这个问题，可能需要一点技巧。

　　第一眼看来，连接失败与路由器或者主机阻塞ICMP请求的情形是一样的。当发生失败时，我们将不可能看到错误消息。事实上，这个过程以标准的“跟踪完成（Trace Complete）”消息结束。

　　有2个现象可以很好地确定是连接失败。一个现象是在跟踪的某一点，每个返回的结果都是超时的。另外一个连接失败的现象是跟踪进行完了整整30跳。这些条件都无法保证就是已经发生了连接失败，即使它们都出现了。比如，我的网站www.brienposey.com，这个时候是正常工作的，然而，当我运行跟踪时，这些症状都同时出现了，如下面的输出所显示的：

　　C:UsersAdministrator>TRACERT www.brienposey.com

　　Tracing route to www.brienposey.com [24.235.10.4]

　　over a maximum of 30 hops:
 
　　1     1 ms     1 ms    <1 ms  147.100.100.100
 
　　2     8 ms    12 ms     8 ms  208.104.224.1
 
　　3     9 ms     8 ms     9 ms  208.104.1.9
 
　　4    10 ms     9 ms     8 ms  208.104.0.9
 
　　5    10 ms    12 ms    11 ms  208.104.0.5
 
　　6    12 ms    10 ms     9 ms  165.166.18.1
 
　　7    15 ms    23 ms    13 ms  gig2-2-1.c01.scclma.infoave.net [165.166.22.17]
 
　　8    13 ms    12 ms    13 ms  66.192.166.9
 
　　9    31 ms    30 ms     *     peer-01-ge-0-0-0-1.asbn.twtelecom.net [64.129.249.10]
 
　　10    56 ms    57 ms    55 ms  bb2-p6-0.ipltin.sbcglobal.net [151.164.242.59]
 
　　11    55 ms    53 ms    55 ms  ded2-g8-0.ipltin.sbcglobal.net [151.164.42.159]
 
　　12    59 ms    56 ms    56 ms  Winnet-1148485.cust-rtr.ameritech.net [66.73.221.254]
 
　　13    64 ms    63 ms    68 ms  216-24-2-237.ip.win.net [216.24.2.237]
 
　　14    68 ms    68 ms    64 ms  fa0-0.cust-gw2.noc.win.net [216.24.30.69]
 
　　15     *        *        *     Request timed out.
 
　　16     *        *        *     Request timed out.
 
　　17     *        *        *     Request timed out.
 
　　18     *        *        *     Request timed out.
 
　　19     *        *        *     Request timed out.
 
　　20     *        *        *     Request timed out.

　　 21     *        *        *     Request timed out.
 
　　22     *        *        *     Request timed out.
 
　　23     *        *        *     Request timed out.
 
　　24     *        *        *     Request timed out.
 
　　25     *        *        *     Request timed out.
 
　　26     *        *        *     Request timed out.
 
　　27     *        *        *     Request timed out.
 
　　28     *        *        *     Request timed out.
 
　　29     *        *        *     Request timed out.
 
　　30     *        *        *     Request timed out.

　　Trace complete.

　　当我们看到诸如上面的输出时，它可能表示已经发生了一个连接失败，但是它又并不保证一定是这样的情况。唯一一种确认的方式是尝试对多个站点上运行跟踪来查看是否我们总是获得相同类型的结果。记住，跳数越多，距离越远。出现错误的距离越远，诊断就越难，因为测试其它站点将可能会经过不同的路由。当我们对多个站点执行路由测试时，我们必须查看实际使用的路由来确定是否发生连接失败。

　　在每一行上显示的最后一个信息是响应ICMP请求的路由器或者主机的身份。跟踪将尽可能的以名称标识每台主机或者路由器，但是，我们无法获得所有的名称。比如，假如我们查看上面的输出，我们可以看到一半的路由器是以名称标识的，而其它的则不是。就其本身而言，这个并不是一个大的问题。

　　有趣的是，我们所跟踪的路由到达的主机并不总会被标识。比如，假如我们查看上面最开始的第一个示例输出，我们将注意到我们输入了命令TRACERT WWW.ESPN.COM。在这样做之后，Tracert很快就将www.espn.com解析为IP地址199.181.132.250。如果我们直接跳到示例输出的最后，我们将注意到Tracert最后到达了它的目的主机，但是它并没有以名称标识目的主机（至少，这个例子中没有）。

　　这个行为并没有问题，设计上就是这样的。我之所以阐述这个，原因是为了让你不会在对站点执行一个Tracert后认为这个过程是失败的，因为目的主机并不是以名称标识的。