📄 fin_wait_2.html.en
字号:
<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><!-- XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX This file is generated from xml source: DO NOT EDIT XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX --><title>Connections in the FIN_WAIT_2 state and Apache - Apache HTTP Server</title><link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" /><link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" /><link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /><link href="../images/favicon.ico" rel="shortcut icon" /></head><body id="manual-page"><div id="page-header"><p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p><p class="apache">Apache HTTP Server Version 2.0</p><img alt="" src="../images/feather.gif" /></div><div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div><div id="path"><a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs/">Documentation</a> > <a href="../">Version 2.0</a> > <a href="./">Miscellaneous Documentation</a></div><div id="page-content"><div id="preamble"><h1>Connections in the FIN_WAIT_2 state and Apache</h1><div class="toplang"><p><span>Available Languages: </span><a href="../en/misc/fin_wait_2.html" title="English"> en </a></p></div> <div class="warning"><h3>Warning:</h3> <p>This document has not been fully updated to take into account changes made in the 2.0 version of the Apache HTTP Server. Some of the information may still be relevant, but please use it with care.</p> </div> <p>Starting with the Apache 1.2 betas, people are reporting many more connections in the FIN_WAIT_2 state (as reported by <code>netstat</code>) than they saw using older versions. When the server closes a TCP connection, it sends a packet with the FIN bit set to the client, which then responds with a packet with the ACK bit set. The client then sends a packet with the FIN bit set to the server, which responds with an ACK and the connection is closed. The state that the connection is in during the period between when the server gets the ACK from the client and the server gets the FIN from the client is known as FIN_WAIT_2. See the <a href="ftp://ds.internic.net/rfc/rfc793.txt">TCP RFC</a> for the technical details of the state transitions.</p> <p>The FIN_WAIT_2 state is somewhat unusual in that there is no timeout defined in the standard for it. This means that on many operating 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 an httpd process.</p> </div><div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#why">Why Does It Happen?</a></li><li><img alt="" src="../images/down.gif" /> <a href="#what">What Can I Do About it?</a></li><li><img alt="" src="../images/down.gif" /> <a href="#appendix">Appendix</a></li></ul></div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="why" id="why">Why Does It Happen?</a></h2> <p>There are numerous reasons for it happening, some of them may not yet be fully clear. What is known follows.</p> <h3><a name="buggy" id="buggy">Buggy Clients and Persistent Connections</a></h3> <p>Several clients have a bug which pops up when dealing with persistent connections (aka keepalives). When the connection is idle and the server closes the connection (based on the <code class="directive"><a href="../mod/core.html#keepalivetimeout">KeepAliveTimeout</a></code>), the client is programmed so that the client does 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:</p> <ul> <li>The client opens a new connection to the same or a different site, which causes it to fully close the older connection on that socket.</li> <li>The user exits the client, which on some (most?) clients causes the OS to fully shutdown the connection.</li> <li>The FIN_WAIT_2 times out, on servers that have a timeout for this state.</li> </ul> <p>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 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. <strong>This is a bug in the browser or in its operating system's TCP implementation.</strong></p> <p>The clients on which this problem has been verified to exist:</p> <ul> <li>Mozilla/3.01 (X11; I; FreeBSD 2.1.5-RELEASE i386)</li> <li>Mozilla/2.02 (X11; I; FreeBSD 2.1.5-RELEASE i386)</li> <li>Mozilla/3.01Gold (X11; I; SunOS 5.5 sun4m)</li> <li>MSIE 3.01 on the Macintosh</li> <li>MSIE 3.01 on Windows 95</li> </ul> <p>This does not appear to be a problem on:</p> <ul> <li>Mozilla/3.01 (Win95; I)</li> </ul> <p>It is expected that many other clients have the same problem. What a client <strong>should do</strong> 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 (<em>e.g.</em>, Win95 and NT clients have this capability, but they seem to be ignoring it).</p> <p>Apache <strong>cannot</strong> 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.</p> <p>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.</p> <h3><a name="code" id="code">A necessary bit of code introduced in 1.2</a></h3> <p>While the above bug is a problem, it is not the whole problem. 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. The most likely source for additional FIN_WAIT_2 states is a function called <code>lingering_close()</code> which was added between 1.1 and 1.2. This function is necessary for the proper handling of persistent connections and any request which includes content in the message body (<em>e.g.</em>, 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 happens if the client is making a request at the same time the 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 <a href="#appendix">appendix</a> for more details.</p> <p>The code in <code>lingering_close()</code> appears to cause problems for a number of factors, including the change in traffic patterns that it causes. The code has been thoroughly reviewed and we are not aware of any bugs in it. It is possible that there is some problem in the BSD TCP stack, aside from the lack of a timeout for the FIN_WAIT_2 state, exposed by the <code>lingering_close</code> code that causes the observed problems.</p> </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div><div class="section"><h2><a name="what" id="what">What Can I Do About it?</a></h2> <p>There are several possible workarounds to the problem, some of which work better than others.</p> <h3><a name="add_timeout" id="add_timeout">Add a timeout for FIN_WAIT_2</a></h3> <p>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:</p> <ul> <li><a href="http://www.freebsd.org/">FreeBSD</a> versions starting at 2.0 or possibly earlier.</li> <li><a href="http://www.netbsd.org/">NetBSD</a> version 1.2(?)</li> <li><a href="http://www.openbsd.org/">OpenBSD</a> all⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -