Introduction to the File Transfer Protocol
| To the uninitiated, FTP and HTTP seem to be quite similar. Both allow file transfers, both support a form of user authentication, and the two protocols often appear to be used interchangeably on the Weba binary package or large multimedia file might be linked from a website via either the http:// or the ftp:// protocols, which seem to do the same thing with regard to downloading the file to your computer. However, a little further investigation shows us that the two protocols are designed for considerably different purposes and therefore support widely different feature sets. Table 27.1 shows a contrast of these crucial areas of difference.
The biggest difference between FTP and HTTP is that FTP is session based, meaning that a complete connection is initiated between the client and server, multiple commands are sent back and forth, and finally the client terminates the connection by choice. (HTTP, as you will recall, is a stateless protocola single request, followed by a single or pipelined response, comprises the whole HTTP "session.") FTP goes even beyond a single connection, as a matter of fact. A complete FTP session contains two connections: one for passing commands and status messages back and forth (control connection), and another to handle the actual file transfers (data connection). Figure 27.1 shows a diagram of a complete FTP connection. Figure 27.1. An FTP session with both the control and data connections established. An FTP client, such as the ftp command built in to FreeBSD, opens the control connection to TCP port 21 on the FTP server. This connection remains open throughout the session. When the user enters a command, such as ls or get picture1.gif, the client and server negotiate a pair of TCP ports between which they will open the data connection, which exists for as long as the response listing or file is being transferred, after which it is closed. A separate data connection is opened for each such transfer. A complete, typical FTP session is shown in Listing 27.1. Listing 27.1. A Command-Line FTP Session
The first part of the connection is the username and password authentication stage, just as you would get in a Telnet or SSH connection. Similar to Telnet, FTP user authentication usually operates directly on a user's account information on the machine running the FTP server. This authentication process differs from HTTP user authentication, which is actually a function of Apache and not of HTTP itself and requires Apache's own user databases to be separately maintained. In order to log in via FTP, the user must either have a valid user account on the server machine or must log in using "anonymous FTP," if the server allows it (a common practice that we will cover later in this chapter). A number of user commands are available in FTP, behaving in much the same way as their familiar shell counterparts: ls, cd, mkdir, pwd, and so on. These commands help you navigate through the directory structure and modify remote files as if they were on the local (client) machine. There is also an lcd command that allows you to change directories on the local machine, in case you want to download a file to a different location from the one you were in when you started the FTP program. Additionally, there are the put (upload), get (download), mput (multiple upload), and mget (multiple download) commands, which control the file transfers themselves. These user commands are translated into client commands (such as RETR, STOR, CWD, and LIST) that the FTP server understands. The server responds with three-digit response codes, much as in HTTP. The meanings of the response codes aren't especially important to know, so we won't cover them here. See man ftpd if you're interested in seeing the complete list of FTP client commands (this manual for the server outlines the client commands the server recognizes). Note FTP file transfers can be done in one of two modes: ASCII or Binary. ASCII mode is used for transfers of plain text, in which all data is transferred as alphanumeric characters and end-of-line symbols are translated by the FTP application to or from whatever the client's platform uses, such as CR/LF for DOS/Windows, CR for classic Mac OS, and LF for UNIX. Binary mode is useful for transferring a stream of untranslated data. Some FTP clients, such as the one built into FreeBSD, automatically detect which type is appropriate and then switch to that mode when the transfer begins. Other clients require that you select either ASCII or Binary mode before transferring files. Use the bin and asc commands to switch modes. It's generally safest to use binary mode at all times; however, if you find you have problems with text files such as HTML files and Perl scripts not rendering correctly after being transferred, try ASCII mode instead. This ensures that end-of-line characters are translated properly. Binary mode can cause Perl scripts to fail to run if uploaded from a non-UNIX client. Binary mode, however, is necessary for images, executables, and any other kind of binary data; binary files transferred in ASCII mode will be corrupted on the destination machine. The default FTP server that ships with FreeBSD, which you learn about in this chapter, is the standard BSD ftpd daemon. It runs from within the inetd super-server, like telnetd and Qpopper, rather than as a standalone daemon. It lacks a few features supported by some of its alternatives (such as WU-FTPD and ProFTPD), but it also lacks a number of security holes that are inevitable with more complex software. You learn more about these alternative daemons at the end of this chapter; meanwhile, the following sections discuss how to make the most of the basic FreeBSD FTP server. |
