traceroute如何超时,但该网站在浏览器中可以正常加载？

我可以在Chrome中加载www.cnn.com,但是当我从命令行(OSX)执行traceroute时,它会在level3.net上超时

我使用此Chrome扩展程序来验证Chrome用于www.cnn.com的IP(我找不到使用Chrome调试程序查看IP地址的方法):https: //chrome.google.com/webstore/detail/ ipvfoo/ecanpcehffngcegjmadlcijfolapggal

当我使用CLI跟踪路由到相同的IP地址时,它会超时？

是否有任何诊断来弄清楚或理解为什么traceroute在这种情况下超时？我认为traceroute和浏览器都使用相同的OS网络层来路由TCP/IP流量？

如果一路上的路由器决定不发送ICMP超时时间(即TTL到达途中)或目的地不可达消息(即UDP数据包到达最终主机但端口已关闭,但正常行为),您将获得超时指向traceroute.

简而言之,如果您正在运行,traceroute xyz您正在执行所谓的基于UDP的traceroute,即从1开始发送具有低TTL的UDP数据包,并且每步增加1.如果你在路由器上丢包,即TTL变为0,根据RFC 792和其他一些路由器,该路由器应该发送ICMP"超时"消息,因为我们说我们无法在时间范围内交付包,但至少我们告诉你,你的包裹已经死了.

还有另外两种方法可以进行traceroute ,如果你想更好地理解这些差异,我建议使用man-page寻求帮助,比如这个.但总之,您还可以发送ICMP Echo数据包或TCP SYN数据包.总而言之,有三种方法都基于不断增加的TTL来映射路径中的"主机":

在具有低TTL的主机上UDP到随机端口(通常为33434 + 100)

根据我的经验,所有命令行工具的默认值,例如traceroute和tracert

ICMP Echo以低TTL为主机

我在几个图形工具中遇到过这个问题,也是大多数命令行工具的选项.

TCP SYN,通常是端口80,这样,流量被"有点"屏蔽,因为http流量被许多路由器传递,这些路由器通常将ICMP回声和UDP数据包丢弃到奇怪的端口.

整齐的技巧和"新"方法,虽然不是正统的,用于寻找到主机的路线.非正统的,因为你在某种程度上错过了互联网标准.存在作为大多数命令行工具的选项.

路由器可以传递正常流量,从而允许基于TCP的http请求完成,但它可以静默地将UDP丢弃到奇怪的端口,半开TCP到奇怪的端口或低TTL的ICMP ping,让你的本地traceroute进程等待然后在那个站点上超时.