12/5/2023 0 Comments Ephemeral ports windowsStarting at least with Windows Server 2008 (and maybe with Windows Server 2003 after the security bulletin, I'm not sure), the dynamic port range is specified per protocol.Ĭheck it for each protocol with these commands:Ī typical recommendation for Microsoft Exchange 2007 systems was a dynamic port range of 1025 to 65535. That default range is still current through Windows Server 2012. Windows Server 2003 security bulletin MS08-037 hotfix introduced a new default dynamic port range from 49152 to 65535. In those versions, HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\MaxUserPort registry key could set a nondefault max dynamic port number. Since power was restored 20 minutes after power was lost, that means that 3 out of 4 new connections will be waiting - either for one of the other new connections to terminate and the port becomes available, or for the remaining default 1 hour and 40 minutes until idle connections from the power loss are terminated.įor Windows version up to and including Windows Server 2003, the default dynamic port range was 1025 to 5000. Of the new connections, only 1/4 will succeed until hitting the dynamic port limit. That's 160% of the available dynamic ports. Assume that many connections will be attempted again when those client servers come back on line 20 minutes after the power loss. Assume the number of connections at the time of power loss was 80% of the available dynamic ports. They aren't terminated immediately, they need to go through TCP timeout protocol. All of the connections on the 'server' server are now idle. So, here's where I've typically seen this come into play in an OLTP setting:Ī power outage drops large number of Citrix or web servers from a client server farm. By default, that will take more than 2 hours. Here's another thing to add to the mix: if a connection isn't properly closed, whether due to the connection being severed between client code and server code (power outage, switch crash or even intrusion prevention), the connection may need to time out as an idle connection before its terminated. A crazy web service could keep the connection inflow rate equal to the port available rate for a long time, leading to lots of connection failures. That's because of the amount of time that a port will wait in the TIME_WAIT state after closed, before it can be reused. If it closes the connections, there could still be a problem. If it keeps those connections open, as long as they are open no more connections for that protocol will succeed. If a web service goes crazy and starts gobbling up dynamic ports, all available dynamic ports can get chewed up real fast. But the main concepts involved are the limited number of dynamic ports on the client and/or server, the amount of time to terminate idle connections, and the amount of time before a "closed" dynamic port can be reused. What can lead to port exhaustion? I'll only give a few examples here. If dynamic ports are used on the client and server side of the connections, port exhaustion could occur on the client or server system. Port exhaustion occurs when there are no available dynamic ports for new connections. FTP is an example of server activity which uses dynamic ports. Some server activities use dynamic ports as well: a communication request initially arrives on a specific server port listener, and the client connection is handed off to a dynamic server port. The maximum number of connections from that client is then limited to the number of dynamic ports. Dynamic ports are also known as ephemeral or anonymous ports.Ĭlient communication will often use an available dynamic port on the client system to begin communication with a specified port on the server. I recommend evaluating the idle connection and TIME_WAIT behavior regardless, from a best practice standpoint.Ĭlient/server communication typically relies on dynamic ports. If you want to evaluate a particular delayed/rejected connection situation for port exhaustion, the Powershell script at the following location is a great place to start: That might still be true once I publish this blog post :) At least it'll be here for me to refer to in the future :) But, here I'll just describe the Windows details.Īlthough I've seen sources discuss Windows idle connection termination behavior, and other sources discuss TIME_WAIT delay status, and still other sources discuss port exhaustion, I can't think of a single place that I saw all of those concepts tied together in a neat little bundle. I first became familiar with port exhaustion and idle connection behavior by recommending intervention and eventually writing up some best practices for a tiered database architecture on AIX and HP-UX systems. Port exhaustion is far from unique to Windows.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |