FTP (File Transfer Protocol)

Sharing files between computers is one of the oldest problems in networking — uploading a website to a hosting server, pulling down a software package, or moving backup files between offices all come down to the same question: how do two machines, possibly running different operating systems, reliably exchange a file over a network?

The File Transfer Protocol (FTP) was one of the first standardized answers to that question, predating even HTTP. Even though modern systems increasingly favor encrypted alternatives like SFTP and FTPS, FTP's design — particularly its split between a control channel and a data channel — is still worth understanding, both because many systems still use it and because it introduced ideas that later protocols built on.

What Is FTP?

FTP is a standard application-layer protocol used to transfer files between a client and a server over a TCP/IP network, such as a LAN or the Internet. It follows the client-server model: an FTP client requests files or sends commands, and an FTP server stores files and responds to those requests.

Formally, FTP is a communication protocol that enables reliable file transfer between computers over TCP/IP using two separate connections — one for control (commands) and one for data (the actual file contents). That separation is the single most distinctive thing about FTP, and it's covered in detail below.

Through FTP, a client can:

• Upload files to a server
• Download files from a server
• Rename and delete files
• Create and remove directories
• List and navigate a server's directory structure

Unlike HTTP, which is built around displaying content (web pages, images, API responses), FTP exists purely to move files efficiently and to manage a remote file system. This narrower focus is why FTP clients expose directory trees and file operations (rename, delete, permissions) rather than rendering content.

Why Do We Need FTP?

Moving a file between two computers sounds simple, but different systems don't always agree on file formats, directory layouts, or how to represent file metadata. Before a standardized protocol existed, exchanging files between dissimilar systems — say, a Windows machine and a Unix server — required ad hoc, often unreliable methods.

FTP solves this by defining a standard set of commands and responses that any compliant client and server understand, regardless of the operating systems on either end.

Example. A web developer builds a website on a Windows laptop. To publish it, those files need to end up on a Linux web server. Despite the two systems using different filesystems, FTP gives both sides a common language for transferring the files intact.

Example. A university runs an FTP server so students can submit assignments to one central location, rather than emailing them individually. The professor then retrieves every submission from the same server. Companies use the same pattern internally — exchanging reports, invoices, software builds, and backups between branch offices through a shared FTP server rather than ad hoc file copies.

How FTP Works

Two Connections, Not One

Most application protocols (HTTP, for example) use a single TCP connection for everything. FTP is unusual because it opens two independent TCP connections between client and server:

The control connection stays open for the entire session — it's where the client authenticates and issues commands. The data connection, by contrast, is opened only when a file or directory listing actually needs to move, and it's closed again once that transfer finishes.

This separation exists so that command-and-response traffic (small, frequent) never has to compete with file traffic (potentially huge, one-off) on the same channel, and so the server can handle control logic and data transfer somewhat independently.

Active vs. passive mode. In active mode, the server opens the data connection back to the client from its own port 20 — which often gets blocked by client-side firewalls and NAT, since it looks like an unsolicited inbound connection. In passive mode, the client opens the data connection to a port the server advertises, which plays much better with firewalls and is the default in most modern FTP clients. Both modes still rely on the same control/data split described above.

Client-Side Components

An FTP client is made of three cooperating parts:

1. User Interface (UI) — what the person actually interacts with, either a GUI (FileZilla, WinSCP, Cyberduck) or a command-line interface. The UI translates user actions ("upload this folder") into FTP commands.
2. Control Process — opens and maintains the control connection: sending login credentials, issuing commands, and reading the server's responses.
3. Data Transfer Process — opens a separate data connection whenever an actual upload or download begins, and handles the byte-level transfer.

Server-Side Components

The server mirrors that split with two components:

1. Server Control Process — accepts incoming client connections, verifies usernames and passwords, interprets incoming commands, and returns numeric response codes (for example, 230 for a successful login or 550 for "file not found").
2. Server Data Transfer Process — handles the actual movement of bytes: sending requested files, accepting uploads, and returning directory listings once the control process has approved the request.

Authentication

Most FTP servers require a username and password before granting access to the file system. Many public FTP archives also support anonymous login, where the username is literally anonymous and the password is typically an email address or left blank — intended for distributing files that anyone should be able to download without a dedicated account.

Example: A Typical FTP Session

A simplified exchange between a client and server, over the control connection, looks like this:

Client connects to server on port 21
Server: 220 Welcome to ExampleFTP server
Client: USER alice
Server: 331 Password required
Client: PASS ********
Server: 230 Login successful
Client: PWD
Server: 257 "/home/alice" is current directory
Client: LIST
Server: 150 Opening data connection for directory listing
          (directory contents sent over a separate data connection)
Server: 226 Transfer complete
Client: RETR report.pdf
Server: 150 Opening data connection for report.pdf
          (file bytes sent over the data connection)
Server: 226 Transfer complete
Client: QUIT
Server: 221 Goodbye

Notice how every command (USER, PASS, LIST, RETR) and its numeric response travels over the control connection, while the directory listing and the file itself each triggered a brief, separate data connection. This is the control/data split in action, not just a diagram abstraction.

Applications of FTP

• Website deployment — uploading HTML, CSS, JavaScript, and image files from a local machine to a web host.
• Software distribution — many Linux distributions and open-source projects host installers and packages on FTP mirrors.
• Data backup — organizations push backup archives to a remote FTP server as part of disaster-recovery planning.
• File sharing between organizations — exchanging invoices, reports, and other documents between businesses or branch offices.
• Cloud storage migration — many cloud storage providers expose an FTP interface specifically to make bulk migration and synchronization easier.

Advantages and Disadvantages

The security weaknesses are the main reason plain FTP has fallen out of favor for anything involving credentials or sensitive files — FTPS (FTP layered over TLS) and SFTP (an entirely different protocol that tunnels file transfer over SSH) both address this by encrypting the session, while keeping a broadly similar command-and-response model for the user.

Common Mistakes

• Assuming FTP is secure by default. Plain FTP sends credentials and file contents unencrypted. Anyone on the same network segment can potentially capture them. Use FTPS or SFTP whenever the connection isn't fully trusted.
• Not accounting for active vs. passive mode when a connection "hangs." A client that connects and authenticates but then fails during a directory listing or transfer is often hitting a firewall/NAT problem with active mode — switching the client to passive mode frequently resolves it.
• Leaving anonymous login enabled unintentionally. Anonymous access is useful for public file distribution but should never be enabled on a server that also stores private data.
• Confusing port 20 and port 21. Port 21 is always the control connection; port 20 is only used for the data connection in active mode, and isn't involved at all in passive mode.

Related Concepts

• FTPS — FTP with a TLS/SSL layer added for encryption, while keeping FTP's original command structure and the control/data connection model.
• SFTP — SSH File Transfer Protocol: despite the similar name, this is a different protocol built on top of SSH, using a single encrypted connection rather than FTP's control/data split.
• HTTP/HTTPS — increasingly used for simple file downloads from browsers, though it lacks FTP's native support for directory browsing and remote file management.

Key Points to Remember

• FTP stands for File Transfer Protocol and operates at the application layer.
• It follows a client-server architecture and runs over TCP for reliable delivery.
• FTP uses two separate TCP connections: a control connection (port 21) and a data connection (port 20 in active mode).
• It supports uploading, downloading, renaming, deleting, and otherwise managing files and directories on a remote server.
• Traditional FTP transmits credentials and data in plain text, which is why FTPS and SFTP are preferred whenever security matters.