HTTP connection management

    HTTP connection manager configuration.

    Envoy’s HTTP connection manager has native support for HTTP/1.1, WebSockets, and HTTP/2. It does not support SPDY. Envoy’s HTTP support was designed to first and foremost be an HTTP/2 multiplexing proxy. Internally, HTTP/2 terminology is used to describe system components. For example, an HTTP request and response take place on a stream. A codec API is used to translate from different wire protocols into a protocol agnostic form for streams, requests, responses, etc. In the case of HTTP/1.1, the codec translates the serial/pipelining capabilities of the protocol into something that looks like HTTP/2 to higher layers. This means that the majority of the code does not need to understand whether a stream originated on an HTTP/1.1 or HTTP/2 connection.

    The HTTP connection manager performs various actions for security reasons.

    Each HTTP connection manager filter has an associated . The route table can be specified in one of two ways:

    • Statically.
    • Dynamically via the RDS API.

    Normally during retries, hosts selection follows the same process as the original request. To modify this behavior retry plugins can be used, which fall into two categories:

    • Envoy supports the following built-in host predicates

      • envoy.retry_host_predicates.previous_hosts: This will keep track of previously attempted hosts, and rejects hosts that have already been attempted.

    Host selection will continue until either the configured predicates accept the host or a configurable has been reached.

    These plugins can be combined to affect both host selection and priority load. Envoy can also be extended with custom retry plugins similar to how custom filters can be added.

    For example, to configure retries to prefer hosts that haven’t been attempted already, the built-in predicate can be used:

    This will reject hosts previously attempted, retrying host selection a maximum of 3 times. The bound on attempts is necessary in order to deal with scenarios in which finding an acceptable host is either impossible (no hosts satisfy the predicate) or very unlikely (the only suitable host has a very low relative weight).

    To configure retries to attempt other priorities during retries, the built-in can be used.

    This will target priorites in subsequent retry attempts that haven’t been already used. The parameter decides how often the priority load should be recalculated.

    These plugins can be combined, which will exclude both previously attempted hosts as well as previously attempted priorities.

    • Connection-level idle timeout: this applies to the idle period where no streams are active.
    • Connection-level : this spans between an Envoy originated GOAWAY and connection termination.
    • Stream-level idle timeout: this applies to each individual stream. It may be configured at both the connection manager and granularity. Header/data/trailer events on the stream reset the idle timeout.
    • Stream-level per-route gRPC max timeout: this bounds the upstream timeout and allows the timeout to be overridden via the grpc-timeout request header.