我试图通过高延迟和高带宽链接传输文件.不幸的是,当我使用rsync时,我的传输速度仅占用了我可用带宽的一小部分.我的总传输时间比我预期的要长得多(即传输时间=字节/字节 – 每秒可
在高延迟和高带宽链路上传输文件的最快方法是什么？
例如：
>延迟大于900毫秒延迟(往返时间)
>带宽512 kbit / s
[1]即利用大部分可用带宽
在高延迟和高带宽情况下使用rsync时,每个连接传输速度将比可用带宽慢[1].对于给出的示例,您的预期传输速度将是56.25 KiB或小于可用带宽的10％.一种解决方案是并行运行N rsync进程：
#!/bin/bash
# tar up the files
tar -cvzf x.tar ${list_of_files}
# [optional]
# compute the md5sum
md5sum x.tar > x.tar.md5sum
# break the large tar file into N files (i.e. x.tar would become x.tar.1 ... x.tar.N)
# TODO
# start N `rsync` processes in parallel
for ((i=1;i<=N;i++)); do rsync -avzh x.tar.${i} ${destination} & done
# wait for the transfers to finish
wait && echo "success" || echo "fail" && exit 1
# stitch the N files back together into x.tar
TODO
# [optional... but gives everyone a nice warm and fuzzy]
# copy the md5sum and verify your files (even though `rsync` already did so)
scp x.tar.md5sum ${destination}
ssh ${destination_machine} "cd ${path} && md5sum -c x.tar.md5sum && echo 'PASS (files verified with md5sum)' || echo 'FAIL (file verification failed md5sum)' && exit 1"
# done!
[1]为什么在这个例子中你的传输速度很慢？
总之一句：bandwidth-delay product(实际上是三个字)
这是高延迟和高带宽链路的示例.有些人可能会使用像rsync这样的工具来传输数据.如果您运行一个rsync实例(或类似的也使用TCP或TCP类协议的实例),则不会使用可用带宽.
减速的原因与发送更多数据之前需要ACK的TCP(或类TCP协议)的往返性质有关.该问题被正式称为bandwidth-delay product.每个连接速度将受到比带宽更多的延迟的限制.
特别是对于给出的示例,理论速度将是56.25 KiB或小于可用带宽的10％.
限制是每个连接.因此,仅使用一个rsync进行文件传输将无法充分利用您的带宽.
解决方案1：
使用不使用类似TCP协议但仍通过其他方式保证数据的其他程序(快速谷歌搜索类似于uftp,它通过UDP协议而不是TCP传输数据).不幸的是,截至本文撰写时,uftp仍未出现在许多发行版中.
解决方案2：
继续使用一个rsync并更改双方的TCP网络参数,但这需要我目前还不具备的专业知识.
解决方案3：
如本问题开头所述,并行运行多个rsync进程.