Apache > HTTP Server > Documentation > Version 2.4

Introduction to the FTP Protocol

Available Languages:  en 

The File Transfer Protocol (FTP) is a classic standard for transfer of files and records over a TCP/IP network. It was defined by Jon Postel and Joyce Reynolds in RFC 959, which was released in 1985. This means that FTP precedes the HTTP protocol that is usually associated with the Apache server by more than half a decade. The mod_ftp module brings support for FTP to the Apache server and includes several updates to the original protocol. Most notably, mod_ftp implements FTP over Transport Layer Security (TLS) as described in RFC 4217.

On this manual page, a brief technical overview of the FTP protocol is provided, followed by a discussion of the FTP implementation by mod_ftp.

See also


Overview of the FTP Protocol

The File Transfer Protocol (FTP) is designed to facilitate bi-directional transfer of files and records between hosts on a TCP/IP network. Unlike HTTP, the FTP protocol is stateful: the client establishes a Control Connection for the duration of an FTP session that typically spans multiple data transfers.

FTP uses a separate TCP connection for data transfer. Commands are issued and acknowledged over the Control Connection, a TCP connection to well-known port 21. If the user issues a command that requires a response more elaborate than a one-line response code, a Data Connection is established between the client and the server. The response data—the contents of a file or a directory listing—is sent over that data connection.

Historically, the data connection was established from the server back to the client. The client would bind to an arbitrary port, and then transmit its IP address and the port number to the server using the PORT command. The server then set up a data connection to that port on the client host, whereupon the client issues the data transfer command. This approach is referred to as Active FTP (since the server acts to set up the data connection). Unfortunately, active FTP does not work well with firewalls and Network Address Translation (NAT) because incoming connections are often blocked. In the case of NAT, the client only instructs the server to connect to its internal, non-routable IP address. Some firewalls and NAT routers support the FTP protocol, but this support is not universal. In cases where FTP is supported, these devices can rewrite the PORT command and establish ad-hoc access rules for FTP data connections.

Because of these limitations, an alternative approach was developed in which the direction of the data connection is reversed. This is known as Passive FTP. Before starting a data transfer, the client issues a PASV command. The server binds to an arbitrary port number and transmits its IP address and that port number back to the client. The client then sets up a data connection to this address and port on the server, and issues the data transfer command. Passive FTP is more firewall-friendly than Active FTP, because client-side firewalls are typically more lenient on outgoing connections than inbound ones.

While it is possible for FTP to support unauthenticated sessions, in practice all sessions are authenticated. Typically, FTP servers authenticate against the user database of the server on which they run. To facilitate downloads by the general public, FTP servers generally support a special username (by convention "anonymous" or "ftp") to provide read-only access. Users are asked (but often not required) to provide their e-mail address as response to the Password prompt.

For more information on the basic functionality of the FTP protocol please refer to RFC 959 or Wikipedia.

Available Languages:  en 



This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.