Network Filter#
Network Filter Chains#
In the Figure: Example of Envoy Inbound Configuration in Istio in the previous chapter, it can be seen that a Listener can contain multiple Network Filter Chains
. Each of these chains has its own filter_chain_match
, which is used to configure the policy of the Network Filter Chain
selected by the newly created Inbound Connection
.
Each Network Filter Chain
has its own name. Note that duplicate Network Filter Chain
names are allowed.
Each Network Filter Chain
consists of sequential Network Filters
.
Network Filter Overview#
Envoy uses a multi-layer plug-in design pattern to ensure scalability. The Network Filter
is the L2 / L3 (IP/TCP) layer component. For example, in the Figure: Example of Envoy Inbound Configuration in Istio above, there are, in order, the following:
istio.metadata_exchange
Network Filter
envoy.filters.network.http_connection_manager
Network Filter
Two network filters, of course, the heavy HTTP proxy tasks is done on http_connection_manager
network filter.
Network Filter Framework Design Concepts#
As I was learning about Envoy’s Network Filter framework design, I realized that it is very different from what I thought a Filter design would be. It was even a bit counter-intuitive. See the following diagram:
Here’s just a word in terms of ReadFilter
:
My intuition Ideal model
is:
the concept of
Upstream
exists in the Filter framework layer.the output data and events of one Filter will be the input data and events of the next Filter. Since this is called Chain, it should be similar to Linux’s
cat myfile | grep abc | grep def
.The Buffer between Filters should be isolated.
In the realistic model
, there is no framework
level.
at the framework level, there is no concept of
Upstream
, the Filter implementation implements or does not implementUpstream
, including connection establishment and data read/write, event notification. So, at the framework level, there is no concept of Cluster / Connection Pool, etc.See the following item
Filters share the Buffer with each other, if the previous Filter reads the Buffer without
drained
, the following Filter will read the data repeatedly. The previous Filter can also insert new data into the Buffer. And this stateful Buffer will be passed to the later Filter.Since “at the framework level, there is no concept of
Upstream
”,WriteFilter
is not a module that intuitively writes Request/Data toUpstream
, but a module that writes Response/Data toDownstream
.
Network Filter object relationships#
Now that I’ve written this, it’s time to look at the code. But not directly. Let’s look at the C++ class diagram first.
As you can see, WriteFilter
is not commonly used in our daily life :) .
Network Filter Framework Design Details#
At the code implementation level, the Network Filter framework has the following collaboration between abstract objects:
Below, the classic TCP Proxy Filter is used as an example.
Network Filter - ReadFilter Collaboration#
The ReadFilter
collaboration is a bit more complex and is the core logic of the Network Filter Framework. That’s why it’s important to talk about it in detail.
As mentioned before, the Framework itself does not directly provide the Upstream / Upstream Connection Pool / Cluster / Route abstractions and related events. Instead, we’ll refer to these as External Objects and Events
, and the Filter implementation needs to create or get these External Objects
and listen for these External Events
itself. External events may include:
Upstream Domain Name Interpretation Completed
Upstream Connection Pool connection available
Upstream socket read ready
Upstream write buffer full
…
Network Filter - WriteFilter Collaboration#
Since WriteFilter
has limited usage scenarios in Envoy, only MySQLFilter / PostgresFilter / KafkaBrokerFilter and Istio’s MetadataExchangeFilter. So I won’t expand on that here.
Extended Reading#
If you are interested in studying the implementation details of Listener, I recommend checking out my blog posts: