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.)

Solution 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.

Solution 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.

Solution 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™)

Solution 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.

Solution 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.

View more solutions

Comments

[skaffman]

+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.

[Urbycoz]

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

[Trisped]

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.

[John Ellinwood]

@Trisped 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.

[spenibus]

This seems very anecdotal.

[Benjamin]

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

[user1133275]

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

[masterxilo]

Are the times reproducible, at least approximately?

[user541686]

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

[Rahmat Ihsan]

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.

[Astara]

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).

[user949300]

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