这看起来与这个有关，但有些不同。
两个公司站点之间有这个WAN链路，我们需要传输一个非常大的文件（Oracle dump，〜160 GB）。
我们有100 Mbps的带宽（已testing），但看起来像单个TCP连接，由于TCP工作方式（ACK等）的原因，无法将其最大化。 我们testing了与iperf的链接，当增加TCP窗口大小时，结果发生了显着的变化：在基本设置下，我们得到〜5 Mbps的吞吐量，而更大的WS我们可以达到〜45 Mbps，但不会超过此值。 networking延迟约为10毫秒。
出于好奇，我们使用多于一个连接来运行iperf，并且我们发现当运行其中的四个连接时，它们确实会达到〜25 Mbps的速度，填充所有可用的带宽; 所以键看起来在运行多个同时传输。
使用FTP，情况会变得更糟：即使使用优化的TCP设置（高窗口大小，最大MTU等），单次传输的速率也不能超过20 Mbps。 我们尝试同时FTP一些大文件，事实上比传输单个文件好得多。 但罪魁祸首成为磁盘I / O，因为很快就会从同一个磁盘瓶颈中读取和写入四个大文件; 同样，我们似乎也不能把这个单一的大文件分割成小的文件，然后把它合并回去，至less在可以接受的时候是不行的（显然我们不能把文件拼接/合并的时间相当于转移它）。
这里的理想解决scheme是一个multithreading工具，可以同时传输文件的各个块; 像eMule或者BitTorrent这样的点对点程序已经做到了，但是从单一来源到单个目的地。 理想情况下，该工具将允许我们select使用多less个并行连接，当然也可以优化磁盘I / O，避免在文件的各个部分之间跳跃（太）。
有谁知道这样的工具？
或者，任何人都可以提出一个更好的解决scheme和/或我们已经没有尝试的东西？
PS我们已经考虑过支持磁带/磁盘并将其发送到目的地; 如果广域网并没有削减，这将是我们的极端措施，但正如塔南鲍姆（AS Tanenbaum）所说的那样，“永远不要低估满载录像带的旅行车的带宽。”
search“高延迟文件传输”带来了很多有趣的命中。 很显然，这是CompSci社区和商业社区都在思考的问题。
一些似乎符合法案的商业产品：
FileCatalyst具有可以使用UDP或多个TCPstream在高延迟networking上传输数据的产品。 他们也有很多其他function（即时压缩，三angular洲转移等）。
Aspera的fasp文件传输“技术”似乎也符合您所寻找的内容。
在开源世界中， uftp项目看起来很有希望。 你并不需要特别的多播function，而是把文件发送给接收者，在传输结束时接收NAK，然后发送NAK块（起泡，漂洗，重复）听起来就像它会做你所需要的，因为直到文件传输完成一次之后，才从接收机中确认（或者NAK）。 假设networking只是潜在的，而不是有损的，这也可能做你所需要的。
真奇怪的build议这一个..build立一个简单的networking服务器来托pipe您的networking上的文件（顺便说一句，我build议nginx），然后在另一端用firefox设置一台电脑，并安装DownThemAll扩展名。
这是一个支持分块和重新组装的下载加速器。
您可以将每个下载分成10个块进行重新组装，而且确实可以让事情变得更快！
（警告：我从来没有尝试过任何大到160GB的东西，但它确实与20GB的iso文件一起工作）
UDT传输可能是高延迟通信中最stream行的传输方式。 这导致他们的其他软件称为Sector / Sphere一个“高性能分布式文件系统和并行数据处理引擎”这可能是值得看看。
我的回答有点迟，但是我只是在findfasp的时候才发现这个问题。 在search期间，我也发现这个： http ： //tsunami-udp.sourceforge.net/ ，“海啸UDP协议”。
从他们的网站：
一种快速的用户空间文件传输协议，使用TCP控制和UDP数据在超高速长距离networking（≥1 Gbps甚至10 GE）上进行传输，旨在通过同一networking提供比TCP更高的吞吐量。networking。
就速度而言，页面提到了这个结果（使用芬兰赫尔辛基与德国波恩之间的1GBit链接：
图1 – 互联网上的国际转移，平均800 Mbit /秒
如果你想使用下载加速器，看看lftp，这是唯一可以做recursion镜像的下载加速器，据我所知。
来自非常相关的页面“如何通过networking传输大量数据”的bbcp实用程序似乎是最简单的解决scheme。