The question is in the title. The reason I wonder this is because I'm coding an tcp service and would like to explore some of the reasons as they may shed some light on my work.

4 Answers 4


I expect that the use of a different port simplifies the handling of the separate expected data connection, which will be in a format different from the control connection. I believe this would allow the receiver to simply start processing the data without having to check if it was a connection initiation as would need to be done if it used port 21.

This would allow the last bullet's example of a linefeed printer start receiving text to print. However, I'm not sure how this was actually used back then (a program on the terminal would forward port 20 to their linefeed printer because there might be a FTP daemon already listening on 21?)

As for the why another connection, there's three primary reasons:

Efficiency of transfer is an important factor affecting the usefulness of FTP. File transfer may be very expensive (in terms of CPU time) and slow (in real-time) if an inappropriate transfer strategy is used (e.g., inappropriate byte size). Every attempt should be made to optimize transfer of data. A good strategy may be to allow transfer of files over a separate connection or close and reopen connections (using perhaps a different byte size).

[4] We considered using two full-duplex links, one for control
information, the other for data. The use of a separate control link
between the cooperating processes would simplify aborts, error
recoveries and synchronization.

It would be desirable to modify FTP to allow sending data to a specified socket in a specified mode and type. TIP users would then find it convenient to obtain listing of their files on a high-speed line printer, input their files from a card reader, and keep back-up on cards or magnetic tapes.

  • @sims I updated the answer with an attempt to actually answer the question about why another port (not just the data connection).
    – Rob Olmos
    Commented Nov 17, 2010 at 10:27
  • 2
    An important element of why why it was done this way can be seen by reading between the lines in RFC 114. FTP predates TCP/IP, and therefore it predates the concept of the complete separation of the Network, Transport, and Session layers! Originally the method to identify a single session was (essentially) to use IP + port. Therefore if you needed multiple connections (multisession) you needed a totally different socket for each session. While later developments resulted in the establishment of the Session layer, FTP is so old that it retains this ancient socket = session model.
    – Bacon Bits
    Commented Jun 2, 2011 at 4:09

Over-engineering might be the main reason.

One (not often used) advantage of the split control/data connections is that it is possible for the client to start a transfer between two servers without the data needing to pass through the client.

  • This is very interesting usage scenario. I did not know this was possible.
    – d-_-b
    Commented Nov 17, 2010 at 10:23
  • 1
    I once used the method (many would call it a hack - I don't know if it is an intended use of the protocol) to transfer a large file between servers I had FTP access to but no shell access (so I couldn't ftp directly from one to the other). At the time the servers could talk to to each other at ~0.5Mbit and I was stuck using a 28k8 modem so it made quite a time saving. It had to be done manually though - there were (and are to my knowledge still) no clients that support the trick. Commented Nov 17, 2010 at 14:42
  • That's too bad. I often thought that would be very handy rather than having to transfer it twice, esp. since most servers have a high bandwidth connection than homes and offices.
    – d-_-b
    Commented Nov 18, 2010 at 2:36
  • This technique is referred to as FTP 'Transloading'. May help you if you want to search for an app that will support it. Commented Nov 18, 2010 at 7:23
  • 2
    Never heard about Transloading. To me this is FXP.
    – petrus
    Commented May 28, 2011 at 11:25

Over-engineering is not the case. It was designed this way, so that different modes of operation are allowed. Active FTP is nowadays rarely used, because in this mode the server connects back to the client. But back then - in the 80s - it was working quite well. Passive FTP is very useful behind firewalls nowadays, in this mode the client connects to ports opened by the Server; the clients are usually not reachable directly anymore because they have a firewall/NAT/appliance in front of them. So this mode also makes sense.

The wikipedia article has nice, detailed info: http://en.wikipedia.org/wiki/FTP


FTP uses one port for data transmission (20) and other to send the commands (21), GET, DIR, PUT, etc...

A more thorough explanation can be found here: http://slacksite.com/other/ftp.html


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .