这是一个创建于 507 天前的主题，其中的信息可能已经有所发展或是发生改变。
第一次
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 fro 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 跳
得出的结果，客户端与服务端 均无改变。
 | 1 liuliancao 2024 年 8 月 21 日 64 每经过一个路由器就-1 ，有时候路由不只一条路 |
 | 2 hefish 2024 年 8 月 21 日  2 tcp/ip 没仔细学啊。赶紧去重新学一遍。 |
 | 3 iijboom 2024 年 8 月 21 日 亲亲你可能在使用移动或者广电等宽带呢 |
 | 4 crc8 OP @hefish 请赐教，服务器是 ubuntu ， 默认 TTL 是 64 ，ping 的 TTL 结果与 tracert 的跳数存在对应关系吗？比如 ping 的 TTL 为 51 ，则可计算到 tracert 的跳数应为 64-51=13 跳，如此，ping 的 TTL=49 时，跳数应为 15 跳，实际上我反复测试过一直是 13 跳，从未出现过 15 跳的情况。 莫非 tracert 的结果跳数还可以主动隐藏起来？ |
 | 6 htfcuddles 2024 年 8 月 22 日 路由会有多条负载均衡的，跳数当然也会变，联通特别明显，最多时候有三四条。另外，有些路由会设置超时 ICMP 黑洞或者走不同路由，有些路由干脆不减 TTL 。 |
 | 7 shcsc 2024 年 8 月 22 日 1 、负载均衡 2 、来回程不一致 3 、多路径路由 |
| 8 hefish 2024 年 8 月 22 日 @crc8 这个就要问具体运营商了，traceroute 的 icmp 包和 ping 的 icmp 包不是同一种类型的，完全可以分流处理的。 另外，windows 下自带的 tracert 是同时使用 icmp 和 udp 的，而 linux 和 mac 自带的 traceroute 好像是只用 udp 的。 我学 tcp/ip 的时候是这样了，过了十来年了，windows,linux,mac 都升级了好多版本了，不知道目前的情况是不是还是这样 。 |
| 9 hefish 2024 年 8 月 22 日 @hefish 啊，现在 linux 下是可以选择使用哪个协议的。icmp/ucp/tcp 都可以。默认情况下是 udp 。 这些是 man traceroute 时候查到的。win10 下的情况现在不清楚。 |
| 10 crc8 OP @htfcuddles 是不是可以理解为 ping 结果中的 TTL 数字与 tracert 结果中的跳数，没有必然的联系？ |
| 11 htfcuddles 2024 年 8 月 22 日 @crc8 #10 tracert 中 TTL 是按接收的 ICMP 包显示的，但有防不住些路由不遵守规则，经过时不减一 |
| 12 crc8 OP @htfcuddles 即是说 tracert 结果中的跳数非 100%准确，ping 结果中的 TTL 是相对准确的？ 拿我这个案例来说，只能说明客户端与服务器之间经过 13-15 个路由器，而不能确定是某个数？ |
| 13 htfcuddles 2024 年 8 月 22 日 @crc8 #12 如果不减 TTL 是一样的，你用 Linux 下的 traceroute 更容易发现多径路由，windows 下的不准确。 |
| 14 crc8 OP @htfcuddles 刚用 Linux 与 windows 测试，ping TTL=49 都是 49 。tracert 跳数都是 14 跳。 |
Select Language