httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kiwi.ICS.UCI.EDU>
Subject Re: [PATCH] lingering_close performance improvement
Date Mon, 10 Feb 1997 09:01:35 GMT
>It's a shame how buggy browsers can cause Apache to implement a
>function that slows performance and kills machines unless OS
>makers patch their stacks to enable a FIN_WAIT_2 timeout...
>Doesn't this seems like a LOT of trouble to go thru? We are
>jumping through hoops and making OS vendors do the same to work around
>buggy browsers... This, to me, seems incredibly warped.

Seems like normal to me.  Both Netscape and Microsoft are incredibly
selfish, lazy, arrogant, and brain-numbingly shortsighted organizations.
In other words, they are just like their customers.  The fact that other
Internet products can interoperate without going through hoops is
solely due to the cooperation of other Internet software developers
and not due to any great robustness in the HTTP/TCP/IP protocols.

However, there is nothing new here -- these problems are well-known in
the IETF and are supposed to be fixed in the TCP API.  In fact, they
would be fixed, if it wasn't for the bugs in all the operating systems
that are equally hopeless when it comes to implementing SO_LINGER right.
RFC 793 even includes a discussion of the linger algorithm and explains
exactly why server implementers like us would want to do a half-close.

Let's get something completely clear:  Even if Apache did not exist, the
OS *still* requires a FIN_WAIT_2 timeout.  There simply doesn't exist a
world in which it is okay for a server to be left holding the bag forever
just because the client has not yet sent a FIN.  Just ask the Sun folks,
who recognized (and fixed) this problem in Solaris 2.2.  It is not, and
has never been, a violation of the TCP standard to have a FIN_WAIT_2
timeout -- the authors just left it under the general category of
"User Timeout" which applies to any state, and didn't include it in the
state diagram.  The ONLY reason we are seeing this problem now, and not
before, is because keep-alive clients behave differently than non-keep-alive
clients.  The FIN_WAIT_2 timeout is necessary because it will cause an
Apache 1.1.3 server (with full keep-alive enabled, including Mozilla/2)
to reboot just as quickly as an Apache 1.2b6 server.  We fixed the other
problems with lingering_close after 1.2b4, and we can reduce the overhead
even more with my performance patch, but we can't do a damn thing about
the client keeping a connection alive when the server-side has closed.

I have talked to the program manager for MSIE and he has assured me that
it will be fixed in MSIE 4.0b2 (b1 has already been frozen).  Has anyone
talked to Lou about closing the client sockets after server FIN?  In this
case, a browser will want to behave nicely because it is in their best
interests to close the connection during the idle time between requests,
rather than at the start of the next request.

You need to remember that I've been dealing with these issues for over
two years now.  All those low-level TCP discussions in the HTTP/1.1 spec
are not there because we thought it was an interesting topic of conversation.
If an HTTP client or server does not recognize the limitations of TCP
and act accordingly, it will never see the HTTP messages which are sent
in times of error or resource limitations.

>If we disable lingering_close(), it puts the "blame" (I know,
>nasty word) back in the browsers court, and OS vendors don't need
>to patch their stacks at all. And all the cases which l_c() are
>supposed to help can be handled more effectively, and more logically,
>on the browser side anyway, it seems to me.

They both have bugs to fix, so I have no problem with forcing them to
fix their bugs.  We are living in a networking environment that hasn't
caught up with the new demand for networking usage; we shouldn't be
surprised if a few old eggs get broken as both servers and clients attempt
to respond to new needs.

.....Roy

Mime
View raw message