我可以在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流量?
答案 0 :(得分:46)
如果一路上的路由器决定不发送ICMP超时时间(即TTL到达途中)或目的地不可达消息(即UDP数据包到达最终主机但端口已关闭,但正常行为),您将得到一个traceroute中该点的超时。
简而言之,如果您正在运行traceroute xyz
,那么您正在执行所谓的基于UDP的traceroute,即从1开始发送具有低TTL的UDP数据包,并且每步增加1。如果你在路由器上丢包,即TTL变为0,根据RFC 792和其他一些路由器,该路由器应该发送ICMP“超时”消息,因为我们说我们无法在时间范围内交付包,但至少我们告诉你,你的包裹已经死了。
还有另外两种方法可以执行traceroute,如果您想更好地理解差异,我建议使用手册页来寻求帮助,例如this one。但总之,您还可以发送ICMP Echo数据包或TCP SYN数据包。总而言之,有三种方法都基于不断增加的TTL来映射路径中的“主机”:
traceroute
和tracert
路由器可以传递正常流量,从而允许基于TCP的http请求完成,但它可以静默地将UDP丢弃到奇怪的端口,半开TCP到奇怪的端口或低TTL的ICMP ping,留下本地traceroute进程等待,然后在那个站点上超时。
答案 1 :(得分:0)
当您的数据解析路径时,Traceroute依赖Web服务器返回响应。这些服务器没有义务为您提供响应或响应您的traceroute。因此,即使您的数据已经到达目的地,您的traceroute仍会等待未响应的响应。
如果您和cnn.com之间的服务器决定不为您的traceroute发送响应,则可以截断剩余的响应。