技术支持人员多次尝试修复问题，但都以失败告终，这让我认为问题出在 Verizon 网络深处。但我想快速检查一下，因为我对读取跟踪路由不是很有经验。基本上，这个问题表现为网站间歇性无法加载——这不是速度问题（速度测试很快，流媒体视频也很快），而是与建立连接相关的其他问题。
（我相信我遇到的问题与这里描述的问题非常相似，而且我在新泽西州，所以这很有意义：http://ireport.cnn.com/docs/DOC-1164097另请参阅这里。
以下是跟踪路由的结果：
bash-3.2$ traceroute -S -q 5 www.latimes.com
traceroute: Warning: www.latimes.com has multiple addresses; using 63.88.100.192
traceroute to a1574.w3.akamai.net (63.88.100.192), 64 hops max, 52 byte packets
1 192.168.1.1 (192.168.1.1) 0.711 ms 0.436 ms 0.428 ms 0.450 ms 0.402 ms (0% loss)
2 l100.nwrknj-vfttp-119.verizon-gni.net (72.88.205.1) 6.323 ms 5.500 ms 5.011 ms 9.535 ms 5.408 ms (0% loss)
3 g0-14-4-7.nwrknj-lcr-22.verizon-gni.net (130.81.59.168) 9.588 ms 9.821 ms 9.469 ms 10.493 ms 8.836 ms (0% loss)
4 * ae2-0.nwrk-bb-rtr2.verizon-gni.net (130.81.209.170) 91.449 ms * 82.672 ms
so-6-1-0-0.nwrk-bb-rtr2.verizon-gni.net (130.81.199.16) 9.064 ms (40% loss)
5 0.xe-3-0-2.xl4.ewr6.alter.net (152.63.5.193) 41.877 ms 25.767 ms
0.ae2.xl4.ewr6.alter.net (140.222.228.45) 7.568 ms 11.517 ms
0.xe-3-0-2.xl4.ewr6.alter.net (152.63.5.193) 17.856 ms (0% loss)
6 tengige0-7-0-0.gw8.ewr6.alter.net (152.63.17.254) 8.606 ms
tengige0-5-0-3.gw8.ewr6.alter.net (152.63.21.50) 7.215 ms 8.632 ms
tengige0-7-0-7.gw8.ewr6.alter.net (152.63.25.30) 14.960 ms
tengige0-7-0-5.gw8.ewr6.alter.net (152.63.25.22) 14.219 ms (0% loss)
7 63.88.100.192 (63.88.100.192) 8.519 ms 9.845 ms 8.241 ms 9.538 ms 9.036 ms (0% loss)
bash-3.2$ traceroute -S -q 5 bing.com
traceroute to bing.com (204.79.197.200), 64 hops max, 52 byte packets
1 192.168.1.1 (192.168.1.1) 0.582 ms 0.434 ms 0.412 ms 0.406 ms 0.396 ms (0% loss)
2 l100.nwrknj-vfttp-119.verizon-gni.net (72.88.205.1) 6.715 ms 5.527 ms 5.293 ms 4.987 ms 5.250 ms (0% loss)
3 g0-9-1-7.nwrknj-lcr-22.verizon-gni.net (100.41.201.78) 9.006 ms 7.372 ms 8.035 ms 8.325 ms 7.870 ms (0% loss)
4 ae0-0.nwrk-bb-rtr2.verizon-gni.net (130.81.209.162) 10.290 ms *
ae4-0.nwrk-bb-rtr2.verizon-gni.net (130.81.199.194) 53.058 ms 7.630 ms
so-6-1-0-0.nwrk-bb-rtr2.verizon-gni.net (130.81.199.16) 7.587 ms (20% loss)
5 * * 0.ae4.xl4.nyc1.alter.net (140.222.226.37) 9.048 ms * * (80% loss)
6 0.ae4.xl4.nyc1.alter.net (140.222.226.37) 8.220 ms 7.500 ms 6.423 ms 7.539 ms 6.716 ms (0% loss)
7 0.xe-9-0-0.gw13.nyc1.alter.net (152.63.19.61) 8.367 ms
0.xe-11-1-1.gw13.nyc1.alter.net (152.63.19.57) 8.623 ms
0.xe-9-2-0.gw13.nyc1.alter.net (152.63.4.145) 17.875 ms
0.xe-11-0-1.gw13.nyc1.alter.net (152.63.20.173) 7.964 ms
microsoft-gw.customer.alter.net (152.179.29.234) 7.954 ms (0% loss)
8 microsoft-gw.customer.alter.net (152.179.29.234) 7.382 ms 8.597 ms
191.234.230.207 (191.234.230.207) 7.836 ms 7.797 ms
torl.nycr2.msedge.net (131.253.32.127) 6.827 ms (0% loss)
9 * torl.nycr2.msedge.net (131.253.32.127) 7.942 ms 7.743 ms 8.254 ms 7.446 ms (20% loss)
10 * * * * * (100% loss)
bash-3.2$ traceroute -S -q 5 www.slashdot.org
traceroute to www.slashdot.org (216.34.181.48), 64 hops max, 52 byte packets
1 192.168.1.1 (192.168.1.1) 0.573 ms 0.445 ms 0.398 ms 0.404 ms 0.405 ms (0% loss)
2 l100.nwrknj-vfttp-119.verizon-gni.net (72.88.205.1) 6.544 ms 5.406 ms 5.037 ms 5.907 ms 9.706 ms (0% loss)
3 g0-9-3-2.nwrknj-lcr-22.verizon-gni.net (130.81.133.46) 9.577 ms 6.881 ms 7.517 ms 8.104 ms 8.325 ms (0% loss)
4 ae2-0.nwrk-bb-rtr2.verizon-gni.net (130.81.209.170) 53.079 ms
ae4-0.nwrk-bb-rtr2.verizon-gni.net (130.81.199.194) 54.713 ms *
ae2-0.nwrk-bb-rtr2.verizon-gni.net (130.81.209.170) 26.503 ms 7.601 ms (20% loss)
5 0.ae1.br1.iad8.alter.net (140.222.229.163) 15.713 ms
xe-15-0-6-0.res-bb-rtr2.verizon-gni.net (130.81.23.161) 17.231 ms 16.871 ms 16.416 ms
0.ae1.br1.iad8.alter.net (140.222.229.163) 14.735 ms (0% loss)
6 * * ber1-ge-7-45.virginiaequinix.savvis.net (208.173.52.81) 15.096 ms 14.452 ms * (60% loss)
7 * * * * * (100% loss)
8 0.ae2.br1.iad8.alter.net (140.222.229.165) 17.779 ms 18.334 ms 18.508 ms
206.28.96.218 (206.28.96.218) 37.857 ms
0.ae2.br1.iad8.alter.net (140.222.229.165) 17.535 ms (0% loss)
9 ber1-ge-7-45.virginiaequinix.savvis.net (208.173.52.81) 17.107 ms 17.664 ms 17.768 ms 17.026 ms 16.014 ms (0% loss)
10 cr2-tengig0-8-5-0.washington.savvis.net (204.70.206.241) 20.793 ms 19.787 ms
das6-v3034.ch3.savvis.net (64.37.207.166) 39.962 ms
cr2-tengig0-8-5-0.washington.savvis.net (204.70.206.241) 19.116 ms
das6-v3034.ch3.savvis.net (64.37.207.166) 39.895 ms (0% loss)
11 64.27.160.198 (64.27.160.198) 37.568 ms
206.28.96.218 (206.28.96.218) 39.595 ms
64.27.160.198 (64.27.160.198) 39.330 ms
206.28.96.218 (206.28.96.218) 40.668 ms 39.726 ms (0% loss)
12 hr1-te-12-0-1.elkgrovech3.savvis.net (204.70.198.73) 42.953 ms 46.232 ms 44.017 ms 43.542 ms 42.858 ms (0% loss)
13 star.slashdot.org (216.34.181.48) 41.410 ms
das6-v3034.ch3.savvis.net (64.37.207.166) 41.214 ms 41.491 ms 42.815 ms 42.055 ms (0% loss)
我知道跟踪路由很难解释，这就是我发帖的原因。我相信这些表明 Verizon 网络内有大量数据包丢失，而 alter.net 似乎是一个特殊问题。我解释得对吗？我多次将它们发送给 Verizon 技术人员，但他们没有以某种方式表明他们对此的看法...
我还应该尝试其他诊断方法吗？我在 hostmycalls.com 上注册，以便从运行跟踪路由到我的计算机（即反向）的服务器获取结果。以下是这些结果显示的内容（抱歉，无法发布图片）：
www.dropbox.com/s/w8qye03qqi16b1m/isproute.png?dl=0
更新
以下是 MTR 报告——我认为这与速率限制的解释一致，对吧？结论是没有任何迹象表明存在问题。我好奇的是最后一个——192.168.1.1 丢失 40%（最后丢失 10%）——怎么会这样？：
bash-3.2$ sudo ./mtr --report www.google.com
HOST: iMac-2.local Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 10 0.5 0.5 0.4 0.5 0.0
2. l100.nwrknj-vfttp-119.verizo 0.0% 10 147.5 23.6 4.4 147.5 45.1
3. g0-9-1-1.nwrknj-lcr-22.veriz 0.0% 10 6.9 9.2 6.3 11.5 1.7
4. ae2-0.nwrk-bb-rtr2.verizon-g 0.0% 10 8.7 19.1 7.2 47.7 13.9
5. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
6. 2.ae0.xt2.nyc4.alter.net 0.0% 10 8.2 16.1 7.9 47.9 15.7
7. tengige0-7-0-8.gw8.nyc4.alte 0.0% 10 20.5 14.4 9.2 20.8 4.8
8. google-gw.customer.alter.net 10.0% 10 8.3 9.1 8.0 10.7 1.0
9. 209.85.255.68 0.0% 10 24.7 13.6 8.0 40.1 10.6
10. 72.14.239.245 0.0% 10 10.6 10.6 9.4 15.2 1.7
11. lga15s46-in-f20.1e100.net 0.0% 10 9.8 9.5 8.5 10.2 0.6
bash-3.2$ sudo ./mtr --report www.yahoo.com
HOST: iMac-2.local Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 10 0.4 0.5 0.4 0.5 0.0
2. l100.nwrknj-vfttp-119.verizo 0.0% 10 4.8 14.6 4.5 77.9 23.2
3. g0-9-1-1.nwrknj-lcr-22.veriz 0.0% 10 7.1 8.3 7.0 10.0 1.1
4. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
5. 0.ae2.br1.nyc1.alter.net 0.0% 10 8.4 9.6 8.3 11.0 0.8
6. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
7. ae-1-60.edge4.newyork1.level 0.0% 10 9.8 17.0 9.5 74.2 20.2
8. ae-1-60.edge4.newyork1.level 0.0% 10 10.1 17.4 8.6 81.9 22.7
9. yahoo-inc.edge4.newyork1.lev 0.0% 10 8.4 11.7 8.4 33.2 7.6
10. ae-2.pat1.bfz.yahoo.com 0.0% 10 20.9 31.9 17.6 100.8 26.1
11. ae-4.msr1.bf1.yahoo.com 0.0% 10 20.1 23.5 18.6 55.9 11.4
12. unknown-98-139-130-x.yahoo.c 0.0% 10 20.3 20.7 17.8 22.2 1.3
13. et-17-1.fab3-1-gdc.bf1.yahoo 0.0% 10 22.3 21.0 18.9 22.6 1.3
14. po-10.bas1-7-prd.bf1.yahoo.c 0.0% 10 22.3 21.5 18.1 23.8 1.8
15. ir2.fp.vip.bf1.yahoo.com 0.0% 10 23.0 20.9 19.0 23.0 1.3
bash-3.2$ sudo ./mtr --report bbcnews.com
HOST: iMac-2.local Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 40.0% 10 0.4 0.5 0.4 0.7 0.1
2. l100.nwrknj-vfttp-119.verizo 0.0% 10 7.5 10.1 5.0 45.2 12.4
3. g0-14-4-7.nwrknj-lcr-21.veri 0.0% 10 6.6 7.7 6.0 10.7 1.5
4. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
5. 2.ae1.xt1.nyc4.alter.net 0.0% 10 8.0 12.4 7.6 37.3 10.0
6. gigabitethernet4-0-0.gw1.nyc 0.0% 10 7.0 7.2 6.3 7.8 0.4
7. teliasonera-test.customer.al 0.0% 10 6.6 6.7 6.1 7.0 0.3
8. nyk-bb2-link.telia.net 0.0% 10 32.3 26.2 9.2 78.9 24.4
9. ldn-bb2-link.telia.net 0.0% 10 95.6 88.2 83.0 115.9 10.4
10. ldn-b3-link.telia.net 0.0% 10 81.7 85.5 81.7 88.1 1.9
11. atos-ic-124708-ldn-b2.c.teli 0.0% 10 82.0 78.3 76.7 82.0 1.5
12. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
13. ae1.er02.thdow.bbc.co.uk 0.0% 10 79.8 79.4 78.0 81.6 1.0
14. ae5-vrf-mitigate.thdow.bbc.c 0.0% 10 80.0 78.5 76.9 80.0 0.8
15. ae0.er01.thdow.bbc.co.uk 0.0% 10 79.0 79.7 78.0 84.4 1.8
16. 132.185.255.92 0.0% 10 79.1 78.5 77.4 80.6 0.9
17. virtual-vip.thdo.bbc.co.uk 10.0% 10 77.8 80.0 76.6 99.5 7.3
答案1
要有效使用 traceroute，您需要了解它的实际作用。Tracert 是一种路径确定工具。它不是数据包丢失分析工具。
Traceroute 会将数据包/数据报（实际上是多个）发送到从源到目标的路径上的每个路由器。这些路由器中的任何一个或全部都可能配置为丢弃或给予发往自己的数据包/数据报低优先级，因为路由器的工作是转发真实的流量，不回复 ping 和 traceroute。您在跟踪中看到的很可能是这些路由器正在这样做。这些路由器可能会丢弃真实的流量，但后续路由器没有显示这一点，因为它们没有显示相同或更多的数据包丢失。如果这些路由器确实有数据包丢失，那么您也会在所有后续路由器上看到一定程度的数据包丢失。否则，一个路由器如何可能丢失 40% 的流量而后续路由器没有显示一定程度的数据包丢失？事实并非如此。
我在您的跟踪路由中看到的唯一真正问题是您到 bing.com 的跟踪路由，这不是您的 ISP 的问题，而是管理 msedge.net 网络的人的问题（可能是 Microsoft）。现在可能是他们只是丢弃/阻止了所有传入到他们网络的跟踪路由、ping 等流量，但我能够成功跟踪到 bing.com，所以我认为情况并非如此。无论如何，我在您的任何跟踪中都没有看到任何表明您的 ISP 存在问题的信息。
总结一下：traceroute 是一种路径确定工具，而不是数据包丢失分析工具。如果要测试路径的数据包丢失，则需要使用可以测试该情况的工具，例如 pathping、MTR 或 iperf。请参阅 MTR 网页上有关数据包丢失的说明：
答案2
@joeqwerty 是绝对正确的 - 不过要扩展他的答案的部分内容 -
从阅读 ireport.cnn.com/docs/DOC-1164097 页面来看，这个问题似乎与您所看到的内容完全无关。
没有什么明显的问题（请记住，我身处世界的另一端，尽管我运行过几个 ISP）。我确实注意到“HostMyCalls”AvgDelay/ms 问题不一定是主要问题 - 您的数据包丢失可以忽略不计，并且延迟 - 虽然高于理想的 < 30ms 并不表示存在任何重大问题。无论如何，这与网站无法加载无关。
如果网站没有加载，但你可以 ping 通该网站（即使出现数据包丢失），这通常意味着存在防火墙问题或缓存损坏。 我要做的第一件事是看看它是否适用于其他浏览器 - 如果可以，请尝试清除常规浏览器的缓存。浏览器缓存损坏导致页面无法加载是一个令人惊讶的常见问题。