TTL 为何有时是 51，有时是 49？

[crc8]

第一次
64 bytes from 13.26.7.208: icmp_seq=4 ttl=51 time=168 ms
64 bytes from 13.26.7.208: icmp_seq=5 ttl=51 time=168 ms
64 bytes from 13.26.7.208: icmp_seq=6 ttl=51 time=173 ms
64 bytes from 13.26.7.208: icmp_seq=7 ttl=51 time=168 ms

第二次
64 bytes from 13.26.7.208: icmp_seq=4 ttl=49 time=168 ms
64 bytes from 13.26.7.208: icmp_seq=5 ttl=49 time=168 ms
64 bytes from 13.26.7.208: icmp_seq=6 ttl=49 time=173 ms
64 bytes from 13.26.7.208: icmp_seq=7 ttl=49 time=168 ms

tracert 的结果总共是 13 跳

得出的结果，客户端与服务端 均无改变。

[liuliancao]

64 每经过一个路由器就-1 ，有时候路由不只一条路

[hefish]

tcp/ip 没仔细学啊。赶紧去重新学一遍。

[iijboom]

亲亲你可能在使用移动或者广电等宽带呢

[crc8]

@hefish 请赐教，服务器是 ubuntu ， 默认 TTL 是 64 ，ping 的 TTL 结果与 tracert 的跳数存在对应关系吗？比如 ping 的 TTL 为 51 ，则可计算到 tracert 的跳数应为 64-51=13 跳，如此，ping 的 TTL=49 时，跳数应为 15 跳，实际上我反复测试过一直是 13 跳，从未出现过 15 跳的情况。

莫非 tracert 的结果跳数还可以主动隐藏起来？

[crc8]

@iijboom 中国电信

[htfcuddles]

路由会有多条负载均衡的，跳数当然也会变，联通特别明显，最多时候有三四条。另外，有些路由会设置超时 ICMP 黑洞或者走不同路由，有些路由干脆不减 TTL 。

[tjiaming99]

1 、负载均衡
2 、来回程不一致
3 、多路径路由

[hefish]

@crc8 这个就要问具体运营商了，traceroute 的 icmp 包和 ping 的 icmp 包不是同一种类型的，完全可以分流处理的。
另外，windows 下自带的 tracert 是同时使用 icmp 和 udp 的，而 linux 和 mac 自带的 traceroute 好像是只用 udp 的。 我学 tcp/ip 的时候是这样了，过了十来年了，windows,linux,mac 都升级了好多版本了，不知道目前的情况是不是还是这样 。

[hefish]

@hefish 啊，现在 linux 下是可以选择使用哪个协议的。icmp/ucp/tcp 都可以。默认情况下是 udp 。 这些是 man traceroute 时候查到的。win10 下的情况现在不清楚。

[crc8]

@htfcuddles 是不是可以理解为 ping 结果中的 TTL 数字与 tracert 结果中的跳数，没有必然的联系？

[htfcuddles]

@crc8 #10 tracert 中 TTL 是按接收的 ICMP 包显示的，但有防不住些路由不遵守规则，经过时不减一

[crc8]

@htfcuddles 即是说 tracert 结果中的跳数非 100%准确，ping 结果中的 TTL 是相对准确的？

拿我这个案例来说，只能说明客户端与服务器之间经过 13-15 个路由器，而不能确定是某个数？

[htfcuddles]

@crc8 #12 如果不减 TTL 是一样的，你用 Linux 下的 traceroute 更容易发现多径路由，windows 下的不准确。

[crc8]

@htfcuddles 刚用 Linux 与 windows 测试，ping TTL=49 都是 49 。tracert 跳数都是 14 跳。