FTP vs HTTP

Mirjana's picture

Differences in general:

FTP
HTTP
FTP is file transfer protocol, so it is optimised for transmitting files
HTTP is hypertext transfer protocol, so it is optimised for transmitting hypertext, i.e. web pages.
FTP does a lot more packet verification. That means it's somewhat slower for a given size file, but the file is more likely to get through in one piece because, for a binary application file, for example, one lost packet is as good as losing the whole thing.
HTTP was designed to be fast, but not solid. Who cares if you lose a few packets here and there anyway?
FTP, is a protocol used to upload files from a workstation to a FTP server or download files from a FTP server to a workstation.
HTTP, is a protocol used to transfer files from a Web server onto a browser in order to view a Web page that is on the Internet. Unlike FTP, where entire files are transferred from one device to another and copied into memory, HTTP only transfers the contents of a web page into a browser for viewing
When ftp appears in a URL it means that the user is connecting to a file server and not a Web server
When http appears in a URL it means that the user is connecting to a Web server and not a file server
Statefull protocol and requires fewer round    trips for communication.
Stateless protocol – only request response
FTP is a two-way system as files are transferred back and forth between server and workstation.
HTTP is a one-way system as files are transported only from the server onto the workstation’s browser.
FTP puts less load on the network for smaller transfers
For transfers of large amounts of data, both are comparable
With ftp, clients can do a directory listing and get time stamps and file sizes.
Directory listing is not usually possible with Web connections, because that information is hidden from the user
Can be tied to specific user accounts and require user authentication – PROS
Can allow anonymous access if desired – PROS
Easy target for hackers – CONS
 
 
HTTP may be less secure than FTP depending on which software you use for your HTTP server and which platform on which you are running the HTTP server and how you configure it
 

Differences in details

Both protocols are used for uploads and downloads on the internet, for text and for binary, both over TCP/IP. But there are a lot of differences in the details:
 
1.
Age
 
FTP appeared roughly ten years before HTTP was invented. FTP was the one and only protocol back then.
2.
Upload
FTP
Both protocols offer uploads. FTP has an "append" command
HTTP
HTTP is more of a "here's data coming now you deal with it" approach.
It could be worth noticing that WebDAV is a protocol on top of HTTP that provides "filesystem-like" abilities
3.
ASCII/binary
FTP
FTP has a notion of file format so it can transfer data as ASCII or binary (and more) where.
FTP thus also allows text conversions when ASCII files are sent between systems of different sorts
HTTP
HTTP always sends things binary.
HTTP provides meta-data with files, Content-Type, which clients use but FTP has no such thing. The meta data can thus be used by clients to intrepret the contents accordingly
4.
Headers
FTP
FTP does not send headers.
When sending small files, the headers can be a significant part of the amount of actual data tranffered - CONS
HTTP
Transfers with HTTP always also include a set of headers that send meta data
HTTP headers contain info about things such as last modified date, character encoding, server name and version and more - PROS
5.
Pipelining
FTP
Something related, although not similar, is FTP's support for requesting multiple files to get transferred in parallel using the same control connection. That's of course using new TCP connections for each transfer so it'll get different performance metrics
HTTP
HTTP supports pipelining. It means that a client can ask for the next transfer already before the previous one has ended, which thus allows multiple documents to get sent without a round-trip delay between the documents, and TCP packets are thus optimized for transfer speed.
6.
FTP
Command
Response
FTP
FTP involves the client sending commands to which the server responds. A single transfer can involve quite a series of commands. This of course has a negative impact since there's a round-trip delay for each command
Reretriving a single FTP file can easily get up to 10 round-trips - CONS
HTTP
HTTP transfers are primarily just one request and one response (for each document)
7.
Two connections
FTP
One of the biggest hurdles about FTP in real life is its use of two connections. It uses a first primary connection to send control commands on, and when it sends or receives data, it opens a second TCP stream for that purpose - CONS
HTTP
Uses only one connection for request and response
8.
Active
Passive
FTP
FTP opens the second connection in an active or passive mode, which basically says which end that initiates it. IT's a client decision to try either way.
HTTP
There is no active/passive option in HTTP
9.
Firewall and NATs
FTP
&
HTTP
FTP's use of two connections, where the second one use dynamic port numbers and can go in either direction, gives the firewall admins grief and firewalls really have to "understand" FTP at the application protocol layer to work really well.
This also means that if both parties are behind NATs, you cannot use FTP!
10.
Encrypted
Control
Connections
FTP
&
HTTP
Since firewalls need to understand FTP to be able to open ports for the secondary connection etc, there's a huge problem with encrypted FTP (FTP-SSL or FTPS) since then the control connection is sent encrypted and the firewall(s) cannot interpret the commands that deal with creating the second connection. Also, the FTPS standard took a very long time to "hit it" so there exist a range of hybrid versions out in the wild.
11.
Authentication
FTP
&
HTTP
FTP and HTTP have a different set of authentication methods documented. While both protocols offer basically plain-text user and password by default, there are several commonly used authentication methods for HTTP that isn't sending the password as plain text, but there aren't as many (non-kerberos) options available for FTP.
12.
Download
FTP
&
HTTP
Both protocols offer support for download. Both protocols used to have problems with file sizes larger than 2GB but those are history for modern clients and servers on modern operating systems
13.
Ranges/
Resume
FTP
&
HTTP
Both FTP and HTTP support resumed transfers in both directions, but HTTP supports more advanced byte ranges
14.
Persistent
Connections
FTP
FTP must create a new connection for each new data transfer.
HTTP
For HTTP communication, a client can maintain a single connection to a server and just keep using that for any amount of transfers.
15.
Chunked
Encoding
HTTP
HTTP has a means of sending data which has an unknown size at the start of the transfer, but still not have to use close of the connection to signal the end of the data. This is done by "chunked encoding", which simply sends a stream of [size-of-data][data] blocks over the wire.
Another obvious benefit with chunked encoding compared to plain closing of the connection is the ability to detect premature connection shutdowns.
16.
Compression
FTP
FTP offers an official "built-in" run length encoding that compresses the amount of data to send, but not by a great deal on ordinary binary data. It has also traditionally been done for FTP using various "hackish" approaches that were never in any FTP spec.
HTTP
HTTP provides a way for the client and server to negotiate and use (different) compression for the sent data. The gzip algorithm being the perhaps most compact one.
19.
Name based
Virtual
hosting
FTP
In FTP, you cannot do name based virtual hosting at all.
HTTP
Using HTTP, you can easily host many sites on the same server and they are all differentiated by their names.
20.
Dir Listing
FTP
One area in which FTP stands out somewhat is that it is a protocol that is directly on file level. It means that FTP has for example commands for listing dir contents of the remote server
However, the FTP spec authors lived in a different age so the commands for listing directory contents (LIST and NLST) don't have a specified output format so it's a pain to write programs to parse the output. Latter specs (RFC3659) have addressed this with new commands, but they are not widely implemented or supported by neither servers nor clients.
HTTP
HTTP does not have a concept of listing dir content
22.
Proxy
FTP
FTP has always been used over proxies as well, but that was never standardized and was always done in lots of different ad-hoc approaches.
HTTP
One of the biggest selling points for HTTP over FTP is its support for proxies, already built-in into the protocol from day 1. The support is so successful and well used that lots of other protocols can be sent over HTTP these days just for its ability to go through proxies.
23.
Transfer speed
FTP
What makes FTP faster:
No added meta-data in the sent files, just the raw binary
Never chunked encoding "overhead"
HTTP
What makes HTTP faster:
reusing existing persistent connections make better TCP performance
pipelining makes asking for multiple files from the same server faster
(automatic) compression makes less data get sent
no command/response flow minimizes extra round-trips