白天通常一切正常，但到了晚上，任何需要带宽（我有一个 30mbps 光纤连接，尽管我不认为它是端到端光纤）或稳定连接（即游戏）的东西都完全没用。我捕获了一些 WinMTR 跟踪，很明显，只要我们经过我的调制解调器，就会在多个地方发生一些数据包丢失：
|------------------------------------------------------------------------------------------| | WinMTR statistics | | Host - % | Sent | Recv | Best | Avrg | Wrst | Last | |------------------------------------------------|------|------|------|------|------|------| | 192.168.1.1 - 0 | 886 | 886 | 0 | 0 | 21 | 0 | | 192.168.200.1 - 0 | 886 | 886 | 0 | 0 | 3 | 0 | | EV1-DSL-208-102-228-1.fuse.net - 88 | 185 | 23 | 0 | 3315 | 4530 | 4088 | | 172.17.74.18 - 2 | 827 | 812 | 27 | 30 | 34 | 30 | | EV-ZT-1.EVE1.core.fuse.net - 2 | 839 | 827 | 27 | 30 | 68 | 30 | |te0-0-2-2.nr11.b016343-1.cvg02.atlas.cogentco.com - 2 | 823 | 807 | 28 | 30 | 35 | 31 | |te0-0-1-1.rcr11.cvg02.atlas.cogentco.com - 4 | 791 | 767 | 28 | 31 | 36 | 31 | |te0-2-0-0.rcr21.ind01.atlas.cogentco.com - 3 | 819 | 802 | 30 | 33 | 37 | 34 | |te0-0-2-2.rcr11.sdf01.atlas.cogentco.com - 2 | 823 | 807 | 32 | 35 | 39 | 36 | |te0-0-2-2.rcr11.bna01.atlas.cogentco.com - 3 | 819 | 802 | 37 | 39 | 43 | 40 | |te0-18-0-34.ccr42.atl01.atlas.cogentco.com - 3 | 799 | 777 | 43 | 45 | 50 | 45 | | be2173.ccr22.iah01.atlas.cogentco.com - 3 | 819 | 802 | 63 | 66 | 70 | 66 | | be2066.ccr22.lax01.atlas.cogentco.com - 2 | 827 | 812 | 100 | 102 | 107 | 102 | | be2179.ccr23.lax05.atlas.cogentco.com - 2 | 823 | 807 | 99 | 103 | 109 | 104 | | att.lax05.atlas.cogentco.com - 3 | 815 | 797 | 101 | 105 | 122 | 105 | | cr1.la2ca.ip.att.net - 3 | 795 | 772 | 96 | 100 | 105 | 100 | | gar5.lsrca.ip.att.net - 3 | 799 | 777 | 96 | 115 | 402 | 110 | | 12-122-254-230.attens.net - 4 | 786 | 761 | 96 | 107 | 319 | 99 | | 206.16.68.42 - 2 | 823 | 807 | 95 | 106 | 328 | 98 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 177 | 0 | 0 | 0 | 0 | 0 | |________________________________________________|______|______|______|______|______|______| WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider如您所见，我们一经过我的调制解调器 (192.168.200.1)，数据包丢失率就达到 88%。这对我来说真的不行。
这是对暴雪服务器的跟踪，但我 ping Google 时也遇到了损失。
然而，最能说明问题的是，在上面的跟踪中，第一个跳转是 fuse.net 地址：
EV1-DSL-208-102-228-1.fuse.net - 88 | 185 | 23
显然是我的 ISP（fuse.net 是 Cincinnati Bell 的域名）。但他们声称问题不在他们那边，我的连接没有问题（他们已经进行了“测试”）。当我打电话时，我要求只与高级技术支持人员通话（我被转接到“主管”，即最高级别的客户支持人员），拒绝与入门级（重启路由器）支持人员通话，但这似乎没有任何效果。
我该怎么办？如果他们说没问题并拒绝帮助我，我还能做什么？
有没有人有什么建议？
答案1
首先，尝试 ping 本地路由器。如果丢失数据包，则说明问题出在您的 PC 和路由器之间，与您的 ISP 无关。
如果一切正常，并且您收到了所有数据包，那么您可以转到网络的下一部分。即路由器和机柜之间。如果是这种情况，那么就有他们的证据。说“看，我可以从我的 PC 上 ping 路由器 [证据]，所以唯一合理的解释是它不是我直接网络本地的东西”
他们的工作是帮助你——我知道这很令人沮丧，但请帮助他们帮助你。如果你给他们一个有证据的逻辑思路。他们真的无法否认这一点。
祝你好运。
答案2
一般来说，使用 MTR（或 WinMTR）时，您不应该过多关注中间跳跃的数据包丢失，因为这通常是由发往自身的 ICMP 流量的阈值引起的（因为这种流量通常需要额外的资源）。如果您在某个跳跃上看到一定量的数据包丢失，然后在下一个跳跃上看到 0% 的数据包丢失，那么您可以相当肯定这不是实际上会影响您的流量的丢失（换句话说，一个特定跳跃上的实际丢失将显示在到达目的地之前的所有下一个跳跃中相同或更多的数据包丢失）。此外，查看延迟平均值以了解性能，留意标准偏差（如果它太高，平均延迟就没有意义，但我不确定 WinMTR 是否可以显示它）。
通过查看你的输出，我发现大约有 2% 的丢失，到最后一个跟踪跳跃的延迟大约为 160 毫秒，没有证据表明网络不可用诚实地。
不幸的是，您的 MTR 没有显示完整路径，但如果您在使用其他互联网服务时遇到同样的问题，您可能会跟踪回复为 8.8.8.8 的 IP。
然而，请记住 MTR 并不代表您在服务中使用的相同流程；为了更好地测试这种连通性，您应该设置一个使用相同套接字的“iperf”测试，但如果您无法访问远程网络，这是无法实现的。仅使用 MTR，会丢失带宽信息，与应用于 MTR 流量的方式相比，您的流量可能会以不同的方式沿路径进行整形/监管，等等。
再次，如果您的问题不仅与特定服务有关，而且与整个互联网浏览有关，那么像 www.speedtest.net/ 这样的测试可以为您提供很好的见解。