The limit is 65k connections per client IP address, limited by the number of available ports on the client. You can theoretically accept connections from all possible client IP addresses simultaneously.

This means that in order to test 1M simultaneous connections, you would need to use at least 16 client IP addresses. Probably more.

As a fun aside, you can do this on localhost by defining additional addresses tied to the loopback interface:

    127.0.0.2
    127.0.0.3
    etc.

I once had to test a piece of software that identified its connections by the source IP, so I had a script to create thousands of loopback addresses within 127.0.0.0/8 and then run against that software and verify the connections were doing what they were supposed to do. (This was on Mac OS X.)

And most linux distros limits the ephemeral range even further to about 30K ports If you take a deeper look, the solution uses Docker to connect clients from different network namespaces to mitigate this

This comment appears routinely on HN. I'd love to find out how something so basic about TCP came to be so widely misunderstood.

Because almost everyone tests with one client IP and one server IP.

The limit is only between a single client and server ip, since there can only be up to 65k source port/ip pairs (assuming the destination port is a single port, which it seems to be in the code examples). So if there are multiple client ips it seems like it's not an issue.

https://stackoverflow.com/a/2332756

An open connection is identified by all 4 values of the unique tuple source IP, source port, destination IP, destination port.

Deep down, the key for a connection is the concatenation of SA DA SP DP. DA and DP are constant for a given service in the simple case and the others are 4 octets [although not all of it usable] for IPv4 and 2 octets (for port).

UNIX sockets can help.

How?