物理距离会影响下载速度吗？

22

我刚刚和我的一位同事发生争执，以为我会就此与专家联系。这是场景。我们正在使用一个网站来衡量您的连接速度。我们使用远离我们的服务器（我们在马来西亚，而服务器在美国）进行了测试。大约是2 Mbps。然后我们在新加坡尝试了一个服务器，它的速度要快得多（大约15 Mbps）。我的同事认为这是因为物理距离，而我认为这并不重要。我的理解是，一旦完成了初始握手并且数据流已经开始，服务器位于何处都没关系，结果应该几乎相同。我在这里想念什么吗？真正如何运作？

tcp latency bandwidth

— 海军蓝
source

2

您可以自己确认一下。ping服务器以获取延迟。然后2Mbps * Latency == Window。您可以使用wireshark确认实际的窗口大小。但是，让我们假设您没有窗口缩放功能，那么它的大小为64kB / 2Mbps = 256ms，因此我预计您的服务器距离256ms。

— ytti

2

@ytti间接描述了BDP（带宽延迟产品），它大致转化为长（延迟），胖（带宽）网络，使其更难以保持满满，并且更少的东西吞噬了您的潜在吞吐量。请参阅en.wikipedia.org/wiki/Bandwidth-delay_product。

— generalnetworkerror

2

@ ytti，Windows Vista和更高版本默认情况下会打开窗口缩放比例……我们需要知道Navid正在使用哪种操作系统进行测试

— Mike Pennington

根据此support.microsoft.com/kb/934430，在Vista中，缩放（因子8）是默认设置，但仅适用于非HTTP。我自己不是Windows用户，因此无法验证。

— ytti 2013年

2

@ytti，我不确定是否相关。我运行Vista，我正在嗅探到该支持页面的HTTP连接，TCP SYN表示：“窗口比例：2（乘以4的倍数）”

— Mike Pennington

23

我的同事认为这是因为物理距离，而我认为这并不重要。我的理解是，一旦完成了初始握手并且数据流已经开始，服务器位于何处都没关系，结果应该几乎相同。我在这里想念什么吗？真正如何运作？

你们俩在历史的某个时刻都是正确的，但是您的理解在大多数情况下是正确的……今天：）。在您的朋友给出的较旧答案与我们今天拥有的功能之间，有一些因素发生了变化。

TCP窗口缩放
主机缓冲区调整

您看到的结果差异可能受到以下因素的影响：

数据包丢失
并行TCP传输

TCP窗口缩放：带宽延迟效果

正如您的朋友所提到的，TCP的较早实现受到TCP标头中原始16位接收窗口大小的限制（参见RFC 793：第3.1节）；RWIN控制单个TCP套接字中可以等待多少未确认的数据。16位RWIN使用高带宽延迟产品来限制Internet路径（当今许多高带宽Internet连接将受到16位值的限制）。

对于高RTT值，拥有非常大的RWIN会很有帮助。例如，如果您从马来西亚到美国的RTT路径约为200毫秒，则原始TCP RWIN会将您限制为2.6Mbps。

_最大吞吐量= Rcv_Win / RTT

* _最大吞吐量= 65535 * 8 / 0.200 *

_最大吞吐量= 2.6Mbps

RFC 1323定义了一些“ TCP选项”来克服这些限制。这些TCP选项之一是“窗口缩放”。它引入了比例因子，该因子乘以原始RWIN值，以获得完整的接收窗口值。使用窗口缩放选项时，最大RWIN为1073725440字节。应用相同的计算：

_最大吞吐量= Rcv_Win / RTT

* _最大吞吐量= 1073725440 * 8 / 0.200 *

_最大吞吐量= 42.96Gbps

请记住，只要数据包丢失不是问题，TCP就会在传输过程中逐渐增加RWIN 。要在高延迟的连接上看到非常大的传输速率，您必须传输一个大文件（因此TCP有时间增加窗口），而数据包丢失对于连接来说不是问题。

数据包丢失

太平洋上的Internet电路有时会非常拥挤。我的一些家庭住在台湾，当我们与他们一起使用Google Talk时，我们经常遇到问题。当我从美国ping他们的DSL线路时，经常会看到超过0.5％的数据包丢失；如果您看到“速度较慢”的服务器损失了0.5％，那么很容易会限制单个TCP套接字的吞吐量。

并行TCP流

仅供参考，一些速度测试网站使用并行TCP流来增加吞吐量；这可能会影响您看到的结果，因为如果路径中有一些数据包丢失，那么并行TCP流会大大提高吞吐量。我已经看到四个并行TCP流完全饱和了遭受1％恒定数据包丢失的5Mbps电缆调制解调器。通常，丢失1％会降低单个TCP流的吞吐量。

奖励材料：主机缓冲区调整

许多较早的OS实现都使用带有有限缓冲区的套接字。对于较旧的操作系统（例如Windows 2000），TCP是否允许传输大量数据都没有关系...它们的套接字缓冲区没有进行调整以利用大型RWIN。为了使TCP传输具有高性能，已经进行了大量研究。现代操作系统（为此，我们可以将Windows Vista和更高版本称为“现代”）在其套接字缓冲区实现中包含更好的缓冲区分配机制。

— 迈克·彭宁顿
source

4

附带一提：有许多老式路由器会阻碍窗口缩放（每天的路由器数量减少，但仍然很多），并将其重置为零，从而极大地减少了带宽。尽管如今大多数网络基础设施提供商都不应遇到此问题，但击中这些损坏的路由器之一的可能性会随着跳到目的地的次数而增加。

— 克里斯·

路由器是L3设备。TCP窗口缩放是L4进程。路由器要么转发数据包，要么不转发数据包，并且除非使用QoS机制，否则TCP，UDP或任何其他协议之间没有区别。路由器当然会对初始MSS协商产生影响（..或者，如果它们丢弃了ICMP无法访问的内容，也会发生影响），但是滑动窗口算法纯粹是终端系统上堆栈的功能。

— rnxrx

2

@rnxrx我同意，主要是边缘固件，这会激怒TCP选项。我还没有听说过路由器修改TCP窗口缩放选项，但是如果有人想出了做到这一点的供应商/模型，我不会感到非常惊讶，因为边缘路由器在传输中修改TCP MSS选项并不罕见，想像一下有人将它付诸实践并不是一个大飞跃。

— ytti

3

简短的答案：是的，距离会影响单个流的带宽。

互联网已经发展出限制这种影响的手段...延迟的ACK，窗口缩放，其他协议:-)但是，物理仍然最终胜出。在这种情况下，很有可能是在这么多跃点上的一般网络拥塞-它只需要丢弃一个数据包即可杀死TCP流。

— 瑞奇光束
source

1

尽管已经有了很好的答案，但我想补充一下：不，速度不一定受距离影响，是的，速度经常受距离影响都是正确的。

这是为什么？

严格简化后，距离越长，通过Internet进行的“跳跃”越多。最大带宽由最慢的跃点和并发流量确定。随着距离的增加和跳跃速度的某种随机分布，使整体速度变慢的可能性越来越大。此外，物理方式会妨碍您，并且增加的延迟也可能会降低链接速度。

但这不是理所当然的。技术使我们能够建立几乎任何所需带宽的环绕地球的连接。但是，带宽和距离是敌人，并且两者都极大地增加了连接成本，再次使得仅为您现在可能需要的连接而存在的可能性较小。

当然，这过于简单了，但实际上，您经常会发现这种情况。再说一次，当连接出现了惊人的快速连接或分发代理时，您就不会再遇到这种情况，但是当一切瞬间发生时，我们很少考虑Internet的速度...

— 扎克67
source

-1

据安德鲁·马丁的答案是肯定的

— 乔纳森
source

不鼓励仅链接的答案。请提供详细信息，以使此答案有用，而不必取决于链接的网页。

— Teun Vink

杜德（Dude），这不仅是一个链接的答案，还是一张具有统计数据的图片

— 乔纳森（Jonathan）

我不是你的兄弟同样，如果不说明Y轴上的内容以及如何进行测量，则该图像没有任何意义。即使这样，您也应该解释一下此图像是如何解决问题的。

— Teun Vink

我不知道为什么这对您来说很困难，但是X和Y轴已标记。“以Mbps为单位的平均下载速度”

— 乔纳森