有些时候在备份或者同步有很多文件的大目录时（比如几个GB或者几十个GB的数据库目录、log目录），直接scp的话花费的时间较长，虽然可以采用先压缩再传输再解压的方法，传输的数据量确实减少了，但压缩和解压也会耗费很多的时间，总体效果也不令人满意，昨天晚上突发奇想，由于之前做过流媒体视频点播的项目的经验，如果能像看高清视频一样只需要下载完视频文件的metadata头就可以实现边下载边播放，即渐进式下载（http://baike.baidu.com/link?url=fTWQYBTqQr1BisysCAkoqIytbwotfBYvFEMxEAlspRbNmE6b5lwVLNzA-qgw6yGlFgBepYBzqvUEb2tqQaehBK） ，那就完美了，今天在网上一搜linux还真行，兴奋之余做一下对比测试：
先上结论：
（1）总体来说，对于文本文件，压缩要比不压缩传输效率更高些，但效果不明显（因为瓶颈不在网络传输这块，而在于压缩，参见下文测试1与2，3与4的对比）；
（2）采用边打包边压缩边传输边解压的流式传输方式的话，传输效率能比直接scp/rsync的方式提高35%；
（3）具体到流式传输的ssh和nc的方式上，因为nc不需要用户验证、不需要加密传输的数据，效率稍微高一点，对比效果不明显（因为瓶颈不在网络传输这块，而在于压缩）；
（4）在实际使用中更倾向于采用ssh的方式，因为：可以采用push或者pull的方式，且一条命令搞定，同一个源可以有多个并发，而nc需要先在接受端监听端口，然后在发送端开始传输，需要分别执行2条命令，
高效同步数据的方法及效率测试边打包边压缩边传输边解压20150105
。担心：如果在传输的同时有第三者同时向接收端的监听端口发送数据，容易造成数据的不完整性，但实际测试发现nc的接受端只能和一个发送端建立连接进行数据传输，如果正在传输数据，那么第三者发往改监听端口的数据将不会传输，只有新监听端口或者等传输完成后，再重新启用改端口进行传输，总之还是倾向于与ssh的方式。测试环境：centos5.5 千兆局域网络
测试目录/var/log大小8.9GB
[root@cap131 ~]# du -h /var/log/
28K /var/log/prelink
8.0K /var/log/conman.old
8.0K /var/log/vbox
24K /var/log/cups
50M /var/log/redis
76K /var/log/nginx
6.1M /var/log/sa
8.0K /var/log/conman
8.0K /var/log/ppp
18M /var/log/audit
152K /var/log/php-fpm
8.8G /var/log/rabbitmq
12K /var/log/pm
16K /var/log/mail
8.9G /var/log/
[root@cap131 ~]#
1、直接纯scp拷贝的时间（5‘20’‘）：
[root@cap131 ~]# time scp -r /var/log/ 192.168.1.130:/root/test-dir/
real 5m20.834s
user 3m29.049s
sys 0m41.038s
2、先打包压缩再传输再解压的时间（3’33‘’+14‘’+1‘19’‘=5’6‘’）：
纯压缩的时间：
[root@cap131 ~]# time tar czf varlog.tar.gz /var/log
tar: Removing leading `/‘ from member names
real 3m33.740s
user 3m28.068s
sys 0m19.081s
纯压缩后的大小：
[root@cap130 test-dir]# du -h ../varlog.tar.gz
399M ../varlog.tar.gz
纯传输压缩包的时间：
[root@cap131 ~]# time scp varlog.tar.gz 192.168.1.130:~
root@192.168.1.130‘s password:
varlog.tar.gz 100% 399MB 30.7MB/s 00:13
real 0m14.024s
user 0m9.510s
sys 0m1.283s
纯解压的时间
[root@cap131 ~]# time tar xzf varlog.tar.gz
real 1m19.916s
user 0m49.498s
sys 0m35.588s
3、直接rysnc不启用压缩功能的传输时间（5‘12’‘）：
[root@cap131 ~]# rsync -r /var/log/ 192.168.1.130:/root/test-dir
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(260) [sender=2.6.8]
[root@cap131 ~]# time rsync -r /var/log/ 192.168.1.130:/root/test-dir
root@192.168.1.130‘s password:
real 5m12.625s
user 3m55.503s
sys 0m34.568s
4、直接rsync启用压缩功能的传输时间（4’36‘’）：
[root@cap131 ~]# time rsync -zr /var/log/ 192.168.1.130:/root/test-dir
real 4m35.991s
user 4m40.208s
sys 0m5.306s
5、边打包边压缩边传输边解压的时间（采用ssh远程执行命令的push方式）：
[root@cap131 ~]# time tar czf - /var/log |ssh 192.168.1.130 tar xzf - -C /root/test-dir/
tar: Removing leading `/‘ from member names
real 3m33.711s
user 3m37.066s
sys 0m22.210s
边打包边压缩边传输边解压的时间（采用ssh远程执行命令的pull方式）：
[root@cap130 test-dir]# time ssh 192.168.1.131 tar czf - /var/log |tar xzf - -C /root/test-dir/
tar: Removing leading `/‘ from member names
real 3m33.772s
user 1m13.207s
sys 0m55.302s
6、边打包边压缩边传输边解压的时间（采用nc push的方式）：
接受端监听端口10086：
[root@cap130 test-dir]# nc -l 10086 |tar xzf - -C /root/test-dir/
发送端开始传输：
[root@cap131 ~]# time tar czf - /var/log |nc 192.168.1.130 10086
tar: Removing leading `/‘ from member names
real 3m31.218s
user 3m27.908s
sys 0m15.839s
边打包边压缩边传输边解压的时间（采用nc pull的方式）：
这种方式好像行不通！
EOF