WarpSend が FTP より 618 倍速い理由

618 倍。それが、我々のベンチマークで WarpSend が 1,024 個の小さなファイルを FTP より転送できた速度差です — US East から Frankfurt、実機、実ネットワーク条件下で。

この数字が誇張に聞こえるなら、当然です — ほとんどの「N 倍速い」マーケティングは「何と比べて、どのシナリオで N 倍速いのか」と問うた瞬間に崩れます。なので、計算を全部見せます。

テスト

マシン 2 台。1 台は us-east-1、もう 1 台は eu-central-1 に。両方とも回線はクリーン — トラフィックシェイピングなし、人工的なキャップなし。シナリオは 2 つ:

1. 単一の 1 GB ファイル (簡単なケース)
2. 1,024 × 1 MB ファイル (難しいケース — 合計バイト数は同じだが、プロトコル挙動が大きく異なる)

同じソース、同じデスティネーション、同じネットワーク。変わるのは転送エンジンだけです。

なぜ TCP はこの距離には不適切なのか

これは long-fat ネットワークの問題で、教科書通りです。

us-east-1 と eu-central-1 の間のラウンドトリップタイムはおよそ 85 ms。単一コネクション上での TCP スループットは以下によって上限が決まります:

throughput ≤ window_size / RTT

これが 帯域遅延積 の上限です。デフォルトの 64 KB 受信ウィンドウと 85 ms RTT では、約 750 KB/s に制限されます — リンクが実際にどれだけの容量を持っていようと関係なく。10 Gbps のパイプ上では、これは 0.06% の利用率です。残りの 99.94% はただ放置されています。

カーネル側でこれと戦うことはできます。より大きな受信バッファ、window scaling、CUBIC ではなく BBR、SACK、TCP オフロード。すべて本物で、すべて役立ち、すべて複雑で、すべてホストごとに必要です。そして BBR — 誰もが手を伸ばす輻輳制御アルゴリズム — は RTT が大きくなるにつれて劣化します。大陸を跨ぐ場面では銀の弾丸ではありません。

すべてをチューニングしたとしても、単一 TCP ストリームは long-haul リンク上では通常 20% の利用率を超えるのが難しい ところで、ルーティングのフェアネスと戦い始めることになります。それが FTP、SFTP、rsync すべてが座っている天井です。

小さなファイルの問題が事態を悪化させる

618 倍という結果は TCP のレイテンシだけによるものではありません。1 つの大きなファイルではなく 1,000 個のファイルを与えたときに FTP が何をするか、ということです。

FTP は転送ごとに新しいデータコネクションを開きます。新しいコネクションごとに TCP ハンドシェイクが必要です — ペイロードの 1 バイトも動かないうちに 3 ラウンドトリップ。85 ms RTT では、これは ファイルあたり ~255 ms のデッドタイム です。

1,024 files × 255 ms = 261 seconds of handshake alone

ソースからデータが出る前に 4 分以上の純粋なオーバーヘッド。SFTP もここでは大して良くありません — TCP 上のパケット指向で、チャンクごとに似たような read-ack ループがあります。ボトルネックは帯域幅ではなく、会話です。

WarpSend は代わりに何をするか

複合する 3 つの変更:

1. 独自の信頼性を備えた UDP transport. パケット間で ack を待ちません。我々のエンジンは、損失検出、再送、順序付けを我々自身の条件で扱います。これは FASP (Aspera)、AFTP (bTrade)、GridFTP、UDT すべてが行っているのと同じアーキテクチャ的な動きです — 同じ理由でどれも TCP ベースではありません。トレードオフは我々側のコードが増えること。勝利は輻輳制御を我々がチューニングできるようになることです。

2. パケットパッキング. 転送前に、小さなファイルをスキャンして大きなチャンクにまとめます。1,000 個の 1 MB ファイルは 1,000 回のハンドシェイクを得るのではなく — 1 つのストリームを得て、内部でフレーミングされます。ファイルあたりのオーバーヘッドはほぼゼロに落ちます。

3. マルチスレッドパイプライン. スキャン、パッキング、暗号化、送信がすべて並列に走ります。送信スレッドはディスクを待ってブロックされず、ディスクはネットワークを待ってブロックされません。

結果: 1,024 ファイルのテストで、WarpSend は ~21 秒で完了するのに対し、FTP は 3.5 時間以上かかります。単一の 1 GB ファイルでは差は狭くなります — 15 秒対 ~85 秒 — TCP がハンドシェイクをより多くのデータに償却できるからです。

これが重要になる場所

618 倍という数字は、大きな 数 のファイルを定期的に動かす場合に最も関連します:

• 撮影日の生カメラフッテージ (編集者が統合する前は数百の小さなクリップであることが多い)
• オフィス間のプロジェクトアセット (数千の小さなファイルを含む npm スタイルのツリー)
• NAS-to-NAS のバックアップとレプリケーション
• ML 訓練データセット (数百万の小さなテンソルであることが多い)

「合計 1 GB なのに、なぜこれが 3 時間もかかっているのか」という形のもの — それがあなたのワークフローに現れている FTP の小さなファイルペナルティです。

読むより見る方が良ければ、無料で試して ください — 月間 1 TB のトラフィック、クレジットカード不要。