FTP の時代は終わった。代替手段はこれだ。

あなたは gigabit 回線にお金を払っています。国の反対側のオフィスへ FTP 転送を始めると、7 MB/s でじりじりとしか進みません。大陸を跨ぐともっとひどい。そこであなたは誰もがやることをします——犯人探しを始めるのです。

それは ISP でも、ディスクでも、ルーターでもない

遅い FTP のスレッドをどれでも読めば、毎回同じ調査が繰り広げられます。ネットワークカードを交換する。NTFS のオーバーヘッドを疑ってドライブをフォーマットし直す。NAS 代わりにしていたルーターを引っこ抜く。iperf3 を走らせてリンクが本当に 900+ Mbps 出ることを確認し、パイプを容疑者リストから外す。サーバーのコネクション上限を上げ、アンチウイルスとファイアウォールの検査をオフにする。いくつかは実際に少しは効きます。

そして同じ転送を LAN 上で走らせると飛ぶように速い——なのに海を跨ぐとまた死ぬ。それが手がかりです。ボトルネックは両端のハードウェアではありません。それは間にある数千キロと、それを越えるために FTP がいまだに頼っている 1970 年代生まれのトランスポートの挙動です。

FTP は古いです。「老いを見せている」レベルの古さではなく — 本当に古い。RFC 114 は 1971 年に公開され、TCP 自体より 6 年も先行しています。設計されたのは ARPANET 用、それも地球規模ではなく部屋を越えて互いに話すマシンのためでした。

その歴史が重要なのは、このプロトコルの最も痛い挙動 — レイテンシへの敏感さ — が、設計時には非問題だったからです。LAN では気づきません。大陸を跨ぐと、ボトルネックの全部になります。

帯域遅延積、率直に

単一コネクション上の TCP スループットは、すべてのネットワークエンジニアが学ぶが大半のアプリケーション開発者は決して見ない公式で上限が決まります:

throughput ≤ window_size / RTT

これが 帯域遅延積 の上限です。「window」は TCP が ack を待たずに in-flight に保つデータ量です。「RTT」はラウンドトリップタイムです。

デフォルトの 64 KB ウィンドウと 80 ms の大西洋横断 RTT では、絶対的な上限は約 800 KB/s — およそ 6 Mbps です。10 Gbps のリンク上で、利用可能容量の 0.06% しか使っていません。残りの 99.94% は、まだ in-flight の ack を待ちながらワイヤーが遊んでいる状態です。

これは FTP 固有のバグではありません。TCP の単一コネクションのバグです。すべての TCP ベースのプロトコル — FTP、SFTP、HTTP/1.1、単一コネクション上の HTTP/2 — がこれを継承します。

SFTP では解決しない

人は SFTP に手を伸ばして、アップグレードしたと思います。セキュリティの軸ではアップグレードです。速度の軸ではアップグレードではありません。

SFTP は構造的には FTP のモダンな置き換えですが — 依然として TCP 上のパケット指向です。クライアントが read/write リクエストを送り、レスポンスを待ち、次を送る。1 Gbps の LAN なら喜んで 100+ MB/s を出します。大西洋横断リンクで同じプロトコルだと、同じクライアントは通常 5 から 30 MB/s のどこか、しばしばそれ以下で頭打ちになります。

TCP を完璧にチューニングしても — window scaling、BBR、ジャンボフレーム、SACK、全部のせ — 単一コネクションは long-haul リンク上で通常 20% の利用率 を超えるのが難しいです。それが現実的な上限です。

実際にはそれより悪いです。400 Mbit のコンシューマー回線上で FileZilla を SFTP で動かすと約 1.1 MB/s に収まります — ライン速度の約 2%。10 Gbit のサーバーをソース側に、1 Gbit のクライアントを宛先に置き、その間で SSH/SFTP を走らせると、セッションあたりのスループットがしばしば 1 MB/s を超えません。ディスクは問題なし。CPU は遊んでいる。ネットワークには余裕がある。プロトコルが全部のボトルネックです。

最も明確に見る方法は、他のすべてを固定してツールだけを変えることです。同じソース、同じ宛先、同じネットワーク上で: FileZilla 経由の SFTP は約 1.5 MB/s。rsync は約 13 MB/s。wget で単一ファイルは 17 MB/s。aria2c は同じ単一ファイルを多数の並列 HTTP レンジに分割して、35 MB/s。変わったのは並列性だけで、スループットはおよそ 20× 跳ね上がりました。

これが、市場にあるすべての UDP ベースの高速転送製品の背後にあるアーキテクチャ的洞察の全部です: 1 つのストリームを送ってそれを待つのをやめ、たくさんを並列で送り、待たない。

rsync は 1 つの特定のケースで役立つ

rsync には別個に言及する価値があります。なぜなら 1 つの シナリオでは、ほとんど何より勝つからです: ファイルの部分的、あるいは以前のバージョンが宛先にすでに存在する場合です。rsync はブロックハッシュを比較し、gzip で圧縮し、差分のみを送ります。10 GB のデータセットを更新中で 9 GB が変わっていないなら、rsync は 1 GB を送ります。完了。

しかし 新規の 転送 — クリーンなターゲット、事前状態なし — に対しては、rsync は他のすべてをボトルネックにする TCP と同じものでボトルネックを受けます。「遅いパイプの上のスマート同期」であって、速いパイプではありません。

速いプロトコルが実際にしていること

すべてのモダンな高速転送システムは、おおむね同じアーキテクチャに収束します。名前は異なります — FASP (Aspera)、AFTP (bTrade)、GridFTP、UDT、FileCatalyst、そして我々自身のエンジン — しかし動きは同じです:

1. TCP ではなく UDP 上で動かす. wait-for-ack-then-send のダンスをスキップ。データをプッシュし、信頼性は別途扱う。
2. ユーザー空間で独自の輻輳制御を実装する. TCP が出荷する保守的なデフォルトではなく、高 BDP リンク向けにチューニング。
3. 複数の並列ストリームを使う. 単一の UDP フローはルーターでフェアネス上限にあたることがあるが、多数の並列フローがそれらを集約して回避する。
4. 送信前に小さなファイルをチャンクにパックする. ハンドシェイクごとのペナルティが消える。

よく調整されたものの報告される結果: SFTP が 5-20% を見るリンク上で、90-95% の帯域利用率. それが「惰性で FTP を使い続けている」と「実際にパイプを飽和させている」の桁違いのギャップです。

FTP がまだ意味を持つ場所

正直に? 稀です。

• LAN 上、変えられないレガシーハードウェア上で — まあ、はい。
• 速度がどうでもいい一回限りの内部スクリプト用 — まあ、はい。
• それ以外のすべて、特に大陸を跨ぐもの — あなたはワークフローあたり時間単位で計測されるレイテンシ税を、毎週、永遠に払っています。2025 年にそれを払い続けるべき人は誰もいません。

WarpSend は上のアーキテクチャを動かします。1 TB / month まで無料。この投稿を読んでいる間ずっと FTP の転送が終わるのを待っていたなら、それは何かを示しているはずです。