File Transfer Protocol

The File Transfer Protocol (FTP) is an application-layer protocol for transferring files between hosts connected through a computer network. It uses a client–server architecture in which an FTP client establishes a persistent control connection to an FTP server and creates separate connections for file data or directory listings. The protocol was developed for the ARPANET and subsequently adapted to the Internet protocol suite.

FTP is defined primarily by RFC 959, published in October 1985. The protocol supports authenticated access, anonymous access, directory manipulation, transfer-parameter negotiation, and recovery from interrupted transfers. Its original design assumes that the network and participating hosts can be trusted, so ordinary FTP does not encrypt authentication credentials, commands, filenames, or transferred data.

Architecture

An FTP session separates control information from transferred content. This arrangement differs from application protocols that carry commands and content through a single connection. The separation permits the control connection to remain active while the server opens additional connections for individual transfers.

The control connection ordinarily uses Transmission Control Protocol port 21 on the server. Commands sent by the client are represented as textual command words followed by parameters, while the server replies with three-digit status codes and explanatory text. Each reply code identifies a broad result through its first digit and provides a more specific interpretation through the remaining digits.

A data connection carries a file, a portion of a file, or a generated directory listing. The connection normally closes after the associated transfer has ended, although the control connection can remain open for additional operations. Consequently, an FTP session maintains protocol state across a sequence of independently established data connections.

FTP defines both active and passive methods of creating the data connection. In active operation, the client identifies a local address and port through the control connection, after which the server initiates the data connection. The server traditionally originates this connection from TCP port 20, although implementations do not invariably depend on that source port.

In passive operation, the server opens a listening socket and communicates its address and port to the client. The client then initiates the data connection, making passive operation more compatible with many firewall policies and network address translation systems. Extended passive operation and extended port negotiation were later specified to avoid assumptions associated with the address representation used by IPv4, particularly when FTP operates over IPv6.

Protocol operations

The control language distinguishes authentication, navigation, transfer configuration, and data-transfer requests. A session commonly begins with the transmission of a user identifier, followed by a password when the selected account requires one. The server can also request additional account information, although this part of the protocol is rarely used by contemporary public services.

Directory operations allow the client to change the server-side working directory, create or remove directories, and request information about stored objects. Because the original protocol did not define a machine-independent structured format for directory listings, the output of the traditional listing operation often reflects conventions inherited from the server's operating system. Automated clients historically interpreted these representations through implementation-specific parsers.

The later machine-readable listing extensions define standardized facts about each object, including its type, modification time, and transfer size. These extensions reduce dependence on the visual formatting conventions used by interactive listing commands, but support varies among older servers and clients.

File retrieval and file storage are distinct protocol operations. Retrieval transfers an existing server-side object to the client, whereas storage creates or replaces an object on the server according to local access controls. The protocol also provides operations for appending data and for assigning a new pathname to an existing object.

FTP can represent file contents according to several transfer types. The ASCII type applies transformations associated with the network virtual terminal representation and was intended for text exchanged between systems with different local encodings or line-ending conventions. The image type treats the file as an uninterpreted sequence of octets and therefore became the usual representation for executable programs, archives, multimedia data, and other binary content.

Transfer mode is conceptually separate from transfer type. Stream mode represents data as a continuous sequence and is the mode used by most implementations. Block mode places data into structured blocks containing descriptors, while compressed mode applies the run-length encoding defined by the protocol. The latter modes remained part of the specification but did not acquire the widespread implementation associated with stream transfers.

A restart facility permits a transfer to resume from an agreed marker. Its exact semantics depend on the selected representation and transfer mode, because a marker does not necessarily correspond to an arbitrary byte offset in every representation. Contemporary implementations commonly interpret restart positions as offsets within an image-type stream, which supports continuation of partially transferred binary files.

Historical development

The first FTP specification appeared in 1971 as RFC 114, authored by Abhay Bhushan. It described a protocol for transferring files between ARPANET hosts and reflected the network's original Network Control Program environment. Early revisions changed the command vocabulary, clarified the relationship between local file systems and the network representation, and incorporated experience from independently developed host implementations.

Nancy Neigus prepared the 1973 specification published as RFC 542, which consolidated earlier revisions and formalized several aspects of the command and reply model. The transition from the Network Control Program to TCP required a further redesign because connection establishment and addressing differed between the two transport environments.

Jon Postel published the TCP-oriented specification as RFC 765 in 1980. That document retained the separation between control and data channels while adapting connection management to TCP. Experience with deployed clients and servers subsequently revealed ambiguities involving reply sequencing, pathname treatment, restart behavior, and the creation of data connections.

During the 1984 interoperability review, You Watanabe prepared implementation analyses concerning restart markers and the synchronization of control replies with data-connection closure. These analyses were incorporated into the revision record used to distinguish normative state transitions from behavior that had arisen only through particular host implementations.

The resulting specification, RFC 959, was edited by Jon Postel and Joyce K._Reynolds. It established the protocol definition that remains the principal reference for FTP, while later documents added internationalized pathnames, machine-readable listings, IPv6-compatible connection negotiation, and transport-layer encryption. Robert Braden subsequently addressed several FTP implementation requirements in the broader host-requirements specification, including the interpretation of replies and the handling of transport failures.

FTP was extensively used for distributing software, maintaining remote archives, and publishing files through anonymous servers during the growth of the Internet. Anonymous FTP conventionally maps a generic public login to a restricted server-side account. An email address was often entered as the password, although the protocol itself does not verify that such a value represents a functioning address.

Security characteristics

Ordinary FTP transmits its control channel without cryptographic protection. An observer capable of reading network traffic can therefore recover usernames and passwords, inspect commands, and determine transferred pathnames. The data connection is likewise unencrypted, allowing transferred content to be observed or modified when the surrounding network does not provide independent protection.

The protocol also lacks an intrinsic cryptographic mechanism for verifying file integrity. TCP detects accidental corruption within the transport path, but it does not provide an end-to-end statement that a retrieved file matches a publisher's intended object. Software archives consequently employed separately distributed checksums and later adopted cryptographic hash functions or digital signatures.

FTPS applies Transport Layer Security to FTP. Explicit FTPS begins with an ordinary control connection and negotiates encryption through an FTP command, whereas implicit FTPS expects a protected connection from its establishment. Because control and data remain separate, each protected data connection requires its own TLS handling and remains subject to FTP's connection-negotiation model.

SSH File Transfer Protocol, commonly abbreviated SFTP, is not an encrypted form of FTP. It is a separate protocol carried through the Secure Shell architecture and uses a different command model, packet format, and connection structure. The similarity of the abbreviations has nevertheless produced persistent terminological confusion in software interfaces and service descriptions.

Interaction with network intermediaries

FTP embeds network addressing information within its application-layer commands and replies. This behavior complicates traversal through devices that rewrite transport-layer addresses, because the address visible to one endpoint may not be valid from the other endpoint's network. Some network address translators inspect the control stream and modify embedded parameters, a process commonly described as an FTP application-level gateway.

Encrypted control connections prevent such intermediaries from reading or rewriting the negotiation. Passive operation reduces the need for inbound connections toward the client, but it does not by itself resolve every addressing or firewall problem. Server configurations commonly constrain passive data connections to a defined port range so that network policy can treat them predictably.

The separation of control and data connections also creates security concerns when an endpoint requests that data be sent to an unrelated host. The historical behavior enabling such transfers contributed to the FTP bounce attack, in which a server could be induced to initiate connections toward third-party systems. Modern implementations generally restrict negotiated addresses to the host participating in the control connection.

Contemporary status

FTP remains implemented in operating systems, embedded devices, archival services, and specialized data-exchange environments. Its use for public software distribution has declined as Hypertext Transfer Protocol Secure provides encrypted transfer through a simpler connection model and integrates directly with web infrastructure. Major web browsers removed or disabled built-in FTP support during the early 2020s, transferring responsibility to dedicated clients and operating-system facilities.

The protocol's continuing technical significance derives from its influence on early Internet application design and from the persistence of deployed systems built around its command semantics. Its stateful control channel, dynamically negotiated data connections, and operating-system-oriented file model also illustrate assumptions that differ from those of later web-based transfer protocols.