让我们考虑 A（客户端）和 B（服务器），其中 A 从 B 下载。
从 A 到 B 的路由错误会对下载速度产生多大影响？
从 A 到 B 的跟踪路由返回一条 10 跳长的路径，往返延迟为 300 毫秒。它还显示第四跳的数据包丢失率为 ~10%。在正常情况下，A 和 B 之间的平均往返延迟在 10 毫秒到 30 毫秒之间。
这种影响是否会大幅降低 A 的下载速度，或者只要两侧和路由都具有足够的链路以满足 A 从 B 到 B 的全部速度，反之亦然，它就应该保持相同的速度？
除了 tracert 和 A 到 B 的 ping 分析之外，还有什么可以用来识别问题？
如果您需要更多信息，请告诉我。
答案1
这个问题涉及到很多方面的问题。我会尽量按顺序回答，然后再提供更详细的解释。
（略作解释）：
从 A 到 B 的跟踪路由返回一条 10 跳长的路径，往返延迟为 300 毫秒。它还显示第四跳的数据包丢失率为 ~10%。在正常情况下，A 和 B 之间的平均往返延迟在 10 毫秒到 30 毫秒之间。
按顺序解决这些问题：
- 路径中的跳数与有效吞吐量几乎无关。重要的是端到端延迟、平均数据包丢失以及 A 和 B 中的 TCP 堆栈中的设置，尤其是与 TCP 窗口相关的设置。（更多详细信息见下文。）
- 跟踪路由中第四跳的 10% 数据包丢失不太可能表示端到端连接存在问题。许多路由器都实现了以下功能控制平面监管或者ICMP 速率限制（特别是生成 ICMP“TTL 在传输中过期”消息，traceroute 依赖该消息）。测量数据包丢失的唯一可靠方法是检查 TCP 堆栈中的计数器，或者使用 tcpdump/Wireshark 从实际数据流中捕获数据包，然后使用协议分析器检查捕获。
- 到给定互联网目的地的往返延迟从 10-30 毫秒变为 300 毫秒的情况非常罕见。这种变化很可能是 ISP 内部灾难性的路由策略变化的结果，并且可能会尽快得到纠正。也许我能看到这种情况正常发生的唯一情况是，一个站点与其 ISP 只有一个物理连接（以太网、DSL 等），并且有卫星备份。
关于延迟对下载速度的影响，许多 TCP 实现都配置为使用 64kbytes 的接收窗口大小。当两个主机之间有高延迟连接时（更具体地说是高带宽延迟积，这个窗口大小通常会限制您的有效吞吐量，因为 TCP 将停止传输缓冲数据，直到它开始从远端接收已发送数据的 ACK。
编辑：根据您配置 pingplotter 的方式，它可能无法为您提供连接丢失的准确表示。如果 pingplotter 使用 ICMP，则网络可能会在拥塞时丢弃/降低此流量的优先级，因为它不被视为“用户流量”。此外，出于上述原因，任何有关中间跳数丢失的数据都应被视为可疑。
如果可能的话，在你的主机上运行数据包捕获会很有趣（这可以通过Wireshark例如），并查看 Wireshark 中与应用程序正在执行的实际 TCP 对话相关的分析。
答案2
是的，网络连接的高延迟肯定会影响下载速度（如果 TCP 窗口足够大，则影响会较小，这样源就可以发送多个数据包而不必等待每个数据包都得到确认）。任何重大的数据包丢失都会对性能产生灾难性的影响，因为每次丢失数据包时，下载都会在 TCP 重新传输超时期间有效停止。