第 2 章 アップロード パス: チャンキング、同時実行、および再開 (キー)

2.1 チャンク化

• クライアントはファイルを複数のチャンクに分割しなければなりません。チャンクはアップロード/リトライの最小単位です。
• 同時実行スケジュールと状態表現を簡素化するために、チャンクは固定サイズ (またはファイルごとのサイズ ポリシー) を使用する必要があります (SHOULD)。
• 即時の利点: 障害が発生した場合、影響を受けるのはファイル全体ではなく 1 つのチャンクのみです。

2.2 並列アップロード

同時実行の目的は「スレッドを増やす」ことではなく、実際のネットワークにおける単一接続の 3 つの実際的な制限を回避することです。

• 遅いスタートとウィンドウの成長: 単一の接続は、特にクロスリージョン RTT が高い場合、ゆっくりと立ち上がります。
• リンクジッター: 1 つの接続上のジッターにより全体の速度が低下する可能性があります。同時実行により効果が滑らかになります。
• フローごとのシェーピング: 一部のネットワークは単一のフローを抑制します。複数のフローは、(コンプライアンスの制約内で) 帯域幅の上限に近づく可能性があります。

• クライアントは、制限された同時実行数 (例: 4 ～ 12) を使用し、メモリのスパイクを避けるために、弱いデバイスでは同時実行数を下げる必要があります (SHOULD)。
• クライアントは同時実行性を調整してもよい(MAY)。スループットが向上した場合は増加させる。エラー率が上昇すると減少します。

2.3 べき等性と再試行

• 同じチャンクの繰り返しアップロードは冪等でなければなりません (MUST)。重複した送信によって、すでに完了した状態が破壊されてはなりません。
• サーバーは、(transferId、fileId、chunkIndex) または同等の制約による一意性を強制する必要があります (SHOULD)。
• クライアントは指数バックオフの再試行を実装しなければなりません。失敗した場合は、失敗したチャンクのみを再試行する必要があります。

2.4 再開可能なアップロード

• サーバーは、クライアントが完了したチャンクをスキップできるように、「どのチャンクがすでにアップロードされているか」に答えることができなければなりません。
• チャンク数に応じて状態サイズが直線的に増大するのを避けるために、アップロードされたセットはビットマップ/範囲セットとして表現されるべきです(SHOULD)。
• 速度の利点: ネットワークの中断、ブラウザのクラッシュ、またはネットワークの切り替え後、再開は 0% から再開されません。

2.5 「アップロード中の共有」（オプション）

• システムは、配信ワークフローを高速化するために、アップロードの進行中に使用可能な転送識別子と共有リンクを生成してもよい(MAY)。
• アップロード完了前に共有が許可されている場合は、受信者に表示される内容を明示しなければなりません。不完全なコンテンツはまだダウンロードできないか、進行状況のみが表示されます。