高速ファイル転送の小史 (1971 — 2025)

ほとんどの「高速ファイル転送」のセールストークは、まるでその技術が昨日生まれたかのように扱います。違います。根本的な洞察 — つまり TCP は long-fat ネットワークには不適切なツールであり、独自の信頼性を備えた UDP が適切なツールであるという認識 — は、過去四半世紀のあいだ、およそ 5 年ごとに独立して再発見されてきました。ここまでに至る経緯の短いバージョンを紹介します。

1971 — FTP (RFC 114)

Abhay Bhushan が 1971 年 4 月 16 日 に RFC 114 を発表します。ARPANET にはホストが 23 台。TCP はまだ存在しません — その仕様化は 6 年後のことです。FTP は、マシンが同じ部屋、少なくとも同じ建物の中にあり、レイテンシが予測可能であるという前提のもとに作られました。

このプロトコルは、当時存在した世界では問題なく動作します。しかし、後に古びてしまう 2 つのアーキテクチャ上の決定も組み込まれていました — ファイルごとに新しい control + data コネクションを張ること、そして内部的に同期的なリクエスト・レスポンスモデルを採用していることです。

1995–2001 — TCP が長距離問題に直面する

1990 年代半ばまでに、公共のインターネットはグローバルなものとなり、帯域幅とレイテンシの非対称性があらゆる場所で顕在化し始めます。RFC 1323 (1992) は、受信ウィンドウを 64 KB 超に拡張するための TCP window scaling を導入します。SACK は RFC 2018 (1996) で出荷されます。HTTP/1.1 は 1999 年に persistent connection を導入します。

これらはどれも実質的な勝利です。同時にどれも、TCP の stop-and-wait の性質を 置き換える のではなく、その周りで 回避する ものです。スループットの公式 window_size / RTT は依然として成立します — 分子を大きくすることはできても、待ち時間そのものをなくすことはできません。

2001–2003 — UDP への転回

決定的な転換は、3 つの異なるグループが独立して作業しながら、いずれも同じアーキテクチャ的回答に到達した 3 年間に起こります。

2001: UDT. Yunhong Gu が UDP ベースの Data Transfer プロジェクトを開始します。2003 年 10 月、NCDM はそれを使ってシカゴからアムステルダムへ 6.8 Gbps を流します — 以前は専用ハードウェアが必要だと考えられていた数字です。UDT はその後の高エネルギー物理学のファイル転送の多くの基礎となります。

~2003: FASP. Michelle Munson と Serban Simu が Fast and Secure Protocol を発明し、Aspera として製品化、放送とポストプロダクションのワークフローでこのモデルを実証します。IBM は 2014 年に Aspera を買収。FASP はその後 10 年間、エンタープライズメディア転送のゴールドスタンダードとなります。

同時期: GridFTP. Globus は FTP 自体を並列 TCP ストリームと部分ファイル再開で拡張します。依然として TCP ベースですが、全員が UDP へ移行する前に「並列性が勝利の大半である」ことを証明する橋渡しプロトコルとなります。

3 つの名前、1 つのアーキテクチャ。ack-then-send のダンスをスキップし、ユーザー空間で独自の輻輳制御を動かし、飽和の代償として一定のパケットロスを受け入れる。

~2013 — Facebook が WDT をオープンソース化

QUIC が出荷され始めるのとほぼ同時期、Facebook は静かに Warp Speed Data Transfer (WDT) を GitHub に公開します。製品ではなく — 社内のホスト間でデータセットを移動するためにインフラチームが使う C++ ライブラリで、テスト用に小さな CLI が付いています。ドキュメントの目玉数字: 単一の WDT セッションが 40 Gbit/s の NIC を飽和させる。

WDT の勝利は依然として並列性に関するものです — UDP 上の単一ストリームではなく、TCP 上の多数のストリーム — しかし結論は、UDT と FASP が 10 年前に到達したものと同じです。単一の逐次接続は long-fat リンクには間違った抽象であり、解決策はそれを分割することです。2013 年までに、その教訓はファイル転送のスタートアップ、IETF、ハイパースケーラーの内部で独立して再発見されていました。ここで Facebook に負っているネーミングの負債が目立つことは、我々も認めるところです。

2013 — QUIC

Google は 2013 年に QUIC を Chrome に出荷し始めます。元々の目標は Web レイテンシ — TLS 1.3 + transport を 1 ラウンドトリップで — ですが、その設計は最終的に、汎用インターネットトラフィックに対する UDP-with-userspace-reliability モデルを正当化することになります。

IETF は 2016 年にこれを取り上げ、QUIC は RFC 9000 として 2021 年に出荷されます。HTTP/3 が広く展開される頃には、「重要なトラフィックは TCP 上で動かすべきではない」という考えは、辺境のアカデミックな立場から、Google、Cloudflare、Meta、ほとんどの CDN にとってのデフォルトへと変わっていました。

ファイル転送に限定すると、QUIC は FASP スタイルの製品を置き換えるものではありません — そのコネクションモデルとフロー制御は、複数 GB の持続的ストリームではなく HTTP 形状のワークロードに合わせて調整されています。しかし、「UDP はゲームと VOIP のためのものだ」という文化的議論を完全に粉砕します。HTTP/3 がその上で動くようになれば、もはや誰も UDP transport を実験的だとは呼べません。

2018–2024 — 帯域制御の雪解け

この期間に、カテゴリの現代的な形に関わる別の 2 つの出来事が起こります:

• BBR (Google, 2016) は、TCP が輻輳制御についてより賢くなれることを示します。long-haul リンクで UDP ベースのシステムに追いつくわけではありませんが、底上げをします — 2024 年のよくチューニングされたモダンカーネルでの TCP スループットは、2014 年のものより実質的に良くなっています。
• Cloudflare の R2 / エッジネットワーク は、ファイル配信のコストモデルを変えます。転送負荷の高いワークロードで S3 を高くしていた帯域 egress 料金は、もはや唯一の選択肢ではありません。今では Cloudflare をリレーパスに使った転送サービスを設計し、egress でほぼゼロを支払う、ということが可能です。

2025 年代のサービスが彼らの価格帯で成立しうるのは、後者のおかげです。

2025 — WarpSend

我々はアーキテクチャを発明したわけではありません。UDP transport、独自の輻輳制御、パケットパッキング、並列ストリーム — そのすべては 2003 年までに固まっていました。

我々がしたのは、そのアーキテクチャを、初期の勝者がサービス対象としなかったバイヤー向けにパッケージし直すこと — 4 人のスタジオ、地方のエージェンシー、NAS ファーストのビジネス。同じプロトコルファミリー。Cloudflare R2 をリレーバックボーンとして。$75,000/year ではなく $5/TB。

この分野におけるエンジニアリングの勝利の大半は、我々の顧客の半数が生まれる前に達成されていました。欠けていたのはパッケージングです。

無料で試す — 1 TB / month、クレジットカード不要。