Date: Fri, 22 May 1998 13:54:55 -0400 From: Mark Mayo <mark@vmunix.com> To: Jim Shankland <jas@flyingfox.com>, tlambert@primenet.com Cc: hackers@FreeBSD.ORG, isp@FreeBSD.ORG Subject: Re: TIME_WAIT/FIN_WAIT_2... Message-ID: <19980522135455.A26169@vmunix.com> In-Reply-To: <199805221643.JAA01914@biggusdiskus.flyingfox.com>; from Jim Shankland on Fri, May 22, 1998 at 09:43:04AM -0700 References: <199805221643.JAA01914@biggusdiskus.flyingfox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980522135455.A26169>