Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Possible Duplicate:
Why was the FTP protocol designed to use more than one port?

I know FTP uses two ports, one for commands and other for data transfer. Is there any specific reason or any advantage provided by the use of two ports. I mean, there must have been some reason that the two ports were chosen.

share|improve this question

marked as duplicate by RobM, John Gardeniers, gravyface, EEAA, Ward Jun 2 '11 at 3:40

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

If you want one port, then you can use SFTP (not FTPS). Check out . – djangofan Jun 1 '11 at 17:25
@djangofan, SFTP has almost nothing to do with FTP; it's a different transfer protocol implemented over SSH with commands vaguely similar to FTP. – Chris S Jun 1 '11 at 17:30
@Chris S - thats obvious. the guy that asked this question didn't seem to care about the protocol... what he seemed to want was a single-port solution (given by the fact that he was asking why there had to be 2 ports). rather than be argumentative, try to be helpful to the question. – djangofan Jun 6 '11 at 21:40
@djangofan; The question seems to be asking "Is there any specific reason or any advantage provided by the use of two ports". Nowhere in the Question did he ask for or imply that he was seeking "a single-port solution". Perhaps that is what he meant to ask, but it is most certainly not the what he asked. – Chris S Jun 7 '11 at 2:17

In order to avoid the extra headers and details for each and every packets which will consume the bandwidth. A separate port is used for data connection.


share|improve this answer
Which headers, i mean they both are same connections over TCP, i think the only the difference is the port numbers. – Ankit Jun 1 '11 at 17:27
@Ankit - if everything was over the same connection you would need extra protocol headers to differentiate between data and commands. – JimB Jun 1 '11 at 18:30
The control and data connections are going to have Ethernet, IP, and TCP headers so what "extra" headers are you referring to? – joeqwerty Jun 1 '11 at 23:31
@Joe, if control and data were comingled, there would have to be an extra header so the client would know which each packet is. The server doesn't always know ahead of time the size of the transfer (particularly with text transfers, where FTP translates the character encoding and endianess). To keep the protocol simple, data and control were separated; control notifies the client when a transfer starts and is done, so that data doesn't have to be encoded in some sort of additional header. – Chris S Jun 2 '11 at 0:46
@Chris S: But it wouldn't actually be an extra header would it? It would have to be a specific sequence of characters in the data portion (payload) of the packet that would be interpreted as a control command as opposed to being interpreted as data. I mean, there's no such thing as an FTP header, right? – joeqwerty Jun 2 '11 at 1:52

The wiki article above seems to have the port numbers a bit messed up :)

FTP uses 21 for control and 20 for data in active mode or a random port in passive mode.

It may have bandwidth impications but I believe one of the main reasons is to allow the control channel to be used during transfers. If you have a decent FTP client that queues transfers you may notice you can still browse the folders while it transfers. I believe it's also possible for the client to notify the server it wants to cancel an in-progress transfer.

share|improve this answer
Note that there isn't a single data connection. Anytime data is being transferred it opens a new data connection (eg listing directory contentds, down/uploading files). Also, active mode connections the Server opens (from port 20) the connection to the Client (to a negotiated port); in passive mode the Client opens (from a random port) the data connection to the Server (again to a negotiated port). – Chris S Jun 1 '11 at 17:26
Sounds reasonable but FTP seems to be a very old protocol and i assume that back then, they only did ftp through command line. – Ankit Jun 1 '11 at 17:33
@Ankit You can transfer in the background from the command line. NcFTP has "bgget" and "bgput" commands, for instance: – Gerald Combs Jun 1 '11 at 18:08
@Ankit, as Gerald said, even quite old command line FTP clients could do multiple transfers simultaneously. This was a side effect, the purpose was to simplify each of the two parts, command and data. Back in the day, it was very common for two systems to use different character encoding, endianess, etc; so when transferring a text file FTP would translate as appropriate for the destination system, this meant the length of the data wasn't known before the transfer started; if command and data were together signaling would have to be added to every packet so the client would know which it was. – Chris S Jun 2 '11 at 0:43

I believe it's due to the fact that the client can initiate a data transfer between 2 servers instead of between the client and the server. The client maintains a control connection to both servers while the servers maintain a data connection between themselves.

share|improve this answer
That's the FXP extension to FTP, the functionality wasn't part of the original protocol. – Chris S Jun 2 '11 at 0:37
@Chris S: I can't seem to find anything in the original FTP RFC (114) that specifies the use of 2 ports or the reason for it other than a reference in the Endnotes to RFC 103, which dicusses NCP communications and the problem of not having enough buffer space on the receiving host to accept a control command if the data and control ports are not separated, which you seem to be implying in your comment to my comment to samarudge's answer. Am I on the right track? – joeqwerty Jun 2 '11 at 1:30
I'd edit your answer to reflect that re: potentially not having enough buffer space; sounds like a reasonable explanation. – gravyface Jun 2 '11 at 2:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.