通过高速、高延迟 WAN 链接传输单个大文件的最佳方法是什么？

Question

这看起来与这个有关，但又有些不同。

两个公司站点之间有这个 WAN 链接，我们需要传输一个非常大的文件（Oracle 转储，~160 GB）。

我们有完整的 100 Mbps 带宽（已测试），但由于 TCP 的工作方式（ACK 等），单个 TCP 连接似乎无法将其最大化。我们使用iperf测试了链接，当增加 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 所说，“永远不要低估一辆装满磁带的旅行车在高速公路上疾驰的带宽。”

Answer 1

搜索“高延迟文件传输”会带来很多有趣的结果。显然，这是 CompSci 社区和商业社区都提出的问题。

一些似乎符合要求的商业产品：

• FileCatalyst 的产品可以使用 UDP 或多个 TCP 流通过高延迟网络传输数据。他们还有很多其他功能（即时压缩、增量传输等）。

• Aspera的fasp文件传输“技术”似乎也符合您的要求。

在开源世界中，uftp项目看起来很有希望。您并不特别需要它的多播功能，但基本思想是将文件发送到接收器，在传输结束时接收丢失块的 NAK，然后发送 NAK 块（泡沫、冲洗、重复）听起来它可以满足您的需求，因为在文件传输完成一次之前，接收器没有 ACK'ing（或 NAK'ing）。假设网络只是潜在的，而不是有损的，这也可以满足您的需求。

Answer 2

这个建议真的很奇怪.. 设置一个简单的 Web 服务器来在您的网络上托管文件（顺便说一下，我建议使用 nginx），然后在另一端设置一台带有 Firefox 的电脑，并安装DownThemAll扩展。

它是一个支持分块和重新组装的下载加速器。
您可以将每个下载分成 10 个块进行重新组装，它实际上确实使事情变得更快！

（警告：我从来没有在 160GB 大的东西上尝试过，但它对 20GB 的 iso 文件效果很好）

Answer 3

该UDT运输可能是高延迟通信中最流行的交通工具。这导致了他们的其他软件Sector/Sphere是“高性能分布式文件系统和并行数据处理引擎”，这可能值得一看。

Answer 4

我的回答有点晚了，但我刚刚在寻找 fasp 时发现了这个问题。在搜索过程中，我还发现了这个：http : //tsunami-udp.sourceforge.net/，“海啸 UDP 协议”。

从他们的网站：

一种快速的用户空间文件传输协议，它使用 TCP 控制和 UDP 数据在非常高速的长距离网络（？1 Gbps 甚至 10 GE）上传输，旨在提供比 TCP 在相同网络上可能实现的更高的吞吐量。相同网络。

就速度而言，该页面提到了这个结果（通过 1GBit 链接使用芬兰赫尔辛基到德国波恩之间的链接：

图 1 - 通过 Internet 进行国际传输，平均 800 Mbit/秒

如果你想使用下载加速器，看看 lftp ，据我所知，这是唯一可以做递归镜像的下载加速器。

Answer 5

来自非常相关页面“如何通过网络传输大量数据”的bbcp实用程序似乎是最简单的解决方案。