Wouldn't it be that clients behind a NAT might end up attempting to connect from the same source address:port (the NAT box), or a load balancer would make conne

Wouldn't it be that clients behind a NAT might end up attempting to connect from the same source address:port (the NAT box), or a load balancer would make connections all from the same address? i.e. when you have to deal with NAT, there's a nonzero possibility of a customer getting an error simply because your app is popular and their ISP has run out of IP's and ports. Or when you don't have to deal with NAT directly, you're limited to ~60k incoming connections per minute which may not be enough. The article suggests listening on more ports so incoming connections are not all on the same port. I have my doubts that will work. (User-hostile to expect users to add a port number to the URL, or non-standard ports only used for automated connections which limits the scope of the solution.) If behind a load balancer, assigning more IPs to the server is easy since they're not public IPs, so that seems like a good solution. On the other hand, the article hints at two really good solutions: 1. End the connection with a RST instead of a clean close(). Yes, the other side will see an error at that point but I wonder if browsers wouldn't just silently ignore that after receiving the entire response? 2. Definitely won't work for browsers, but if the client does the close() call then the client gets to handle the TIME-WAIT and the server can recycle ports as fast as it wants. P.S. With IPv6 assigning more public IPs is a great solution.