Speed, Resume, and Reliability Compared: What Testing Actually Shows

Ask which of FTP, FTPS, and SFTP is fastest and you will collect three confident, contradictory answers, usually including "encryption makes SFTP slow" from someone who last measured it on hardware two generations old. Protocol performance is one of the most folklore-heavy corners of file transfer — and the folklore leads to real mistakes, like choosing a weaker protocol for a speed advantage that vanishes under measurement, or blaming the protocol for slowness that actually lives in a disk, a distant network path, or a badly chosen client.

This article replaces the folklore with a model you can reason from and a benchmark you can run. You will learn which factors genuinely separate the three protocols — bulk throughput, per-file overhead, latency sensitivity, and resume behavior — where they are effectively tied, and how to measure your own environment in an afternoon so the next "why is this slow?" conversation starts from numbers. It is part of our SFTP vs FTPS vs FTP series, and no performance background is assumed.

Think in Pipelines, Not Protocols

Every transfer, regardless of protocol, is a pipeline of stages: read from disk, process through the protocol engine, encrypt (for the secure protocols), push through TCP, cross the network, and reverse the whole sequence on the far side. The transfer runs exactly as fast as the slowest stage — the bottleneck — and no faster. This single idea explains most confusing benchmark results: swapping protocols only changes performance when the protocol stage was the bottleneck, and on modern hardware it usually is not. A server reading from a busy disk array, or a link with high latency, sets the speed no matter which acronym moves the bytes.

The diagram below shows the pipeline. Everything in this article is about when the two highlighted stages — protocol behavior and encryption — become the narrow point, and when they are irrelevant.

What Each Protocol Actually Adds

To predict where each protocol can become the bottleneck, look at what each adds on top of a raw TCP stream:

• Plain FTP adds almost nothing to the data itself — a file rides a dedicated data connection as an unmodified byte stream. Its overhead is per transfer: commands on the control connection plus a brand-new TCP connection for every file and listing.
• FTPS is that same design plus TLS: a cryptographic handshake when each connection starts and encryption of the flowing bytes. The steady-state stream stays simple; the per-file connection cost grows, because each new data connection may need its own handshake (good clients and servers soften this by reusing TLS session state).
• SFTP runs inside one SSH connection and works differently: the client sends requests — open this file, write this block at this offset, close — and data travels as discrete packets subject to the protocol's own flow-control windows, on top of TCP's. There is no per-file connection cost at all, but there is per-request bookkeeping, and how aggressively a client keeps many requests in flight is an implementation choice that separates fast SFTP clients from slow ones more than the protocol itself does.

One more difference hides in FTP's age: its ASCII transfer mode, which rewrites line endings in flight and can silently corrupt binary files while also slowing transfers. SFTP has no such mode — it is byte-exact always. It is a small point that has destroyed more files than any performance issue ever did; make sure FTP jobs force binary mode.

Large Files: Closer to a Tie Than Anyone Admits

For a single big file on a healthy local network, all three protocols can typically drive the link to saturation, and the podium order is decided by rounding errors. The per-transfer overheads amortize to nothing over gigabytes, and the encryption stage — the traditional justification for "FTP is faster" — stopped being expensive when processors gained hardware-accelerated AES, which mainstream CPUs have had for many hardware generations. Encrypting at line speed costs a few percent of one core.

The honest caveats, because they are the cases you will actually meet: on very old or very small hardware (embedded devices, ancient servers, tiny virtual machines without crypto acceleration), encryption genuinely can become the bottleneck, and plain FTP or a lighter cipher choice shows a real margin. And at multi-gigabit speeds, single-core crypto throughput can cap a transfer before the network does — an argument for modern ciphers and clients, not for abandoning encryption. If your large-file transfers are slow on a fast LAN, suspect disks and measure them before blaming any protocol.

Many Small Files: Where the Protocols Actually Separate

Transfer one thousand small files instead of one large one and the per-file overhead stops amortizing — it multiplies. This is the workload where protocol behavior dominates, and where latency joins the equation, because most per-file costs are round trips: request-and-reply exchanges that each take one full network round trip regardless of bandwidth.

Run the arithmetic once and the effect stops being surprising. Suppose the network round-trip time is 30 milliseconds. For FTP and FTPS, each file costs several round trips before its first payload byte: the command exchange, the passive-mode negotiation, the new TCP connection's handshake — call it three to five round trips, so roughly 100–150 ms of pure overhead per file, plus a TLS handshake for FTPS unless session reuse is working. A thousand files means two or three minutes of overhead even if the files themselves are tiny. SFTP skips the per-file connections entirely, but each file still needs its open-write-close request sequence; a naive client that processes them strictly one at a time pays a similar round-trip tax, while a good client pipelines requests and collapses much of the wait. In every case the bandwidth barely matters — the workload is latency-bound.

The practical fixes follow directly from the cause, and they outperform any protocol switch:

• Archive first. Compress the thousand files into one archive, transfer it, extract on arrival. This converts the worst workload into the best one and routinely wins by an order of magnitude.
• Parallelize. Several concurrent transfer streams overlap their round-trip waits. Most automation tools and modern clients support this directly.
• Prefer pipelining clients. For SFTP specifically, client implementation quality is the difference between painful and fine on this workload — worth a head-to-head test with your real file set.
• Sync instead of re-sending. If the real task is keeping two trees current, a delta-synchronization approach transfers only changes — see our rsync and delta transfer pillar.

Distance: The Great Equalizer

On long network paths — cross-country, intercontinental, or over VPNs that add their own distance — a different ceiling appears that has nothing to do with any of our three protocols. TCP can only keep a limited amount of data "in flight" awaiting acknowledgment (the window), and when the path's latency is high, that limit caps single-stream throughput no matter how much bandwidth exists. All three protocols hit this ceiling identically, because all three ride TCP.

SFTP deserves one honest asterisk here: on top of TCP's window it has its own protocol-level flow control, and older or conservatively configured clients kept that window small — which is the true origin of the durable "SFTP is slow over distance" reputation. Modern implementations mostly fixed this, but the asterisk is testable: if SFTP lags FTPS badly on a high-latency path in your benchmark while matching it on the LAN, try a different SFTP client before redesigning anything. When distance itself is the dominant problem — huge files, long paths, transfer windows you cannot meet — the answer eventually stops being any TCP protocol at all; our UDP-accelerated transfer pillar covers that territory.

One lever worth knowing on genuinely slow links: protocol-level compression. SSH offers optional compression that SFTP transfers can use, and some FTP and FTPS implementations support the MODE Z extension, which compresses the data stream. On a constrained link carrying compressible data — CSV exports, logs, text — compression can multiply effective throughput for the cost of some CPU. On fast links, or for data that is already compressed (archives, images, video), it burns CPU to gain nothing and can even slow the transfer. Like everything else in this article, it is a bottleneck question: compress when the network is the narrow stage and the data is squeezable, and never by reflex.

Resume and Restart: The Comparison That Matters for Big Transfers

For long transfers over imperfect networks, the ability to resume — continue an interrupted transfer from where it stopped instead of starting over — is worth more than raw speed. The three protocols differ here in mechanism and in reliability of support:

The last row describes a classic failure worth recognizing on sight: during a very long FTP or FTPS transfer, the data connection is busy but the control connection sits idle, and an aggressive firewall quietly discards the idle connection from its state table. The file arrives completely, yet the client reports failure because the "transfer complete" reply had no connection left to travel on — and a scheduled job then re-sends a file that already arrived. Keep-alive settings and sane firewall timeouts fix it; the diagnostic pattern is close cousin to the ones in diagnosing FTP mode failures.

On reliability generally: none of the three protocols verifies end-to-end file integrity beyond TCP's weak checksums, so unattended workflows should verify transfers themselves — compare file sizes at minimum, hashes where it matters — and signal completion with an upload-then-rename convention. This is standard practice in automation tooling; a scheduler like Sysax FTP Automation builds the retry logic and error handling around the transfer so an interrupted job resumes or re-runs without a human noticing, whichever of the three protocols the job speaks.

The Reproducible Benchmark: Measure Your Own Truth

General claims end here. Your hardware, your network, and your file sizes are the only benchmark that matters, and the method below produces defensible numbers in an afternoon. The fairness rules are the important part — most published protocol comparisons break at least two of them:

1. One server, one client, all protocols. Serve FTP, FTPS, and SFTP from the same machine and disk so only the protocol varies — a multi-protocol server such as Sysax Multi Server makes this trivial, since all three listeners share one host and one folder tree.
2. Two file sets: one large file (a gigabyte-class single file) and one small-file set (a thousand files of about 10 KB). They stress opposite stages of the pipeline.
3. Both directions, five runs each, take the median. First runs include cache warm-up noise; medians ignore outliers.
4. Record context with every result: round-trip time to the server, client CPU load during the run, and the client software name and version — the three facts that explain most differences later.

# 0. Create the test sets (run once)
#    big.bin  = 1 GB single file;  small/ = 1000 x 10 KB files

# 1. Record the path's round-trip time (context for every result)
ping -c 10 transfer.example.com        # note the average RTT

# 2. Large file, one protocol at a time — repeat each line 5x, keep medians
time curl -o /dev/null ftp://user:pw@transfer.example.com/big.bin
time curl -o /dev/null --ssl-reqd ftp://user:pw@transfer.example.com/big.bin
time sftp user@transfer.example.com:/big.bin /dev/null

# 3. Small-file set — same three protocols, recursive fetch
#    (use your real client here too; client choice IS part of the result)
time curl -s "ftp://user:pw@transfer.example.com/small/[1-1000].dat" -o /dev/null
time sftp -r user@transfer.example.com:/small /tmp/small-test

# 4. Uploads: repeat 2 and 3 with -T (curl) / put (sftp)
# 5. Compute MB/s = file bytes / median seconds; log RTT, CPU, versions

Guard against the three pitfalls that corrupt more benchmarks than anything else. First, caching: the second download of the same file may be served from the server's memory rather than its disk, which is why runs are repeated and medians reported — and why a result that improves suspiciously between run one and run two is telling you about the disk, not the protocol. Second, colocation: a client and server on the same host or virtual machine share CPU and skip the real network, producing numbers that predict nothing. Third, mismatched clients: comparing one protocol's best client against another's worst measures the clients. That last one is only a pitfall if it is accidental — testing your actual production client per protocol is precisely the point.

Then read the results against the model from this article. Large-file numbers within a few percent of each other: the protocols are tied in your environment and the decision belongs to operations and security — which is the argument of SFTP vs FTPS and the firewall's view. A large gap on large files points at encryption CPU or a client implementation, not the protocol concept — try another client before concluding anything. Small-file results dramatically slower than large-file results (they will be): that is round-trip arithmetic, fixed by archiving or parallelism, not by protocol switching. And if everything is slow everywhere, benchmark the disk and the path — the pipeline's quiet stages — before touching a protocol setting.

What Testing Actually Shows, in Five Lines

Bulk speed on modern hardware: effectively a tie, with plain FTP's edge real only where crypto acceleration is absent. Small files: everyone suffers, latency is the villain, archiving and parallelism are the heroes, and client quality matters more than protocol. Distance: TCP's window caps all three equally, with older SFTP clients earning their bad reputation and newer ones mostly shedding it. Resume: SFTP's is native and symmetric; FTP and FTPS depend on server support for REST. Reliability: none of them verifies your file — your tooling must, with hashes, renames, and retries.

Put differently: choose your protocol for security posture, firewall fit, and operational burden — the subjects of the rest of this pillar — and solve performance where it actually lives. If this article leaves you planning a move off plain FTP, the migration playbook is the next read.

Frequently Asked Questions