为什么traceroute会超时，而站点却可以在浏览器中正常加载？

Question

我可以在Chrome中加载www.cnn.com，但是当我从命令行执行traceroute时，它在level3.net超时

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

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

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

Answer 1

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

简而言之，如果您正在运行traceroute xyz，您正在执行的是所谓的基于UDP的traceroute，即发送具有低TTL的UDP数据包，从1开始，每一步递增1。如果您的数据包在路由器上死亡，即TTL变为0，根据RFC 792和其他一些路由器，该路由器应该发送ICMP“超时”消息，因此说我们无法在时间范围内递送数据包，但至少我们告诉您您的数据包死亡。

还有另外两种执行traceroute的方法，如果你想更好地理解它们之间的区别，我推荐使用手册页的帮助，比如this one。但简而言之，您还可以发送ICMP Echo数据包或TCP SYN数据包。总而言之，有三种方法都是基于不断增加的TTL来映射路由上的“主机”：

• UDP到主机上的随机端口(通常为33434 + 100)，根据我的经验，所有命令行工具(如traceroute和tracert

)的默认TTL

• 都很低

​

• ICMP Echo to host with low TTL
  • 我在一些图形工具中遇到过这一点，也是大多数命令行ICMP的一个选项

​

• TCP，通常是到端口80，这样流量就被“某种”掩蔽，因为http流量是由许多路由器传递的，这些路由器通常会将ICMP回显和UDP数据包丢弃到奇怪的端口。
  • 巧妙的技巧和“新”方法，虽然不是正统的，但却能找到通往主机的路由。非正统的是，你在某种程度上错过了互联网标准。作为大多数命令行tools.

的选项存在

​

路由器可能会传递正常通信量，从而允许您完成基于TCP的http请求，但它可能会将UDP静默丢弃到奇怪的端口，将TCP半开放给奇怪的端口或TTL较低的ICMP ping，使本地traceroute进程等待，然后在停止时超时。

Answer 2

Traceroute依赖于webservers来返回响应，因为您的数据解析了路径。这些服务器没有义务向您提供响应或响应您的traceroute。因此，您的traceroute停滞不前，等待没有响应，即使您的数据到达了它要去的地方。

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