HTTP routing

Envoy includes an HTTP router filter which can be installed to perform advanced routing tasks. This is useful both for handling edge traffic (traditional reverse proxy request handling) as well as for building a service to service Envoy mesh (typically via routing on the host/authority HTTP header to reach a particular upstream service cluster). Envoy also has the ability to be configured as forward proxy. In the forward proxy configuration, mesh clients can participate by appropriately configuring their http proxy to be an Envoy. At a high level the router takes an incoming HTTP request, matches it to an upstream cluster, acquires a connection pool to a host in the upstream cluster, and forwards the request. The router filter supports the following features:

Route table

The configuration for the HTTP connection manager owns the route table that is used by all configured HTTP filters. Although the router filter is the primary consumer of the route table, other filters also have access in case they want to make decisions based on the ultimate destination of the request. For example, the built in rate limit filter consults the route table to determine whether the global rate limit service should be called based on the route. The connection manager makes sure that all calls to acquire a route are stable for a particular request, even if the decision involves randomness (e.g. in the case of a runtime configuration route rule).

Retry semantics

Envoy allows retries to be configured both in the route configuration as well as for specific requests via request headers. The following configurations are possible:

  • Maximum number of retries: Envoy will continue to retry any number of times. An exponential backoff algorithm is used between each retry. Additionally, all retries are contained within the overall request timeout. This avoids long request times due to a large number of retries.
  • Retry conditions: Envoy can retry on different types of conditions depending on application requirements. For example, network failure, all 5xx response codes, idempotent 4xx response codes, etc.

Note that retries may be disabled depending on the contents of the x-envoy-overloaded.

Priority routing

Envoy supports priority routing at the route level. The current priority implementation uses different connection pool and circuit breaking settings for each priority level. This means that even for HTTP/2 requests, two physical connections will be used to an upstream host. In the future Envoy will likely support true HTTP/2 priority over a single connection.

The currently supported priorities are default and high.