为何scp比rsync更快？rsync传输速度远低于scp的技术咨询

我之前也碰到过类似的情况——原本以为rsync速度不会输给scp，结果实际用起来差了一大截。结合你的场景（1G带宽跑不满、存在1GB大文件+多小文件），咱们来一步步优化：

先搞懂为什么rsync更慢 #

rsync默认的-avr参数包含了很多额外操作：

• a（归档模式）会同步文件权限、所有者、修改时间等元数据，这些操作会增加额外的IO和网络开销
• rsync默认会做块级校验（用来实现增量同步），即便是第一次全量复制，它也会先对比文件的校验信息，这对大文件来说会消耗不少时间
• 递归处理大量小文件时，rsync逐个文件的校验和元数据同步开销会被放大，而scp相对更“轻量化”，直接专注于文件传输

针对性优化方案 #

1. 关闭块级校验，让rsync像scp一样传输全量文件 #

如果是第一次复制不需要增量同步，直接加-W（--whole-file）参数，跳过块校验环节，命令改成：

rsync -avrW remote:/your/source/path/ ./local/target/path/

这个参数对大文件传输的提升特别明显，能立刻减少rsync的额外开销。

2. 减少不必要的元数据同步 #

如果不需要保留文件的权限、所有者等元数据，可以去掉a里的冗余项，用更精简的参数：

rsync -r --no-perms --no-owner --no-group --no-times remote:/your/source/path/ ./local/target/path/

这样rsync就只专注于文件内容的传输，不用处理额外的元数据。

3. 调整传输缓冲区和SSH加密算法 #

• 增大传输缓冲区：默认的缓冲区大小可能限制了大文件的传输速度，加--buffer-size参数，比如设置为64M或128M：

rsync -avrW --buffer-size=64M remote:/your/source/path/ ./local/target/path/

• 改用更快的SSH加密算法：SSH的加密解密开销也会影响传输速度，选择轻量的加密算法（比如aes128-gcm@openssh.com），命令：

rsync -avrW --buffer-size=64M -e 'ssh -c aes128-gcm@openssh.com' remote:/your/source/path/ ./local/target/path/

4. 小文件密集场景的特殊处理 #

如果目录里有大量小文件，逐个传输的开销会非常大，不如先在远程端打包，再传输后解压：

# 远程打包+管道传输到本地解压
ssh remote_host "tar -cf - /your/source/path" | tar -xf - -C ./local/target/path/

这种方式能减少大量文件系统的操作开销，速度会比rsync逐个传小文件快很多。

总结 #

结合你的情况，优先试试-W+大缓冲区+优化SSH加密的组合命令，应该能让rsync的速度接近甚至达到scp的水平。如果是小文件特别多的场景，打包传输会更高效。

内容的提问来源于stack exchange，提问作者Pythoneer