長距離 FTP が遅い理由：ファイル数・遅延・設定から調べる

長距離 FTP の速度を、ファイルごとの接続処理、TCP ウィンドウ、往復遅延、損失から解説。SFTP との違いと測定方法も紹介します。

WarpSend Team レビュー Charlie 2026年5月25日更新 2026年9月24日 4 分で読めます

同じ FTP サーバーでも、大きなファイルを 1 つ送ると速く、小さいファイルを含むフォルダーでは遅くなることがあります。遠隔拠点への転送を改善するには、回線容量だけでなく、ファイルごとの接続処理と往復遅延を確認する必要があります。

WarpSend のドイツから米国への比較では、調整済み FTP は単一の大容量ファイルで高い速度を出しました。一方、256 個の小ファイルでは接続準備の影響が大きくなりました。結果と測定条件は公開ベンチマークに掲載しています。

大きなファイルとフォルダーで条件が変わる

FTP は制御接続とデータ接続を分けます。制御接続を再利用しても、一般的なストリームモードではファイルごとにデータ接続を開き直すため、その準備と完了確認が繰り返されます。RFC 959 にこの構成が定義されています。

大きなファイルなら、接続準備の時間を長い連続転送に分散できます。小さいファイルでは、データを送る時間より準備にかかる時間の方が長くなる場合があります。LAN では短い待ち時間でも、大陸間では同じ往復処理の負担が増えます。

フォルダーをアーカイブにまとめると、この負担を減らせます。ただし、作成・展開時間と一時保存容量が必要です。ファイル単位で再開したり、一部だけ取得したりする必要がある場合は、その操作性も比較してください。

回線を十分に使うには、確認応答が戻るまでの間に必要量のデータを送れるようにします。目安は帯域遅延積です。

必要な送信中データ量 ≈ 目標転送速度（bytes/s）× 往復時間（秒）

1 Gbps、往復時間 143 ms の経路なら、約 17.9 MB が必要です。受信ウィンドウや輻輳ウィンドウが小さいと、回線容量に余裕があっても送信速度が制限されます。

現代の TCP はウィンドウスケーリングやバッファ調整に対応しています。RFC 7323 が説明するように、高帯域・高遅延の経路ではこれらの設定が重要です。TCP に一律の「回線利用率 20%」という上限はありません。ストレージ、輻輳制御、損失、サーバー設定も含めて測定してください。

往復時間が長いことと、パケットが失われることは別の条件です。損失からの回復や送信速度の調整が完了時間に影響する度合いは、輻輳制御方式と損失パターンによって変わります。

公開ベンチマークは、測定上ほぼ損失のないクラウド間経路で実施しています。家庭の Wi-Fi や不安定な WAN で同じ結果になるとは限りません。近距離と遠距離、単一ファイルとフォルダーを分けて測ると、原因を絞れます。

SFTP は SSH 上でファイルを操作する方式です。FTP に暗号化だけを加えたものではなく、要求の並列数、転送バッファ、SSH のチャネル制御、暗号化処理などが性能に関係します。

SFTP を使っている場合は、FTP の接続設定ではなく、長距離 SFTP の調整手順を参照してください。CPU が先に上限に達している場合と、要求数が少なく待ち時間が生じている場合では対処が異なります。

既存のサーバーとの互換性が必要で、測定した完了時間が要件を満たすなら、現在の方式を維持できます。通常の FTP は認証情報とデータの保護も別途検討し、必要に応じて SFTP や FTPS など、要件に合う方式を選んでください。

小ファイルが多い、中断が多い、外部の受信者にアカウントを配りたくないといった場合は、転送全体の流れを比較する価値があります。WarpSend は接続を再利用し、ファイル処理をまとめ、再開と検証に対応します。直接接続できない場合の Shuttle 経由の転送には、有料 UDP 速度プランが必要です。