Take the 2-minute tour ×

How fast would one need to allocate ephemeral ports in order to get into the TCP port exhaustion condition?

I was told there are ~4k (older Windows), ~16k (newer Windows) or ~28k (RH Linux) ports available for the client requests. Now, is the pool of port numbers global or per remote IP address?

If they are global, since ports do not become reusable until after 240 (Windows) or 60 (RH Linux) seconds, one would need to allocate them at the rate of ~16/66/466 per sec correspondingly?

Is this correct?

In your experience, is this something I should be practically worried about?

share|improve this question

closed as not a real question by Mathias R. Jessen, mdpc, Sirex, Scott Pack, Ward Dec 1 '12 at 7:32


found this: serverframework.com/asynchronousevents/2011/01/… –  zvolkov Nov 29 '12 at 21:20
Yes, global, your numbers look generally correct. It can really happen. Note, on *nix systems there's usually a limit to the number of files/sockets a process can open (so that one process can't file/socket-bomb the whole computer) –  Chris S Nov 29 '12 at 21:21
add comment

2 Answers

DOS attacks apart, only with poorly written applications. The basic trick to avoiding TCP port exhaustion is connection pooling, for example HTTP keep-alive. This has several beneficial effects:

  1. Fewer connections per unit of time.
  2. The first close of a connection is usually done by the client, not the server. This moves the TIME_WAIT state from the server to the client, which is using far fewer sockets and ports and can therefore tolerate it much better.
share|improve this answer
Poorly written applications is what I'm married to :)) Thanks for your answer, but what I really am looking for is some hard math I can give to my boss to show how we are not vulnerable (or are, and when). –  zvolkov Nov 29 '12 at 20:52
You don't need math then really, you need monitoring. Start graphing your tcp port usage and give it to your boss. –  Sirex Nov 29 '12 at 20:55
Poorly written applications are not the only cause of TCP port exhaustion -- it's still a fairly common DoS technique against small sites. –  voretaq7 Nov 29 '12 at 21:21
@voretaq7 Agreed, edited. –  EJP 22 hours ago
add comment

Diito EJP and Sirex. Monitoring will give you a better understanding of where you stand. You can also tweak how long a socket is allowed to remain in a TIME_WAIT state. I've had to do this very thing on a system that talks to thousands of GPRS telemetry devices. They dial in, and consume ports like nobody's business. A more aggressive TIME_WAIT threshold has meant our (the) application is more stable.

There are some useful tools on MS Windows for monitoring port usage, e.g.: TCPView and ProcessExplorer (MS SysInternals). netstat -a can be slow when there are thousands of connections, so you can use netstat -an instead (this stops DNS resolution from occuring on the addresses). I can't vouch for Linux though....

share|improve this answer
add comment
