Tracert命令与PathPing命令你常用吗：
前段时间本网吧网速不太正常.每晚8点后到11点之间网速爆慢.其余时间则正常。在8~11点间PING电信DNS TIME值要100多MS以上，但PING电信网关是正常的。PING网吧路由，网吧路由返回值正常且稳定也没丢包现象，故先排除蠕虫等病毒影响原因。
排除病毒干扰原因后就着手开始检查是否局域网本身问题。因晚8~11时为高峰时段，考虑到网络负荷问题及怀疑可能有部分网络设备损坏，于是进行了排查。经检测各机器网卡，网线，及其各交换机工作正常。且局域网内部游戏联机，大规模文件复制均正常，速度理想。
既 然设备没问题，且其余时间段网络速度正常，就不太可能是网吧自身问题了。因为用的是4M的FTTB光纤带不到200台机器按说还是满轻松的。可事实又摆在 眼前，虽说看看网页，聊聊QQ是没问题，但上互联网打打反恐PING值高达80多以上那也不能玩呀。去上海热线下载频道去下个文件平常都是300多 K/s，现在却只有几十K/s，呵可。那可不行啊。打电话给电信，遇到个SB技术说是我被黑客攻击，呵呵，我路由防火墙的日志上根本就没有攻击记录，又何 来的攻击之说，再说我之前专门请我北京从事网络安全工作的朋友帮测过，路由没有漏洞。当然咱不排除重量级高手攻击的可能。不过我想这小小网吧跟这种人应该 没有什么直接利益关系吧。:)
在电话里跟那家伙理论了半天无果后只能做罢，这时脑中闪过一个念头何不用Tracert命令跟踪下路由看一下。于是Tracert 202.96.209.5 这个DNS看了一下。下面是跟踪结果：
Tracing route to ns-px.online.sh.cn [202.96.209.5]
over a maximum of 30 hops:
1 <10 ms <10 ms <10 ms my.router [xxx.xxx.x.xxx]
2 <10 ms <10 ms <10 ms xxx.xxx.xxx.xxx
3 <10 ms <10 ms <10 ms 5ge0-ip-xxsn-012.online.sh.cn [218.1.2.141]
4 31 ms 47 ms 31 ms 218.1.2.29
5 47 ms 47 ms 31 ms 218.1.1.238
6 46 ms 47 ms 32 ms 1so1-0-jnpr-lc.online.sh.cn [202.109.0.58]
7 47 ms 47 ms 47 ms 1so1-0-jnpr-px.online.sh.cn [202.109.0.37]
8 63 ms 46 ms 47 ms vlan99-c6k2-px.online.sh.cn [202.109.39.5]
9 * * * Request timed out.
10 47 ms 46 ms 63 ms ns-px.online.sh.cn [202.96.209.5] Trace complete.
相 信大家看了结果懂行的心里明白的也应该差不多了。大家可以看到，从我网吧到DNS：202.96.209.5中间经过了8个路由。上面跟踪结果中第一个路 由是我自己的。第十个是目的DNS。大家也看到了，在经过前三个路由时速度还是正常的都<10MS,从第四个开始网络廷时开始变的时显。当到达第九 个路由时压根就没反映了，来了个请求超时，由此看来是电信的部分路由出了问题无法及时处理数据而导致了网速变慢。知道原因后又致电给电信部门，叫他们技术 主管听的电话把情况跟他说明后他看纸包不住火终于吐透了真相，原来是有部分路由器出了故障，正在准备更换成Cisco的设备，已有很多用户向他们反映遇到 了上述问题。知道原因后让人舒了口气，几天后网络速度也恢复正常了。
好了故障叙述就到这了。下面给个PathPing的示例及注解给大家。希望能给有些朋友带来帮助：
（PathPing 不仅具有Tracert的路由跟踪功能，还能分析当前网络状况.2K及XP系统有此命令）
C:>pathping 202.96.209.133
Tracing route to ns-pd.online.sh.cn [202.96.209.133]
over a maximum of 30 hops:
0 a98 [192.168.0.98]
1 my.router [192.168.0.253]
2 218.80.229.73
3 5ge0-ip-yl-012.online.sh.cn [218.1.2.77]
4 218.1.2.1
5 4pos0-ip-jy-416.online.sh.cn [218.1.1.122]
6 218.1.1.238
7 vlan199-c6k1-pd.online.sh.cn [202.109.39.66]
8 ns-pd.online.sh.cn [202.96.209.133]
Computing statistics for 200 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 a98 [192.168.0.98]
10/ 100 = 10% | （请注意这一行：沿路径转发数据包丢失率的显示在最右边标记为 |）
1 0ms 0/ 100 = 0% 0/ 100 = 0% my.router [192.168.0.253]
0/ 100 = 0% |
2 2ms 0/ 100 = 0% 0/ 100 = 0% 218.80.229.73
0/ 100 = 0% |
3 4ms 1/ 100 = 1% 1/ 100 = 1% 5ge0-ip-yl-012.online.sh.cn [218.1.2.77]
0/ 100 = 0% |
4 3ms 0/ 100 = 0% 0/ 100 = 0% 218.1.2.1
0/ 100 = 0% |
5 4ms 0/ 100 = 0% 0/ 100 = 0% 4pos0-ip-jy-416.online.sh.cn [218.1.1.122]
0/ 100 = 0% |
6 2ms 0/ 100 = 0% 0/ 100 = 0% 218.1.1.238
0/ 100 = 0% |
7 3ms 0/ 100 = 0% 0/ 100 = 0% vlan199-c6k1-pd.online.sh.cn [202.109.39.66]
0/ 100 = 0% |
8 2ms 0/ 100 = 0% 0/ 100 = 0% ns-pd.online.sh.cn [202.96.209.133]
Trace complete.
带有“|”标记的行显示的信息，表示沿路径转发丢失的数据包。该丢失表明链接阻塞。显示为百分比方式。
如上例：192.168.0.98（跃点 1）和 192.168.0.253（跃点 2）丢失 10% 的数据包。 所有其他链接工作正常
有个问题一直困扰了我很久了,希望各位高手帮忙解答
如下图tracert到一个站点或者IP
问题一:tracert所经过的路由节点延迟信息1 2 3列分别是什么意思,为什么有这3列
问题二:在我们tracert一个站点时,往往会遇到中间某一个或者几个节点延迟非常高,如图第三跳的延迟达到了1000多ms,为什么最终ping到这个站点的延迟又是正常的.既然结果正常,那中间节点的这个延迟又充当什么角色.(这个是关键想知道的!)
至于大家回答的第三跳延迟这么高的原因不是重点,这个我知道原因,可能是运营商设备的icmp响应排序,大家可以忽略这点
在下例中，数据包必须通过两个路由器（10.0.0.1 和 192.168.0.1）才能到达主机 172.16.0.99。主机的默认网关是 10.0.0.1，192.168.0.0 网络上的路由器的 IP 地址是 192.168.0.1。
C:\>tracert 172.16.0.99
Tracing route to 172.16.0.99 over a maximum of 30 hops
1 2ms 3ms 2ms 10,0.0,1
2 75 ms 83 ms 88 ms 192.168.0.1
3 73 ms 79 ms 93 ms 172.16.0.99
Trace complete.
左边的数字是该路由经过的路由器数目和顺序。如果出现“*”表示往返时间太长，这个节点做了禁止跟踪了，应该是核心设备的一跳，防止核心设备的IP泄露。引起一些不必要的麻烦，tracert将这个时间“忘记了”，也就是说服务器繁忙。
2ms是向经过的第一个路由器通常应该是网关了（220.170.78.166）发送报文的往返时间，由于每个报文每次的往返时间不一样，tracert 将显示三次往返时间。（你经过的第一个计算机发送报文的三次往返时间就不一样，但一般的情况下是一样的，比如你经过的第二台计算机）
在时间之后的，是设备的信息，是IP地址，它可以让你知道，你的计算机与目的计算机在网络上的距离有多远，要经过多少步才能到达。
你目前的网络，经过的第二个网关和第三个网关之间的延迟很大，如果是两个不同的运营商之间设备的互通的话，你最好确定一下第三个网关的IP地址是那个运营商的，反馈信息给他，让他替你解决问题
- 1. 三列 分别表示，为了准确性，tracert 每次发三个报文出去，返回三个值；
- 2. 结果不丢包或延时但过程有丢包或延时是因为：网络设备的控制平面和转发平面是两套机制，你直接PING 包对于网络设备来说，直接asic芯片转发过去了；但你的TRACERT 报文其实是不停的去向交换机发一个目的IP是交换机的报文，这个时间，交换机需要调用CPU来处理这个报文，经常而言，像H3C 或华为这样的设备，在CPU处理队列中，ICMP的处理优先级是较低的（高的优先级都是用来处理路由表，MAC表，ARP表，CEF表的计算），所以你会 发现他的转发OK，但处理ICMP报文延时严重甚至丢包！
