☰

多线程网络文件传输

tag-icon • tag-icon file-transfer
多线程网络文件传输

连接纽约和阿姆斯特丹的许多链路经常处于饱和状态。这意味着，与我们的连接能力相比，通过这些链路进行传输（例如，以 1MB/s 的速度传输 300GB）将需要很长时间。

我以前遇到过这个问题，大概是 3 年前，当时我刚接触编程和 Linux，我决定在这篇文章的底部发布。但是，它很脏，我不喜欢它。该脚本无法正常工作，因为它是为非常特定的环境编写的，但它给了你灵感。

我的问题是，您是否知道有什么更好的方法可以快速跨洋传输文件？

#!/bin/sh

upto="$1"
filepath="$2"
remotepath="$3"

if [ ! -f ${filepath} ]
then
exit 0
fi

password=$(/all/script/password 10)
filesize=$(du -b ${2} | sed 's/\([0-9]*\)\(.*\)/\1/')

if [ $filesize -gt 5368709120 ]; then
parts="80"
elif [ $filesize -gt 2147483648 ]; then
parts="50"
elif [ $filesize -gt 1310720 ]; then
parts="20"
else
parts="2"
fi

splitsize=$(($filesize / $parts))

split -b "$splitsize" -a 2 "$2" /all/tmp/cup/${password}_

#UPLOAD
declare -a pwait
for tmpfile in /all/tmp/cup/${password}_*
do
    scp ${tmpfile} root@${upto}.domain.com:/all/tmp/cup/ &
        array_lenght=${#pwait[@]}
        pwait[${array_lenght}]=$!
done

#ATTENDERE
for prid in ${pwait[@]}
do
wait $prid
done

#UNISCI FILE REMOTO
ssh root@${upto}.domain.com "cat /all/tmp/cup/${password}_* > ${remotepath} && wait && rm -f /all/tmp/cup/${password}_*"

#RIMUOVI ROBA DI TROPPO LA
#eval ssh root@${upto}.domain.com rm -f /all/tmp/cup/${password}*

#REMOVE HERE
rm -f /all/tmp/cup/${password}_*

exit 0

答案1

假设你的网络不是饱和（与你在问题中所说的相反），你应该调整你的链接来处理（相对）高的带宽延迟积就像 Andrew 提到的那样。（该链接引用的文章包含有关调整什么、何时调整以及为什么调整的一些信息。）

如果您的网络链路确实已饱和（传输最大数据量），那么唯一的解决方案就是增加更多带宽（在两个站点之间增加光纤干线，向另一家运营商付费以减轻高峰时段的传输负担，或者如果您使用“专用”链路，则支付更高的 CIR / 向环路中添加更多电路）。

您如何分辨出差异？
好吧，如果启动更多流可以提高速度，那么您的链接尚未饱和。您可能会受到从美国到欧洲相对较长的往返时间的影响（与本地网络的往返时间相比）。
（这里存在收益递减点，因为更多 TCP 连接的开销最终会导致其他瓶颈出现。）

如果添加更多流并不能带来净速度的增加（两个流的净速度只有一个流的一半），则说明您的链路已饱和，您需要添加带宽来提高性能。

其他需要考虑的事项

您应该尽量减少通过管道推送的数据，rsync如果合适，使用或类似的协议（rsync 最适合将较小的更改集转换为较大的数据集合）。

永远不要低估装有几块硬盘的 FedEx 隔夜包裹的带宽。尤其是对于初始同步而言。

答案2

我会检查 TCP/IP 调优选项，例如窗口缩放、重新传输、路由表以及 icmp。如果一切正常，并且操作系统上的网络堆栈不是 Windows XP 或 Centos 5 或任何比 Vista 更早的版本，那么您应该没问题，因为不需要多线程网络连接。或者，它不会改善超过 20%，所以实际上，它只会对文件系统进行碎片整理并使其速度进一步降低。

答案3

https://en.wikipedia.org/wiki/Bandwidth-delay_product

在设计传输控制协议 (TCP) 等协议时，高带宽延迟积是 TCP 调优方面的一个重要问题，因为只有当发送方在被要求停止并等待接收方发送确认消息（确认已成功接收该数据）之前发送了足够多的数据时，协议才能实现最佳吞吐量。如果发送的数据量与带宽延迟积相比不足，则链路未保持繁忙状态，协议的运行效率低于链路的峰值效率。

这是基本理论，但还有其他因素：根据您的操作系统和 TCP 调整选项，您可能会使用大窗口（大窗口使其运行得更快），但一些 ISP 使用“TCP 窗口操作”作为整形和拥塞控制工具（即中间的框知道某些链接拥塞，然后尝试通过编辑 ACK 数据包来抑制 TCP 源，以便使源确信接收方的窗口大小很小），因此您的大窗口可能实际上并没有发挥作用，即使您认为已经打开它们。

还有一件事情可能发生，那就是当数据包队列在拥塞的路由器中堆积时，它会开始随机地从队列中删除数据包（参见 Cisco 加权随机早期检测或简称 WRED），但只使用一个 TCP 流的人往往比使用一堆并行 TCP 流的人退缩得更快，因此通过使用多个并行流，您可以在该拥塞队列中获得更大的带宽“份额”（以牺牲不使用这种技术的其他人为代价）。

有一个有趣的工具叫做“tcptrace”，它能让你看到正在发生的事情，前提是你可以在任一端捕获数据包。不幸的是，你需要使用“xplot”，这是一个有点糟糕的程序，但你可以忍受它。

相关内容