Table of Contents
Introduction
File transfer is one of the oldest and most common uses of networks. Two classic ways to move files over IP networks are FTP and SFTP. Their names sound similar, but they are very different in how they work and how secure they are. This chapter focuses on what makes FTP and SFTP unique, how they behave on the network, and why SFTP is preferred today.
What FTP Is
FTP stands for File Transfer Protocol. It is an application layer protocol created early in the history of the internet to upload and download files between a client and a server.
An FTP setup usually has a dedicated FTP server. Users connect with an FTP client program, provide a username and password, then list directories, upload files, and download files. FTP can work interactively, where a human types commands, or in scripts and automated jobs.
Typical FTP server functions include user authentication, directory access control, and permission handling for who can read or write which files. From the perspective of networking, FTP is most famous for its unusual use of multiple TCP connections and for sending data in clear text.
FTP and TCP Ports
FTP always uses TCP, not UDP. There are two main TCP connections involved in classic FTP.
The first connection is the control connection. It is used for user login and commands like listing directories and telling the server to start a file transfer. By default, the server listens on TCP port 21 for this control connection.
The second connection is the data connection. It is used for sending actual file contents or directory listings. This connection uses a different port and can be initiated either by the server or by the client, depending on the FTP mode.
It is important to remember that for FTP you almost always see at least two TCP connections between the same client and server, one for control on port 21 and one or more for data on other ports.
FTP control port (default): TCP port 21
FTP uses separate control and data connections.
Active vs Passive FTP
FTP can operate in two main modes, active and passive. The difference is who opens the data connection and which ports are used. Both modes still use port 21 for the control connection.
In active mode, the client connects from a random high TCP port to the server on TCP port 21 to create the control connection. When the client wants to transfer data, it tells the server which client port to use for data. The server then opens the data connection from its TCP port 20 to the specified client port. This means that the server initiates the data connection back to the client.
In passive mode, the client again connects from a random high TCP port to the server on port 21 for the control connection. When a data transfer is requested, the client asks the server to enter passive mode. The server responds with an IP address and a port number where it will listen for the data connection. The client then opens the data connection from a random high port to that server port. In passive mode, both the control and data connections are initiated from the client to the server.
This difference becomes very important when firewalls and NAT are involved, because in active mode the server needs to be able to open a connection from the outside towards the client, while in passive mode the client always initiates both connections.
A short comparison is useful.
| Aspect | Active FTP | Passive FTP |
|---|---|---|
| Control connection | Client → server port 21 | Client → server port 21 |
| Data connection dir | Server → client | Client → server |
| Server data port | TCP port 20 | Random high port chosen by server |
| Firewall friendliness | Often problematic for clients behind NAT | Usually easier with NAT and firewalls |
FTP Commands and Data
FTP has its own command language that is exchanged on the control connection in plain text. Examples are commands to log in, change directories, list files, and initiate transfers.
A typical sequence over the control connection might be:
- Client connects to server on port 21.
- Server sends a greeting message.
- Client sends a command with a username.
- Client sends a password command.
- Client sends a command to list the current directory.
- Client sends commands to upload or download files.
The important networking aspect is that both commands and responses, including usernames and passwords, are sent unencrypted. Anyone with the ability to capture packets along the path can read credentials and filenames directly. This is one of the main reasons FTP is considered insecure on modern networks.
Security Limitations of FTP
FTP has no native encryption. It does not protect the confidentiality or integrity of the control commands or the data. Some of the key security problems are the following.
Usernames and passwords are sent in clear text on the control connection. File data contents are also sent in clear text on the data connection. Directory listings and filenames are visible to anyone sniffing the traffic.
Because FTP opens additional connections dynamically for data transfers, it can be more difficult to lock down with simple firewall rules. Firewalls need to track the FTP control connection and inspect it to understand which ports to allow, or use special application inspection features.
Over time, extensions like FTPS were introduced that add TLS encryption to FTP, but FTPS is different from SFTP and still keeps the basic two connection structure of FTP. In general, if encryption and security are required, modern designs strongly prefer SFTP instead of plain FTP.
What SFTP Is
SFTP stands for SSH File Transfer Protocol. Despite the similar name, SFTP is not FTP combined with SSH. It is a separate file transfer protocol that runs inside an SSH connection.
SFTP uses SSH to provide authentication, confidentiality, integrity, and encryption. When a client connects to an SFTP server, it first establishes an SSH session. Inside that SSH session, SFTP messages are exchanged to perform file operations like listing, uploading, downloading, renaming, and deleting files.
SFTP clients and servers are commonly implemented as part of SSH software. For example, when you enable SSH on a server, you can often enable SFTP at the same time without running a separate service on a different port.
SFTP and TCP Ports
SFTP uses only one TCP connection. This is a major difference from classic FTP.
By default, SFTP uses the same port as SSH, which is TCP port 22. The client opens a TCP connection to server port 22. The SSH handshake occurs, the user is authenticated, then an SFTP subsystem is started inside that single encrypted session.
All SFTP commands and all file data travel over that one encrypted TCP connection. There is no separate data channel, and there is no need to open extra ports for each transfer.
SFTP default port: TCP port 22
SFTP uses a single encrypted connection inside SSH.
This simple port usage makes SFTP far easier to handle with firewalls and NAT devices. Network administrators usually only need to allow outbound connections to TCP port 22 on servers that accept SFTP.
Security Characteristics of SFTP
SFTP inherits its security from SSH. SSH provides strong encryption, authentication, and integrity checks for the session. As a result, every part of the SFTP communication is protected.
Usernames and passwords, or SSH keys, are exchanged securely. File names, directory structures, and file contents are all encrypted while in transit. Attackers who capture SFTP packets see only encrypted data and cannot read the clear contents.
SSH also supports public key authentication, which allows SFTP clients to authenticate without sending a password. Instead, the client proves possession of a private key that matches a public key trusted by the server. This is often used for automated SFTP backups and batch jobs.
Because SFTP is strongly encrypted and authenticated, it has become a standard choice for secure file transfer in many organizations.
FTP vs SFTP on the Network
From a network behavior perspective, FTP and SFTP differ in many ways. The following table summarizes the main differences that matter to a network engineer.
| Feature | FTP | SFTP |
|---|---|---|
| Protocol name | File Transfer Protocol | SSH File Transfer Protocol |
| Underlying protocol | Own protocol over TCP | Runs on top of SSH |
| Default TCP port | Control on 21, data often from 20 or random ports | 22 |
| Connections used | Separate control and data connections | Single connection |
| Encryption | None by default | Encrypted by SSH |
| Authentication | Clear text passwords | Encrypted passwords or SSH keys |
| Firewall handling | More complex, dynamic data ports | Simple, usually only port 22 |
| Security level | Low | High |
From the point of view of firewalls and NAT, FTP often requires special helpers that inspect the control connection to dynamically open the correct ports. SFTP traffic, in contrast, is like any other SSH connection. It uses one port, one flow, and is easy to allow or block.
Typical Use Cases
FTP, especially plain FTP without encryption, is less and less common on the open internet because it exposes credentials and data. You may still see FTP in closed internal networks where legacy systems are in use, or in simple anonymous download sites where no authentication is required and the data is not sensitive.
SFTP is widely used wherever secure file transfer is needed. Common scenarios include automated backups to a remote server, secure log collection, moving data between business partners, and transferring files into or out of cloud environments.
Many modern managed file transfer solutions use SFTP behind the scenes while providing friendly graphical interfaces to users. In such cases, the user may not even know that SFTP and SSH are in use, but network traces will clearly show encrypted traffic to TCP port 22.
Performance and Overhead
FTP sends data without encryption, so in pure throughput terms, it can be slightly more efficient than SFTP, which must perform encryption and decryption on both ends. However, on modern hardware and typical network speeds, this difference is usually small.
SFTP has an overhead in CPU usage because of encryption. This overhead becomes visible only at very high transfer rates or on very low power devices. In most enterprise networks, the security benefits of SFTP far outweigh this small performance cost.
For network planning, both FTP and SFTP consume bandwidth proportional to the file sizes transferred. Encryption does not change the fundamental data size by much, although there may be some extra protocol headers and padding.
Practical Considerations for Beginners
When you see traffic to TCP port 21 with separate data flows, you are probably observing FTP. When you see traffic to TCP port 22 with encrypted payloads and no separate data connections, it may be SSH terminal sessions, SFTP transfers, or other SSH based services.
If you need to allow users to transfer files across a firewall, SFTP is usually the preferred choice. You allow TCP port 22 to the SFTP server, and then manage authentication and access on the server side. With FTP, you might need more complex firewall rules or an application aware firewall that can understand FTP commands.
For internal labs and learning environments, experimenting with both FTP and SFTP helps you see the difference in packet captures. FTP captures reveal clear text commands and data, while SFTP captures show almost nothing readable because everything is encrypted.
Summary
FTP and SFTP both move files, but they behave very differently on the network. FTP uses separate control and data connections, operates mostly on TCP ports 21 and 20, and has no built in encryption. SFTP runs inside SSH on TCP port 22, uses a single encrypted connection, and provides secure authentication and data transfer.
In modern networks, SFTP is usually the default choice for secure file transfers, while FTP remains mostly for legacy or non sensitive use cases. Understanding the differences in ports, connections, and security helps you configure firewalls, analyze traffic, and choose the right protocol for a given scenario.