performance - 通过高延迟和高带宽链接传输文件的最快方法是什么？

Question

我正在尝试通过高延迟和高带宽链接传输文件。不幸的是，当我使用 rsync我的传输速度只占用了我可用带宽的一小部分。我的总传输时间比我预期的要长得多(即传输时间 = 字节/字节每秒可用带宽)!

在高延迟和高带宽链路上传输文件的最快方法 [1] 是什么？

例如:

延迟大于 900 毫秒 延迟(往返时间)

带宽 512 kbit/s

[1] 即利用大部分可用带宽

Answer 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 协议(protocol)的类似协议(protocol))您将不会利用可用带宽。

速度变慢的原因与 TCP(或类似 TCP 的协议(protocol))在发送更多数据之前需要 ACK 的往返特性有关。该问题正式称为 bandwidth-delay product .每个连接速度都将受到延迟而不是带宽的限制。

特别是对于给出的示例，理论速度将为 56.25 KiB 或小于可用带宽的 10%。

限制是每个连接。所以只使用一个 rsync因为您的文件传输不会充分利用您的带宽。

解决方案1:

使用不使用类似 TCP 协议(protocol)但仍通过其他方式保证您的数据的不同程序(快速谷歌搜索类似于 uftp ，它通过 UDP 协议(protocol)而不是 TCP 传输数据)。不幸的是 uftp在撰写本文时，它仍然没有出现在许多发行版存储库中。

解决方案2:

继续使用一个 rsync并更改双方的 TCP 网络参数，但这需要我目前不具备的专业知识。

解决方案3:

运行多个 rsync如本问题开头所述，并行处理。