在高速,高延迟WAN链路上传输单个大文件的最佳方法是什么?

Modified on: Fri, 07 Jun 2019 18:20:03 +0800

这看起来与这个,但它有些不同。

两个公司站点之间有这个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,以免在文件的各个部分之间疯狂地跳转。

有谁知道这样的工具?

或者,任何人都可以建议更好的解决方案和/或我们已经尝试过的东西吗?

P.S。我们已经考虑过将其备份到磁带/磁盘并将其物理地发送到目的地;如果WAN不削减它,那将是我们的极端措施,但是,作为A.S. Tanenbaum说:“永远不要低估一辆满载磁带的旅行车的带宽。”

作者:Community,Massimo

最佳答案

搜索“高延迟文件传输”会带来很多有趣的点击。很显然,这是CompSci社区和商业界都已经陷入困境的问题。

一些似乎适合该法案的商业产品:

  • FileCatalyst的产品可通过高延迟网络传输数据使用UDP或多个TCP流。它们还有许多其他功能(动态压缩,增量传输等)。

  • 来自Aspera的fasp文件传输“技术”出现为了满足你所寻找的目标而适合你。

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


相关问答

添加新评论