目前很多应用场景中，出于各种考虑，使用了 scp 或者rsync+ssh 的方式进行数据传输。但是一直都使用缺省选项，很少进行优化。我在内部数据同步时，也长期使用了缺省选项，后来碰到几百G到几个T的数据同步，不得不考虑到带宽和效率问题，决定进行一些简单优化。
经过一个快速的简单测试，可以明显看到：建立ssh数据通道进行传输时，缺省使用的加密方式(3des-cbc为缺省优先选择加密算法)和指定arcfour（在openssl中为rc4）的传输速率相差很大，是否使用压缩参数也差异显著，大概有5倍左右的传输速率差异。因此有必要对scp或者rsync+ssh数据传输的参数进行调整。我的最终调整结果如下：
rsync -apur --partial -e "ssh -p 22 -carcfour" SRC DEST
scp -P 22 -c arcfour SRC DEST
其中数字22为ssh服务监听端口号，可以根据实际情况变更。大多数情况下服务器内都是缺省22端口的，同时在比较新的GNU/Linux Distros如RHEL5U4、CentOS 5.2里边rsync缺省已经设置—rsh=ssh，因此可以省略-e选项中的[-p22]部分。但是为了完整起见，请尽量不要省略此参数。
我之前给过的命令行参数是：
rsync -azpur --progress -e "ssh -p22" SRC DEST
请取消如下参数：
-z压缩选项，避免浪费CPU解压缩计算资源。对于已经压缩过或者可压缩性很低的文件就不要使用此选项了。对于纯文本或者有高压缩率的文件可以考虑使用。但建立ssh加密通道时最好是别用了。鉴于目前大多数情况下的数据传输的实际使用场景，建议不要使用-z压缩选项。
-v和--progress选项是适合于交互使用或者需要日志统计的情况，可以随时观察进度；对于后台执行的可以忽略不要。
ssh的cipher可用算法列表，同时也是缺省使用次序：3des-cbc,aes128-cbc, aes192-cbc, aes256-cbc, aes128-ctr, aes192-ctr, aes256-ctr,arcfour128, arcfour256, arcfour, blowfish-cbc, andcast128-cbc
寻找最快的加密算法的方法，用于选择ssh的fastestcipher参数：openssl speed或者opensslspeed aes rc4 blowfish
