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

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

• 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 补充，有助于克服这些限制；这些RFC 1323 TCP 选项之一是“窗口缩放”。它引入了一个比例因子，乘以原始RWIN值，以获得完整的接收窗口值；使用窗口缩放选项允许最大 RWIN 为 1073725440 字节。应用相同的计算：

吞吐量_最大值= Rcv_Win / RTT
吞吐量_最大值= 1073725440 8 / 0.200*
吞吐量_最大值= 42.96Gbps

请记住，只要数据包丢失不是问题，TCP 会在传输期间逐渐增加 RWIN 。要通过高延迟连接查看真正大的传输速率，您必须传输一个大文件（因此 TCP 有时间增加窗口）并且数据包丢失对于连接来说不是问题。

数据包丢失

横跨太平洋的互联网线路有时会非常拥挤。我的部分家人住在海外，我们必须跨越太平洋与他们交谈……当拥塞和丢包严重时，有时我们在使用 Google Talk 时会遇到视频吞吐量问题。即使是适度的数据包丢失（例如 0.5% 的丢失）也会减慢高带宽连接的速度。

还值得一提的是，并非所有丢包都是坏事。TCP 被设计为有意丢弃数据包。上面我提到TCP随着时间的推移逐渐打开RWIN（只要不丢包就行）。当拥塞的电路丢弃数据包时，TCP 会通过减慢连接速度来响应丢弃（并分布在足够多的 TCP 套接字上，TCP 的响应有助于缓解电路拥塞）。然而，这种 TCP 尾部丢弃行为有一些缺点……当我们谈论 RED 时，我们将谈论另一种拥塞避免方案。

与故意丢包的主题还相关的是随机早期检测 (RED)。老实说，当您启用 QoS / HQoS 时，这是在 TCP 流量队列中启用的一项很棒的功能。它的工作原理是查看接口队列并随机丢弃一个数据包。数据包丢失（在 TCP 连接上）会减慢套接字；并且它被广泛认为是比尾部丢弃 TCP 更好的替代方案。还值得注意的是，此功能仅适用于 TCP……您可能知道，许多（非多媒体）UDP 协议在丢包时不会减慢速度。

并行 TCP 流

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

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

许多较旧的操作系统实现具有缓冲区有限的套接字；对于较旧的操作系统（如 Windows 2000），TCP 是否允许传输大量数据并不重要……它们的套接字缓冲区没有调整为利用大型 RWIN。为实现 TCP 传输的高性能进行了大量研究。现代操作系统（对于这个答案，我们可以将 Windows Vista 和更高版本称为“现代”）在其套接字缓冲区实现中包含更好的缓冲区分配机制。

简短回答：是的，距离对单流带宽有影响。

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

虽然对此已经有很好的答案，但我想补充一点：不，速度不一定受距离影响，是的，速度受距离影响通常都是如此。

这是为什么？

强烈简化，距离越长，通过互联网的方式涉及的“跳数”越多。最大带宽由最慢的跃点和并发流量决定。随着距离的增加和跳跃速度的随机分布，整体速度变慢的可能性正在增加。此外，物理会妨碍并且增加延迟也可能会减慢链接速度。

但这不是理所当然的。技术使我们能够建立几乎任何所需带宽的行星连接。然而，带宽和距离是敌人，两者都会显着增加连接成本，再次使得它不太可能仅用于您现在可能需要的连接。

当然，这过于简单化了，但实际上，这种情况是您经常发现的。然后再一次，当有一个令人惊讶的快速连接或即将到来的分发代理时，你不会 - 但是当一切都是即时的时，我们很少考虑互联网的速度......

是的，这是真实的数据，而不仅仅是理论。

资料来源：来自世界城市的平均下载速度，Andrew Martin