第 2 章 上傳路徑：分塊、並行與續傳（重點）
在上傳端，目標是在網路起伏不定的情況下，盡可能逼近「把頻寬跑滿」，同時把失敗的代價降到最低（只重傳失敗的區塊）。 這兩個目標，大致說明了上傳為什麼感覺更快。
2.1 分塊
- 用戶端 MUST 把檔案切分為多個區塊；區塊是上傳／重試的最小單位。
- 區塊 SHOULD 採用固定大小（或依檔案大小而定的策略），以簡化並行排程與狀態表示。
- 立即的好處：任何失敗都只影響單一區塊，而不是整個檔案。
2.2 平行上傳
並行的目的不是「更多執行緒」，而是避免單一連線在真實網路中的三項實際限制：
- 慢啟動與視窗成長：單一連線的速度爬升緩慢，在跨區域 RTT 較高時尤其明顯。
- 鏈路抖動：單一連線上的抖動可能拉低整體速度；並行可以平滑這種影響。
- 單一流量限速：有些網路會對單一流量限速；多條流量可以更接近頻寬上限（在合規限制範圍內）。
- 用戶端 SHOULD 採用有限的並行度（例如 4–12），並在效能較弱的裝置上調低，以避免記憶體暴增。
- 用戶端 MAY 自適應調整並行度：吞吐量上升時提高，錯誤率上升時降低。
2.3 冪等與重試
- 同一區塊的重複上傳 MUST 具備冪等性：重複提交不得破壞已完成的狀態。
- 伺服器 SHOULD 以 (transferId, fileId, chunkIndex) 或等效的限制條件來確保唯一性。
- 用戶端 MUST 實作指數退避重試；發生失敗時 SHOULD 只重試失敗的區塊。
2.4 可續傳上傳
- 伺服器 MUST 能夠回答「哪些區塊已經上傳」，讓用戶端可以跳過已完成的區塊。
- 已上傳的集合 SHOULD 以點陣圖（bitmap）／範圍集合（range-set）表示，避免狀態大小隨區塊數量線性成長。
- 速度上的好處：網路中斷、瀏覽器當機或網路切換之後，續傳不會從 0% 重新開始。
2.5「邊傳邊分享」（選用）
- 系統 MAY 在上傳仍在進行時，就產生可用的傳輸識別碼與分享連結，以加快交付工作流程。
- 若允許在上傳完成前分享，MUST 明確說明接收者看到的內容：尚未完成的內容暫時無法下載，或僅顯示進度。