罗恩回答中的评论 4 对于通过 tcp 进行的长距离数据复制至关重要且占主导地位。您只是无法在长（甚至中等）距离上用 tcp 套接字填充大带宽管道。如果要远距离复制大文件，一种方法是拆分并使用多个 tcp 套接字。

另一种方法是使用为该任务设计的文件传输软件。此类软件要么优化 tcp 窗口大小，要么使用 udp。有可用的公共领域和商业选项（但具体建议不在主题范围内）。

永远不要低估一辆满载磁带的旅行车在高速公路上疾驰而过的带宽。— 安德鲁·S·塔南鲍姆

编辑：

从理论上讲，它没有区别。如果源和目标之间的最慢链接是 100Mb（例如），那么传输速度是 1E10*8/1E8，或 800 秒（忽略开销）。

在实践中，有几个因素可以产生影响。

1. 源计算机和目标计算机的磁盘传输速度。
2. 可能在计算机上运行的其他进程。
3. 错误率。如果存在重大错误，则以较小的块发送可能会更快。
4. 如果带宽延迟积 (BDP) 足够大，以至于最慢的链路没有被充分利用，则多个并发流可以更快。

如果您只看网络，而忽略所有其他因素（源和目标硬件和软件限制、中间设备/路由器的开销……），则基本上有两个因素：带宽和往返时间。对于较大的网络，路径中最慢链路的带宽是相关的 - 显然，您的吞吐量永远不会高于此。

如果传输协议一次发送一个数据包，等待确认，然后发送下一个数据包，则往返时间完全决定了可实现的吞吐量：发送和确认需要一个完整的往返 (RTT) 并传输单个数据包。吞吐量是 RTT * 数据包大小，与可用带宽无关（除非实际上更低）。

为了解决这个限制，许多协议在第一次确认到期之前发送特定数量的数据包 - 最突出的是 TCP 传输协议，其中这是发送窗口。使用与上述相同的逻辑，可实现的吞吐量现在已增加到 RTT * 窗口大小，与物理数据包大小无关。

现在，当带宽延迟积大于可能的窗口大小时，大型高带宽网络可能仍会受到 RTT 的限制。可能需要将窗口大小增加到超出 TCP 标准的 64 KiB。这是窗口比例选项的用武之地，将潜在的窗口大小增加到 appr。1 GB。

总而言之，如果可能的窗口大小太小而无法利用网络的全部带宽，则将数据拆分为多个流并同时传输它们会更快。

但是，我们之前假设网络有适当的可用带宽来容纳我们的流。当不同流之间存在争用并且网络变得拥塞时，情况就会发生变化。通常，争用发生在不同的流或连接之间。因此，并行使用多个连接可能能够使用更大部分的拥塞网络：当您的单个流之外还有四个竞争对手时，每个连接获得 1/5 的带宽。如果您随后将您的流分成四个，每个流获得 1/8 的带宽，但您的组合流 4/8 = 1/2 的带宽。

简而言之，在以下情况下，将一个流拆分为多个并发流会更快：a）窗口大小不足以满足可用带宽或 b）路径拥塞且争用由连接仲裁时

从网络的角度来看，您使用 FTP 还是 HTTP 并不重要——两者都使用 TCP 作为底层传输层协议，并且行为应该非常相似。在实践中，由于应用程序及其实现的不同，这可能会有所不同。