大文件传输... nc很牛啊

来源：互联网发布：ug6铣螺纹编程实例编辑：程序博客网时间：2024/05/11 01:41

from: http://www.yankay.com/linux%E5%A4%A7%E6%96%87%E4%BB%B6%E4%BC%A0%E8%BE%93/

我们经常需要在机器之间传输文件。比如备份，复制数据等等。这个是很常见，也是很简单的。用scp或者rsync就能很好的完成任务。但是如果文件很大，需要占用一些传输时间的时候，怎样又快又好地完成任务就很重要了。在我的测试用例中，一个最佳的方案比最差的方案，性能提高了10倍。

复制文件

如果我们是复制一个未压缩的文件。这里走如下步骤：

压缩数据
发送到另外一台机器上
数据解压缩
校验正确性

这样做会很有效率，数据压缩后可以更有效的利用带宽

使用ZIP+SCP

我们可以通过ZIP+SCP的组合实现这个功能。

gzip -c /home/yankay/data | ssh yankay01 "gunzip -c - > /home/yankay/data"

这条命令是将/home/yankay/data经过GZIP压缩，通过ssh传输到yankay01的机器上。

data文件的大小是1.1GB,经过Zip压缩后是183MB，执行上面的命令需要45.6s。平均吞吐量为24.7MB/s

我们会发现Scp也有压缩功能，所以上面的语句可以写成

scp -C -c blowfish /home/yankay/data yankay01:/home/yankay/data

这样运行效果是相同的，不通之处在于我使用了blowfish算法作为Scp的密匙算法，使用这个算法可以比默认的情况快很多。单单对与scp,使用了blowfish 吞吐量是62MB/s,不使用只有46MB/s。

可是我执行上面一条命令的时候，发现还是需要45s。平均吞吐量还为24MB/s。没有丝毫的提升，可见瓶颈不在网络上。

那瓶颈在哪里呢？

性能分析

我们先定义几个变量

压缩工具的压缩比是 CompressRadio
压缩工具的压缩吞吐是CompressSpeed MB/s
网络传输的吞吐是 NetSpeed MB/s

由于使用了管道，管道的性能取决于管道中最慢的部分的性能，所以整体的性能是：

speed=min(NetSpeed/CompressRadio,CompressSpeed)

当压缩吞吐较网络传输慢的时候，压缩是瓶颈；但网络较慢的时候，网络传输/吞吐是瓶颈。

根据现有的测试数据(纯文本)，可以得到表格：

压缩比吞吐量千兆网卡(100MB/s)吞吐量千兆网卡吞吐量,基于ssh(62MB/s)百兆网卡(10MB/s)吞吐量ZLIB35.80%9.69.69.69.6LZO54.40%101.7101.7101.718.38235294LIBLZF54.60%134.3134.3113.553113618.31501832QUICKLZ54.90%183.4182.1493625112.932604718.21493625FASTLZ56.20%134.4134.4110.320284717.79359431SNAPPY59.80%189167.2240803103.678929816.72240803NONE100%3001006210

可以看出来。在千兆网卡下，使用QuickLZ作为压缩算法，可以达到最高的性能。如果使用SSH作为数据传输通道，则远远没有达到网卡可以达到的最佳性能。在百兆网卡的情况下，各个算法相近。对比下来QuickLZ是有优势的。

对于不同的数据和不同的机器，可以得出不同的最佳压缩算法。但有一点是肯定的，尽量把瓶颈压在网络上。对于较慢的网络环境，高压缩比的算法会比较有优势；相反对于较快的网络环境，低压缩比的算法会更好。

结论

根据上面的分析结果，我们不能是用SSH作为网络传输通道，可以使用NC这个基本网络工具，提高性能。同时使用qpress作为压缩算法。

scp /usr/bin/qpress yankay01:/usr/bin/qpressssh yankay01 "nc -l 12345 |  qpress -dio > /home/yankay/data" &qpress -o /home/yankay/data |nc yankay01 12345

第一行是将gpress安装到远程机器上，第二行在远程机器上使用nc监听一个端口，第三行压缩并传送数据。

执行上面的命令需要2.8s。平均吞吐量为402MB/s,比使用Gzip+Scp快了16倍！！

根据上文的公式，和自己的数据，可以绘出上面的表格，就可以选择出最适合的压缩算法和传输方式。达到满意的效果。如果是一个长期运行的脚本的话，这么做是值得的。