fin_wait_2.html.en

apache的软件linux版本

          versions(?)</li>

          <li><a href="http://www.bsdi.com/">BSD/OS</a> 2.1, with
          the <a href="ftp://ftp.bsdi.com/bsdi/patches/patches-2.1/K210-027">
          K210-027</a> patch installed.</li>

          <li><a href="http://www.sun.com/">Solaris</a> as of
          around version 2.2. The timeout can be tuned by using
          <code>ndd</code> to modify
          <code>tcp_fin_wait_2_flush_interval</code>, but the
          default should be appropriate for most servers and
          improper tuning can have negative impacts.</li>

          <li><a href="http://www.linux.org/">Linux</a> 2.0.x and
          earlier(?)</li>

          <li><a href="http://www.hp.com/">HP-UX</a> 10.x defaults
          to terminating connections in the FIN_WAIT_2 state after
          the normal keepalive timeouts. This does not refer to the
          persistent connection or HTTP keepalive timeouts, but the
          <code>SO_LINGER</code> socket option which is enabled by
          Apache. This parameter can be adjusted by using
          <code>nettune</code> to modify parameters such as
          <code>tcp_keepstart</code> and <code>tcp_keepstop</code>.
          In later revisions, there is an explicit timer for
          connections in FIN_WAIT_2 that can be modified; contact
          HP support for details.</li>

          <li><a href="http://www.sgi.com/">SGI IRIX</a> can be
          patched to support a timeout. For IRIX 5.3, 6.2, and 6.3,
          use patches 1654, 1703 and 1778 respectively. If you have
          trouble locating these patches, please contact your SGI
          support channel for help.</li>

          <li><a href="http://www.ncr.com/">NCR's MP RAS Unix</a>
          2.xx and 3.xx both have FIN_WAIT_2 timeouts. In 2.xx it
          is non-tunable at 600 seconds, while in 3.xx it defaults
          to 600 seconds and is calculated based on the tunable
          "max keep alive probes" (default of 8) multiplied by the
          "keep alive interval" (default 75 seconds).</li>

          <li><a href="http://www.sequent.com">Sequent's ptx/TCP/IP
          for DYNIX/ptx</a> has had a FIN_WAIT_2 timeout since
          around release 4.1 in mid-1994.</li>
        </ul>

        <p>The following systems are known to not have a
        timeout:</p>

        <ul>
          <li><a href="http://www.sun.com/">SunOS 4.x</a> does not
          and almost certainly never will have one because it as at
          the very end of its development cycle for Sun. If you
          have kernel source should be easy to patch.</li>
        </ul>

        <p>There is a <a href="http://www.apache.org/dist/httpd/contrib/patches/1.2/fin_wait_2.patch">
        patch available</a> for adding a timeout to the FIN_WAIT_2
        state; it was originally intended for BSD/OS, but should be
        adaptable to most systems using BSD networking code. You
        need kernel source code to be able to use it.</p>

    

    <h3><a name="no_lingering" id="no_lingering">Compile without using
                             <code>lingering_close()</code></a></h3>

        <p>It is possible to compile Apache 1.2 without using the
        <code>lingering_close()</code> function. This will result
        in that section of code being similar to that which was in
        1.1. If you do this, be aware that it can cause problems
        with PUTs, POSTs and persistent connections, especially if
        the client uses pipelining. That said, it is no worse than
        on 1.1, and we understand that keeping your server running
        is quite important.</p>

        <p>To compile without the <code>lingering_close()</code>
        function, add <code>-DNO_LINGCLOSE</code> to the end of the
        <code>EXTRA_CFLAGS</code> line in your
        <code>Configuration</code> file, rerun
        <code class="program"><a href="../programs/Configure.html">Configure</a></code> and rebuild the server.</p>

    

    <h3><a name="so_linger" id="so_linger">Use <code>SO_LINGER</code> as 
                an alternative to <code>lingering_close()</code></a></h3>

        <p>On most systems, there is an option called
        <code>SO_LINGER</code> that can be set with
        <code>setsockopt(2)</code>. It does something very similar
        to <code>lingering_close()</code>, except that it is broken
        on many systems so that it causes far more problems than
        <code>lingering_close</code>. On some systems, it could
        possibly work better so it may be worth a try if you have
        no other alternatives.</p>

        <p>To try it, add <code>-DUSE_SO_LINGER
        -DNO_LINGCLOSE</code> to the end of the
        <code>EXTRA_CFLAGS</code> line in your
        <code>Configuration</code> file, rerun
        <code class="program"><a href="../programs/Configure.html">Configure</a></code> and rebuild the server.</p>

        <div class="note"><h3>NOTE</h3>Attempting to use
        <code>SO_LINGER</code> and <code>lingering_close()</code>
        at the same time is very likely to do very bad things, so
        don't.</div>

    

    <h3><a name="increase_mem" id="increase_mem">Increase the amount of memory 
                           used for storing connection state</a></h3>

        <dl>
          <dt>BSD based networking code:</dt>

          <dd>
            BSD stores network data, such as connection states, in
            something called an mbuf. When you get so many
            connections that the kernel does not have enough mbufs
            to put them all in, your kernel will likely crash. You
            can reduce the effects of the problem by increasing the
            number of mbufs that are available; this will not
            prevent the problem, it will just make the server go
            longer before crashing. 

            <p>The exact way to increase them may depend on your
            OS; look for some reference to the number of "mbufs" or
            "mbuf clusters". On many systems, this can be done by
            adding the line <code>NMBCLUSTERS="n"</code>, where
            <code>n</code> is the number of mbuf clusters you want
            to your kernel config file and rebuilding your
            kernel.</p>
          </dd>
        </dl>

    

    <h3><a name="disable" id="disable">Disable KeepAlive</a></h3>

        <p>If you are unable to do any of the above then you
        should, as a last resort, disable KeepAlive. Edit your
        httpd.conf and change "KeepAlive On" to "KeepAlive
        Off".</p>

    
  </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="appendix" id="appendix">Appendix</a></h2>

   <p>Below is a message from Roy Fielding, one of the authors
   of HTTP/1.1.</p>

   <h3><a name="message" id="message">Why the lingering close 
                     functionality is necessary with HTTP</a></h3>

        <p>The need for a server to linger on a socket after a close
        is noted a couple times in the HTTP specs, but not
        explained. This explanation is based on discussions between
        myself, Henrik Frystyk, Robert S. Thau, Dave Raggett, and
        John C. Mallery in the hallways of MIT while I was at W3C.</p>

        <p>If a server closes the input side of the connection
        while the client is sending data (or is planning to send
        data), then the server's TCP stack will signal an RST
        (reset) back to the client. Upon receipt of the RST, the
        client will flush its own incoming TCP buffer back to the
        un-ACKed packet indicated by the RST packet argument. If
        the server has sent a message, usually an error response,
        to the client just before the close, and the client
        receives the RST packet before its application code has
        read the error message from its incoming TCP buffer and
        before the server has received the ACK sent by the client
        upon receipt of that buffer, then the RST will flush the
        error message before the client application has a chance to
        see it. The result is that the client is left thinking that
        the connection failed for no apparent reason.</p>

        <p>There are two conditions under which this is likely to
        occur:</p>

        <ol>
          <li>sending POST or PUT data without proper
          authorization</li>

          <li>sending multiple requests before each response
          (pipelining) and one of the middle requests resulting in
          an error or other break-the-connection result.</li>
        </ol>

        <p>The solution in all cases is to send the response, close
        only the write half of the connection (what shutdown is
        supposed to do), and continue reading on the socket until
        it is either closed by the client (signifying it has
        finally read the response) or a timeout occurs. That is
        what the kernel is supposed to do if SO_LINGER is set.
        Unfortunately, SO_LINGER has no effect on some systems; on
        some other systems, it does not have its own timeout and
        thus the TCP memory segments just pile-up until the next
        reboot (planned or not).</p>

        <p>Please note that simply removing the linger code will
        not solve the problem -- it only moves it to a different
        and much harder one to detect.</p>
    
  </div></div>
<div class="bottomlang">
<p><span>Available Languages: </span><a href="../en/misc/fin_wait_2.html" title="English">&nbsp;en&nbsp;</a></p>
</div><div id="footer">
<p class="apache">Copyright 2007 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
<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></div>
</body></html>