在 Windows 上,如果我 tracert 到 Google,我会得到以下信息;
C:\Users\Dave>tracert -d -w 100 www.google.com
Tracing route to www.google.com [216.58.220.100]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 17 ms * 16 ms [redacted]
3 17 ms 16 ms 17 ms [redacted]
4 34 ms 34 ms 34 ms 150.101.33.18
5 35 ms 43 ms 33 ms 72.14.221.174
6 33 ms 33 ms 33 ms 66.249.95.234
7 31 ms 31 ms 31 ms 209.85.142.11
8 33 ms 33 ms 38 ms 216.58.220.100
Trace complete.
现在,如果我 ping 倒数第三个 IP 地址 66.249.95.234,我会得到这个...
C:\Users\Dave>ping 66.249.95.234
Pinging 66.249.95.234 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 66.249.95.234:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
tracert 内部的“ping”与真正的 ping 有何不同?它们有何不同?我需要做什么才能让 ping 像 tracert 一样工作?
答案1
这一切都与 tracert 的工作方式有关。Ping 是从 A 点到 B 点的直接 ICMP,通过路由规则穿越网络。Tracert 的工作方式非常不同,尽管它使用 ICMP。
Tracert 的工作方式是,以最后一跳为目标,但限制 TTL 并等待超时消息,然后在下一次迭代中将其增加一。因此,它得到的响应不是沿途主机对 ICMP 回显请求的 ICMP 回显回复,而是来自该主机的超时消息 - 因此,即使它使用 ICMP,它也以非常不同的方式使用它。
您可以阅读更多详细信息这里。
答案2
首先,您的两个命令发送的数据包具有不同的目标 IP 地址。这意味着它们可能采用不同的路由。
当您看到66.249.95.234
通往的路线时216.58.220.100
,您可能会认为具有目标地址的数据包66.249.95.234
将使用相同的路线直到到达该点。然而,这并不是一个有效的假设。
66.249.95.234
到 的路由比到 的路由长是完全合理的216.58.220.100
。有时甚至会发生没有路由可以将数据包传送到中间路由器的情况,但如果是这种情况,那么它就不是一个设计良好的网络。
我不知道您使用的tracert
和ping
命令是否都使用相同的协议。大多数 ping 实现都使用 ICMP 回显请求数据包。但是,traceroute 实现支持多种协议,包括 ICMP 回显请求、TCP SYN 和 UDP 数据包。如果两者恰好使用不同的协议,则这可能是导致结果不同的一个因素。
最后,即使所有数据包都到达66.249.95.234
,也可能66.249.95.234
会根据是否需要采取以下行动而表现出截然不同的行为:
- 转发数据包
- 对发往自身的数据包产生 ICMP 错误
- 对发送给其他人的数据包产生 ICMP 错误
选择在这三种情况中的任意一种情况下静默丢弃数据包显然会破坏许多网络诊断工具,但是这并不能阻止一些系统管理员这样做。
答案3
随着网络安全性的不断提高,现在许多人都会做的一件简单的事情就是禁用 ICMP 协议的各个方面。这可以防止响应跟踪路由并从跳转返回 FQDN。有时管理员会将事情锁定得非常严格,以至于 ping 都不起作用。这是所涉及系统管理员的决定。
还有一种可能是,系统正在处理大量的网络负载,与实际数据相比,ICMP 的处理优先级通常很低。