knitti wrote:
quoted text
> you tell me that there is some correlation between HTTP keep alives and
> a socket ending up in CLOSE_WAIT for some time. That is the practical
> observation. But I'm interested in whether this is by design or not.
> RFC 2616 doesn't mention implementation details, and I can't see why
> the socket implementation (OS) would want to keep a socket in
> CLOSE_WAIT for some time (not sending a final ACK).

One more thing I also forgot to add, or may be didn't come across as 
clear as it should.

If you put of in front of it and use it to proxy the connections, it 
will only pass the real connection to httpd that are real and as such 
save you socket that httpd would have to manage and that would end up in 
  CLOSE_WAIT.

Why? Let say someone doesn't like your site and send you a bunch of fake 
connections to (initiate connections) occupy all your sockets and as 
such making your site totally useless.

You can increase the number of connection httpd can support, recompile 
it and sue it, or a much more logical and practical ways is to use pf to 
actually filter these connections and avoid the problem in the first 
place that the limit of httpd have in the default.

If you try to establish a connection to httpd directly then it will use 
a socket even if it can't reply to the source as fake and as such use 
your resources and I guess end up in CLOSE_WAIT state and waiting to get 
the final ACK that will never come as it is a fake source.

However putting PF in front of it, your httpd wouldn't suffer this part 
anyway of the depletion of the sockets it can use.

Now adjusting the tcp stack value would/could then improve on the time 
sockets stay in this CLOSE_WAIT state.

So, all are connected in any way or angle you try to look at it.

Keep alive, max_spare_connections, etc, for speed and time delay for the 
httpd application to release that socket to the OS.

PF to handle these fake/forged TCP connections that would otherwise 
occupy your httpd sockets available and as such needs to do the full 
cycle of open, wait and close based on the delay preset and may keep it 
open for way more time that you may want as it will wait for ever on the 
ACK for the fake source.

And TCP stack variable in making more or less of them (sockets) 
available sooner or later.

So, that's how each one interact with each others in many ways.

Hopefully I didn't make more of a mess then it was already and make it a 
little bit more clear. That's my intend anyway.

Hope it help you anyhow.

Best,

Daniel