scp默认不支持断点续传、无压缩、无心跳机制，易因网络抖动或拥塞失败；rsync需配--partial和ServerAliveInterval等参数才能稳定传输大文件。
scp 和 rsync 都能传大文件，但默认行为下容易卡死、断连、耗时翻倍——关键不在“能不能”，而在“怎么配参数”。
为什么大文件传输总失败或极慢
不是SSH本身扛不住，而是默认配置没针对大文件优化：
• scp 不带压缩时，原始字节全量发，千兆网也压不住 100MB+ 日志包
• TCP 窗口太小 + 无重传策略，一丢包就卡住十几秒，scp 不自动续传
• SSH 加密开销叠加网络抖动，未启用压缩或限速反而触发拥塞丢包
• 目标端磁盘 I/O 慢（比如 NFS 或低速 USB 盘），但 scp 完全不感知，只管推
scp 传大文件必须加的三个参数
单靠 scp file user@host:/path 传几百 MB 就可能失败。要稳定，至少补这三项：
-
-C：强制启用 SSH 层压缩（LZ4 级别），文本类文件实测提速 40%~60%，二进制（如 tar.gz）效果弱但仍有缓冲作用 -
-o ConnectTimeout=30 -o ServerAliveInterval=60：避免中间网络抖动导致连接静默断开；ServerAliveInterval是心跳，比单纯调ConnectTimeout更治本 -
-l 5120（单位 Kbit/s）：限速到约 640KB/s，避开交换机缓冲区溢出；实测在 100Mbps 网络上传 2GB 文件，不限速失败率超 30%，限 5Mbit/s 后失败率为 0
完整命令示例：scp -C -l 5120 -o ConnectTimeout=30 -o ServerAliveInterval=60 big.tar.gz user@192.168.1.100:/data/
rsync 对大文件更可靠，但别直接套默认参数
rsync 天然支持断点续传和增量，但默认不开启关键防护项，大文件照样挂：
- 必须加
--partial：传输中断后保留已写部分，下次自动续传（scp完全没这功能） - 必须加
--timeout=60：防 SSH 连接空闲超时，配合-e "ssh -o ServerAliveInterval=30"双保险 -
-z压缩和-C（保留权限）对大文件意义不大，可省；重点用-av（归档+详细输出）+--progress实时看卡在哪
推荐命令：rsync -av --partial --timeout=60 --progress -e "ssh -o ServerAliveInterval=30" big.iso user@host:/backup/
真正超过 10GB 的文件，换思路
再好的参数也救不了物理瓶颈。这时该放弃“一次传完”思维：
- 先
split -b 2G big.file big_part_拆块，用rsync并行传多个分片（注意加--files-from控制顺序） - 传完在远端用
cat big_part_* > big.file拼合，比单进程传 15GB 稳定得多 - 如果目标是备份场景，直接上
rsync --sparse（对稀疏文件如虚拟机镜像跳过空块），节省 70%+ 传输量
最后提醒一句：别信“加大 TCPWindowSize 就能提速”这种玄学操作。Linux 内核自适应足够好，真正拖慢大文件的，90% 是没设 --partial 和 ServerAliveInterval 导致的静默中断——而这俩参数，scp 根本不支持。
