首先, 数据包在网络上传递的过程类似于平信在邮局间传递的过程. 当你寄出一封信的时候, 它先通过寄出方的街道邮局转运到区县邮, 再到市邮局, 再到省局, 到收件方省局...... 你 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 速度很快
来源: http://www.bubuko.com/infodetail-3304202.html