Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

found this:… – 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

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 Jul 10 '14 at 3:27
TCP port exhaustion is a simple attack for single server services; one public ip address can exhaust all available ports on a target server. Even with Idlensss detection it can bring down access to a system. Pooling doesn't help with this. – bond Jan 13 at 18:03

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.