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 や高速なハンドシェイク経路は、特定の条件下でセッションを再開するための機能です。条件が整えば恩恵を受けてもかまいません (MAY)。ただし、性能を高める唯一の手段として頼ってはなりません (MUST NOT)。

確認方法

  • ブラウザーの開発者ツール (Network や Protocol など。画面はブラウザーによって異なります) で、リクエストが h3 (HTTP/3) を使っているか、h2 や h1 にフォールバックしているかを確認できます。
  • 同じネットワーク条件で、h3 と h3 以外の接続確立の速さやスループットの安定性 (特に RTT が大きい場合やパケットロスがある場合) を比べると、はっきり違いが出ることがあります。

1.3 極限の並列処理: チャンクストリーミング (Chunked Streaming)

  • システムは、大きなファイルを論理的に複数のチャンクへ分割しなければなりません (MUST)。各チャンクは、アップロード、再試行、復旧の最小単位です (第 2 章を参照)。
  • クライアントは、同時実行数を制限しながら (たとえば複数の並列パイプラインで) 複数のチャンクを転送すべきです (SHOULD)。これにより、帯域の上限に近づき、単一接続のジッターに左右されにくくなります。
  • クライアントは、再開できる転送に対応しなければなりません (MUST)。復旧時は、完了済みのチャンクを飛ばして不足分だけを取得し、ファイル全体の再送を避けます (第 2 章を参照)。
  • 並列処理とチャンク分割によって、単一リクエストの詰まり (ヘッドオブラインや再送の待ち時間を含みます) による待機は大幅に減りますが、特定のネットワーク現象を「完全に排除する」と主張すべきではありません (SHOULD NOT)。 目的は、影響を減らして、スループットを安定して高めることです。

確認方法

  • Network パネルで、複数のアップロードまたはダウンロードのリクエストが同時に走っている様子 (チャンクの並列実行) を確認できます。
  • ネットワークを切断したり、ページを再読み込みしたりしたあとに転送を再開しても、0% からやり直しにはなりません (不足しているチャンクだけが補われます)。

1.4 トポロジーの強み: Anycast による最寄りエッジへの接続 (エッジネットワーク)

  • システムは、Anycast やエッジの入口を通じて、ユーザーのリクエストを最寄りのノードへルーティングすべきです (SHOULD)。これにより、RTT と、リージョンをまたぐホップによる遅延やジッターを減らします。
  • 最寄りエッジへの接続は、並列チャンク分割の全体的な効率を高めます。RTT が小さいほど、並列に走る各フローの実効スループットの上限が上がりやすく、回線を使い切りやすくなります。
  • エッジのカバレッジや拠点数は、インフラの進化に伴って変わることがあります。対外的には「エッジのカバレッジ / 最寄りの入口」と表現し、数値は確約ではなく目安として扱ってください。

確認方法

  • traceroute やブラウザーの接続情報を使うと、接続がより近い入口で終端していることを確認できる場合が多くあります (方法は環境によって異なります)。
  • リージョンをまたぐ比較 (たとえば米国↔欧州、日本↔米国) では、通常、RTT の短縮が最もはっきり現れます。

1.5 マルチソースの並列処理: インテリジェントなスケジューリング (Multi-Source)

  • システムは、リンク品質の指標 (スループット、遅延、エラー率など) に基づいて動的に選択を行うべきです (SHOULD)。これにより、異なるチャンクを、より条件の良い複数のノードや配置先に割り当てられ、 単一箇所の輻輳が全体のスループットに与える影響を減らせます。
  • ダウンロード時、クライアントは、複数のソースから異なるチャンクを同時に取得し、「マルチソースで引き込む」高速化の効果を得てもかまいません (MAY)。マルチソースを利用できない場合は、可用性を保つために、自動的に単一ソースのダウンロードへ縮退しなければなりません (MUST) (第 3 章を参照)。
  • これを「AI」として訴求する場合は、スケジューリングと意思決定のためのアルゴリズムによる仕組みとして位置づけ、入力、出力、縮退時の動作を明確に定義して、あいまいな主張を避けるのが望ましいでしょう。

確認方法

  • ダウンロード中に、異なるソースや接続からの同時リクエストが見られる場合があります (実装やブラウザーでの見え方によって異なります)。
  • 輻輳やパケットロスがある状況では、マルチソースの並列処理によってスループットが安定することが多くあります。条件を満たさない場合は自動的に縮退しますが、引き続き利用できます。

1.6 次の章との対応関係

  • 第 2 章では、「チャンク分割、並列処理、冪等性、再開できるアップロード」を、実装できるフローと制約 (MUST / SHOULD / MAY) として具体化し、それらがアップロードの速度と安定性を直接左右する理由を説明します。
  • 第 3 章では、「並列ダウンロード、復旧、再構成」と、回線の弱い環境で重複ダウンロードによる速度低下を避ける方法を説明します。
  • 第 4 章では、性能と復旧性に関わる最小限のストレージモデル (オブジェクト層と状態層、TTL と削除の意味づけ) だけを取り上げます。