Why Is FTP Slow Over Long Distance? Causes and Fixes

An FTP transfer can move one large file quickly yet take much longer with a folder of the same total size. Across distant sites, repeated connection setup adds enough waiting that advertised bandwidth alone no longer predicts completion time.

In WarpSend’s Germany-to-US test, the tuned FTP baseline handled a single large stream well on a route with 143 ms round-trip time. The smaller-file workload exposed the cost of preparing each file separately. Understanding that difference helps you decide whether to tune the existing service, package the folder, or test another delivery method.

One big file is FTP’s best case

FTP keeps a control connection open and creates a data connection for each file. With one large file, the setup cost is amortized over a lot of data.

A tuned TCP stack can also keep a large amount of data in flight. In our test, both hosts used BBR and 128 MB TCP buffers on a near-zero-loss route. That is why the single stream performed well despite the 143 ms RTT.

If your workload is a few large files between controlled servers, FTP may be entirely adequate from a throughput perspective. Security, firewall design, operational visibility, and resume behavior are separate questions.

Many small files expose the round trips

Every additional file creates more control and data-path setup. On a local network, the delay is hard to notice. Across continents, each exchange pays the full RTT.

In our 256-file test, FTP averaged roughly 1.6 seconds per 1 MiB file. At its own single-file rate, the same payload would take only a few milliseconds. Almost all the wait came from the surrounding protocol work.

This is why zipping a folder before FTP often helps. You turn hundreds of separate transfers into one data stream. The trade-off is extra packaging, temporary storage, and loss of file-level resume or inspection.

The bandwidth-delay product still matters

The bandwidth-delay product (BDP) is the amount of data that must be in flight to fill a path:

bandwidth × round-trip time

A 1 Gbps link with 143 ms RTT needs roughly 17.9 MB in flight. If the sender or receiver window is smaller, the transfer cannot fill the link no matter how fast the disks are.

Modern TCP window scaling and a tuned congestion controller can solve much of this on a clean route. Defaults, middleboxes, packet loss, and conservative server settings can still hold performance down.

Compare the operating-system settings and file pattern before drawing a conclusion from another team’s FTP result.

Packet loss changes the calculation

Our July 2026 comparison had near-zero measured loss. Lossy and unstable routes need separate tests.

On a lossy or jittery route, TCP congestion control may reduce the sending rate. The exact impact depends on the controller, buffers, RTT, loss pattern, and number of streams. Any vendor promising distance-independent speed should publish its test conditions.

Why SFTP is not the same protocol

SFTP is the SSH File Transfer Protocol, not “secure FTP.” It runs over SSH and has different request pipelining, encryption, and implementation behavior.

SFTP fixes the plaintext credentials and data problem of classic FTP, but encryption and request/response patterns can introduce their own CPU and latency limits. Benchmark the specific client and server pair you plan to use, and follow the measured tuning sequence in how to speed up SFTP over long distance.

How accelerated file transfer avoids the folder penalty

Products such as IBM Aspera and WarpSend use different architectures, but accelerated transfer systems generally try to:

• keep more useful data in flight;
• avoid a new long-distance setup for every file;
• pipeline disk, encryption, hashing, and network work;
• resume from verified progress;
• separate the fast path from fallback delivery.

IBM says FASP is designed to maintain throughput across distance, latency, and packet loss. IBM Aspera overview

WarpSend uses a persistent endpoint-to-endpoint tunnel over libp2p/QUIC when possible, with a managed WarpFabric Shuttle route when direct connectivity is not the practical path — Shuttle fallback on transfers requires a paid speed tier. Transfers use application-layer encryption, resumable chunks, and whole-file verification.

The TCP vs UDP file transfer guide explains why this is an application-architecture comparison rather than evidence that raw UDP is automatically faster than TCP.

Should you replace FTP?

Keep FTP or SFTP when:

• compatibility with an existing server is the primary requirement;
• the route is controlled and well tuned;
• the workload is a small number of large files;
• the operational and security model is acceptable.

Evaluate an accelerated transfer tool when:

• folders contain hundreds or thousands of files;
• routes have high RTT, jitter, or interruptions;
• failed transfers must resume instead of restart;
• external recipients should not manage FTP accounts;
• teams need direct transfer, share links, or folder sync in one workflow.

See the full DE-to-US benchmark, the guide to why thousands of small files transfer slowly, or the high-speed long-distance file transfer guide for a test matrix you can reproduce. Use the file transfer time calculator to estimate the network-time lower bound before testing.