FTP vs HTTP
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
|
