PASV

[...]

FTP command issued as part of setting up a transfer with the connection direction being in the same direction as the command channel (i.e. the FTP server creates a temporary server socket and it is up to the client to connect to it.) Why do this? Generally--very generally--it's to get through a firewall. Why not just use HTTP? It's not clear. There's folklore about FTP being faster, in some sense, and there are the usual legacy reasons, too.

As of February 2003, tcllib's ftp implements PASV, but ftpd does not.

DKF - When setting up a firewall, it is generally best if you can only let through selected protocols, ideally in both directions (outgoing is usually more permissive than incoming, but the aggressively paranoiac impose similar rules in both directions.) Some protocols (like HTTP) only use a single socket, and it is easy enough to write rules to handle this, but other protocols (FTP is the most common one) use a control channel and potentially multiple data channels. These data channels can potentially be on any socket, which is not good from a firewall PoV since it is difficult to write rules to handle this; some firewall software systesm, like iptables in Linux, include special modules to handle this sort of thing, but the fundamental problem is that the protocol is not restricted to a single port. And to make things worse, for FTP the data channels are opened in the "opposite direction" to the command channel; the server socket for the data channels is on the FTP client!

By using PASV, you can make all data connections in the same direction as the command connections and (IIRC) to a known port as well. This makes FTP much easier to fit in with a standard firewall configuration.

The folklore about FTP being faster than HTTP is not quite that. It depends on some of the TCP connection parameters which it is easier to set up differently on separate channels (I do not recall the precise details; they're not a detail of sockets currently exposed at the Tcl level in any case) though these things are in truth dynamically configurable anyway, so heavy-duty webservers shouldn't face the hit when shifting large amounts of data. IOW, it's not entirely folklore, but there's not really all that much basis to it at the high-end. Tcl isn't quite there yet though, but not for either protocol... :^)

DKF: Revisiting this years later, I now know that the difference between the two depends on the relative values of latency and bandwidth. Latency affects how fast an individual message goes through (and is critical for TCP socket connect creation, which requires a message exchange) whereas bandwidth is how fast you can shove bytes through. With modern hardware, you can have many more packets in transit than before, which means that bandwidth is larger without latency being improved: the net result is that protocols which use bandwidth instead of latency seem faster, and this benefits small HTTP transfers more than small FTP transfers. Large transfers don't really care (though there can be some benefit to doing multiple transfers at once; that's quite possible with both protocols though).

RFox Why not HTTP? Pretty simple answer FTP RFC dates 10/1985 HTTP's first one dates 1/1997 it just wasn't an option back in 1985.

See Also edit