From: Roy T. Fielding Date: Thu, 30 Jan 1997 00:48:31 +0000 (+0000) Subject: Adjusted some of the explanations of the FIN_WAIT_2 problems to X-Git-Tag: APACHE_1_2b7~19 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=5ea9107c1cb40311f07c1522f9cbdf727b0ac639;p=apache Adjusted some of the explanations of the FIN_WAIT_2 problems to accurately reflect the current status, reasons why it occurs, and what client authors should be doing. Also reformatted my mail message appendix so that it is applicable to a non-Apache audience. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@77533 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/misc/fin_wait_2.html b/docs/manual/misc/fin_wait_2.html index fe65c7c790..2911add76d 100644 --- a/docs/manual/misc/fin_wait_2.html +++ b/docs/manual/misc/fin_wait_2.html @@ -31,7 +31,7 @@ systems, a connection in the FIN_WAIT_2 state will stay around until the system is rebooted. If the system does not have a timeout and too many FIN_WAIT_2 connections build up, it can fill up the space allocated for storing information about the connections and crash -the kernel. The connections in FIN_WAIT_2 do not tie up a httpd +the kernel. The connections in FIN_WAIT_2 do not tie up an httpd process.

  • But why does it happen?

    • @@ -50,18 +50,23 @@ not send back a FIN and ACK to the server. This means that the connection stays in the FIN_WAIT_2 state until one of the following happens:

    If you are lucky, this means that the buggy client will fully close the connection and release the resources on your server. However, there -are many cases where things, such as a dialup client disconnecting from -their provider before closing the client, cause it to remain open. -This is a bug in the browser.

    +are some cases where the socket is never fully closed, such as a dialup +client disconnecting from their provider before closing the client. +In addition, a client might sit idle for days without making another +connection, and thus may hold its end of the socket open for days +even though it has no further use for it. +This is a bug in the browser or in its operating system's +TCP implementation.

    The clients on which this problem has been verified to exist:

    -It is expected that many other clients have the same problem.

    - -Apache can NOT do anything to avoid this other -than disabling persistent connections for all buggy clients, just -like we recommend doing for Navigator 2.x clients due to other bugs -in Navigator 2.x. As far as we know, this happens with all servers -that support persistent connections including Apache 1.1.x and -1.2.

    - -

    Something is broken

    +It is expected that many other clients have the same problem. What a +client should do is periodically check its open +socket(s) to see if they have been closed by the server, and close their +side of the connection if the server has closed. This check need only +occur once every few seconds, and may even be detected by a OS signal +on some systems (e.g., Win95 and NT clients have this capability, but +they seem to be ignoring it).

    + +Apache cannot avoid these FIN_WAIT_2 states unless it +disables persistent connections for the buggy clients, just +like we recommend doing for Navigator 2.x clients due to other bugs. +However, non-persistent connections increase the total number of +connections needed per client and slow retrieval of an image-laden +web page. Since non-persistent connections have their own resource +consumptions and a short waiting period after each closure, a busy server +may need persistence in order to best serve its clients.

    + +As far as we know, the client-caused FIN_WAIT_2 problem is present for +all servers that support persistent connections, including Apache 1.1.x +and 1.2.

    + +

    Something in Apache may be broken

    While the above bug is a problem, it is not the whole problem. -There is some other problem involved; some people do not have any -serious problems on 1.1.x, but with 1.2 enough connections build -up in the FIN_WAIT_2 state to crash their server. This is due to -a function called lingering_close() which was added +Some users have observed no FIN_WAIT_2 problems with Apache 1.1.x, +but with 1.2b enough connections build up in the FIN_WAIT_2 state to +crash their server. We have not yet identified why this would occur +and welcome additional test input.

    + +One possible (and most likely) source for additional FIN_WAIT_2 states +is a function called lingering_close() which was added between 1.1 and 1.2. This function is necessary for the proper -handling of PUTs and POSTs to the server as well as persistent -connections. What it does is read any data sent by the client for +handling of persistent connections and any request which includes +content in the message body (e.g., PUTs and POSTs). +What it does is read any data sent by the client for a certain time after the server closes the connection. The exact -reasons for doing this are somewhat complicated but involve what +reasons for doing this are somewhat complicated, but involve what happens if the client is making a request at the same time the -server closes the connection; without it, the client would get an -error. With it the client just gets the closed connection and -knows to retry. See the appendix for more -details.

    +server sends a response and closes the connection. Without lingering, +the client might be forced to reset its TCP input buffer before it +has a chance to read the server's response, and thus understand why +the connection has closed. +See the appendix for more details.

    We have not yet tracked down the exact reason why lingering_close() causes problems. Its code has been -thoroughly reviewed. It is possible there is some problem in the BSD -TCP stack which is causing this. Unfortunately, we are not able to -easily replicate the problem on test servers so it is difficult to -debug. We are still working on the problem.

    +thoroughly reviewed and extensively updated in 1.2b6. It is possible +that there is some problem in the BSD TCP stack which is causing the +observed problems. It is also possible that we fixed it in 1.2b6. +Unfortunately, we have not been able to replicate the problem on our +test servers.

  • What can I do about it?

    • There are several possible workarounds to the problem, some of which work better than others.

    +

    Add a timeout for FIN_WAIT_2

    -The obvious workaround is to simply have a timeout for the FIN_WAIT_2 -state. This is not specified by the RFC and could be claimed to be a -violation of the RFC, however it is becoming necessary in many cases. + +The obvious workaround is to simply have a timeout for the FIN_WAIT_2 state. +This is not specified by the RFC, and could be claimed to be a +violation of the RFC, but it is widely recognized as being necessary. The following systems are known to have a timeout: