[tilolebo]

> considering that a single server can easily handle a million simultaneous connections

Can you elaborate on that part?

[joisig]

Not the GP but they might be referring to [0] or one of several other articles you will find if you Google "handle a million connections in *".

Realistically you also usually need to perform some non-trivial work from time to time for some non-trivial portion of those connections, which will further load your server, but still.

[0] https://phoenixframework.org/blog/the-road-to-2-million-webs...

[crgwbr]

Genuinely curious on this—with port numbers only being 16 bits, how is it possible for one machine to ever handle more than 65k concurrent connections?

[pipe_connector]

Connections must have unique IP:Port pairs between client and server. You're limited to 65K concurrent connections for the same client. In practice, no one is opening that many connections from a single client.

[dtjohnnymonkey]

You might run into this limitation more quickly if you are receiving connections via a load balancer.

[adra]

As such, the load balancer itself can probably hold a group of source IPs to use as second-hop solution to this problem as well if we're sincerely talking about load balancers holding a ton of largely idle connections simultaneously.

The more likely load balancer outcome would be DNS split on inbound client IPs, and scaling out until each load balancer handles the appropriate amount of traffic (by some measure and scale out if exceeded).

[NavinF]

Only for L4 load balancers. L3 (switches doing ECMP) won’t modify source IP and L7 (e.g. nginx) will reuse TCP connections to the backend servers.

[dxhdr]

A connection is the tuple {source_ip, source_port, dest_ip, dest_port}

[alduin32]

For outbound connections, it can be done using multiple IP addresses.