Main | Articles/Papers | Projects | Multiplayer Cheat | MP3 Trade | Fun Stuff | Links | About... [ Read/Sign my Guestbook ] [ Send me E-Mail ] [ Contact me by ICQ ]
No More FTP!
(Written by Stanislaw Y. Pusep, 21/May/2002, revision #1)
  1. Introduction
  2. HTTP vs. FTP
    1. Efficiency
    2. Portability
    3. Flexibility
    4. Security
  3. Resume

3D bar

Introduction

So, what FTP client do you use for your downloads? It can be whatever from that command-line one, passing by browser's built-in and up to somewhat like gFTP. But the question is: do we really need FTP services? Or they are past just like Telnet and Gopher? No, I'm not trying to persuade you to shut down your FTP server neither erradicate FTP protocol at all. Neither Telnet is totally dead! Just think if you really want to support FTP service when building your shiny new high-end download server. Now, I'll try to show some of disadvantages of FTP service I found. Certainly, they could be more. And, of course, I'll attempt to point some more efficient solution.

3D bar

HTTP vs. FTP

FTP means "File Transfer Protocol", and HTTP - "HyperText Transfer Protocol". By RFC-1945 definition, "HTTP is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems.". RFC-959 tells us that "The objectives of FTP are 1) to promote sharing of files (computer programs and/or data), 2) to encourage indirect or implicit (via programs) use of remote computers, 3) to shield a user from variations in file storage systems among hosts, and 4) to transfer data reliably and efficiently.". They are completely different protocols, but they are frequently used for same purpose: file download. So, which one is better?

3D bar

Efficiency

Although FTP says about "transfer data efficiently" it's not right. I had benchmarked downloads of same file (PGP signature of Linux kernel v2.4.18) from same server (zeus.kernel.org) using same client (Wget 1.7) but with different protocols. FTP exchanged 47 TCP/IP packets during normal and 48 during passive transfer. HTTP exchanged only 10 packets. What does it means? Today's networks suffers from high latency (also know as "high ping"). Doesn't matter how small the packet is it will take some time to reach it's destination. So, sending less packets and using bigger packets is more efficient. Also, FTP command packets are tiny so network suffers from significant overhead. This is not so big problem when you transfer huge files, but I feel a great anger when FTP takes too much time to authenticate me as anonymous on too far server. No, FTP is not efficient! HTTP wins here.

3D bar

Portability

Portability depends a lot from how simple the code is. FTP could not be called "simple" protocol, as it have lots of commands performing different actions. HTTP has few commands, it's main complexity resides in it's parameters. In fact, I know "micro_httpd" which is 150 lines long implementation of HTTP service. I also know http server which is written in x86 assembly and it's executable has only... 532 bytes! In fact, HTTP service can be easily ported to different languages. One of the biggest problems of FTP is a mess with it's binary/text modes. Imagine you taking hours to download that archive and soon discovering you did that in ASCII mode! Now, if you used HTTP, it's metainformation tags saves you from human mistakes. Other, more recent problem appears when you need FTP services when you're inside virtual network (IP Masquerade, NAT). One can try to use passive transference mode in his/her clients, but if you want to build some server, you'll need to unfirewall lots of useless ports. Yeah, that seems a bit paranoid but it stills unsafe. No, FTP is also not portable! HTTP - 2, FTP - 0.

3D bar

Flexibility

The main goal of HTTP protocol wasn't transfer of files. But it seems to do that with no problems. You can easily mix dynamic scripts with static files on your HTTP server. You can also run "HTTP accelerator", a tiny but very efficient HTTP server for static files and do all the "clean" job of script processing to more powerful server. "khttpd" and "TUX" are inside-kernel accelerators and you can use something like "thttpd" if you don't like patched kernel. By the other side, FTP has ability to run executables but it's pretty misused due to security reasons (and not-so-friendly user interface, too). HTTP scores again.

3D bar

Security

Due to it's flexibility HTTP is able to run over encrypted SSL tunnel. Secure version of FTP, sftp, isn't exactly a child of FTP protocol. It's quite different, so some people could become bored if you said "sftp is FTP". HTTP supports authentication through hashes, so no one could sniff and reuse passwords. AFAIK, FTP has unofficial authentication that uses MD5, but not all servers can do it. Other thing that bores me a lot in FTP is it's "anonymous" login. It's implementation consumes time and bandwidth. And most people prefer enter somewhat like "a@b.c" instead of their real e-mail addresses. And, as I said before, FTP has a big problem with firewalls/NAT. This reduces dramatically my (and others) trust to it.

3D bar

Resume

Certainly, it is impossible just to throw away all our FTP servers and clients. FTP's upload ability is one of the most wanted, as HTTP PUT/DELE commands are misused even by HTTP server creators; and sftp isn't so popular yet. But why to make huge download servers run space & time consuming FTP service? Generally, people put FTP links on their Web pages. If one will use whatever proud to be called "browser" to navigate Web pages, why should he/she use FTP client do download things?
  Page last modified on February 04 2004 00:14 (BRST) | ©opyLeft by SysD Destructive Labs, 1997-2006
 
Valid HTML 4.01!