A connection isn't just a dest_port, it's the unique combination of 4 components: source_ip:source_port:dest_ip:dest_port

I would guess they may be muxed over fewer sockets, by their LBs, but that's not strictly necessary.

I'm not sure exactly what you mean by "run out of TCP sockets", but theoretically speaking, the only limitation is how much memory is available to store the necessary info about the socket (like address/protocol info and process info).

In practice, OS's do have a "max socket" or "max FD" limit, but that's usually configurable and (with enough RAM) could easily be set to "millions".

> I'm not sure exactly what you mean by "run out of TCP sockets", but theoretically speaking, the only limitation is how much memory is available to store the necessary info about the socket (like address/protocol info and process info).

Probably the 65k port limit since each connection will get assigned a remote port, which can be solved by binding to multiple local ports and using a load balancer in front or using multiple network interfaces.

The 65k limit is per client address and port. Each client can have 65,535 connections to a single port on your server from each and every 65,535 of their own ports. (65,536? I dunno what would actually happen if you tried to use port 0.)

That would be the end of the Internet.

You can have more than one connection per port, so you don't even need the load balancer or more interfaces! :)

On my default Ubuntu install, the hard limit for open files of a process is 1048576 (ulimit -Hn). So you you have to run a handful of processes.

socket multiplexing