4

In the description of TCP in the Wikipedia, it is stated that

The number of sessions in the server side is limited only by memory and can grow as new connections arrive, but the client must allocate a random port before sending the first SYN to the server.

The first part seems logical: The server simply uses the port that the clients have connected to as the source port, and is thereby only limited by (number of client IPs) * (number of ephemeral client ports) - a big number.

But why can't the clients do basically the same thing? If socket A connects to server1 using ephemeral port 12345 (e.g. client:12345 -> server1:80), why can't socket B connect to server 2 by reusing the same source port (client:12345 -> server2:80)? That would allow more than (number of ports) outgoing TCP connections from a single host.

Is there something in the TCP specification that prohibits that kind of port reuse, or is the limitation only a practical result of common TCP implementations? If so, is the first case really handled in a different way than the second one, or is the number of incoming TCP connections on a single server port practically also limited to 65535?

To clarify, I'm looking for the theoretical (according to the specs) and practical (implementations; especially Linux) limits for:

  • Outgoing connections from a single client to ANY server/port. (client:* -> *:*)
  • Connections from a single client to the SAME server and port (client:* -> server:port) - this can obviously not be greater than 65535.
  • Incoming connections to a single server port from ANY client (*:* -> server:port) - I suspect this is greater than 65535 according to the quoted paragraph and the reasons stated above.
Improve this question
1

2 Answers 2

Reset to default
7

A tcp session is defined by all four parts of the address, and only all four parts in combination need to be unique.

So 

client ip : source port  -> server ip : destination port

Provided these are different from the next session, the next session is valid, even if it uses the same source port and client ip.

Whether this is possible in reality is dependent on implementation of both the networking stack of the OS and the TCP library being used.

Clearly for incoming connections, the incoming count can be far greater than 65535 - a busy website could easily have far more concurrency than 65000 connections.

Improve this answer
3
  • +1 But also, information about each connection must be stored by the Operating System, this usually takes about 1KB. While the IP:Port tuple gives a theoretical maximum of billions of connections, the practical RAM limits of simply keeping track of those connections would cap first.
    – Chris S
    Commented Nov 21, 2012 at 18:52
  • I already suspected that the practical limits are not imposed by the specs, but by the implementations - but I would like to learn those as well :)
    – lxgr
    Commented Nov 22, 2012 at 9:21
  • Ok, I've run some tests, and it seems that Linux doesn't allow source port reuse by default. When setting SO_REUSEADDR though, it is possible for the port to be reused! Of course, even then the connect() fails when connecting to the same host.
    – lxgr
    Commented Jan 15, 2013 at 18:44
0

Clients are limited by the network stack of the OS. It's unlikely that any operating system allows multiple processes to use the same source port in a socket connection. It is theoretically possible to allow unlimited connections even on existing client OSes using an intermediate service for known protocols such as HTTP similar to how HTTP.SYS works for multiple HTTP servers (in different processes!) on port 80 on Windows.

Improve this answer

You must log in to answer this question.

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