doc the layer 4 plugins (#623)

Signed-off-by: spacewander <spacewanderlzx@gmail.com>

site/content/en/docs/concept/consumer.md

@@ -94,7 +94,7 @@ Each Consumer plugin configured on the Route will proceed through the following
 
 If no Consumer is matched after all the Consumer plugins have been executed, a 401 HTTP status code will be returned.
 
-Furthermore, we can configure specific plugins for the consumer. These plugins will only execute after the authentication process has passed. Take the following configuration as an example:
+In addition to that, we can configure additional plugins for consumers under the `filters` field. These plugins are only executed after the consumer has been authenticated. Take the following configuration as an example:
 
 ```yaml
 apiVersion: htnn.mosn.io/v1
@@ -143,4 +143,6 @@ spec:
 
 If the authentication result is for a prestigious VIP member, then the `average` configuration would be 10. If it's a regular member, then the corresponding configuration would be just 1.
 
-Unlike consumers in some gateways, HTNN's consumers are at the `namespace` level. Consumers from different `namespaces` will only apply to the Routes within their respective `namespace` configurations (HTTPRoute, VirtualService, etc.). This design prevents consumer conflicts between different business units.
+All plugins implemented in Go and set to execute after the authentication order can be configured as additional plugins for consumers.
+
+Unlike consumers in some gateways, HTNN's consumers are at the `namespace` level. Consumers from different `namespaces` will only apply to the Routes within their respective `namespace` configurations (HTTPRoute, VirtualService, etc.). This design prevents consumer conflicts between different business units.

site/content/en/docs/concept/filterpolicy.md

@@ -2,9 +2,9 @@
 title: FilterPolicy
 ---
 
-Most features on gateways and service mesh revolve around the HTTP protocol, such as authentication, rate limiting, request rewriting, etc. HTNN implements these features via configuration rules provided by FilterPolicy.
+Most businesses on gateways and service mesh revolve around network protocols, such as authentication, rate limiting, request rewriting, etc. HTNN abstracts these needs and uses FilterPolicy to express specific configuration rules.
 
-Unlike some products in this area, HTNN does not use different CRDs for different HTTP relative purposes. Instead, it uses a single CRD called FilterPolicy to solve all business needs at the HTTP layer. This is because we believe the cost of multiple CRDs is too high. We even introduced a `0 CRD` [embedded mode](../embedded_mode) to reduce the cost of onboarding and maintenance.
+Unlike some similar products, HTNN does not use different CRDs for different business categories, but unifies all policy-level business needs using a single CRD, FilterPolicy. This is because we feel the cost of multiple CRDs is too high. We even introduced the `0 CRD` [embedded mode](../embedded_mode) to reduce the cost of integration and maintenance.
 
 ## Structure of FilterPolicy
 
@@ -377,6 +377,35 @@ For example, to issue a policy for a particular Listener of a Gateway API's Gate
 
 Plugins configured by different FilterPolicies with overlapping scopes will merge and then execute in the order specified at the time the plugins were registered. If different levels of FilterPolicy configure the same plugin, the configuration on the smaller scoped FilterPolicy will override the broader scoped configuration, namely `SectionName` > `VirtualService/HTTPRoute` > `Gateway`. If the same plugin is configured by the same level of FilterPolicy, the FilterPolicy created earliest takes precedence; if the timings are the same, they are ordered by the namespace and name of the FilterPolicy.
 
+## The Relationship between FilterPolicy and Plugins
+
+FilterPolicy is simply the carrier for plugins. HTNN's plugins can be divided into two categories:
+
+* Go plugins that run on the data plane
+* Plugins that run on the control plane to generate Envoy configurations, which we call Native plugins
+
+Depending on their location, Native plugins can be further divided into the following categories:
+
+* HTTP Native plugins, which affect HTTP filters
+* Network Native plugins, which affect Network filters
+* Listener Native plugins, which affect Listeners
+
+In the documentation for each plugin, we have indicated its category. In the "Attribute" section, if `Order` is:
+
+* `Listener`, it is a Listener Native plugin
+* `Network`, it is a Network Native plugin
+* `Outer` or `Inner`, it is an HTTP Native plugin
+* The rest are Go plugins
+
+Which plugins can be configured on a FilterPolicy depends on the target resource type in `TargetRef`, as shown in the table below:
+
+| Plugin Type             | Configured on Gateway | Configured on Route |
+|-------------------------|-----------------------|---------------------|
+| Go plugins              | Supported             | Supported           |
+| HTTP Native plugins     | Pending support       | Supported           |
+| Network Native plugins  | Supported             | Not supported       |
+| Listener Native plugins | Supported             | Not supported       |
+
 ## Using SubPolicies to Reduce the Number of FilterPolicies
 
 For gateways configured by domain dimension, a VirtualService could contain hundreds of routes. If each route requires its configuration, we would need to create hundreds of FilterPolicies. To reduce the load on the API server, we support targeting multiple routes with a single FilterPolicy as shown below:
@@ -435,3 +464,5 @@ For gateways configured by domain dimension, a VirtualService could contain hund
 ```
 
 FilterPolicy supports using the `subPolicies` field to configure policies for multiple `sectionNames` simultaneously. Both `filters` and `subPolicies` can be used together, and the merging rules for configurations are the same as when using multiple separate FilterPolicies.
+
+Note that `subPolicies` currently only supports VirtualService.

site/content/zh-hans/docs/concept/consumer.md

@@ -94,7 +94,7 @@ spec:
 
 如果执行完全部消费者插件后，仍然没有匹配到消费者，则返回 401 HTTP 状态码。
 
-除此之外，我们还可以给消费者配置特定的插件。这些插件只有在通过认证之后才会执行。以下面的配置为例：
+除此之外，我们还可以在 `filters` 字段下给消费者配置额外的插件。这些插件只有在通过认证之后才会执行。以下面的配置为例：
 
 ```yaml
 apiVersion: htnn.mosn.io/v1
@@ -143,4 +143,6 @@ spec:
 
 如果认证结果是尊贵的 VIP 会员，那么 `average` 的配置会是 10。如果是普通的会员，那么对应的配置只是 1。
 
+所有使用 Go 实现且执行阶段在认证阶段之后的插件都能作为额外插件配置在消费者上。
+
 和有些网关里面的消费者不同的是，HTNN 的消费者是 `namespace` 级别的。来自不同 `namespace` 的消费者，只会应用到对应 `namespace` 里的路由配置（HTTPRoute、VirtualService 等等）里的路由。这种设计避免了不同业务间的消费者发生冲突。

site/content/zh-hans/docs/concept/filterpolicy.md

@@ -2,9 +2,9 @@
 title: FilterPolicy
 ---
 
-绝大部分网关和 service mesh 上的业务需求，都是围绕着 HTTP 协议做一些事情，如认证鉴权、限流限速、请求改写等等。HTNN 把这部分的需求都抽象出来，使用 FilterPolicy 来表达具体的配置规则。
+绝大部分网关和 service mesh 上的业务需求，都是围绕着网络协议做一些事情，如认证鉴权、限流限速、请求改写等等。HTNN 把这部分的需求都抽象出来，使用 FilterPolicy 来表达具体的配置规则。
 
-和一些同类产品不同，HTNN 并没有为不同的业务分类使用不同的 CRD，而是统一使用 FilterPolicy 一个 CRD 来解决所有的 HTTP 层面上的业务需求。这是因为我们觉得多 CRD 的成本太大了。我们甚至引入 `0 CRD` 的 [embedded mode](../embedded_mode)，来减低接入和维护成本。
+和一些同类产品不同，HTNN 并没有为不同的业务分类使用不同的 CRD，而是统一使用 FilterPolicy 一个 CRD 来解决所有的策略层面上的业务需求。这是因为我们觉得多 CRD 的成本太大了。我们甚至引入 `0 CRD` 的 [embedded mode](../embedded_mode)，来减低接入和维护成本。
 
 ## FilterPolicy 的结构说明
 
@@ -377,7 +377,36 @@ status:
 如果不同级别的 FilterPolicy 配置了同一个插件，那么范围更小的 FilterPolicy 上的配置会覆盖掉范围更大的配置，即 `SectionName` > `VirtualService/HTTPRoute` > `Gateway`。
 如果同一级别的 FilterPolicy 配置了同一个插件，那么创建时间更早的 FilterPolicy 优先；如果时间都一样，则按 FilterPolicy 的 namespace 和 name 排序。
 
-## 使用 SubPolicies 减少 FilterPolicy 数量
+## 插件和 FilterPolicy 的对应关系
+
+FilterPolicy 只是插件的载体。HTNN 的插件可以分成两类：
+
+* 运行在数据面上的 Go 插件
+* 运行在控制面上，生成对应 Envoy 配置的插件，我们称之为 Native 插件
+
+Native 插件根据其作用位置不同，又可分成以下几类：
+
+* HTTP Native 插件，作用在 HTTP filter 上
+* Network Native 插件，作用在 Network filter 上
+* Listener Native 插件，作用在 Listener 上
+
+在每个插件的文档上，我们标注了它所属的类别。在“属性”这一节里，如果 `Order` 为
+
+* `Listener`，则是 Listener Native 插件
+* `Network`，则是 Network Native 插件
+* `Outer` 或 `Inner`，则是 HTTP Native 插件
+* 剩下的则是 Go 插件
+
+一个 FilterPolicy 上能配置哪些插件取决于 `TargetRef` 里的目标资源类型，见下表：
+
+| 插件类型             | 在 Gateway 上配置 | 在路由上配置 |
+|----------------------|-------------------|--------------|
+| Go 插件              | 支持              | 支持         |
+| HTTP Native 插件     | 待支持            | 支持         |
+| Network Native 插件  | 支持              | 不支持       |
+| Listener Native 插件 | 支持              | 不支持       |
+
+## 使用 subPolicies 减少 FilterPolicy 数量
 
 对于按域名维度配置的网关，一个 VirtualService 内可能会有上百个路由。如果每个路由都需要有自己的配置，那么我们需要创建成百个 FilterPolicy。为了减少对 API server 的压力，我们支持使用同一个 FilterPolicy 匹配多个路由。
 
@@ -437,3 +466,5 @@ status:
 ```
 
 FilterPolicy 支持使用 `subPolicies` 字段同时给多个 `sectionName` 配置策略。`filters` 和 `subPolicies` 能同时使用，配置合并的规则和分开使用多个 FilterPolicy 一样。
+
+注意目前 `subPolicies` 仅支持 VirtualService。