Logo

第 1 章 高速になる理由: 4 つの主要なメカニズム

FileBolt の速度の利点は、トランスポート、並列チャンキング、グローバル トポロジ、およびマルチソース スケジューリングの組み合わせによってもたらされます。 この章では、どのメカニズムがピーク スループットを向上させ、どのメカニズムがパケット損失やネットワーク スイッチング時の安定性と回復可能性を向上させるかを監査可能な方法で説明します。

1.1 設計目標 (スピードビュー)

  • 目標 A: 帯域幅の上限に近づく。 一般的な状況では、利用可能な帯域幅が飽和状態になるようにしてください。
  • 目標 B: 安定したスループット。 損失、ジッター、ネットワーク スイッチング、およびクロスリージョン RTT が高くても、突然低下するのではなく、使用可能なスループットを維持します。
  • 目標 C: 回復可能な失敗。 エラーが発生した場合は、再送信するコストを少量のデータのみに制限し、0% から再開することは避けてください。

1.2 トランスポート層の最適化: HTTP/3 (QUIC)

  • クライアントとエッジのイングレスは HTTP/3 (QUIC) を優先する必要があります (SHOULD)。ブラウザ、ネットワーク、またはミドルボックスがそれをサポートしていない場合、システムは自動的に HTTP/2/HTTP/1.1 にフォールバックしなければなりません (MUST)。 可用性を維持するため。
  • パケット損失が発生した場合、QUIC のトランスポートと輻輳制御により、多くの場合、エンドツーエンドのスループットに対するヘッドオブライン ブロッキングの影響が軽減され、安定性が向上します (結果はネットワークの状態によって異なります)。
  • 0-RTT / 高速ハンドシェイク パスは、特定の条件下でのセッション再開機能です。システムは、条件が満たされたときに恩恵を受ける場合がありますが、唯一のパフォーマンス レバーとして依存してはなりません。

確認方法

  • ブラウザの DevTools (ネットワーク/プロトコルなど。UI はブラウザによって異なります) で、リクエストが h3 (HTTP/3) を使用しているか、h2/h1 にフォールバックしているかを観察できます。
  • 同じネットワーク条件下で、h3 接続セットアップと非 h3 接続セットアップを比較すると、スループットの安定性 (特に高い RTT / 損失の下) が著しく異なる場合があります。

1.3 極端な同時実行性: チャンク ストリーミング (チャンク ストリーミング)

  • システムは、大きなファイルを論理的に複数のチャンクに分割しなければなりません。各チャンクはアップロード/リトライ/リカバリの最小単位です (第 2 章を参照)。
  • クライアントは、帯域幅の上限に近づき、単一接続のジッターに対する感度を下げるために、制限された同時実行性 (例: 複数の並列パイプライン) で複数のチャンクを転送する必要があります (SHOULD)。
  • クライアントは再開可能な転送をサポートしなければなりません (MUST)。回復時に、完了したチャンクをスキップし、欠落したチャンクのみをフェッチし、ファイル全体の再送信を回避します (第 2 章を参照)。
  • 同時実行性とチャンク化により、単一リクエストのブロック (ヘッドオブラインや再送信の待機を含む) によって引き起こされる待機が大幅に削減されますが、特定のネットワーク現象を「完全に排除する」と主張すべきではありません。 目標は、影響を軽減し、安定したスループットを向上させることです。

確認方法

  • [ネットワーク] パネルでは、複数の並列アップロード/ダウンロード リクエストを同時に観察できます (チャンクの同時実行)。
  • ネットワークを切断した後、またはページを更新した後、転送を再開する際は 0% から再開しないでください (欠落したチャンクのみが完了します)。

1.4 トポロジの利点: エニーキャスト最近接エッジ アクセス (エッジ ネットワーク)

  • システムは、RTT とクロスリージョンホップによって引き起こされるレイテンシ/ジッターを削減するために、エニーキャスト/エッジイングレスを介してユーザーリクエストを最も近いノードにルーティングすべきです(SHOULD)。
  • ニアレスト エッジ アクセスにより、並列チャンクの全体的な効率が向上します。通常、RTT が低いと、各同時フローの実効スループットの上限が上昇し、リンクが飽和しやすくなります。
  • エッジのカバレッジとロケーションの数は、インフラストラクチャの進化に応じて変化する可能性があります。対外的には、これを「エッジ カバレッジ / 最も近い入力」と表現し、数値を厳密な保証ではなく指針として扱います。

確認方法

  • トレースルートまたはブラウザの接続情報を使用すると、接続がより近い入口で終了することがよくわかります (方法は環境によって異なります)。
  • 地域間比較 (例: 米国↔EU / 日本↔US) では、通常、RTT の削減が最も顕著になります。

1.5 マルチソースの同時実行: インテリジェントなスケジューリング (マルチソース)

  • システムは、リンク品質信号 (スループット、レイテンシー、エラー率など) に基づいて動的選択を行うべきであり、異なるチャンクを複数のより優れたノード/配置に割り当てることができます。 全体のスループットに対する単一ポイントの輻輳の影響を軽減します。
  • ダウンロード時に、クライアントは「マルチソース プル」加速効果のために、複数のソースから異なるチャンクを同時にフェッチしてもよい(MAY)。マルチソースが利用できない場合は、自動的に単一ソースのダウンロードに低下しなければなりません (MUST) 可用性を維持するため (第 3 章を参照)。
  • これを「AI」として宣伝する場合は、それをスケジューリングと意思決定のためのアルゴリズム システムとしてフレーム化し、曖昧な主張を避けるために入出力と劣化動作を明確に定義することが最善です。

確認方法

  • ダウンロード中に、さまざまなソース/接続からの同時リクエストが観察される場合があります (実装とブラウザの可視性によって異なります)。
  • 輻輳や損失が発生した場合、マルチソースの同時実行により安定したスループットが実現されることがよくあります。条件が満たされない場合、自動的に機能が低下しますが、引き続き使用できます。

1.6 これが次の章にどのように対応するか

  • 第 2 章では、「チャンク、同時実行性、冪等性、および再開可能なアップロード」を実装可能なフローと制約 (MUST/SHOULD/MAY) に拡張し、それらがアップロード速度と安定性を直接決定する理由を説明します。
  • 第 3 章では、「並列ダウンロード、リカバリ、再構築」と、弱いネットワーク下での冗長ダウンロードによる速度低下を回避する方法について説明します。
  • 第 4 章では、パフォーマンスと回復可能性 (オブジェクト層と状態層、TTL/削除セマンティクス) に関連する最小限のストレージ モデルのみを保持します。