关于 traceroute/mtr 的一些说明

traceroute 默认发送的是 UDP 包,而非 ICMP,可以通过 -I 参数来使 traceroute 发送 ICMP 包,另外还可以使用 -T 参数来测试 syn 握手。
另外使用 -p 参数可以指定端口,对于 UDP 而言,每进行一个 probe 端口就会在原来的基础上加 1;而对于 ICMP 而言,可以用来初始化 icmp sequence 值,同样的,每进行一次 probe,sequence 会加 1。
对于 TCP 而言则指定发送的端口。

commandlinefu 上有一个使用 ping 来模拟 traceroute 的 shell,前面说了,ping 用的是 ICMP 而 traceroute 用的是 UDP,还是有点小差别的:

for i in {1..30}; do  ping -t $i -c 1 google.com; done | grep "Time to live exceeded"

默认情况下,traceroute 只发 3 次探测,可以通过 -q 参数改变此值。还可以通过 -f 指定 TTL。

除了 traceroute 之外,还有个叫 mtr 的工具,基本可以取代前者了,从 man 手册来看,默认应该使用的是 ICMP,可以通过 -u 参数来指定使用 UDP 报文。Debian 的安装包叫 mtr-tiny 之外,其余(CentOS, Arch) 都叫 mtr。

使用很简单,无非就是 -r, -n, -c 那几个参数。另外在执行 mtr 的时候,还可以通过 O 执行要显示的内容,默认从左到右为:
Loss%(丢包) Snt(probe 数量) Last(最近一次的 RTT) Avg(平均 RTT) Best(最短的 RTT) Wrst(最长的 RTT) StDev(就理解为方差吧)

跟 traceroute 一样,对于 loss 以及 latency 的分析,不能一概而论,这两篇文档(traceroute, mtr)分析的比较全面,可以参考。

简单总结一下 linode 那边文档的表述,traceroute 的那篇类似。如果只是某一个节点出现丢包,可能是由于路由限制了 ICMP 的流量;如果是从某个点开始接下去的几个点都出现不同程度的丢包,这个就可能是真正意义上的丢包了,可能是由于路由器撑不住了,或者直接把这部分包给过滤掉了,当然,由于去的包跟回来的包走的路由可能不一样,丢包可能是发生在回来的路上。因此最好的办法是 srs/dst 两边同时 mtr,不过这个一般情况下只有一方能实现,而另一方的控制权不在自己的手上。
尽管 TCP 有重传机制,当丢包达到一定的程度的时候还是会影响网路的性能,尤其在 latency 比较大的时候,如果 latency 比较小,比如在几ms之内,出现小部分的丢包也可以接受,但是如果 latency 本身就达到了 3,400ms,再来个 10% 的丢包,效果可想而知了。基本就是 latency 可以接受但是丢包律高就不可以接受了。
最能体现上面观点就是下面这张图,从北京某个 BGP 测试国外的某个节点的网络质量,白天 latency 以及 loss 逐步攀升,到晚上上网高峰期 latency 稳定在 500ms 左右,loss 一般在 10% 左右,峰值有 50%,并且 stDev 我理解的其实就是 jitter 了,也比较大。这时候网络质量就会有明显的下降,一般上网会受到比较明显的影响。

  • http://log4d.com/ alswl

    唔~还有这个区别啊,mtr 的确好用