第 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 明确接收方会看到什么：未完成的内容暂不可下载，或仅显示进度。