Re: why use ftp if http provides the same services???

From: Rogan Dawes (SeeMySig_at_dev.null)
Date: 04/20/04 

Date: Tue, 20 Apr 2004 11:17:13 +0200

Sudsy wrote:

> yogesh wrote:
>
>> when downloading a file often the websites give two option..either
>> download it from a ftp site or http..
>> what is the difference between downloading a file(non
>> html.eg.word,spread*** file) from http server and ftp server.?
>> if the http server could also provide the service of storing the
>> downloadable file then why ftp servers are used?
>
>
> Two reasons:
> - performance
> - firewalls
> vis:
> - FTP is typically more efficient, i.e. there's less protocol overhead
> compared to HTTP.
> - Corporate firewalls often restrict the use of the ports needed to
> use FTP. Port 80 (HTTP) is usually wide open.
>
> So it depends on your target market. But Chris is quite correct in that
> this is not really a Java question, merely one which affects those of
> us attempting to make our Java services available to the largest user
> population.
>

I believe that HTTP is much more efficient for anonymous downloads than
FTP is, due the the limited number of connections and conversations
required. For FTP, there is a whole process that has to be followed
before the first byte of real data is transferred:

connect to server on port 21, receive banner and login prompt
supply username
receive password prompt
supply password
receive OK message
change directory
receive OK message
set binary mode
receive Ok message
request PASV mode (optional, but likely)
receive OK message
request filename
receive data port on server to connect to
open TCP connection to new port
start downloading data file

v.s.

connect to server on port 80, request file and supply some headers
Server sends a few headers back, and immediately follows with the data

HTTP is also better supported by secure proxies than FTP is, as well as
supporting proxy authentication, which is usually a kludge in FTP.

HTTP also supports automatic compression of content (mod_gzip, for
instance), but if that is a concern, you would probably be supplying
pre-compressed data to start with.

HTTP/1.1 also support reconnects and partial transfer (resume). You may
argue that this is not that common, but that is implementation, and not
protocol.

The only thing that FTP is natively better at than HTTP, in my opinion,
is *authenticated* file uploads, and even this can be overcome by an
application, or implementing the PUT method. A web application for doing
large authenticated file uploads will most likely be 75% as efficient as
an FTP upload, due to the MIME encoding of the POST body. This is not an
issue when using the PUT method.

However, most browsers do not support PUT, I think. You could probably
write a custom script to do this (as you could with POST, in fact), but
this post is long enough already! 

-- 
Rogan Dawes
nntp_AT_dawes*DOT*za-DOT-net