File Transfer Protocol

It uses a control connection for commands and a separate data connection for the bytes. The control side defaults to TCP port 21. The data side is negotiated per transfer.

That split is the part operators still trip over. The client sends USER, PASS, and a transfer command on the control connection. RETR pulls a file from the server. STOR pushes one to the server. The file itself moves on the data connection, which may be opened by the server back to the client (active) or by the client to a server port (passive). A firewall that allows port 21 and blocks the data port will authenticate and then hang. The login succeeded. The file did not move.

RFC 959 also separates type and structure. ASCII mode can translate line endings. Image, often called binary, copies bytes unchanged. Sending a ZIP or a video in ASCII mode corrupts it. The protocol will still report a completed transfer. The file will not open.

A vendor drops a 800 MB product feed on an FTP server at 02:00. A job uses passive mode, binary type, and RETR. The control session stays up for the whole copy. If the data connection dies at 500 MB, the client has a partial file and the server has no obligation under the base spec to resume it. Resume is a later convention (REST), not something you should assume from the 1985 text.

FTP is not SFTP. SFTP is a different protocol on SSH. FTP is not FTPS either. FTPS, specified in RFC 4217, is FTP with TLS on the control connection and usually on the data connection. Plain FTP sends the password and the file in the clear. Auditors flag anonymous FTP and cleartext credentials for that reason. A banner that says "secure FTP" is not a spec. Ask whether the session is FTP, FTPS, or SFTP, and which ports the data path uses.

People also say "FTP" for any file move. A browser upload is not FTP. An expiring link is not FTP. If there is no control connection and no STOR or RETR, you are describing file transfer in general, not this protocol.