Comparing HTTP and FTP for transferring files

Question

What are the advantages (or limitations) of one over the other for transferring files over the Internet?

(I am aware of secure forms of both protocols. I'd like to hear comparisons through personal experiences in terms of performance, reliability, file size limitations etc.)

Valero

Answer 1

Here's a performance comparison of the two. HTTP is more responsive for request-response of small files, but FTP may be better for large files if tuned properly. FTP used to be generally considered faster. FTP requires a control channel and state be maintained besides the TCP state but HTTP does not. There are 6 packet transfers before data starts transferring in FTP but only 4 in HTTP.

I think a properly tuned TCP layer would have more effect on speed than the difference between application layer protocols. The Sun Blueprint Understanding Tuning TCP has details.

Heres another good comparison of individual characteristics of each protocol.

Wail

+1 good answer. I think FTP's day has been and gone, it has little relevance any more. It's also an absolute pig to implement. – Enlil

What size is meant by "small" or "large" files? – Tatianatatianas

The performance comparison link points to an analysis of expected gains from implementing P-HTTP, T/TCP, and S-TCB. No where does it mention FTP. Also, the properly tuned link is broken. – Leonoreleonsis

@Leonoreleonsis did you read the performance comparison link? There are 12 references to FTP and the very first section says "The HTTP protocol was originally developed to reduce the inefficiencies of the FTP..." and then goes on to explain. I also updated the "Understanding Tuning TCP" link... it looks like Oracle threw away all the old Sun Blueprints whitepapers. – Wail

what about error correction? does ftp additional error correction on top op tcp/ip? – Ahlgren

August 16, 1996... really? Even in your 2009 answer you couldn't expect this to be representative of the current state of affairs. -1 – Oza

For anyone intrested in reading "Understanding Tuning TCP", here is the link to an archive. – Luckless

Answer 2

I just benchmarked a file transfer over both FTP and HTTP :

• over two very good server connections
• using the same 1GB .zip file
• under the same network conditions (tested one after the other)

The result:

• using FTP: 6 minutes
• using HTTP: 4 minutes
• using a concurrent http downloader software (fdm): 1 minute

So, basically under a "real life" situation:

1) HTTP is faster than FTP when downloading one big file.

2) HTTP can use parallel chunk download which makes it 6x times faster than FTP depending on the network conditions.

Makell

This seems very anecdotal. – Chrysoberyl

@anecdotal he provided numbers (facts from research) which is less anecdotal then any other answer so far. – Seumas

Are the times reproducible, at least approximately? – Thegn

few days ago i tried to download 90MB files with http, failed network at 2MB. But with ftp (same server, same file, same network through mobile hotspot), the download success. I don't know why. – Forrest

ftp is faster for single files due to lower overhead. If your testing got a different answer, try another client (or less likely, another server). http can't download faster than the max bit rate and any parallel option used to try to exceed that will introduce protocol overhead. Vs. Multi-files can be transferred back-to-back at line speeds over FTP with no protocol overhead. FTP's parallel option uses multiple TCP connections which usually surpass single-point connections (ex. SMB3.1 vSMB2.1, 3.x can use multi-connect). – Fulvia

Answer 3

Many firewalls drop outbound connections which are not to ports 80 or 443 (http & https); some even drop connections to those ports that are not HTTP(S). FTP may or may not be allowed, not to speak of the active/PASV modes.

Also, HTTP/1.1 allows for much better partial requests ("only send from byte 123456 to the end of file"), conditional requests and caching ("only send if content changed/if last-modified-date changed") and content compression (gzip).

HTTP is much easier to use through a proxy.

From my anecdotal evidence, HTTP is easier to make work with dropped/slow/flaky connections; e.g. it is not needed to (re)establish a login session before (re)initiating transfer.

OTOH, HTTP is stateless, so you'd have to do authentication and building a trail of "who did what when" yourself.

The only difference in speed I've noticed is transferring lots of small files: HTTP with pipelining is faster (reduces round-trips, esp. noticeable on high-latency networks).

Note that HTTP/2 offers even more optimizations, whereas the FTP protocol has not seen any updates for decades (and even extensions to FTP have insignificant uptake by users). So, unless you are transferring files through a time machine, HTTP seems to have won.

(Tangentially: there are protocols that are better suited for file transfer, such as rsync or BitTorrent, but those don't have as much mindshare, whereas HTTP is Everywhere™)

Wyattwyche

Answer 4

One consideration is that FTP can use non-standard ports, which can make getting though firewalls difficult (especially if you're using SSL). HTTP is typically on a known port, so this is rarely a problem.

If you do decide to use FTP, make sure you read about Active and Passive FTP.

In terms of performance, at the end of the day they're both spewing files directly down TCP connections so should be about the same.

Adrial

Answer 5

One advantage of FTP is that there is a standard way to list files using dir or ls. Because of this, ftp plays nice with tools such as rsync. Granted, rsync is usually done over ssh, but the option is there.

Khalkha

Good point. HTTP often requires scraping child links from the parent webpage. – Idalia

Answer 6

FTP is from the old days; I've used it instead of HTTP for Web pictures in the 2000 early days. Then connections were very slow, and some Mb picture were a heavy load for HTTP, and often the picture didn't load (because of connection fails). FTP were fine to do the work... but many corporative clients contacted me because they couldn't see that pictures, as their firewall didn't allow the FTP connections.

Now there are only a few places/reasons where may make sense to use SFTP, and even less FTPS, because of the additional port and firewall configuration needed, although SFTP may need a more complex security configuration to be used properly. Using SSH and then FTP is just the same as using SFTP.

Ku

Answer 7

Both of them uses TCP as a transport protocol, but HTTP uses a persistent connection, which makes the performance of the TCP better.

Sierra