想改善这个问题吗？ Update the question，所以它是on-topic，用于堆栈溢出。
7年前关闭。
Improve this question
我可以在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的跟踪路由，即发送具有低TTL的UDP数据包，从1开始，每步增加1。如果您在路由器上死了包，即TTL变为0，则该路由器应根据RFC 792和其他一些规定发送ICMP“超时”消息，因此我们无法在规定的时间内交付包裹，但至少我们告诉您您的包裹已死亡。
还有两种其他方法可以执行跟踪路由，如果您想更好地了解它们之间的区别，建议您参考手册页以获得帮助，例如this one。简而言之，您还可以发送ICMP Echo数据包或TCP SYN数据包。概括地说，有三种方法都基于不断增加的TTL来沿路径映射“主机”：
UDP到低TTL主机上的随机端口（通常为33434 + 100）
以我的经验，所有命令行工具（例如traceroute和tracert）的默认设置
ICMP回音以低TTL主机
我已经在几个图形工具中遇到了这个问题，这也是大多数命令行工具的一种选择。
TCP SYN，通常到端口80，这样，由于许多路由器将http流量传递出去，因此流量被“某种程度”地掩盖了，这些路由器通常将ICMP Echoes和UDP数据包丢弃到奇怪的端口。
整洁的技巧和“新的”方法，尽管这是非传统的，但它可以找到通往宿主的路线。不合常规的是，您在某种程度上滥用Internet标准。作为大多数命令行工具的选项存在。
路由器可能会传递正常流量，从而使您基于TCP的http请求得以完成，但是它可能会默默地将UDP丢弃到怪异的端口，将TCP半开放地打开到怪异的端口或TTL低的ICMP ping，从而使本地traceroute进程等待，然后在该站上暂停。
关于traceroute - traceroute怎么可能超时，但是该站点在浏览器中可以正常加载？ ，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/16499694/