In protocol design, why would you ever use 2 ports?

Question

When a TCP Server does a socket accept on a port, it gets a new socket to work with that Client.
The accepting socket remains valid for that port and can accept further

Answer 1

IIRC, the issue wasn't that FTP uses two (i.e., more than one) ports. The issue is that the control connection is initiated by the client and the data channel was initiated by the server. The largest difference between FTP and HTTP is that in HTTP the client pulls data and in FTP the server pushes it. The NAT issue is related to the server pushing data through a firewall that doesn't know to expect the connection.

FTP's usage of separate ports for control and data is rather elegant IMHO. Think about all of the headaches in HTTP surrounding the multiplexing of control and data - think Trailing headers, rules surrounding pipelined requests, connection keep-alives, and what not. Much of that is avoided by explicitly separating control and data not to mention it is possible to do interesting things like encrypt one and not the other or make the control channel have a higher QoS than the data.

Answer 2

FTP has a very long history, being one of the first ARPANET protocols back in the early seventies (for instance, see RFC114 from 1971). Design decisions which may seem odd now made more sense then. Connections were much slower, and performing the connection control "out of band" probably seemed a good move with the available network technology.

The current RFC959 includes a good section on history, linking to earlier RFCs, if you fancy doing a little archaeology...

Answer 3

The IETF has banned the practice of allocating more than one port for new protocols so we likely won't be seeing this in the future.

Newer IP protocols such as SCTP are designed to solve some of the shortcommings of TCP that could lead one to use multiple ports. TCPs 'head-of-line' blocking prevents you from having multiple separate requests/streams in flight which can be a problem for some realtime applications.

Answer 4

Because FTP allows for separate control and data. IIRC, as originally designed, you could have 3 hosts: Host A could ask host B to send data to host C.

Answer 5

You should have a look at the RTSP + RTP protcol. It is a similar design : each stream can be sent on a different port, and statistics about jitter, reordering etc... is sent on yet another port.

Plus there is no connection since it is UDP. However it was developped when firewall where already something banal (sorry for my english), so a mode was developped where all this connection could be embedded in one TCP connection with HTTP syntax.

Guess what ? The multi port protocol is much simpler (IMO) to implement than the http multiplexed one and and it has a lot more features. If you are not concerned with firewall problem, why choose complicated multiplexing scheme when there is already one existing (TCP port)?

Answer 6

In my view, it's just a bad design choice in the first place. In the old ages where it was invented, firewall and NAT were not existing ... Nowadays, the real question is more "why people still want to use FTP" ? Everything FTP does can be done using HTTP in a better way.