Envoy Compressor 过滤器升级为 Upstream HTTP Filter面向 OTLP 流量的请求压缩实战【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy本文基于 Envoy 仓库 changelog 新特性记录changelogs/current/new_features/compressor__upstream.rst与 Compressor 官方文档、示例配置、过滤器源码 展开。读者将掌握如何在 Envoy 中把 compressor 过滤器挂载到上游 HTTP 链路上、何时会跳过压缩、以及如何用它对 OpenTelemetryOTLP请求做端到端压缩。Envoy 的 Compressor 过滤器HTTP 过滤器此前只服务于下行downstream方向即压缩 Envoy 转发给客户端的响应。本次新特性将其扩展为可同时作为Upstream HTTP Filter使用从而在请求离开 Envoy、发往上游服务之前完成压缩。最典型的落地场景是OTLPOpenTelemetry Protocol流量的请求压缩遥测数据traces、metrics、logs通常以 protobuf/JSON 编码且体量可观在带宽受限或需要控制上游存储/传输成本时于边缘代理处压缩请求能显著减少上行字节数。一、什么是 Compressor 过滤器Compressor 是一个 HTTP 过滤器它允许 Envoy 根据客户端请求来决定是否压缩从上游服务分发回来的数据响应压缩以及在新特性加持下是否压缩发往上游的请求请求压缩。压缩的价值在于当带宽稀缺、负载较大时以额外的 CPU 开销换取传输字节数的下降CPU 压力也可以通过压缩加速器如 QAT卸载。过滤器类型 URLtype.googleapis.com/envoy.extensions.filters.http.compressor.v3.Compressor目前原生支持三种压缩库扩展gzip、brotli、zstd其他压缩库可作为扩展接入。从源码结构看compressor 过滤器 同时实现了decodeHeaders/decodeData请求方向与encodeHeaders/encodeData响应方向两组接口并在 config.cc 中同时注册了两类工厂REGISTER_FACTORY(CompressorFilterFactory, Server::Configuration::NamedHttpFilterConfigFactory); REGISTER_FACTORY(UpstreamCompressorFilterFactory, Server::Configuration::UpstreamHttpFilterConfigFactory);也就是说同一个过滤器既可以出现在 HCM 的http_filters链下行也可以出现在集群的typed_extension_protocol_options内上游这正是本次新特性的源码级实现基础。二、新特性核心把 compressor 用作 Upstream HTTP Filterchangelog 明确说明Extended the compressor filter to support usage as an upstream HTTP filter. This can be used to apply request compression for OTLP traffic.当 compressor 作为上游过滤器挂载到某个集群后Envoy 在向该集群发出请求前会检查请求头并执行压缩压缩后携带content-encoding: scheme头部发出同时移除原始content-length由分块/重算取代。官方文档compressor_filter.rst专门增设了 Upstream HTTP Filter Support 一节并给出与仓库示例配置一致的 OTLP 请求压缩范例说明该能力已被视为正式配置形态而非实验功能。2.1 完整示例OTLP/HTTP 集群上的请求压缩仓库中的 configs/envoy-otel-http.yaml 展示了最直接可用的配置。该文件演示如何通过 HTTP 导出 OpenTelemetry 的 logs、traces、metrics并在otel_collector集群上启用 OTLP 请求压缩clusters: - name: otel_collector type: STRICT_DNS lb_policy: ROUND_ROBIN load_assignment: cluster_name: otel_collector endpoints: - lb_endpoints: - endpoint: address: socket_address: address: 127.0.0.1 port_value: 4318 # OTLP request compression: # The following snippet enables OTLP request compression when used over HTTP/1.1 # with protobuf or JSON payloads. typed_extension_protocol_options: envoy.extensions.upstreams.http.v3.HttpProtocolOptions: type: type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions explicit_http_config: http_protocol_options: {} http_filters: - name: compressor typed_config: type: type.googleapis.com/envoy.extensions.filters.http.compressor.v3.Compressor compressor_library: name: envoy.compression.gzip.compressor typed_config: type: type.googleapis.com/envoy.extensions.compression.gzip.compressor.v3.Gzip request_direction_config: common_config: enabled: default_value: true min_content_length: 512 content_type: - application/grpc - application/x-protobuf - application/json - name: envoy.filters.http.upstream_codec typed_config: type: type.googleapis.com/envoy.extensions.filters.http.upstream_codec.v3.UpstreamCodec要点拆解挂载位置上游过滤器必须写在typed_extension_protocol_options的envoy.extensions.upstreams.http.v3.HttpProtocolOptions.http_filters列表中与下行链路http_filters相互独立链路顺序compressor 必须排在envoy.filters.http.upstream_codec上游编解码过滤器之前由 upstream_codec 收尾完成实际编码request_direction_config.common_config.enabled.default_value: true显式打开请求压缩默认关闭见下文min_content_length: 512请求体小于 512 字节时不压缩避免小包浪费 CPUcontent_type白名单只对application/grpc、application/x-protobuf、application/json三种遥测常见编码压缩其余类型原样转发该配置注释明确适用范围HTTP/1.1 protobuf/JSON 载荷OTLP/HTTP。2.2 运行方式仓库示例注释给出了完整的本地验证链路configs/envoy-otel-http.yaml# 1. 在本机 4318 端口启动一个 OTLP HTTP collector如 otel-tui # 2. 启动 Envoy bazel-bin/source/exe/envoy-static -c configs/envoy-otel-http.yaml # 3. 产生一次请求触发遥测上报 curl localhost:10080/get # 4. 等待 5 秒stats_flush_interval: 1s让日志/指标刷新然后在 collector 中核对三类信号该配置同时把 Envoy 自身的 stats sinkenvoy.stat_sinks.open_telemetry、tracingenvoy.tracers.opentelemetry和 access logenvoy.access_loggers.open_telemetry都指向该 collector 集群因此可一次性验证 metrics、traces、logs 三条链路上的请求压缩是否生效。三、请求压缩的启用与跳过逻辑请求压缩在默认情况下是关闭的request_direction_config.common_config.enabled默认 false需显式打开。从源码看compressor_filter.h 中RequestDirectionConfig::compressionEnabled()的判定是is_set_ compression_enabled_.enabled()——即必须同时满足「显式配置了 enabled」与「运行时开关为真」两个条件。即使启用在以下任一情形下请求压缩也会被跳过即请求保持原样发出请求没有content-type或 content-type 不在所选 mime 类型白名单中。默认白名单为application/javascriptapplication/jsonapplication/xhtmlxmlimage/svgxmltext/csstext/htmltext/plaintext/xml请求没有content-length头无法预判可压缩性请求带有content-encoding头已压缩过的内容不再重复压缩请求的transfer-encoding值中包含已知的压缩算法名如gzip。content-length与content-type的白名单校验在 DirectionConfig 中通过isMinimumContentLength()与isContentTypeAllowed()完成content_type使用大小写不敏感的集合匹配StringUtil::CaseUnorderedSet。四、响应压缩的行为对比下行方向虽然本特性的主角是请求压缩但理解响应压缩的既有行为有助于避免混淆同一个过滤器两种方向并存。响应压缩默认开启被跳过的情形包括请求缺少accept-encoding头或虽有但不含gzip/*accept-encoding中gzip/*的权重为q0如gzip;q0,*;q1不压缩而*;q0,gzip;q1会压缩链路中存在权重更高的其他编码对应统计项header_compressor_overshadowed响应已含content-encoding、cache-control: no-transform或transfer-encoding中含已知压缩名响应 content-type 不在白名单、缺少content-length/transfer-encoding、响应体小于 30 字节非 chunked 时、状态码命中uncompressible_response_codes列表。当响应压缩真正执行时移除content-length、写入transfer-encoding: chunked与content-encoding: gzip、注入vary: accept-encoding即使因不兼容的 accept-encoding 未压缩只要资源本身可压缩也会注入防止前端缓存代理缓存未压缩副本。五、其他可叠加使用的配置能力上游方向之外文档还提供了多个与请求压缩互补的能力可组合进同一集群或路由1. 不同压缩库分别用于请求与响应安装两个 compressor 过滤器一个仅开响应、一个仅开请求compressor-filter-request-response.yaml例如响应侧用BEST_COMPRESSION换取高压缩率请求侧用BEST_SPEED降低延迟http_filters: - name: envoy.filters.http.compressor # 仅响应方向 typed_config: type: type.googleapis.com/envoy.extensions.filters.http.compressor.v3.Compressor request_direction_config: common_config: enabled: default_value: false runtime_key: request_compressor_enabled compressor_library: name: for_response typed_config: type: type.googleapis.com/envoy.extensions.compression.gzip.compressor.v3.Gzip compression_level: BEST_COMPRESSION - name: envoy.filters.http.compressor # 仅请求方向 typed_config: type: type.googleapis.com/envoy.extensions.filters.http.compressor.v3.Compressor response_direction_config: common_config: enabled: default_value: false runtime_key: response_compressor_enabled request_direction_config: common_config: enabled: default_value: true runtime_key: request_compressor_enabled compressor_library: name: for_request typed_config: type: type.googleapis.com/envoy.extensions.compression.gzip.compressor.v3.Gzip compression_level: BEST_SPEED - name: envoy.filters.http.router注意示例中两个过滤器的enabled都挂了同一个runtime_key: request_compressor_enabled运行时开关生产环境建议为两个方向分配独立 key 以便单独控制。2. 按路由/虚拟主机控制与压缩库覆盖通过typed_per_filter_config的CompressorPerRoute类型...compressor.v3.CompressorPerRoute可对单个虚拟主机禁用、对单个路由重新启用overrides.response_direction_config: {}也可在overrides.compressor_library中替换压缩库例如某条路由用 brotli 而全局用 gzip。CompressorPerRouteFilterConfigcompressor_filter.h中responseCompressionEnabled()、compressorFactory()的「先查 per-route、再回退全局」逻辑保证了该能力生效。3. 压缩状态响应头设置response_direction_config.status_header_enabled: true后每个响应会带上x-envoy-compression-status格式为编码器类型;状态[;附加参数]多个 compressor 过滤器以逗号拼接例如gzip;Compressed;OriginalLength1024。状态值包括Compressed、ContentLengthTooSmall、ContentTypeNotAllowed、EtagNotAllowed、StatusCodeNotAllowed可用于缓存失效策略与压缩决策可观测性。4. ETag 处理响应带ETag时disable_on_etag_header: true则跳过压缩保持原样weaken_etag_on_compress: true则将强 ETag 弱化abc123→W/abc123后照常压缩兼容缓存与条件请求。weaken_etag_on_compress优先级高于disable_on_etag_header。六、统计指标每个 compressor 过滤器实例的统计根路径为stat_prefix.compressor.compressor_library.name.compressor_library_stat_prefix.direction_prefix.*其中direction_prefix区分请求/响应方向若未配置response_direction_config响应侧统计回退到不带方向前缀的旧树stat_prefix.compressor.name.stat_prefix.*。通用计数器请求与响应共有名称类型含义compressedCounter被压缩的请求/响应数not_compressedCounter未压缩的请求/响应数total_uncompressed_bytesCounter所有标记为压缩的请求/响应的未压缩字节总数total_compressed_bytesCounter压缩后的字节总数content_length_too_smallCounter接受压缩编码但载荷过小未压缩的次数响应方向独有名称类型含义no_accept_headerCounter请求无accept-encoding头header_identityCounteraccept-encoding为identityheader_compressor_usedCounteraccept-encoding明确选用本过滤器编码header_compressor_overshadowedCounter被同链其他过滤器接管而跳过header_wildcardCounteraccept-encoding为*header_not_validCounteraccept-encoding无效q0或不支持的编码not_compressed_etagCounter因含ETag且启用disable_on_etag_header而未压缩这些计数器的宏定义可直接在 compressor_filter.h 中核对COMMON_COMPRESSOR_STATS与RESPONSE_COMPRESSOR_STATS。其中total_uncompressed_bytes只统计被标记为压缩的请求/响应若未标记则只递增not_compressed而不计入字节数从而可量化压缩的内存/带宽收益。七、小结本次 changelog 新特性将 Envoy 的 compressor 过滤器从纯下行扩展为双方向可用其核心价值在于通过集群级HttpProtocolOptions.http_filters挂载 compressor 即可实现上游请求压缩无需改动任何业务代码开箱即用的 OTLP 场景模板configs/envoy-otel-http.yaml覆盖 protobuf/JSON/grpc 三类遥测载荷配合min_content_length与content_type白名单可精确控制压缩范围请求压缩默认关闭、具备完整的跳过判定content-type / content-length / content-encoding / transfer-encoding与响应压缩共享同一套统计与 per-route 覆盖机制。对于需要降低遥测上行带宽、或任何请求体大且可压缩的上游 HTTP 场景将 compressor 挂到上游链路是目前 Envoy 原生提供的最直接方案。【免费下载链接】envoyCloud-native high-performance edge/middle/service proxy项目地址: https://gitcode.com/GitHub_Trending/en/envoy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考