Max Client TCP Ports?

forbin

New Member
Credits
33
65535 is often mentioned as the max number of TCP client ports on a single server. However, isn't that per local IP? Let's say I have a server with 5 IP addresses, and 5 processes, each communicating on a different IP. Since a socket consists of 4 elements (src_ip, src_port, dst_ip, dst_port) isn't it true that the server would have up to 65535 client ports for each process?
 


dos2unix

Well-Known Member
Credits
4,407
I suspect you mean sockets.

For example if you have 100 clients talking to a web server on port 80, it's still only one port.

The number of clients is kind of irrelevant.
Again using a web server as a example.

My web server only runs on one port on one IP address.
Apache may break down into sub processes, (child forks)
But all of those are controlled by one parent process. The number of processes
does not increase the maximum number of sockets I can have.

In reality, it's very unlikely that you will ever have 65000 clients talking to your web server
all at the same exact nano-second. Each connection spawns a new socket.

Also in reality most likely these are "usually" cached (static) data connections.
If the web page never changes, it doesn't have to read from disk every request, it'll read from cache.
If the web page is dynamic and changes frequently (say almost every connection)
Now you are limited by the I/O of the disk and and the network.

Now you could split this off into different ports.
Maybe I'm running 443 (https) and port 80 (http) now I could have more sockets in theory.

But I'm still limited by the bandwidth of my network, the bandwidth of my CPUs (more cores helps)
and the IOPs of my disks (RAID helps). So there is a very good chance you would start seeing
latency long before you saturated your sockets.

The way to get around this is clustering, but it's no longer a single process (i.e. port/IP address)
on a single computer.
 

forbin

New Member
Credits
33
Th
I suspect you mean sockets.

For example if you have 100 clients talking to a web server on port 80, it's still only one port.

The number of clients is kind of irrelevant.
Again using a web server as a example.

My web server only runs on one port on one IP address.
Apache may break down into sub processes, (child forks)
But all of those are controlled by one parent process. The number of processes
does not increase the maximum number of sockets I can have.

In reality, it's very unlikely that you will ever have 65000 clients talking to your web server
all at the same exact nano-second. Each connection spawns a new socket.

Also in reality most likely these are "usually" cached (static) data connections.
If the web page never changes, it doesn't have to read from disk every request, it'll read from cache.
If the web page is dynamic and changes frequently (say almost every connection)
Now you are limited by the I/O of the disk and and the network.

Now you could split this off into different ports.
Maybe I'm running 443 (https) and port 80 (http) now I could have more sockets in theory.

But I'm still limited by the bandwidth of my network, the bandwidth of my CPUs (more cores helps)
and the IOPs of my disks (RAID helps). So there is a very good chance you would start seeing
latency long before you saturated your sockets.

The way to get around this is clustering, but it's no longer a single process (i.e. port/IP address)
on a single computer.
Thanks for the feedback, but I think you misread my question or I asked it poorly. You're addressing the question from the perspective of the server, and in that sense you are correct. Thousands of clients all connect to the same server port (for example, port 443).

My question is from the perspective of the client, not the server, and it does make a difference. Imagine you have a workstation, and on that workstation you have a program (the "client," let's call it MyProgram) that connects to a remote server on port 9000 and holds open that connection. MyProgram opens a TCP session from the workstation's source IP and an ephemeral source port, to the server's destination IP and destination port. So far so good.

Now imagine MyProgram wants to open a second session to the same server. The new session will have the same source IP, destination IP, and destination port, but it will have a different ephemeral source port. This is normal TCP behavior.

Further, imagine that MyProgram wants to repeat this process thousands of times, keeping thousands of connections open to the same server. All the connections would have the same source IP, destination IP, and destination port, but each connection would have a different ephemeral source port (also called the client port).

MyProgram will eventually run out of available ephemeral source ports (65535), so the maximum number of connections MyProgram can make to the server and hold them open is 65535.

But wait... now suppose I add a secondary IP address to my workstation, and I launch a second instance of the client software which we'll call MyProgram2, and we tell MyProgram2 to bind to the secondary IP address. When MyProgram2 attempts to connect to the server, it will be using a different source IP, so does it get it's own set of 65535 client ports?
 
$100 Digital Ocean Credit
Get a free VM to test out Linux!

Staff online


Top