当 traceroute 始终打印带有“6 * * *”的一行时，是否存在需要修复的问题？

Question

我想弄清楚为什么我无法从 Mac OSX Yosemite 访问特定网站。服务提供商建议我运行一个traceroute，当我这样做时，无论目的地如何，我都会得到如下结果：

traceroute to google.com (74.125.239.96), 64 hops max, 52 byte packets
 1  10.1.10.1 (10.1.10.1) 60 bytes to 10.1.10.14  1.398 ms  1.423 ms  1.202 ms
 2  24.4.6.1 (24.4.6.1) 36 bytes to 10.1.10.14  11.383 ms  9.741 ms  9.311 ms
 3  te-0-2-0-12-sur04.santaclara.ca.sfba.comcast.net (162.151.30.169) 76 bytes to 10.1.10.14  9.483 ms  10.148 ms  9.452 ms
 4  te-0-5-0-8-sur03.santaclara.ca.sfba.comcast.net (162.151.78.109) 76 bytes to 10.1.10.14  9.690 ms
    te-0-5-0-9-sur03.santaclara.ca.sfba.comcast.net (162.151.78.113) 76 bytes to 10.1.10.14  9.923 ms
    te-0-5-0-2-sur03.santaclara.ca.sfba.comcast.net (69.139.198.41) 76 bytes to 10.1.10.14  10.323 ms
 5  be-232-ar01.santaclara.ca.sfba.comcast.net (162.151.78.253) 76 bytes to 10.1.10.14  12.258 ms  13.268 ms  9.708 ms
 6  * * *
 7  he-0-10-0-0-pe03.11greatoaks.ca.ibone.comcast.net (68.86.85.214) 76 bytes to 10.1.10.14  15.528 ms
    he-0-13-0-0-pe03.11greatoaks.ca.ibone.comcast.net (68.86.83.134) 76 bytes to 10.1.10.14  11.379 ms
    he-0-15-0-1-pe03.11greatoaks.ca.ibone.comcast.net (68.86.86.222) 76 bytes to 10.1.10.14  11.174 ms
 8  173.167.59.66 (173.167.59.66) 36 bytes to 10.1.10.14  14.655 ms
    66-208-228-70.ubr01a.hurtl301.al.hfc.comcastbusiness.net (66.208.228.70) 36 bytes to 10.1.10.14  10.514 ms
    173.167.59.66 (173.167.59.66) 36 bytes to 10.1.10.14  35.888 ms
 9  72.14.232.138 (72.14.232.138) 36 bytes to 10.1.10.14  10.164 ms
    209.85.241.55 (209.85.241.55) 36 bytes to 10.1.10.14  13.837 ms  15.349 ms
10  66.249.95.29 (66.249.95.29) 36 bytes to 10.1.10.14  13.930 ms  10.773 ms  15.731 ms
11  nuq05s01-in-f0.1e100.net (74.125.239.96) 60 bytes to 10.1.10.14  12.693 ms  16.125 ms  11.041 ms

注意第6步，三个星号（*），打印的时候很慢，每一个大约需要四秒钟才会出现。根据手册页：

如果在 5 秒内没有响应。超时间隔（随 -w 标志更改），会为该探测器打印“*”。

为什么第 6 行没有探测器的名称，或者只是第 7 行？我注意到另一个 Comcast 服务提供的位置的类似结果。我是否应该与康卡斯特交谈，如果是这样，我会要求他们解决什么问题？此问题是否表示无法正常访问特定网站？除了在访问顶部提到的网站时遇到周期性问题之外，我还遇到VNC了与完全无关的系统的会话的周期性问题，该系统有 3 到 4 秒的超时，其中屏幕没有刷新。运行 a traceroute，我发现了该目的地的类似问题。几个月来，我一直在断断续续地看到这些问题，但traceroute一直在超时。

Answer 1

不，关于您的跟踪路由，没有什么可以解决的。

首先，该列表中唯一不是路由器的设备是第一个和最后一个。每跳代表一个路由器。其中一些路由器可能不在公共地址空间中，在这种情况下，它们无法显示跃点名称。由于您在第 6 跳之后有跳数，因此这不会导致您在访问特定服务器时遇到任何问题。

其次，这与您的 VNC 质量或任何其他服务无关，只是它们共享超时间隔。Traceroute 根本不测​​试连接的质量，只测试其连通性。没有迹象表明在第 6 跳通过设备的实际流量会超时。Traceroute 纯粹是一种诊断性的东西，路由器的处理方式与正常流量不同，例如检索网页或在 VNC 连接中发送数据包。

具体来说，当数据包因 TTL 被丢弃（或者它可能根本不接受 ICMP PING/ECHO 请求）时，第 6 跳设备的操作员选择不发送ICMP TTL Exceeded 消息。无论哪种方式，这是别人的设备，他们有权以自己喜欢的方式运行它。如果路由器没有响应 TTL Exceeded 消息，traceroute 将不会打印其名称或 IP。

如果有帮助，大多数人无法获得与您在自己和 Google 之间获得的信息一样多的信息。我只能看到我和他们之间大约 3 跳。所有其余的跃点超时。