mirror of
http://git.haproxy.org/git/haproxy.git/
synced 2025-01-16 02:30:46 +00:00
983ac4397d
This patch introduces a new setting: tune.h2.fe.max-total-streams. It sets the HTTP/2 maximum number of total streams processed per incoming connection. Once this limit is reached, HAProxy will send a graceful GOAWAY frame informing the client that it will close the connection after all pending streams have been closed. In practice, clients tend to close as fast as possible when receiving this, and to establish a new connection for next requests. Doing this is sometimes useful and desired in situations where clients stay connected for a very long time and cause some imbalance inside a farm. For example, in some highly dynamic environments, it is possible that new load balancers are instantiated on the fly to adapt to a load increase, and that once the load goes down they should be stopped without breaking established connections. By setting a limit here, the connections will have a limited lifetime and will be frequently renewed, with some possibly being established to other nodes, so that existing resources are quickly released. The default value is zero, which enforces no limit beyond those implied by the protocol (2^30 ~= 1.07 billion). Values around 1000 were found to already cause frequent enough connection renewal without causing any perceptible latency to most clients. One notable exception here is h2load which reports errors for all requests that were expected to be sent over a given connection after it receives a GOAWAY. This is an already known limitation: https://github.com/nghttp2/nghttp2/issues/981 The patch was made in two parts inside h2_frt_handle_headers(): - the first one, at the end of the function, which verifies if the configured limit was reached and if it's needed to emit a GOAWAY ; - the second, just before decoding the stream frame, which verifies if a previously configured limit was ignored by the client, and closes the connection if this happens. Indeed, one reason for a connection to stay alive for too long definitely comes from a stupid bot that periodically fetches the same resource, scans lots of URLs or tries to brute-force something. These ones are more likely to just ignore the last stream ID advertised in GOAWAY than a regular browser, or a well-behaving client such as curl which respects it. So in order to make sure we can close the connection we need to enforce the advertised limit. Note that a regular client will not face a problem with that because in the worst case it will have max_concurrent_streams in flight and this limit is taken into account when calculating the advertised last acceptable stream ID. Just a note: it may also be possible to move the first part above to h2s_frt_stream_new() instead so that it's not processed for trailers, though it doesn't seem to be more interesting, first because it has two return points. This is something that may be backported to 2.9 and 2.8 to offer more control to those dealing with dynamic infrastructures, especially since for now we cannot force a connection to be cleanly closed using rules (e.g. github issues #946, #2146). |
||
|---|---|---|
| .. | ||
| design-thoughts | ||
| internals | ||
| lua-api | ||
| 51Degrees-device-detection.txt | ||
| acl.fig | ||
| architecture.txt | ||
| coding-style.txt | ||
| configuration.txt | ||
| cookie-options.txt | ||
| DeviceAtlas-device-detection.txt | ||
| gpl.txt | ||
| haproxy.1 | ||
| intro.txt | ||
| lgpl.txt | ||
| linux-syn-cookies.txt | ||
| lua.txt | ||
| management.txt | ||
| netscaler-client-ip-insertion-protocol.txt | ||
| network-namespaces.txt | ||
| peers-v2.0.txt | ||
| peers.txt | ||
| proxy-protocol.txt | ||
| queuing.fig | ||
| regression-testing.txt | ||
| seamless_reload.txt | ||
| SOCKS4.protocol.txt | ||
| SPOE.txt | ||
| WURFL-device-detection.txt | ||