第3章 ダウンロード経路：並列ダウンロード、復旧、再構築（重要）
受信者にとって、「速い」ことは主に 2 つの形で現れます。複数のチャンクを並列で取得してスループットを高めることと、電波の弱いネットワークやネットワークの切り替え時にも、最初からやり直さずに復旧できることです。 エンジニアリングの観点では、ダウンロード経路はアップロード経路と対称になっています。
3.1 ダウンロード対象とマニフェスト
- ダウンロードの前に、クライアントはマニフェストを取得して、チャンクの総数、順序、各オブジェクトの場所を把握することが望まれます（SHOULD）。
- マニフェストは、（オブジェクトキーの規則またはそれと同等のインデックスによって）各チャンクの場所を一意に特定できなければなりません（MUST）。
3.2 並列ダウンロード
- クライアントは、帯域の上限に近づけるため、複数のチャンクを同時にダウンロードすることが望まれます（SHOULD）。
- クライアントは、同時実行数に上限を設け、エラー率が上がったら減らすことが望まれます（SHOULD）。
- 単一の接続は RTT やジッターの影響を受けやすいため、リージョンをまたぐ RTT が大きいほど、並列化の効果は大きくなる傾向があります。
3.3 再開可能なダウンロード
- クライアントは、完了したチャンクの集合（ビットマップやインデックスの集合など）を記録できなければなりません（MUST）。
- 中断後は、ファイル全体を再ダウンロードするのではなく、不足しているチャンクだけを取得することが望まれます（SHOULD）。
- サーバーがダウンロード回数の上限を設けている場合、クライアントは、回数を無駄にしないよう、復旧時の重複したダウンロードを最小限にすることが望まれます（SHOULD）。
3.4 再構築
- クライアントは、出力ファイルを chunkIndex の順に再構築しなければなりません（MUST）。
- クライアントは、メモリのピークを抑えるため（特に非常に大きなファイルの場合）、ストリーミング書き込みや段階的な再構築を使うことが望まれます（SHOULD）。
- 複数のファイルがまとめられている場合、クライアントは、ファイルごとに出力するか、コンテナ形式を使って出力してもかまいません（MAY。製品の設計によります）。
3.5 整合性チェック（概要）
- ダウンロード後、クライアントは、チャンクを検証する（ハッシュや長さの整合性など）ことが望まれます（SHOULD）。
- 検証に失敗した場合は、フェイルクローズし、該当するチャンクを再試行しなければなりません（MUST）。
- 暗号化や認証の失敗に関する境界については、セキュリティとプライバシーのホワイトペーパーの該当する節を参照してください。