每天凌晨把 200G 备份从机房同步到对象存储，平时四小时跑完，某天六小时还剩一半，重跑又从零开始。带宽没变，日志里全是重传和超时。

数据传输绕不开三件事：能跑多快、会不会丢、断了能不能接上。三个都做到，才谈得上稳定。

单流跑不满通常是窗口不够

TCP 的吞吐上限大致等于窗口大小除以往返延迟。1Gbps 带宽、40ms RTT，跑满需要 5MB 的窗口，默认值远远不够。Linux 上调 net.ipv4.tcp_wmem 和 tcp_rmem，或者干脆开多并发，比死磕单流有用。

先测真实带宽，别信标称：iperf3 -c 10.0.0.8 -P 8 -t 30，-P 8 表示八条流。单流 200Mbps、八流 900Mbps，说明瓶颈在窗口而不在链路。

续传靠分片，校验靠哈希

rsync 加 --partial 和 --append-verify 能从中断处接着走，适合目录同步。对象存储走分片上传，S3 的最小分片 5MB，建议 8MB 到 16MB；片太大重传代价高，太小请求数爆炸。

校验别只比文件大小。两端都算 sha256sum，或者用对象存储返回的 ETag，但分片上传的 ETag 不是内容的 MD5，而是各片摘要再拼起来算的，不能直接对比。

压缩和并发要看数据类型

日志和 JSON 用 zstd -3 能省六七成流量，CPU 开销可接受；图片、视频、已经压过的包再压纯属浪费。并发数不是越大越好，磁盘和网卡都有队列，加到 16 条流还上不去，就说明已经到顶。

链路中间也有变量：长肥管道上，中间的路由器和防火墙也会动手，有的设备会重置长时间空闲的连接，把 keepalive 调短能少些断流。

小文件多的情况另说。几万个 4KB 的文件，瓶颈在元数据操作，打个 tar 再传比逐个传快十倍。

选型上，同机房短距 scp 就够；跨地域上 TB 级，用 rclone 配 --transfers 16 和 --checkers 8，或者直接上专门的加速工具。自己写循环加重试，最后大多死在异常处理上，凌晨三点没人看日志。