knitti wrote:
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
