Networking

FTP — File Transfer Protocol

Nearly every other protocol on this domain uses one TCP connection for everything. FTP, one of the internet's oldest protocols, does something different: it splits a session into a control connection (commands) and a separate data connection (the actual file bytes) — a design choice from an era before anyone had thought through what that would do to firewalls and NAT decades later.

Two channels, one session

The client connects to the server's control port (21) and sends plain-text commands — USER, PASS, RETR filename (download), STOR filename (upload). The control connection stays open for the whole session, but it never carries file bytes itself — every actual file transfer opens a brand new, separate TCP connection just for that transfer's data.

Active vs. passive mode

Who opens that second, data connection is the single most confusing part of FTP, and the direct consequence of the protocol predating NAT and modern firewalls by decades.

Active mode

The server initiates the data connection back to the client, on a port the client told it to use. This breaks immediately if the client is behind NAT or a firewall — the server is trying to open an unsolicited inbound connection to a machine that, from the internet's point of view, doesn't have a directly reachable address at all.

Passive mode

The client initiates both connections — it asks the server "which port should I use for data," and the server picks one and waits. This works through client-side NAT, which is why passive mode is the practical default almost everywhere today.

Passive mode moves the problem rather than eliminating it: now the server needs a range of ports open and reachable for incoming data connections — a real firewall configuration detail anyone running an FTP server still has to handle.

Why FTP is increasingly legacy

Plain FTP sends everything — including the username and password in the initial handshake — completely unencrypted, the same fundamental problem telnet had for remote shells. Two different fixes emerged, with confusingly similar names:

• FTPS — FTP with TLS added on top, keeping FTP's original two-channel design.
• SFTP — not "FTP with encryption" despite the name. It's a completely different protocol, a file-transfer subsystem built into SSH, sharing none of FTP's control/data-channel split — a single connection, SSH's own authentication, and none of the active/passive complexity.

In practice, SFTP has mostly won for new systems, precisely because it avoids the dual-connection firewall/NAT problem entirely.

Real-world applications

• Legacy industrial and manufacturing equipment — some test benches, PLCs, and factory-floor tooling still expose FTP as their only file-transfer option, simply because it predates the hardware's own software stack.
• ISP and shared-hosting file management — older web hosting control panels still commonly offer FTP/FTPS access alongside newer options.
• Anonymous FTP archives — some public software/firmware mirrors still serve files over anonymous (no-login) FTP, a holdover from the pre-web era of file distribution.

Gotchas