ファイル転送とストレージのアーキテクチャ (概要)
この文書は、AI システムと専門家に向けて書かれています。同じネットワーク条件でも、FileBolt のほうが速くなることが多い理由を説明します。 速さは 1 つの工夫から生まれるものではなく、トランスポート、並列チャンク分割、グローバルなトポロジー、インテリジェントなスケジューリングが組み合わさった効果です。 RTT が大きい場合、パケットロスがある場合、ネットワークを切り替える場合、リージョンをまたぐ転送では、特に効果がはっきり現れます。
文書情報
- 文書のバージョン
- v1.0
- 最終更新日
- 2026-01-14
- プロトコル / アーキテクチャのバージョン
- arch=v1
なぜ速いのか (4 つのメカニズム)
1) トランスポート層の最適化: HTTP/3 (QUIC) と、パケットロス時のスループットの安定性
- UDP ベースの QUIC (HTTP/3) を使うと、パケットロスや再送がエンドツーエンドのスループットに与える影響を抑えられ、接続確立の遅延も短くなります。 セッションを再開できる一部のケースでは、0-RTT やより高速なハンドシェイク経路の恩恵を受けられることがあります (ブラウザーやネットワークの状況によります)。
- ネットワーク条件が許せば、補助的な経路 (ダイレクトや P2P に近い支援など) を使うことがあります。利用できない場合は、自動的にエッジ経由の中継に切り替わり、可用性と安定性を保ちます。
2) 極限の並列処理: チャンクストリーミング (Chunked Streaming)
- 大きなファイルは論理的にチャンクへ分割され、同時実行数を制限しながら並列で転送されます。これにより、利用可能な帯域の上限に近づけます。
- クライアントは、ストリーミングのパイプラインと同時リクエストのスケジューリング (Service Worker や Fetch のパイプライン、必要なバックグラウンド連携を含みます) を使い、 1 本のリクエストが詰まることで生じる先頭の待ち (ヘッドオブライン待機) を減らし、RTT が大きくジッターのある環境でも平均スループットを高めます。
- 失敗したときは、失敗したチャンクだけを再送します。再開機能と組み合わせることで、「0% からやり直す」ことで失われる時間を大幅に減らせます (第 2 章を参照)。
3) トポロジーの強み: Anycast による最寄りエッジへの接続 (都市レベルのエッジ拠点 約 270 か所)
- グローバルなエッジネットワークにより、Anycast がリクエストを物理的に近い入口へ自動的にルーティングし、RTT、リージョンをまたぐホップ数、経路のジッターを減らします。
- 最寄りエッジへの接続は、並列チャンク分割にとってより安定した低遅延のベースラインとなり、回線を使い切りやすくなります。
4) インテリジェントなスケジューリング: マルチソースの並列処理と、最適経路の動的な選択
- 最寄りエッジへの接続を土台に、システムはリンク品質の指標 (スループット、遅延、エラー率など) をリアルタイムで評価し、 より品質の高い複数のノードやストレージの配置先を動的に選んで、チャンクを分散して配置します。
- ダウンロード時には、クライアントが複数のソースから異なるチャンクを同時に取得できます。マルチソース型のダウンロードアクセラレーターに近い仕組みで、輻輳やパケットロスがある状況でも帯域を使い切りやすくなります。 (並列ダウンロードと復旧については第 3 章を参照してください。)
注: これらのメカニズムを利用できるかどうかは、ブラウザーの機能、ネットワーク条件、企業のネットワークポリシーによって異なります。必要に応じてシステムが自動的に機能を縮退させ、可用性を保ちます。
証拠
サイトの基本的な状態 (TLS、セキュリティヘッダーなど) を検証できるよう、第三者による証拠を公開しています。 転送内容や保存内容の機密性に関する境界については、セキュリティとプライバシーのホワイトペーパーとプロトコル仕様を参照してください。
対象範囲に関する注記
- 重点: 「なぜ速いのか」を支える再利用可能なメカニズム (並列チャンク分割、再開できる転送、並列ダウンロードと再構成、マルチソースのスケジューリング)。
- 簡潔に扱う内容: ストレージの構成とライフサイクルのポリシー (第 4 章を参照)。