use*_*171 1 performance rsync scp
Scp 传输单个文件的速度非常慢。执行此操作的最快方法是什么？
我需要速度的原因不是因为我有大量的文件要传输。我只希望单个文件传输（从开始到完成）快速完成（因此 rsync 和 tar 和传输不够快）。
Tom*_*ime 11
传输许多小文件有很多限制。已经提到了一些：网络延迟、磁盘写入速度等。但是，大多数可以通过使用“rsync”进行最佳优化。如果目标文件不存在，并且您非常确定该过程不会中断，则使用 tar 管道传输到 tar 将非常有效：
cd /SOURCE/DIR && tar cf - . | ssh DESTINATIONHOST "cd /DESTINATION/DIR && tar xpvf -"
从根本上说，您需要将所有文件一起批处理，以便 SCP 的启动/关闭开销只发生一次。如果您对每个文件都执行启动/关闭操作，效率将非常低下。上面的“tar”管道可以做到这一点。事实上，90% 的用例这已经足够了。
这个“tar 管道”具有并行处理的好处（在一个进程中读取而在另一个进程中写入）。但是，它受到以下几点限制：
您可以通过各种 hack 来解决 #2，例如运行两个或多个进程，每个进程都在文件的一个子集上。然而，这些都是不完美的，有点草率。
TCP/IP 更难解决，并将继续成为您的限制。事实上，如果您调整系统使一切都处于最佳状态，TCP/IP 将不会使用完整的管道。每次 TCP/IP 认为它已找到最佳发送速率时，它都会尝试多发送一点以测试是否有“更多空间”可用。这将失败并且 TCP/IP 将退避一点。这种持续增加/失败/回退循环意味着 TCP/IP 流将在 100% 利用率和 50% 利用率之间交替……结果是管道的平均利用率为 75-80%。（注意：这些是估计值......做一些谷歌搜索以找到确切的数字。关键是它将是 100% 的平均值，而不是 100%，因此它永远不会是 100%） .
如果您运行多个 TCP/IP 流，它们都会不断循环通过这个增加/失败/回退循环。如果你不走运，它们会同时发生碰撞，并且都后退很远，从而使管道未得到充分利用。如果你幸运的话，它们会减少碰撞，你会得到一个看起来像许多弹跳球的图表......仍然使管道总体上没有得到充分利用。
哦，如果你有一台 TCP/IP 实现的机器没有最新的优化，或者没有完美地调整，它可能会使整个系统失控。
那么如果 TCP/IP 这么可怕，我们为什么还要继续使用它呢？在许多不同类型的流量共享管道的典型情况下，这并不是那么糟糕。这里的问题是您有一个非常具体的应用程序，有非常具体的要求。因此，您需要一个非常具体的解决方案。幸运的是，很多人也处于您的位置，因此这些解决方案变得越来越容易找到。
http://asperasoft.com/等系统使用 UDP/IP 上的自定义协议，因此它们可以控制退避/rety 算法。他们使用前向纠错 (FEC)，因此小错误不需要重新传输（使用 TCP/IP，小错误是退避信号）、自定义压缩方案、增量复制和他们自己的退避算法和速率限制系统以实现管道的完全（或接近完全）利用。这些都是专有的，因此尚不清楚 Aspera 及其竞争对手究竟使用什么技术或具体如何工作。
有许多公司发明了这样的系统，或者将它们作为自己产品的一部分，或者作为商业产品出售。
我目前不知道任何开源实现。（我想被纠正！）
如果这是一个非常紧迫的问题并且值得花钱解决，请尝试其中一种商业产品。或者，如果您无法更改软件，则需要购买更大的管道。幸运的是，10G 和 40G 网络接口的价格正在下降。