第 3 章 ダウンロード パス: 並列ダウンロード、リカバリおよび再アセンブリ (キー)
受信者にとって、「高速化」は主に 2 つの方法で現れます。1 つはスループットを向上させるために複数のチャンクを並行してフェッチすること、もう 1 つは弱いネットワークまたはネットワーク切り替え下で再起動せずに回復できることです。 エンジニアリングの観点から見ると、ダウンロード パスはアップロード パスと対称です。
3.1 オブジェクトとマニフェストをダウンロードする
- ダウンロードする前に、クライアントはマニフェストを取得して、総チャンク数、順序、各オブジェクトの検索方法を学習する必要があります (SHOULD)。
- マニフェストは、(オブジェクト キー ルールまたは同等のインデックスを介して) 各チャンクを一意に見つけなければなりません (MUST)。
3.2 並列ダウンロード
- クライアントは、帯域幅の上限に近づくために、複数のチャンクを同時にダウンロードする必要があります (SHOULD)。
- クライアントは制限された同時実行性を使用し、エラー率が上昇した場合にはそれを減らす必要があります(SHOULD)。
- 単一の接続は RTT とジッターによって制限されやすくなるため、クロスリージョン RTT が高いほど同時実行性のメリットが大きくなることがよくあります。
3.3 再開可能なダウンロード
- クライアントは、完成したチャンクのセット (ビットマップ/インデックス セットなど) を記録できなければなりません (MUST)。
- 中断後、クライアントはファイル全体を再ダウンロードするのではなく、欠落しているチャンクのみをフェッチすべきです(SHOULD)。
- サーバーがダウンロード数の制限を強制する場合、クライアントはカウントの無駄を避けるために、リカバリ中の冗長なダウンロードを最小限に抑えるべきです(SHOULD)。
3.4 再組み立て
- クライアントは出力ファイルを chunkIndex の順序で再構築する必要があります。
- クライアントは、メモリのピークを減らすためにストリーミング書き込み/プログレッシブ再アセンブリを使用する必要があります (特に非常に大きなファイルの場合)。
- 複数のファイルがパッケージ化されている場合、クライアントはファイルごとに出力するか、コンテナ形式を使用してもよい (製品設計に応じて)。
3.5 整合性チェック (短い)
- ダウンロード後、クライアントはチャンク (ハッシュ/長さの一貫性など) を検証する必要があります (SHOULD)。
- 検証が失敗した場合は、フェールクローズして、対応するチャンクを再試行しなければなりません (MUST)。
- 暗号化/認証の失敗に関する境界については、セキュリティとプライバシーのホワイトペーパーの関連セクションを参照してください。