HTTP content
Mirjana's picture


Differences in general:

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:
FTP appeared roughly ten years before HTTP was invented. FTP was the one and only protocol back then.
Both protocols offer uploads. FTP has an "append" command
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
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 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
FTP does not send headers.
When sending small files, the headers can be a significant part of the amount of actual data tranffered - CONS
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
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 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.
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 transfers are primarily just one request and one response (for each document)
Two connections
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
Uses only one connection for request and response
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.
There is no active/passive option in HTTP
Firewall and NATs
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!
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.
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.
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
Both FTP and HTTP support resumed transfers in both directions, but HTTP supports more advanced byte ranges
FTP must create a new connection for each new data transfer.
For HTTP communication, a client can maintain a single connection to a server and just keep using that for any amount of transfers.
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.
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 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.
Name based
In FTP, you cannot do name based virtual hosting at all.
Using HTTP, you can easily host many sites on the same server and they are all differentiated by their names.
Dir Listing
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 does not have a concept of listing dir content
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.
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.
Transfer speed
What makes FTP faster:
No added meta-data in the sent files, just the raw binary
Never chunked encoding "overhead"
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
Mirjana's picture

HTTP protocol

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.
HTTP provides the capability not only for your web browser to request pages and files from the webserver, but also HTTP provides the ability for your browser to send information back to the server. Usually this information is in the form of text box information, check boxes, and radio buttons you click on or fill out when you register on a particular website, respond to a poll, or submit any form.

HTTP characteristics

  • Stateless - Each transaction between the client and server is independent and no state is set based on a previous transaction or condition.
  • Uses requests from the client to the server and responses from the server to the client for sending and receiving data.
The HTTP protocol is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol version, followed by a MIME-like message containing request modifiers, client information, and possible body content over a connection with a server. The server responds with a status line, including the message's protocol version and a success or error code, followed by a MIME-like message containing server information, entity metainformation, and possible entity-body content.
Most HTTP communication is initiated by a user agent and consists of a request to be applied to a resource on some origin server. In the simplest case, this may be accomplished via a single connection between the user agent and the origin server.
A more complicated situation occurs when one or more intermediaries are present in the request/response chain. There are three common forms of intermediary: proxy, gateway, and tunnel.
A proxy is a forwarding agent, receiving requests for a URI in its absolute form, rewriting all or part of the message, and forwarding the reformatted request toward the server identified by the URI.
A gateway is a receiving agent, acting as a layer above some other server(s) and, if necessary, translating the requests to the underlying server's protocol.
A tunnel acts as a relay point between two connections without changing the messages; tunnels are used when the communication needs to pass through an intermediary (such as a firewall) even when the intermediary cannot understand the contents of the messages.
In HTTP/1.0, most implementations used a new connection for each request/response exchange. In HTTP/1.1, a connection may be used for one or more request/response exchanges, although connections may be closed for a variety of reasons.

 HTTP Methods

The HTML specifications technically define the difference between GET and POST:
GET means that form data is to be encoded (by a browser) into a URL, it creates a query string of the name-and-value pairs and then appends the query string to the URL of the script on the server that handles the request.
While the POST means that the form data is to appear within a message body, it passes the name-and-value pairs in the body of the HTTP request message


HTTP is insecure and is subject to man-in-the-middle and eavesdropping attacks which can let attackers gain access to website accounts and sensitive information. HTTPS is designed to withstand such attacks and is secure.
HTTPS can create a secure channel over an insecure network.
Syndicate content