FTP is one of the oldest application protocols still in daily use. It was specified in April 1971, when the ARPANET had roughly twenty nodes, TCP/IP did not exist, and the idea of a personal computer was still a decade away.
Understanding where it came from explains almost every strange thing about it.
RFC 114, and a graduate student
The first specification was RFC 114, written by Abhay Bhushan at MIT and published on 16 April 1971. It ran to a few pages and described something remarkably ambitious for the time: a way for a user at one machine to manipulate files on another, over a network, without knowing anything about the remote machine’s filesystem.
That last part was the hard problem. The ARPANET connected machines that disagreed about nearly everything — word sizes, character encodings, what a “file” was, whether text had records or lines. FTP had to define a common denominator. That is why it carries concepts like TYPE, STRU and MODE: negotiating representation was the central difficulty, not moving bytes.
It also ran over NCP, the ARPANET’s original host protocol. TCP/IP would not replace it until the flag day of 1 January 1983, and FTP was revised to suit.
Why two connections
The design that defines FTP — separate control and data connections — came from a requirement that has since disappeared.
The goal was that a user sitting at terminal A should be able to move a file from machine B to machine C without the data passing through A. With a single connection that is impossible. With a control channel that steers and a data channel that flows independently, it falls out naturally.
That capability became known as FXP, and it later turned into a security liability: the “FTP bounce attack” abused it to make a server open connections to arbitrary hosts, effectively using it as a port scanner. RFC 2577 documented the countermeasures in 1999, and servers today refuse data connections to any address other than the client’s.
The feature is gone. The architecture it required is still with us, and it is why FTP struggles with NAT and firewalls — see active vs passive mode, a problem that would not exist if FTP had been designed after 1990.
RFC 959: the version everyone implements
Between 1971 and 1985 the specification was revised repeatedly — RFC 172, 265, 354, 542, 765. Then came RFC 959 in October 1985, written by Jon Postel and Joyce Reynolds.
RFC 959 is the FTP everyone actually implements. It is forty years old and still the normative reference: the three-digit reply codes, the command set, the ASCII and binary types. A client written to it today interoperates with servers written to it in the 1980s, which is a genuinely remarkable piece of engineering longevity.
Passive mode is in there too — as an option, because in 1985 the assumption was still that every host on the internet was directly reachable. NAT would not arrive until the mid-1990s and turn the option into the default.
The extensions that kept it alive
RFC 2228 (1997) added security extensions, including the AUTH command that makes FTPS possible.
RFC 2428 (1998) introduced EPSV and EPRT, the extended passive and port commands, mostly to support IPv6 — the classic PASV reply hard-codes four bytes of IPv4 address.
RFC 3659 (2007) added MLSD and MLST, machine-readable listings, along with SIZE and MDTM. This fixed a genuinely serious flaw: for two decades clients had been screen-scraping directory listings formatted for humans, guessing at date formats and column positions from a dozen incompatible server styles. MLSD finally made a listing a data structure. It is also why hidden files behave differently depending on server age.
RFC 4217 (2005) formalised FTP over TLS as we use it now.
The competitor that came from somewhere else
SSH appeared in 1995, written by Tatu Ylönen at Helsinki University of Technology after a password-sniffing attack on the university network. It was a response to exactly the problem FTP has: credentials crossing the network in the clear.
SFTP arrived as part of SSH-2 at the end of the 1990s. It was never an FTP extension — it is a file transfer protocol built inside SSH’s encrypted channel, sharing no code or design with FTP. The name is one of the more consequential naming accidents in networking, and it still confuses people configuring servers today. The distinction is worth getting right.
The long retreat
The 2010s removed FTP from most places ordinary users met it:
- 2011 — OS X Lion drops write support for FTP volumes in the Finder.
- 2017 — macOS High Sierra removes the
ftpcommand entirely. - 2020–2021 — Chrome, Firefox and Safari all remove FTP support. Chrome’s removal notes cited usage below 0.1% of navigations and the impossibility of securing it.
- Throughout — hosting providers move to SFTP by default, and plain FTP becomes something you opt into.
Why it is still here
And yet it persists, for reasons worth taking seriously rather than dismissing.
It is trivially simple to implement: a text-based command protocol and a byte stream. That matters for embedded devices, cameras, scanners, industrial controllers and routers with kilobytes of memory and no room for an SSH stack.
It is universally supported, including by equipment that will never receive another firmware update. A protocol frozen in 1985 has the advantage that nothing about it can break.
And there is enormous inertia in shared hosting, where FTPS-over-FTP was the cheapest way to add encryption without giving every customer shell access.
The realistic summary after fifty-five years: use SFTP when SSH exists, FTPS when it does not, and plain FTP only when talking to something that offers nothing else — which, more often than anyone expected in 1971, still happens.
Questions people ask
How old is FTP?
The first specification, RFC 114, was published on 16 April 1971 — before TCP/IP, and about twenty years before the World Wide Web.
Who invented FTP?
Abhay Bhushan, then a graduate student at MIT, wrote the original RFC 114. The modern specification, RFC 959, was edited by Jon Postel and Joyce Reynolds in 1985.
Why does FTP use two connections?
So a user could transfer a file directly between two remote machines without routing the data through their own terminal. The feature was later disabled for security reasons; the architecture remains.
Is FTP deprecated?
Not formally — RFC 959 has never been obsoleted. But browsers have removed it, macOS has removed its client, and plain FTP is no longer considered acceptable over the public internet.
What replaced FTP?
SFTP for anything with SSH access, FTPS where only TLS is available, and for one-way distribution, HTTPS. Object storage APIs have taken over much of what FTP was used for in the 2000s.