Jack Barnett wrote:
> Niclas Hedhman wrote:
> >
> > Can anyone explain why it takes 1-5 minutes to get any FTP transfer to
> > start, while HTTP transfers are pretty quick?
> >
> > Is this due to slow connections and FTP wasn't designed for high
> > latency, and keep aborting and reconnecting the TCP over and over again,
> > or what ??
> >
> > And is FTP that more efficient on the server, or why does all
> > high-volume sites insist on using FTP instead of HTTP for download, such
> > as Apache and Linux sites?
> >
> > Curious, but frustrated...
> > Niclas
>
> Slow start ups could be alot of differant things. For HTTP there is a
> dedicated server sitting in memory waiting for your connections, most
> FTP are run from inetd, which the ftp server isn't loaded into memory,
> untill you try to make a connection to it. If the server is busy and/or
> doesn't have alot of primrary memory avaiable, the ftp server will half
> to fight with other processes on the server then it will have to wait
> for the swap daemon to free it up some room... then it can take your
> connection...
>
> Also ftp requires a login, even if it is anonymous, http servers don't
> have to use cpu cycles, bandwidth and memory to verify user name and
> password... (they can if you want them to, but don't by default.).
>
> Also depends on the machine the ftp server is running on compared to the
> http server. If the company or organization thinks that their http
> image is more important and spend mega bucks on beefed up http server,
> they may have to use an old 486 for ftp since they blow all their money.
>
> Also if you are tyring to "browser" and ftp by a web browser like
> Netscape or IE, it will be slower, because the browser does NOT keep a
> connection, it will re-login to the ftp each and everytime you switch
> directories... fun fun.
>
> Also I think HTTP is more designed for "stop and go" traffic, where as
> ftp connections and expected to be connected for awhile...
>
> Than again, I never read an entire RFC or studied anything remotely
> dealing with either protrocol on a design level, so this information
> could be wrong, use at your own risk..
>
> Jack
I think that all said above is "bad excuses". No computer is that slow. Few
companies has a 10Mbps or faster Internet connection and running on 486's or
less. And way back, I made a study that a Netware 2.15 file server running on
a 25MHz 286, could deliver the files faster than the 10Mbps Ethernet could
transport.
It is something much more serious, and that's why I have been suspecting
timeouts and/or problems with lost packets. If I can get a HTTP request
served in 1-2 seconds, there is no reason that the FTP request takes 2
minutes or more. None at all.
And since not enough people is complaining, I guess that latency/lost packets
for far-away users like myself escalates the issue exponentially.
Anyway, I will be dropping FTP out of my consciousness, before I tear down a
wall.
Niclas
