详解tracert

在工作生活中，如果干点跟网络沾边的活，可能都会用到tracert，tracert是windows操作系统上用于追踪到达目标地址路由的一个小工具，同样的软件在linux上也有，只不过是traceroute，原理相似，可能tracert就是根据traceroute开发的，细节上有些不同而已。

Tracert属于icmp协议，通过使用它可以轻而易举的找出ip地址在网路上的路径，判断IP地址经过了哪些设备，找出哪些设备延迟过高，从而发现网络中存在的问题。比如，我们经常接到反馈说，访问某个网站特别慢，那到底是什么慢呢，其实就是我们到达服务器的延时较高，从而导致数据传输过慢，网页加载也就更慢了。

一、Tracert原理

要弄清tracert的原理什么，就得首先简单了解下ICMP和IP包头字段中的TTL。

ICMP全称Internet控制报文协议，作为TCP/IP的一个子协议，常用来在IP传输中用来指出网络不通、主机是否可达、路由是否可用等。例如常见的ping应用，当主机A测试能否到达主机B时，由主机A发送imcp request（type:8,code0），当主机B收到这个数据包时，主机B发送给主机A一个icmp replay（type:0,code0）。这时，主机A将收到的信息回显传输给上层应用。

TTL是IP包头的一个字段，用于表示该数据包在网络里存活了多久，一般根据系统不同，初始的TTL值也不尽相同。例如在windows 10里，TTL一般设置为64。IP采用这个机制主要是为了防环，数据包每经过一个设备，TTL都会减一，也就是说，该数据包在网络里最多能有64跳，当然已经这足够用了。当TTL被最终减到1或0时，接收设备就不会再次转发该数据包，而是丢弃，然后给发送该数据包的源主机发送一个icmp Time-to-live exceeded（type:11,code:0）报文，也就是告诉源主机:“你的数据包死掉啦，重传还是改变ttl你自己看着办吧!”

Tracert就巧妙的运用了以上两种技术，实现了对路径的识别。Tracert选取icmp协议（linux下traceroute使用udp协议，高端口号），当我的PC Tracert一个IP地址时，pc向目的ip发送一份icmp request（type:8,code0）报文，但是tracert程序会把该数据报的ttl设置1。什么，那不就发送不出去了吗？是的，tracert本来也没想直接就能送达到目的主机，他要的是什么？他要的是差错报文消息！

这样一来，第一跳设备就会给源主机回复一个icmp Time-to-liveexceeded（type:11,code:0）告诉源主机，你的ttl超时啦！tracert记录下时间，再重复两次该过程，如此以来，tracert就完成了第一跳信息的收集。接下来，tracert会把第二个数据报ttl设置为2，第三个数据报ttl设置为3，依次类推，直到某个数据报收到icmp replay（type:0,code0）,连续收到3次后，最终认为tracert已经完成。

二、tracert抓包分析

接下来我们看看数据包收发过程是否像我说的那样。

ttl=1,ttl=2,ttl=3……我们可以看到每个数据包都发送了3次，而每次都收到了icmp Time-to-live exceeded 消息。

    但是也有没有收到icmp Time-to-liveexceeded 消息的，这将被tracert认为是未收到回应，将显示*号，请求超时。

当成功收到来自119.75.217.109的icmp replay时，则认为追踪完成。

三、Tracert排障应用

原理我们懂了，如何排除故障就简单了。根据案例分析，我们到达目的地址119.75.217.109总共经历了8跳，但是有人要问了，为什么8跳延迟没什么规律呢？其实，延迟除了由线路转发设备决定，也受回包设备的性能影响。现在的网络设备都是控制层面和转发层面分离，控制层面可以理解为一个小电脑，转发层面由控制层面进行控制，但是控制层面出问题短时间不一定会影响转发层面转发。有点绕对不？

一般设备上的cpu主频比较低，再加上还要处理一些路由协议之类的信息，所以有可能回复的就慢一些，因为icmp协议处理的优先级比较低。所以一般而已，负载高的设备回复ping延迟高一些，负载低的设备回复ping延迟低一些。

所以，但只是根据延迟判断网络问题是不靠谱的。

如图所示，延迟到了16跳的时候，直接增加了200ms左右，而且后面的设备回应都大于200ms了，也就是说这一跳的设备要不是带宽负载过高，要不就是有限制。当然根据ip地址分析了下，15-16跳估计到国际出口了，带宽不足正常现象。但是如果假设这些延迟增高现象是发生在你自己的网络里的话，那你可就得小心了。