# HTTP connection manager HTTP连接管理 HTTP是现代面向服务的体系结构的关键组成部分，Envoy实施了大量HTTP特定功能。Envoy有一个内置的网络级 filter，称为 HTTP连接管理器。该 filter将原始字节转换为HTTP级别的消息和事件（例如，接收到的标头，接收的正文数据，接收的预告片等）。它还处理所有HTTP连接和请求共有的功能，例如访问日志记录，请求ID生成和跟踪， 请求/响应头操作，路由表管理和统计信息。 HTTP连接管理器配置。 HTTP协议 Envoy的HTTP连接管理器对HTTP / 1.1，WebSockets和HTTP / 2具有本机支持。它不支持SPDY。Envoy的HTTP支持首先设计为HTTP / 2多路复用代理。在内部，HTTP / 2术语用于描述系统组件。例如，HTTP请求和响应发生在stream上。编解码器API用于将不同的有线协议转换为与流，请求，响应等无关的协议形式。对于HTTP / 1.1，编解码器将协议的串行/流水线功能转换为类似于HTTP的形式/ 2到更高的层。这意味着大多数代码不需要了解流是起源于HTTP / 1.1还是HTTP / 2连接。 HTTP标头清理 出于安全原因，HTTP连接管理器执行各种头清理操作。 路由表配置 每个HTTP连接管理器 filter都有一个关联的路由表。可以通过以下两种方式之一指定路由表： 静态地。 通过RDS API动态地。 重试插件配置 通常，在重试期间，主机选择与原始请求遵循相同的过程。重试插件可用于修改此行为，它们分为两类： 主机谓词：这些谓词可用于“拒绝”主机，这将导致主机选择重新尝试。可以指定任意数量的谓词，如果任何谓词拒绝主机，则主机将被拒绝。 Envoy支持以下内置主机谓词 envoy.retry\_host\_predicates.previous\_hosts：这将跟踪以前尝试过的主机，并拒绝已经尝试过的主机。 envoy.retry\_host\_predicates.omit\_canary\_hosts：这将拒绝任何标记为金丝雀主机的主机。主机通过设置标记为在端点的 filter过滤的元数据。有关更多详细信息，请参见LbEndpoint。canary: trueenvoy.lb envoy.retry\_host\_predicates.omit\_host\_metadata：这将基于预定义的元数据匹配条件拒绝任何主机。有关更多详细信息，请参见下面的配置示例。 优先级谓词：这些谓词可用于调整为重试尝试选择优先级时使用的优​​先级负载。只能指定一个这样的谓词。 Envoy支持以下内置优先级谓词 envoy.retry\_priorities.previous\_priorities：这将跟踪先前尝试的优先级，并调整优先级负载，以便在后续的重试尝试中将其他优先级作为目标。 主机选择将继续进行，直到配置的谓词接受主机或达到可配置的最大尝试次数为止 。 这些插件可以组合使用，以影响主机选择和优先级负载。还可以使用自定义重试插件扩展Envoy，类似于添加自定义 filter的方式。 配置实例 例如，要将重试配置为首选尚未尝试过的主机，envoy.retry\_host\_predicates.previous\_hosts可以使用内置 谓词： retry\_policy: retry\_host\_predicate: * name: envoy.retry\_host\_predicates.previous\_hosts host\_selection\_retry\_max\_attempts: 3 这将拒绝先前尝试的主机，最多重试主机选择3次。为了处理不可能（无法找到满足条件的主机）或不可能（无法找到合适的主机，唯一合适的主机具有相对较低的权重）的情况，必须对尝试进行限制。 要基于主机的元数据拒绝主机，envoy.retry\_host\_predicates.omit\_host\_metadata可以使用： retry\_policy: retry\_host\_predicate: * name: envoy.retry\_host\_predicates.omit\_host\_metadata typed\_config: "@type": type.googleapis.com/envoy.extensions.retry.host.omit\_host\_metadata.v3.OmitHostMetadataConfig metadata\_match: ``` filter_metadata: envoy.lb: key: value ``` 这将拒绝其元数据中具有匹配（键，值）的任何主机。 要将重试配置为在重试期间尝试其他优先级，envoy.retry\_priorities.previous\_priorities可以使用内置功能 。 retry\_policy: retry\_priority: name: envoy.retry\_priorities.previous\_priorities typed\_config: "@type": type.googleapis.com/envoy.extensions.retry.priority.previous\_priorities.v3.PreviousPrioritiesConfig update\_frequency: 2 这将针对尚未使用的后续重试尝试中的优先级。该update\_frequency参数决定应重新计算优先级负载的频率。 这些插件可以组合使用，这将同时排除先前尝试的主机和先前尝试的优先级。 retry\_policy: retry\_host\_predicate: * name: envoy.retry\_host\_predicates.previous\_hosts host\_selection\_retry\_max\_attempts: 3 retry\_priority: name: envoy.retry\_priorities.previous\_priorities typed\_config: "@type": type.googleapis.com/envoy.extensions.retry.priority.previous\_priorities.v3.PreviousPrioritiesConfig update\_frequency: 2 内部重定向 Envoy支持内部处理3xx重定向，即捕获可配置的3xx重定向响应，合成新请求，将其发送到新路由匹配所指定的上游，并将重定向后的响应作为对原始请求的响应返回。 内部重定向是通过路由配置中的内部重定向策略字段配置的。启用重定向处理后，来自上游的与redirect\_response\_codes匹配的任何3xx响应 都将由Envoy处理。 为了成功处理重定向，它必须通过以下检查： 具有与redirect\_response\_codes中的一个匹配的响应代码，该响应代码要么是302（默认情况下），要么是一组3xx代码（301、302、303、307、308）。 具有带有有效的标准URL的位置标头。 该请求必须已由Envoy完全处理。 该请求不得包含正文。 allow\_cross\_scheme\_redirect为true（默认为false），或者下游请求的方案和位置标头相同。 给定下游请求中先前处理的内部重定向的数量不超过 该请求或重定向的请求所命中的路由的最大内部重定向。 所有谓词都接受目标路由。 任何失败都将导致重定向传递到下游。 由于重定向的请求可能会在不同的路由之间退回，因此重定向链中的任何路由都会 没有启用内部重定向 或 当重定向链命中时，内部最大重定向次数小于或等于重定向链长度 或任何谓词不允许 将导致重定向传递到下游。 可以使用两个谓词来创建DAG，以定义重定向链，先前的路由谓词和allow\_listed\_routes。具体来说，允许列出的路由谓词定义了DAG中各个节点的边缘，而先前的路由谓词定义了边缘的“已访问”状态，因此可以避免循环。 第三个谓词safe\_cross\_scheme 可用于阻止HTTP-> HTTPS重定向。 重定向通过这些检查后，将通过以下方式修改发送到原始上游的请求标头： 将完全限定的原始请求URL放在x-envoy-original-url标头中。 用Location标头中的值替换Authority / Host，Scheme和Path标头。 然后，更改后的请求标头将选择新的路由，通过新的filter chains发送，然后在上游进行所有正常的Envoy请求清理。 警告 请注意，HTTP连接管理器清理操作（例如清除不可信的标头）将仅应用一次。即使原始路由和第二个路由相同，每个路由的报头修改也将同时应用于原始路由和第二路由，因此请谨慎配置报头修改规则，以避免重复不必要的报头值。 重定向流示例如下所示： 客户端发送GET请求以获取 上游1发送带有“位置： Envoy配置为允许在原始路由上进行重定向，并向上游2发送新的GET请求，以使用其他请求标头“ x-envoy-original-url：http//来获取 foo.com/bar” Envoy将对 超时时间 各种可配置的超时适用于HTTP连接及其组成流。请查看 此常见问题解答条目，以获取重要超时配置的概述。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://rocdu.gitbook.io/deep-understanding-of-istio/9/2.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.