Hacker News Reader

Comment by bartwe | Hacker News Reader

Exhausting ports or generating a lot of TIME_WAIT states would also cause similar problems. How to protect against those ?

View on HN

There are two ways to avoid getting TIME_WAIT states in the first place:

1. Convince the client to close the connection. The initiator of the close will be the one holding the TIME_WAIT socket (for ~2 minutes)

2. Send RSTs to clients that refuse to close. RST avoids creating a TIME_WAIT state. I think this is slightly more dangerous than a normal FIN close, because wandering duplicates could interfere with the next connection. From Python, you can close a TCP socket in a way that causes a RST to be sent:

  # Set SO_LINGER to 1,0 which, by convention, causes a 
  # connection reset to be sent when close is called, 
  # instead of the standard FIN shutdown sequence. 
  self.socket.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, 
      struct.pack("ii", 1, 0))

(From the patches and branch in http://twistedmatrix.com/trac/ticket/78)

You'll be hard-pressed to exhaust all ports: modern operating systems track connections by source address + source port + target address + target port. I wouldn't be surprised if the TCP sequence number is also part of the mix.

TIME_WAIT times can be tweaked with the net.ipv4.tcp_tw_recycle and net.ipv4.tcp_tw_reuse sysctls, on Linux systems anyway.

Exactly, you can only really exhaust the ports from the server address/port to your single host, which is effectively only DoSing your own access to the server. Ive seen over a million sockets in time_wait and it did not effect the servers.

However if doing something like behind a single software load balancer then the number of ports available will be limited to the 65k connections since the source address/port and target address(the lb) are fixed.

Running out of ports is a poor way to put it, but it can be read as "Run the target machine out of fd (file descriptors)." In unixy systems there is a system parameter limiting the maximum number of file descriptors that can be open at one time (actually 2, per-proces and system-wide limits). These limits need to be turned up for big servers.

The why is a pretty boring story: the number exists as a check against runaway processes or big jobs (e.g. busy servers) causing an I/O overload, so the numbers are set to a "reasonable value" by default. Of course the reasonable value is usually much lower than the system can handle, and at tuned for older common hardware.

I seem to recall that there are five numbers involved: Source address, source port, target address, target port, and a fifth number. I want to say it's the file descriptor, but that just sounds wrong when I type it out.

Reply on news.ycombinator.com