第 2 章 上传链路：分片、并发与断点续传（重点）
上传侧的目标是：在波动网络下尽量接近“跑满带宽”，并且在失败时把代价限制在最小范围（只重传失败分片）。 这两点共同决定了“为什么更快”。
2.1 分片（Chunking）
- 客户端 MUST 将文件拆分为多个 chunk，chunk 为上传/重试的最小单位。
- chunk SHOULD 使用固定大小（或按文件大小分段策略），以便并发调度与状态表示。
- 分片的直接收益：任何失败只影响单个 chunk，而不是整文件。
2.2 并发（Parallel Upload）
并发的核心目的不是“多开线程”，而是规避单连接在真实网络中的三类限制：
- 慢启动与窗口增长：单连接爬坡慢，尤其跨洲高 RTT 时更明显。
- 链路抖动：单连接一抖动就会全局降速；并发能把抖动平均掉。
- 路径限速：某些网络对单流限速，多流更容易接近带宽上限（以合规为前提）。
- 客户端 SHOULD 采用有限并发（例如 4~12），并在弱设备上降低并发以避免内存峰值。
- 客户端 MAY 做自适应并发：吞吐上升则增加、错误率上升则减少。
2.3 幂等与重试（Idempotency & Retry）
- 同一 chunk 的重复上传 MUST 幂等：重复提交不得破坏已完成状态。
- 服务端 SHOULD 以（transferId, fileId, chunkIndex）作为唯一键或等价约束。
- 客户端 MUST 支持指数退避重试；失败 SHOULD 仅重试失败 chunk。
2.4 断点续传（Resumable Upload）
- 服务端 MUST 能回答“哪些 chunk 已上传”，客户端据此跳过已完成分片。
- 已上传集合 SHOULD 用 bitmap / range-set 表示，避免状态体积随 chunk 数线性膨胀。
- 断点续传的速度收益：网络中断/浏览器崩溃/切网后恢复时，不需要从 0% 重来。
2.5 “边上传边可用”（可选能力）
- 系统 MAY 在上传进行中生成可用的 transfer 标识与分享链接，用于加快交付流程。
- 如果允许“上传未完成就可分享”，MUST 明确接收方体验：未上传完成的内容不可下载或仅可看到进度。