为什么压缩后的SCP比没有压缩时慢？

我需要将20 GB的KVM虚拟磁盘文件从一台实验室服务器传输到另一台实验室服务器，以存储CentOS 6.5 VM的根文件系统。文件很大，而且我曾经将这样的虚拟磁盘文件压缩到几百兆字节，这一事实使我本能地启用了压缩功能，scp但是我看到传输速度相当低感到惊讶。然后，我尝试bzip2与ssh和结合使用，cat并大吃一惊。这是方法和平均吞吐量的摘要。

• scp -C vm1-root.img root@192.168.161.62:/mnt/vdisks/，每秒11 MB。
• bzip2 -c vm1-root.img | ssh -l root 192.168.161.62 "bzip2 -d -c > /mnt/vdisks/vm1-root.img"，每秒5 MB。这个更低的结果促使人们在网上搜索。
• scp -c arcfour -C vm1-root.img root@192.168.161.62:/mnt/vdisks/，每秒13 MB。在serverfault的一个答案-c arcfour中建议使用as 。它几乎没有帮助。最后，我禁用了压缩。
• scp vm1-root.img root@192.168.161.62:/mnt/vdisks/，每秒23 MB。

压缩不应该更快吗？

编辑：我不知道为什么这个问题已被否决。我认为这里有一些要学习的东西。

ssh(1)从@sven 收到手册页提示后，我尝试了几种不涉及压缩的文件传输替代方法，两种方法均具有较好的效果。

• cat vm1-root.img | ssh -l root 192.168.161.62 "cat > /mnt/vdisks/vm1-root.img"，每秒26 MB。

• nc -l 5678 > /mnt/vdisks/vm1-root.img在接收器和nc 192.168.161.62 5678 < vm1-root.img发送器上的速度为40 MB / s。该端口5678是可用的任意端口 。

使用nc原来是最快的复制方法！

过去，scp -C只要我认为可行，它的效果都很好。例如，当传输/var/log/messages*大小为几GB的syslog（）时。几百KB / s的未压缩传输速率将增加到1-2 MB / s。如手册页中所指出的，此示例确实是在连接缓慢的情况下发生的。

我遇到的情况是，为20 GB分区新建的虚拟磁盘映像的压缩大小仅为200 MB。传输速率约为25 MB / s，我们只需8秒即可完成复制，而无需花费13分钟以上！显然，scp在这种情况下，不进行压缩会导致效率低下scp -C甚至更糟。

我想，这里学到的主要教训是，scp -C应该认为这只是一种方便。如果可以对文件进行显着压缩，则最好先在源上对其进行压缩，然后传输压缩后的格式，最后在目标上进行dcompress。快速执行压缩和解压缩的工具（例如pbzip2）将提供更大的帮助。

报价man ssh（这是的基础scp）：

在调制解调器线路和其他慢速连接上需要压缩，但是压缩只会减慢快速网络上的速度。

问题在于，压缩数据需要花费更多的时间，而不仅仅是通过网络发送数据。

另外，在压缩之外，nc也获得了最佳速率，因为它也不加密。无损压缩依赖于找到数据的冗余部分，在网络级完成时，您可以查看最大[buffer-size]个字节，而当首先处理整个文件时，则为[file-size]个字节在其中搜寻和处理重复的字节句子。

同样，对于移动磁盘映像，您应该使用文件系统感知工具，例如ntfsclone / partclone，因为即使压缩也无法克服普通跳过未分配的块的问题-如果您不必传输任何数据，则传输速率是无限的。另外，别忘了销毁Windows分区上的交换和休眠文件，否则您将在复制垃圾时将其丢弃并重新创建。