Mission

Download report.pdf, and count how many TCP connections it really takes.

ftp passive mode · two connections, both client-originated0 connections

control connection · port 21 · commands and numbered replies, never file bytes—

no session yet — open the control connection below

the two sockets · who dials whom, and on what port

control socket: 51120 → 21
who dials the data: the client
data socket: —
port from 227: —
file bytes on :21: 0
file bytes on :50000: —
credentials: —
next transfer: —

session_state

Data connection mode

idle · nothing connected

1Control connection open — port 21

2USER / PASS — in the clear

3PASV — "you pick a port, I will dial it"

4227 Entering Passive Mode (203,0,113,20,195,80)

5Second TCP connection — client dials :50000

6RETR report.pdf — 2.4 MB flows on the data connection

7226 Transfer complete — data connection closes

Think first · step 1 of 7

Nothing is connected yet. Which well-known FTP port does the client connect to first?

what just happened

Fetch one file and count the connections. The command channel and the file itself do not travel together, and the port the file uses is negotiated on the fly.

mode: passive · client will send PASV · client will originate both connections

the common mistake

“FTP is port 21.” Port 21 carries the conversation and not one byte of any file. Every transfer — every directory listing too — opens a second, separate TCP connection on a port nobody knew in advance.

That second connection is why FTP fights firewalls. In active mode the server dials the client — an unsolicited inbound connection, which is commonly what NAT and stateful firewalls block unless an FTP helper or explicit rule permits it. Passive mode makes the client originate both connections.

And it is all cleartext: USER and PASS travel exactly as typed, like the port-80 run in the HTTPS lab. SFTP and FTPS exist for this reason.