How Envoy’s Filter Chain Powers Istio’s Service Mesh: A Deep Dive

Envoy is a core component of Istio, deployed as a sidecar proxy that intercepts and forwards service traffic, offering routing, traffic control, and other powerful features. It uses libevent to implement an event‑driven asynchronous architecture where all network‑blocking operations (accept, read, connect, write) are handled by an event loop.

Filter Types and Interfaces

1. ListenerFilter – invoked when a new downstream connection is accepted. Interface: onAccept(callback). Built‑in types include envoy.listener.original_dst (used for Istio’s 15001 port) and envoy.listener.tls_inspector (registers a read callback to detect TLS and perform handshake).

2. ReadFilter – handles new connections and data readiness for protocol parsing. Interfaces: onNewConnection(), onData(data, end_stream). Built‑in filters: Envoy::Http::CodecClient, envoy.http_connection_manager, envoy.tcp_proxy, envoy.redis_proxy, etc.

3. WriteFilter – called when data is written to an upstream connection. Interface: onWrite(data, end_stream). Built‑in types include envoy.filters.network.dubbo_proxy, envoy.mongo_proxy, envoy.filters.network.mysql_proxy, envoy.filters.network.zookeeper_proxy.

4. StreamDecodeFilter (specific to envoy.http_connection_manager) – processes HTTP request parts. Interfaces: decodeHeaders(headers, end_stream), decodeData(data, end_stream), decodeTrailers(HeaderMaps& trailers), decodeComplete(). Built‑in filters: envoy.cors, envoy.fault, envoy.router.

5. StreamEncodeFilter – handles sending response parts to the downstream client. Interfaces include encodeHeaders(headers, end_stream), encodeData(data, end_stream), encodeTrailers(HeaderMap& trailers), encodeMetadata(metadata_map), encodeComplete(). Built‑in filters: envoy.cors, envoy.fault, envoy.lua.

6. PerFilterConfig – not a filter itself; provides route‑level configuration data for HTTP filters via route.virtual_hosts.per_filter_config, stored as map<string, Struct> and interpreted by the filter implementation.

7. ConnectionCallbacks – callbacks for connection lifecycle events. Interface: onEvent(event) where event can be RemoteClose, LocalClose, or Connected. Additional water‑mark callbacks are also defined.

8. AccessLogHandlers – invoked at request completion to log or report. Interface:

log(request_headers, response_headers, response_trailers, stream_info)

. Implementations include Istio’s Mixer filter ( Envoy::Http::Mixer::Filter) and various file or gRPC loggers.

Key Processing Steps in the Filter Pipeline

1. findActiveListenerByAddress – selects the appropriate Listener based on the socket’s local address and port. It first attempts to retrieve the original destination port via

getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, &orig_addr, &addr_len)

when envoy.listener.original_dst is configured, then matches Listener by address/port or falls back to a wildcard Listener.

2. Route and Cluster Matching – constructs a RouteMatcher that iterates over virtual_hosts sorted by domain length (descending). Matching proceeds in the order: exact virtual_hosts_, wildcard_virtual_host_suffixes_, wildcard_virtual_host_prefixes_, and finally default_virtual_host_. Once a virtual host is selected, the request’s match field (prefix, regex, or path) determines the route, and weighted clusters are chosen based on a random stream_id when applicable.

3. Load‑Balancing and Endpoint Selection – after identifying the clusterName, the ThreadLocalClusterManagerImpl provides a per‑worker copy of the cluster data. For HTTP, the host_http_conn_pool_map_ maps host → protocol → connpool, supporting HTTP/1.0, HTTP/1.1, and HTTP/2 each with independent connection pools.

4. Mixer Integration – Istio adds a Mixer filter to Envoy. The filter registers StreamDecodeFilter and StreamEncodeFilter; the former’s decodeHeaders hook performs a Check by sending attributes to the Mixer server, while the log method of the AccessLogHandler performs a Report. Reports are batched and sent either when a size threshold or time interval is reached.

Summary

Envoy’s extensible filter chain allows developers to inject custom functionality at every stage of request processing, either by writing C++ filters and registering them via REGISTER_FACTORY, or by leveraging built‑in filters such as the Istio Mixer filter for policy checks and telemetry reporting.

Istio’s integration demonstrates how a service mesh can use Envoy’s filter architecture to implement check‑and‑report semantics without modifying application code.