对比常见两种指令的执行流程以及背后的原理

在一次偶然的过程中，我发现访问网址速度很快，但是做路由追踪就非常慢，通过查阅资料了解了两种不同方式的执行流程以及背后的原理

首先，数据包在网络上传递的过程类似于平信在邮局间传递的过程。当你寄出一封信的时候，它先通过寄出方的街道邮局转运到区县邮，再到市邮局，再到省局，到收件方省局……你trace route的时候看到经过的地址，就是这些中间转运的邮局（路由器）的地址。

现在再谈谈ping，ping和tracert都是基于icmp协议的，在你ping的时候，电脑会发出一个icmp echo request报文，目标设备在收到这个报文后，会返回icmp echo reply报文，这个过程耗时大概就是数据在网络中来回传输的时间，很快。

但是你也会发现，如果丢包或者ping一个不存在的地址的时候，会等一会儿才出结果，这是因为ping应用无法判断是丢包了还是延时比较大，只能等等看，通常最多等2s，如果还收不到回包，就认为丢包了。

而要说tracert，就要先说TTL，TTL（time to live)是IP报文头部的一个标记，最开始的时候，大家想用它来记录IP包在网络中可以存活的剩余时间，用来避免拥塞和环路，但是后来大家发现算时间太麻烦了，于是决定每经过一次路由器（邮局）就把这个数值减1，当减到0的时候，就把这个数据包丢弃，并以自己的IP为源地址向发出这个包的地址回应一个icmp time-to-live exceeded报文。linux电脑发出数据包的ttl一般默认初始值是64，windows通常是128。

当你使用tracert的时候，他也会发出icmp echo request报文，与ping不同的是，他会先将TTL设置为1，这样第一个接收到这个报文的路由将ttl减1后得到0，返回time-to-live exceeded报文，这样就能探测到第一跳路由的地址。然后在发出一个ttl为2的报文……依次类推，探测出中间每一跳路由的地址，直到收到echo reply报文为止。

然而，time-to-live exceeded报文受到的待遇却不如echo reply报文，有些路由根本没有开启回应这种报文，有些防火墙之类安全设备会拦截这种报文，还有些nat设备处理后，发送tracert的机器会误以为回复的报文不是给自己的。也就是说time-to-live exceeded报文丢失是很常见的。

和ping相同，tracert程序会等待2秒后，才认为数据丢失了，继续发下一个包，这是造成tracert慢的最重要的原因。还一个原因，是网络中的路可能有很多走法，tracert会同一个ttl值发送多个报文，看看有没有其他的走法。

如果你受不了tracert，有一个叫mtr的工具能帮你，它的工作原理和tracert一样，但是它采用了并行处理的办法，不是发一次加一次ttl，而是一股脑发一群，等收到echo reply再做修剪，它的速度回很快，基本1、2秒就能出结果。

所以，综上所述，traceroute因为各种原因导致速度很慢，反而ping速度很快