16

我可以在 Chrome 中加载 www.cnn.com，但是当我从命令行 (OSX) 执行跟踪路由时，它在 level3.net 处超时

我使用此 Chrome 扩展程序来验证 Chrome 用于 www.cnn.com 的 IP（我无法通过 Chrome 调试器找到查看 IP 地址的方法）： https ://chrome.google.com/webstore/detail/ ipvfoo/ecanpcehffngcegjmadlcijfolapggal

当我使用 CLI 跟踪路由到同一个 IP 地址时，它会超时？？

在这种情况下，是否有任何诊断可以找出或理解为什么 traceroute 会超时？我认为 traceroute 和浏览器都使用相同的操作系统网络层来路由 TCP/IP 流量？

4

2 回答 2

54

如果一路上的路由器决定不发送超过 ICMP 时间（即到达途中的 TTL）或目的地不可达消息（即 UDP 数据包到达最终主机但端口关闭，但行为正确），您将获得超时点在跟踪路由中。

简而言之，如果您正在运行一个traceroute xyz基于 UDP 的跟踪路由，即发送具有低 TTL 的 UDP 数据包，从 1 开始，每步增加 1。如果您的数据包在路由器处死掉，即 TTL 变为 0，那么根据 RFC 792 和其他一些标准，该路由器应该发送 ICMP“超时”消息，也就是说我们无法在时间范围内交付数据包，但至少我们告诉你你的包裹死了。

还有其他两种方法可以进行跟踪路由，如果您想更好地理解差异，我建议您使用手册页寻求帮助，例如这个。但总之你也可以发送ICMP Echo 数据包或TCP SYN 数据包。总而言之，有三种方法都基于不断增加的 TTL 来映射路由上的“主机”：

  • UDP 到低 TTL 主机上的随机端口（通常为 33434 + 100）
    • 根据我的经验，所有命令行工具的默认设置，例如traceroute和tracert
  • ICMP Echo 以低 TTL 托管
    • 我在几个图形工具中遇到过这种情况，也是大多数命令行工具的一个选项。
  • TCP SYN，通常到端口 80，这样流量被“有点”屏蔽为 http 流量通过许多路由器，这些路由器通常将 ICMP Echo 和 UDP 数据包丢弃到奇怪的端口。
    • 巧妙的技巧和“新”方法，虽然非正统，用于寻找到主机的路线。非常规，因为您在某种程度上滥用了 Internet 标准。作为大多数命令行工具的选项存在。

路由器可能会传递正常流量，从而允许您完成基于 TCP 的 http 请求，但它可能会默默地将 UDP 丢弃到奇怪的端口，将 TCP 半开放到奇怪的端口或具有低 TTL 的 ICMP ping，让您的本地跟踪路由进程等待，然后在那一站超时。

于 2013-05-11T17:16:53.240 回答
-1

Traceroute 依靠网络服务器在您的数据解析路径时返回响应。这些服务器没有义务为您提供响应或响应您的跟踪路由。因此，即使您的数据到达了它要去的地方，您的 traceroute 也会被卡在等待没有出现的响应。

如果您和 cnn.com 之间的服务器决定不为您的 traceroute 发送响应，它可以截断剩余的响应。

于 2013-05-11T17:17:07.437 回答