FTP is dead. Here's what to use instead.

You pay for a gigabit line. You start an FTP transfer to the office across the country, and it crawls in at 7 MB/s. A continent away it’s worse. So you do what everyone does — you start blaming things.

It’s not your ISP, your disk, or your router

Read any thread about slow FTP and the same investigation plays out every time. People swap network cards. They reformat drives, suspecting NTFS overhead. They rip out the router that was doubling as a NAS. They run iperf3, confirm the link really does 900+ Mbps, and cross the pipe off the list. They raise the server’s connection limits and switch off antivirus and firewall inspection. A few of these even help a little.

Then they run the same transfer over the LAN and it flies — and across an ocean it dies again. That’s the tell. The bottleneck isn’t the hardware on either end; it’s the thousands of kilometres in between, and the 1970s-era transport behaviour FTP still leans on to cross them.

FTP is old. Not “showing its age” old — actually old. RFC 114 was published in 1971, predating TCP itself by six years. It was designed for ARPANET on machines that talked to each other across the room, not the planet.

That history matters because the protocol’s most painful behaviour — its sensitivity to latency — was a non-issue when it was designed. On a LAN, you don’t notice. Across continents, it’s the entire bottleneck.

The bandwidth-delay product, plainly

TCP throughput on a single connection is bounded by a formula every network engineer learns and most application developers never see:

throughput ≤ window_size / RTT

This is the bandwidth-delay product ceiling. The “window” is how much data TCP will keep in flight before pausing for an acknowledgment. The “RTT” is the round-trip time.

With a default 64 KB window and an 80 ms transatlantic RTT, your absolute ceiling is about 800 KB/s — roughly 6 Mbps. On a 10 Gbps link, you’re using 0.06% of the available capacity. The other 99.94% is the wire sitting idle, waiting on an ack that’s still in flight.

This is not an FTP-specific bug. It’s a TCP single-connection bug. Every TCP-based protocol — FTP, SFTP, HTTP/1.1, HTTP/2 over a single connection — inherits it.

SFTP doesn’t fix it

People reach for SFTP thinking they’ve upgraded. They have, on the security axis. They haven’t, on the speed axis.

SFTP is FTP’s modern replacement structurally — but it’s still packet-oriented over TCP. The client sends a read/write request, waits for a response, sends the next one. On a 1 Gbps LAN it’ll happily push 100+ MB/s. Over a transatlantic link with the same protocol, the same client typically caps out somewhere between 5 and 30 MB/s, often less.

Even with TCP perfectly tuned — window scaling, BBR, jumbo frames, SACK, the works — a single connection usually struggles to exceed 20% utilization on a long-haul link. That’s the realistic ceiling.

In practice it’s worse than that. FileZilla over SFTP on a 400 Mbit consumer pipe settles around 1.1 MB/s — about 2% of line rate. Put a 10 Gbit server on the source side and a 1 Gbit client on the destination, run SSH/SFTP between them, and the per-session throughput often doesn’t crack 1 MB/s. The disks are fine. The CPU is idle. The network has headroom. The protocol is the entire bottleneck.

The cleanest way to see it is to fix everything else and vary only the tool. On the same source, same destination, same network: SFTP via FileZilla pulls around 1.5 MB/s. rsync pulls around 13 MB/s. wget on a single file pulls 17 MB/s. aria2c, which splits that same single file across many parallel HTTP ranges, pulls 35 MB/s. The only thing that changed was parallelism, and throughput jumped roughly 20×.

That’s the entire architectural insight behind every UDP-based fast-transfer product on the market: stop sending one stream and waiting for it; send many, in parallel, and don’t wait.

rsync helps in one specific case

rsync deserves a separate mention because in one scenario it actually beats nearly everything: when a partial or earlier version of the file already exists at the destination. rsync compares block hashes, compresses with gzip, and only sends the delta. If you’re updating a 10 GB dataset and 9 GB hasn’t changed, rsync sends 1 GB. Done.

But for fresh transfers — a clean target, no prior state — rsync is bottlenecked by the same TCP that bottlenecks everything else. It’s a “smart sync over a slow pipe,” not a fast pipe.

What the fast protocols actually do

Every modern fast-transfer system converges on roughly the same architecture. The names are different — FASP (Aspera), AFTP (bTrade), GridFTP, UDT, FileCatalyst, and our own engine — but the moves are the same:

1. Run over UDP, not TCP. Skip the wait-for-ack-then-send dance. Push data; handle reliability separately.
2. Implement custom congestion control in userspace. Tuned for high-BDP links, not the conservative defaults TCP ships with.
3. Use multiple parallel streams. A single UDP flow can still hit fairness limits at routers; many parallel flows aggregate around them.
4. Pack small files into chunks before sending. The per-handshake penalty disappears.

The reported result for the well-tuned ones: 90-95% bandwidth utilization on links where SFTP sees 5-20%. That’s the order-of-magnitude gap between “still using FTP because of inertia” and “actually saturating your pipe.”

Where FTP still makes sense

Honestly? Rarely.

• On a LAN, on legacy hardware you can’t change — sure.
• For a one-off internal script where speed doesn’t matter — sure.
• For everything else, especially anything crossing a continent — you’re paying a latency tax measured in hours per workflow, every week, forever. Nobody should still be paying that in 2025.

WarpSend runs the architecture above. Free up to 1 TB / month. If you’ve been waiting for an FTP transfer to finish while reading this post, that should tell you something.