这看起来与这个，但又有些不同。
两个公司站点之间有一条 WAN 链接，我们需要传输一个非常大的文件（Oracle 转储，约 160 GB）。
我们已经拥有 100 Mbps 的带宽（经过测试），但由于 TCP 的工作方式（ACK 等），单个 TCP 连接似乎无法将其发挥到最大。我们测试了以下链接：防火墙，当增加 TCP 窗口大小时，结果会发生巨大变化：使用基本设置，我们获得约 5 Mbps 的吞吐量，使用更大的 WS，我们可以获得高达约 45 Mbps 的吞吐量，但不会超过这个数字。网络延迟约为 10 毫秒。
出于好奇，我们使用多个连接运行了 iperf，我们发现，当运行四个连接时，它们确实可以达到每个连接约 25 Mbps 的速度，填满所有可用带宽；因此，关键似乎在于运行多个同时传输。
使用 FTP 时，情况会变得更糟：即使优化了 TCP 设置（高窗口大小、最大 MTU 等），单次传输也无法获得超过 20 Mbps 的速度。我们尝试同时通过 FTP 传输一些大文件，确实比传输单个文件时情况好得多；但罪魁祸首变成了磁盘 I/O，因为从同一个磁盘读取和写入四个大文件很快就会出现瓶颈；而且，我们似乎无法将单个大文件拆分成较小的文件然后再合并回来，至少在可接受的时间内无法做到（显然，我们不能将拼接/合并文件的时间与传输文件的时间相当）。
理想的解决方案是使用多线程工具，可以同时传输文件的各个部分；有点像 eMule 或 BitTorrent 等点对点程序已经实现的功能，但传输的是从一个源到单个目标。理想情况下，该工具允许我们选择使用多少个并行连接，当然还可以优化磁盘 I/O，以免在文件的各个部分之间（过于）疯狂地跳转。
有人知道这样的工具吗？
或者，有人可以建议更好的解决方案和/或我们还没有尝试过的东西吗？
PS 我们已经考虑过将其备份到磁带/磁盘并通过物理方式发送到目的地；如果 WAN 不能解决问题，那将是我们的极端措施，但是，正如 AS Tanenbaum 所说，“永远不要低估在高速公路上飞驰的装满磁带的旅行车的带宽。”
答案1
搜索“高延迟文件传输”会得到很多有趣的结果。显然，这是计算机科学界和商业界都考虑过的问题。
以下一些商业产品似乎符合要求：
在开源世界中，FTP该项目看起来很有前途。您并不特别需要它的多播功能，但基本思路是将文件发送到接收方，在传输结束时接收丢失块的 NAK，然后发送 NAK 块（泡沫、冲洗、重复），听起来它能满足您的需要，因为在文件传输完成一次之前，接收方不会发送 ACK（或 NAK）。假设网络只是潜在的，而不是有损的，这也可能满足您的需要。
答案2
这个建议真的很奇怪。设置一个简单的 Web 服务器来托管网络上的文件（顺便说一下，我建议使用 nginx），然后在另一端设置一台装有 Firefox 的 PC，并安装全部击倒扩大。
它是一款支持分块和重组的下载加速器。
您可以将每次下载分成 10 个块进行重组，这确实可以加快下载速度！
（警告：我从未在 160GB 这么大的东西上尝试过，但它对 20GB 的 iso 文件确实有效）
答案3
答案4
这韓國来自非常相关页面的实用功能如何通过网络传输大量数据似乎是最简单的解决方案。