On 5/27/22 7:33 PM, Eric Covener wrote:
> People might recall an event bug where keepalive connections might be
> closed up to 200ms early (r1874350).
>
> I was recently looking at something with $bigco hat on where (IIUC) a
> slow TTFB for a proxied request causes TCP congestion to kick in and
> makes even a relatively short response sit in the write buffer.
>
>>From the behavior, it appears the browser is:
>
> 1) willing to use nearly every millisecond of the advertised KeepAlive
> time for reusing a connection from its pool
> 2) starts counting from when the response is complete
> 3) can't be asked to use Expect: 100-continue on an XHR POST
> 4) leaves error handling up to the caller and doesn't give it a ton of
> feedback
>
> This results in Apache starting the keepalive countdown "tens" of
> milliseconds early while the last bytes of the response are in the
> queue. If we get unlucky, a POST and a FIN cross in the night on a
> subsequent request.
>
> These types of investigations can be really painful. Is there any
> harm in allowing the server to act like "KeepAliveTimeout 5" is e.g.
> "KeepAliveTimeout 5200ms".
>
> If this fudge buffer existed as an addl directive (rather than a trick
> documented in KeepAliveTimeout) , would it be reasonable as a non-zero
> default to discourage this race?
>
In the end you want to get to a KeepAlive we announce to the client and
a KeepAlive which is longer than that that we execute.
My understanding of keepalive is that the client cannot take for granted
that a connection is really kept alive for as long as it was announced by
the server (it SHOULD be but there seems no MUST) and in fact we close keepalive
connections if get too busy and keeping these would prevent us from accepting
new connections.
Hence I think the issue will not be fixed in all situations.
I am willing to have this possibility, I guess best by adding an additional
amount of grace to the KeepAliveTimeout configurable by a directive, but I think
it should be zero by default to avoid confusion unless the behavior you report
above
is widespread.
Regards
Rüdiger
