rsync启用--compress时，高压缩等级反而拖慢传输，因压缩全在客户端CPU执行，网络不拥塞时CPU成瓶颈；level 0禁用压缩仅快速打包，level 1–3适合带宽受限场景，level 9多属浪费。
用 rsync + --compress-level 时，压缩等级反而拖慢传输？
不是压缩等级越高越好。远程备份走 rsync 时，如果启用了 --compress（或 -z），它默认用 zlib 的 level 6 压缩，但这个压缩过程全在客户端 cpu 上跑，服务端不参与。当网络其实不拥塞（比如千兆内网、云厂商同可用区），cpu 压缩反而成了瓶颈，延迟上升、吞吐下降。
-
rsync的--compress-level只在启用--compress时生效；没开压缩，设了也白设 - level 0 表示“只做 LZ4 式快速打包，不真正压缩”，实际是禁用压缩但保留协议层压缩协商，适合 SSD+高带宽场景
- level 1–3 更适合老服务器或上传带宽受限（如家庭宽带上传 50Mbps）的场景；level 9 在多数远程备份中纯属浪费 CPU
- 验证方法：加
--stats看Bytes Sent和Bytes Received比原始文件大小，再用time rsync ...对比耗时
备份链路丢包率高，ssh 层该调哪些参数？
丢包不是 rsync 能解决的，得从 ssh 底层入手。默认 ssh 对丢包很敏感，重传策略保守，小丢包就触发 TCP 重传+超时，表现就是卡顿、连接中断、Write failed: Broken pipe。
- 在
~/.ssh/config里为对应主机加：ServerAliveInterval 30和ServerAliveCountMax 3，避免 NAT 超时断连 - 禁用
TCPKeepAlive no（改用应用层保活更可靠） - 关键：加
TcpNoDelay yes，关闭 Nagle 算法，减少小包攒批延迟——对交互式备份尤其有效 - 不要碰
IPQoS或Compression yes，后者会跟rsync --compress冲突，导致双重压缩
tar 打包阶段就该控制压缩，别全压给 rsync
很多人习惯 tar czf - /data | ssh host 'tar xzf -'，这会让压缩完全发生在本地管道里，无法增量、不可暂停、出错难恢复。而 rsync 的优势在于 delta 传输，前提是源和目标都有完整文件树。
- 先用
rsync -av --delete同步原始文件（无压缩），再单独对归档目录跑gzip -1或zstd -T1 --long=31——分离关注点 - 如果必须边传边压，用
rsync --rsync-path="gzip -1 | rsync --server ..."这类绕过方式极不稳定，容易因管道阻塞失败 -
zstd比gzip在 level 1–3 下快 3–5 倍，压缩率接近 gzip level 6，适合备份场景；但注意目标服务器得装zstd，否则解压失败
真正影响延迟的，往往是 DNS 和 SSH 密钥交换
一次 rsync 连接建立，常被忽略的耗时大户是 DNS 查询和密钥协商。特别是用域名连跳板机或私有 CA 签发的证书时，ssh 会尝试反向 DNS 查找、OCSP Stapling、CRL 检查等。
- 在
~/.ssh/config加UseDNS no和VerifyHostKeyDNS no，省掉两次 DNS 往返 - 用
ed25519密钥代替rsa（尤其是 4096 位），密钥交换快 3–4 倍；确认服务端sshd_config含PubkeyAcceptedAlgorithms +ssh-ed25519 - 加
ControlMaster auto和ControlPersist 600，后续rsync复用已有连接，首次握手耗时只付一次
压缩等级只是表象，真正卡住备份速度的，常常是 SSH 连接建立慢、DNS 查不到、密钥太老、或者 rsync 在反复试探路径权限。调参前先用 rsync -vv --stats 和 ssh -v 看清哪一步停住了。
