From owner-freebsd-hackers Fri May 22 10:47:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA05675 for freebsd-hackers-outgoing; Fri, 22 May 1998 10:47:45 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from vnode.vmunix.com (vnode.vmunix.com [209.112.4.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA05663; Fri, 22 May 1998 10:47:30 -0700 (PDT) (envelope-from mark@vnode.vmunix.com) Received: (from mark@localhost) by vnode.vmunix.com (8.8.8/8.8.8) id NAA26223; Fri, 22 May 1998 13:54:55 -0400 (EDT) (envelope-from mark) Message-ID: <19980522135455.A26169@vmunix.com> Date: Fri, 22 May 1998 13:54:55 -0400 From: Mark Mayo To: Jim Shankland , tlambert@primenet.com Cc: hackers@FreeBSD.ORG, isp@FreeBSD.ORG Subject: Re: TIME_WAIT/FIN_WAIT_2... References: <199805221643.JAA01914@biggusdiskus.flyingfox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <199805221643.JAA01914@biggusdiskus.flyingfox.com>; from Jim Shankland on Fri, May 22, 1998 at 09:43:04AM -0700 X-Operating-System: FreeBSD 2.2.6-STABLE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, May 22, 1998 at 09:43:04AM -0700, Jim Shankland wrote: > [mark@vmunix.com (Mark Mayo) asks about large numbers of TCP connections > in TIME_WAIT and FIN_WAIT_2 states on a busy Web server. [in resonse to Terry's post, Jim writes:] > I suspect what you really mean is that the client side never sends its > FIN, even though it's really done sending, leaving the server-side > hanging in FIN_WAIT_2 state, waiting for either more data or a close > from the client, while the client wll never bother to send either.. > This can happen due to application-layer or TCP-layer bugs on the > client side, or because the client crashed or was powered off at an > inopportune time. Or IE 3.01 which just never sends it's FIN under "normal" conditions.. :-) > What BSD-based TCP stacks do is this: if the FIN_WAIT_2 socket has > been closed by the application (i.e., there's no-one there to receive > any data that might arrive), and no data arrives for about 11 minutes, > then the connection is silently dropped. (Remember, if the FIN_WAIT_2 > socket has not been closed, then data could arrive after an arbitrarily > long silence, and there's a process there to read that data; so the > connection *must not* be dropped.) > > So what you're really seeing, Mark, is connections in FIN_WAIT_2 state, > where the web server has closed the socket, but the client has never > indicated that it is done sending. These hang around for about 11 > minutes, then disappear. (Of course, more take their place.) Thanks. I read rfc793.txt which gives the definition. That combined with a review of the Steven's book about TCP closing handshakes brought me to the same conclusions. Very well stated though! Thanks for a super readable explantion. :-) > > The reason for the 11 minute wait is so that if the client is just > slow going through its shutdown stuff, the server can still walk the > client through an orderly close. On the other hand, maybe 11 minutes > is too long? I'll bet nothing terrible happens if that timeout drops > to 1 minute ... or 30 seconds. Even 0 would at worst lead to some > unnecessary RST's on closing connections. Anyone have any thoughts on > this? I'm thinking that setting it to 2MSL, like TIME_WAIT might be okay, and still relatively conservative. 4 minutes is not bad, and on a machine dedicated strictly to http shouldn't have any adverse affects. Anyone else have experience tweaking things like this to squeeze out extra http performance (apache BTW)?? I still think the ratio of TIME_WAIT/FIN_WAIT to ESTABLISHED is high, but apparently that's normal. Like I said, under previous machines I've seen doing fewer transfers, it wasn't nearly as bad.. Although I might not be able to do anything about it, it still irks me. 8-) -Mark > > Jim Shankland > Flying Fox Computer Systems, Inc. -- ------------------------------------------------------------------------ Mark Mayo mark@vmunix.com RingZero Comp. http://www.vmunix.com/mark finger mark@vmunix.com for my PGP key and GCS code ------------------------------------------------------------------------ "The problem is how do you build tools that understand your programs at a deeper semantic level." - James Gosling To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message