Messages in this thread | | | Date | Sun, 12 Sep 2004 08:56:08 +0200 | From | Willy Tarreau <> | Subject | Re: Linux 2.4.27 SECURITY BUG - TCP Local (probable Remote) Denial of Service |
| |
Hi Peter,
On Sat, Sep 11, 2004 at 11:27:05PM -0700, Peter Zaitsev wrote:
> I do not care about TIME_WAIT connection on client site itself, what > concerns me is, until connection is not fully closed server side does > not seems to be informed connection is dead and so server resources are > not deallocated. > > Any ideas ?
TIME_WAIT status does not eat much resource, since they're in a separate list. I've already had several *millions* of while stressing some equipment, and I can assure you that it's really not a problem as long as you increase your tcp_max_tw_buckets accordingly. There is even no performance impact (I could still get 40000 hits/s with this number of time-waits). As David said, the connection has been closed when it enters TIME_WAIT, so it has been detached from apache.
I think you confuse it with CLOSE_WAIT. This is a very common case on web servers when the client does not support HTTP keep-alive and does a shutdown(WRITE) after sending its request. The server receives the FIN, and passes from ESTABLISHED to CLOSE_WAIT during all the time it sends its data to the client, then closes the connection, making it TIME_WAIT.
TIME_WAIT state is more annoying on the client side (eg when your apache is a reverse proxy), because by default you can run out of source ports. But you can increase the local source port range (ip_local_port_range), decrease the FIN timeout which also happens to control TIME_WAIT timeout, and even force tcp_tw_reuse to 1 to let the system reallocate an old connection which was sitting in TIME_WAIT.
Hoping this helps, Willy
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |