通过高速，高延迟的WAN链接传输单个大文件的最佳方法是什么？
已锁定。已禁用对此问题的评论，但它仍在接受新的答案和其他交互方式。了解更多。 这看起来与这一个，但它是有所不同的。 两个公司站点之间存在此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不削减它，这将是我们的极端措施，但正如Tanenbaum所说，“永远不要低估充满胶带的旅行车的带宽。”