#1 楼
我的同事认为这是因为物理距离，而我认为这并不重要。我的理解是，一旦您完成了初始握手并且数据流已经开始，服务器位于何处都没关系，结果应该几乎相同。我在这里想念什么吗？
你们俩在历史的某个时候都是正确的，但是您的理解在今天基本上是正确的。在您的朋友给出的较旧答案和我们今天拥有的功能之间，有一些因素发生了变化。 />您看到的结果差异可能受到以下因素的影响：
数据包丢失
并行TCP传输
TCP窗口缩放：带宽-delay effect
正如您的朋友所提到的，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
* Throughputmax = 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流完全饱和了5Mbps电缆调制解调器，该调制解调器遭受了1％的恒定数据包丢失。通常，丢失1％会降低单个TCP流的吞吐量。对于较旧的操作系统（例如Windows 2000），TCP是否允许传输大量数据都没有关系...它们的套接字缓冲区没有进行调整以利用大型RWIN。为了实现TCP传输的高性能，已经进行了大量研究。现代操作系统（为此，我们可以将Windows Vista和更高版本称为“现代”）在其套接字缓冲区实现中包含更好的缓冲区分配机制。
评论
附带说明：有很多老式路由器会阻碍窗口缩放（每天的路由器数量减少，但仍然很多），并将其重置为零，从而极大地减少了带宽。尽管如今大多数网络基础设施提供商都不应该遇到此问题，但击中这些损坏的路由器之一的可能性会随着跳到目的地的次数而增加。
–克里斯唐（Chris Down）
13年7月11日在10:59
路由器是L3设备。 TCP窗口缩放是一个L4进程。路由器转发数据包或不转发数据包，并且除非使用QoS机制，否则TCP，UDP或任何其他协议之间没有区别。路由器当然会对初始MSS协商产生影响（..或者，如果它们丢弃了ICMP无法访问的消息，也会发生影响），但是滑动窗口算法纯粹是终端系统上堆栈的功能。
–rnxrx
13年7月12日在3:08
@rnxrx我同意，主要是边缘固件，这会激怒TCP选项。我还没有听说过路由器修改TCP窗口缩放选项，但是如果有人想出了做到这一点的供应商/模型，我不会感到非常惊讶，因为边缘路由器在传输中修改TCP MSS选项并不罕见，想像一下有人将它付诸实践并不是一个大飞跃。
–ytti
13年7月12日在6:06
#2 楼
简短的答案：是的，距离对单流带宽有影响。结束。在这种情况下，很有可能是在这么多跃点上的一般网络拥塞-它只需要丢弃一个数据包即可杀死TCP流。#3 楼
尽管已经有了很好的答案，但我想补充一下：不，速度不一定受距离影响，是的，速度经常受距离影响都是正确的。为什么？
经过严格简化，距离越长，通过Internet进行的“跳跃”越多。最大带宽由最慢的跃点和同时发生的流量确定。随着距离的增加和跳跃速度的某种随机分布，使整体速度变慢的可能性越来越大。此外，物理妨碍了工作，而增加的延迟也可能会减慢链接的速度。技术使我们能够建立几乎任何所需带宽的环绕地球的连接。但是，带宽和距离是敌人，并且两者都极大地增加了连接成本，再次降低了它仅为您当前可能需要的连接而存在的可能性。现实中，这种情况是您经常发现的。再说一次，当连接出现了惊人的快速连接或分发代理时，您就没有了-但是当一切瞬间，我们很少考虑互联网的速度...
#4 楼
根据安德鲁·马丁（Andrew Martin）的回答，是
评论
不鼓励仅链接的答案。请提供详细信息，以使此答案有用，而不必取决于链接的网页。
– Teun Vink♦
17年8月11日在5:05
杜德（Dude），这不仅是链接的答案，还是具有统计数据的图片
–乔纳森
17年8月12日在21:21
我不是你的兄弟同样，如果不说明Y轴上的内容以及如何进行测量，则该图像没有任何意义。即使这样，您也应该解释一下此图像是如何解决问题的。
– Teun Vink♦
17年8月12日在21:43
我不知道为什么对您来说很困难，但是X和Y轴已标记。 “以Mbps为单位的平均下载速度”
–乔纳森
18年8月16日在23:29
评论
您可以自己确认一下。 ping服务器以获取延迟。然后2Mbps *延迟==窗口。您可以使用wireshark确认实际的窗口大小。但让我们假设您没有窗口缩放，那么它的大小为64kB / 2Mbps = 256ms，因此我预计您的服务器距离256ms。@ytti间接描述了BDP（带宽延迟产品），它大致转化为长（延迟），胖（带宽）网络，更难以保持满满，并且更少的东西吞噬了您的潜在吞吐量。请参阅en.wikipedia.org/wiki/Bandwidth-delay_product。
@ ytti，Windows Vista和更高版本默认情况下会启用窗口缩放...我们需要知道Navid正在使用什么操作系统进行测试
根据此support.microsoft.com/kb/934430，在Vista中，缩放（因子8）是默认设置，但仅适用于非HTTP。我自己不是Windows用户，因此无法验证。
@ytti，我不确定是否相关。我运行Vista，我正在嗅探到该支持页面的HTTP连接，TCP SYN表示：“窗口比例：2（乘以4的倍数）”