proposal: add connection-level L4 idle timeout support to clusters
#9.231 aberto em 4 de dez. de 2019
Métricas do repositório
- Stars
- (27.997 stars)
- Métricas de merge de PR
- (Mesclagem média 8d) (378 fundiu PRs em 30d)
Description
Title: Add connection-level L4 idle timeout support to clusters
Description: The logic would effectively be what's currently present in the TCP proxy connection timeout: https://www.envoyproxy.io/docs/envoy/latest/api-v2/config/filter/network/tcp_proxy/v2/tcp_proxy.proto#envoy-api-field-config-filter-network-tcp-proxy-v2-tcpproxy-idle-timeout
This differs from the existing connection idle timeouts currently supported. Current timeouts consider the number of active requests on a connection and the timeout tracks the interval when no requests are present. The new proposed timeout would track the interval between bytes being sent or received.
We'd like to use this on Envoy Mobile to get earlier indications of defunct connections, independent of request timeouts. Request idle timeouts don't quite serve our purpose since we'd like requests to be able to be relatively idle as long as we have reason to believe the connection is healthy. We also generally have a high volume of requests, leaving us without timely insight into the health of an underlying connection. Obviously if there are no active requests, this essentially replicates the behavior of the existing idle timeouts, but it differs in a few important ways when there are active requests:
- It's a signal for the health of the connection overall, not just the requests in flight, and can be used to trigger the establishment of new connections in the event that its hit.
- It allows us to have relatively idle requests (e.g. for streaming), but still get a timely signal of an unhealthy connection.
In theory we could implement a poorer version of this ourselves without an upstream Envoy change that would instead rely on any L7 transmissions per session. We propose an upstream Envoy change because we think this mechanism could be generally useful, because we'd get a better quality signal at L4, and because we could support more sophisticated behavior (e.g. h2 pings could be leveraged to heartbeat the connection and keep it alive in the absence of requests).