Application Load Balancer 的侦听器 - Elastic Load Balancing

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

Application Load Balancer 的侦听器

侦听器是一个使用您配置的协议和端口检查连接请求的进程。在开始使用 Application Load Balancer 之前,必须添加至少一个侦听器。如果您的负载均衡器没有侦听器,则无法接收来自客户端的流量。您为侦听器定义的规则确定负载均衡器如何将请求路由到您注册的目标。例如 EC2 实例。

侦听器配置

侦听器支持以下协议和端口:

  • 协议:HTTP、HTTPS

  • 端口:1-65535

可以使用 HTTPS 侦听器将加密和解密的工作交给负载均衡器完成,以便应用程序可以专注于其业务逻辑。如果侦听器协议为 HTTPS,您必须在侦听器上部署至少一个 SSL 服务器证书。有关更多信息,请参阅 为您的 Application Load Balancer 创建 HTTPS 侦听器

如果必须确保目标解密 HTTPS 流量而不是负载均衡器,则可以在端口 443 上使用 TCP 侦听器创建网络负载均衡器。通过 TCP 侦听器,负载均衡器将加密流量传递到目标,而不会对其进行解密。有关 Network Load Balancer 的更多信息,请参阅 Network Load Balancers 用户指南

应用程序负载均衡器为提供原生支持。 WebSockets您可以使用 HTTP 连接升级将现有的 HTTP/1.1 连接升级为 WebSocket (wswss)连接。升级时,用于请求的 TCP 连接(到负载均衡器和到目标)会通过负载均衡器成为客户端与目标之间的永久 WebSocket 连接。您可以同时使用 WebSockets HTTP 和 HTTPS 侦听器。您为监听器选择的选项适用于 WebSocket 连接以及 HTTP 流量。有关更多信息,请参阅《Amazon CloudFront 开发者指南》中的 WebSocket 协议工作原理

Application Load Balancer 为将 HTTP/2 与 HTTPS 侦听器一起使用提供本机支持。使用一个 HTTP/2 连接最多可以并行发送 128 个请求。您可以通过协议版本使用 HTTP/2 将请求发送到目标。有关更多信息,请参阅 协议版本。由于 HTTP/2 可以更高效地使用前端连接,您可能注意到客户端与负载均衡器之间的连接较少。无法使用 HTTP/2 的服务器推送功能。

有关更多信息,请参阅 Elastic Load Balancing 用户指南中的请求路由

侦听器规则

每个侦听器都有默认操作,也称为默认规则。默认规则无法删除,并且始终在最后执行。可以创建其他规则,这些规则由优先级、一个或多个操作以及一个或多个条件组成。您可以随时添加或编辑规则。有关更多信息,请参阅 编辑规则

默认规则

创建侦听器时,请为默认规则定义操作。默认规则不能有条件。如果未满足侦听器的任一规则条件,则将执行默认规则的操作。

下面是控制台中所示的默认规则的示例:


                                侦听器的默认规则。

规则优先级

每个规则都有一个优先级。规则是按优先级顺序 (从最低值到最高值) 计算的。最后评估默认规则。您可以随时更改非默认规则的优先级。您不能更改默认规则的优先级。有关更多信息,请参阅 更新规则优先级

规则操作

每个规则操作都具有执行操作所需的类型、优先级和信息。有关更多信息,请参阅 规则操作类型

规则条件

每个规则条件都有类型和配置信息。当规则的条件满足时,将执行其操作。有关更多信息,请参阅 规则条件类型

规则操作类型

以下是侦听器规则支持的操作类型:

authenticate-cognito

[HTTPS 侦听器] 使用 Amazon Cognito 验证用户身份。有关更多信息,请参阅 使用 Application Load Balancer 验证用户身份

authenticate-oidc

[HTTPS 侦听器] 使用符合 OpenID Connect (OIDC) 条件的身份提供商验证用户身份。

fixed-response

返回自定义 HTTP 响应。有关更多信息,请参阅 固定响应操作

forward

将请求转发到指定目标组。有关更多信息,请参阅 转发操作

redirect

将请求从一个 URL 重定向到另一个。有关更多信息,请参阅 重定向操作

先执行优先级最低的操作。每条规则必须包含以下操作之一:forwardredirectfixed-response,并且其必须为要执行的最后一个操作。

如果协议版本是 gRPC 或 HTTP/2,则唯一支持的操作是 forward 操作。

固定响应操作

您可以使用 fixed-response 操作删除客户端请求并返回自定义 HTTP 响应。您可以使用此操作返回 2XX、4XX 或 5XX 响应代码和可选的消息。

采取 fixed-response 操作时,操作和重定向目标的 URL 记录在访问日志中。有关更多信息,请参阅 访问日志条目。成功 fixed-response 操作的计数在 HTTP_Fixed_Response_Count 指标中报告。有关更多信息,请参阅 Application Load Balancer 指标

例 AWS CLI 固定响应操作示例

您可以在创建或修改规则时指定操作。有关更多信息,请参阅 create-rulemodify-rule 命令。以下操作发送具有指定状态代码和消息正文的固定响应。

[ { "Type": "fixed-response", "FixedResponseConfig": { "StatusCode": "200", "ContentType": "text/plain", "MessageBody": "Hello world" } } ]

转发操作

您可以使用 forward 操作,将请求路由到一个或多个目标组。如果为某个 forward 操作指定多个目标组,您必须为每个目标组指定权重。每个目标组权重都是一个介于 0 到 999 之间的值。对于将侦听器规则与加权目标组匹配的请求,会根据这些目标组的权重分配给这些目标组。例如,如果指定两个目标组,每个目标组的权重为 10,则每个目标组将接收一半的请求。如果指定两个目标组,一个权重为 10,另一个权重为 20,则权重为 20 的目标组接收的请求将是另一个目标组的两倍。

默认情况下,配置规则以便在加权目标组之间分配流量时,并不能保证支持粘性会话。为了确保支持粘性会话,请为规则启用目标组粘性。当负载均衡器首次将请求路由到加权目标组时,它会生成一个名为的 Cookie AWSALBTG ,用于对有关选定目标组的信息进行编码,对 Cookie 进行加密,并将该 Cookie 包含在对客户端的响应中。客户端应该在向负载均衡器的后续请求中包含它收到的 cookie。当负载均衡器收到与启用目标组粘性的规则匹配并且包含 Cookie 的请求时,请求将路由到 Cookie 中指定的目标组。

Application Load Balancer 不支持 URL 编码的 Cookie 值。

对于 CORS(跨源资源共享)请求,某些浏览器需要 SameSite=None; Secure 来启用粘性。在这种情况下,Elastic Load Balancing 会生成第二个 cookie AWSALBTGCORS,其中包含与原始粘性 cookie 相同的信息以及此SameSite属性。客户端会同时收到这两个 Cookie。

例 带有一个目标组的转发操作示例

您可以在创建或修改规则时指定操作。有关更多信息,请参阅 create-rulemodify-rule 命令。以下操作将请求转发到指定的目标组。

[ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067" } ] } } ]
例 带有两个加权目标组的转发操作示例

下面的操作将根据每个目标组的权重,将请求转发到两个指定的目标组。

[ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-targets/73e2d6bc24d8a067", "Weight": 10 }, { "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-targets/09966783158cda59", "Weight": 20 } ] } } ]
例 启用粘性的转发操作示例

如果您具有一个包含多个目标组的转发操作,并且一个或多个目标组已启用了粘性会话,则必须启用目标组粘性。

下面的操作将请求转发到两个指定的目标组,并启用了目标组粘性。对于不包含粘性 Cookie 的请求,将根据每个目标组的权重进行传输。

[ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-targets/73e2d6bc24d8a067", "Weight": 10 }, { "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-targets/09966783158cda59", "Weight": 20 } ], "TargetGroupStickinessConfig": { "Enabled": true, "DurationSeconds": 1000 } } } ]

重定向操作

您可以使用 redirect 操作将客户端请求从一个 URL 重定向到另一个。根据需要,您可以将重定向配置为临时 (HTTP 302) 或永久 (HTTP 301)。

URI 包括以下组成部分:

protocol://hostname:port/path?query

您必须修改以下至少一个组成部分以避免重定向循环:协议、主机名、用户名、端口或路径。未修改的任何组成部分将保留其原始值。

协议

协议(HTTP 或 HTTPS)。您可以将 HTTP 重定向到 HTTP、将 HTTP 重定向到 HTTPS 以及将 HTTPS 重定向到 HTTPS。不能将 HTTPS 重定向到 HTTP。

hostname

主机名。主机名不区分大小写,长度最多为 128 个字符,由字母数字字符、通配符(* 和 ?)及连字符 (-) 组成。

port (远程调试端口)

端口(1 到 65535)。

path

绝对路径,以前导“/”开头。路径区分大小写,长度最多为 128 个字符,由字母数字字符、通配符(* 和 ?)、&(使用 &)及以下特殊字符组成:_-.$/~"'@:+。

查询

查询参数。最大长度为 128 个字符。

您可以通过以下保留关键字,在目标 URL 中重用原始 URL 的 URI 组成部分:

  • #{protocol} – 保留协议。在协议和查询组成部分中使用。

  • #{host} – 保留域。在主机名、路径和查询组成部分中使用。

  • #{port} – 保留端口。在端口、路径和查询组成部分中使用。

  • #{path} – 保留路径。在路径和查询组成部分中使用。

  • #{query} – 保留查询参数。在查询组成部分中使用。

执行 redirect 操作时,操作记录在访问日志中。有关更多信息,请参阅 访问日志条目。成功 redirect 操作的计数在 HTTP_Redirect_Count 指标中报告。有关更多信息,请参阅 Application Load Balancer 指标

例 使用控制台的重定向操作的示例

以下规则设置永久重定向到一个 URL,该 URL 使用 HTTPS 协议和指定的端口 (40443),但保留原始主机名、路径和查询参数。此屏幕等同于“https://#{host}:40443/#{path}?#{query}”。

New EC2 experience

                                    将请求重定向到一个 URL 的规则,该 URL 使用 HTTPS 协议和指定的端口 (40443),但保留原始域、路径和原始 URL 的查询参数。
Old EC2 experience

                                    将请求重定向到一个 URL 的规则,该 URL 使用 HTTPS 协议和指定的端口 (40443),但保留原始域、路径和原始 URL 的查询参数。

以下规则设置永久重定向到一个 URL,该 URL 包含原始协议、端口、主机名和查询参数,并使用 #{path} 关键字来创建修改的路径。此屏幕等同于“#{protocol}://#{host}:#{port}/new/#{path}?#{query}”。

New EC2 experience

                                    将请求重定向到一个 URL 的规则,该 URL 包含原始协议、端口、主机名和查询参数,并使用 #{path} 关键字来创建修改的路径。
Old EC2 experience

                                    将请求重定向到一个 URL 的规则,该 URL 包含原始协议、端口、主机名和查询参数,并使用 #{path} 关键字来创建修改的路径。
例 AWS CLI 重定向操作示例

您可以在创建或修改规则时指定操作。有关更多信息,请参阅 create-rulemodify-rule 命令。以下操作将 HTTP 请求重定向为端口 443 上的 HTTPS 请求,其主机名、路径和查询字符串与 HTTP 请求相同。

[ { "Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "Host": "#{host}", "Path": "/#{path}", "Query": "#{query}", "StatusCode": "HTTP_301" } } ]

规则条件类型

以下是规则支持的条件类型:

host-header

基于每个请求的主机名进行路由。有关更多信息,请参阅 主机条件

http-header

基于每个请求的 HTTP 标头进行路由。有关更多信息,请参阅 HTTP 标头条件

http-request-method

基于每个请求的 HTTP 请求方法路由。有关更多信息,请参阅 HTTP 请求方法条件

path-pattern

基于请求 URL 中的路径模式进行路由。有关更多信息,请参阅 路径条件

query-string

基于查询字符串中的键/值对或值进行路由。有关更多信息,请参阅 查询字符串条件

source-ip

基于每个请求的源 IP 地址进行路由。有关更多信息,请参阅 源 IP 地址条件

每个规则可以有选择地最多包含以下条件之一:host-headerhttp-request-methodpath-patternsource-ip。每个规则还可以有选择地包含以下每个条件中的一个或多个:http-headerquery-string

您可以为每个条件指定最多三个匹配评估。例如,对于每个 http-header 条件,您最多可以指定三个字符串,以与请求中的 HTTP 标头的值进行比较。如果其中一个字符串与 HTTP 标头的值匹配,则满足条件。若要要求所有字符串都匹配,请为每个匹配评估创建一个条件。

您可以为每条规则指定最多五个匹配评估。例如,您可以创建一个具有五个条件的规则,其中每个条件都有一个匹配评估。

您可以在 http-headerhost-headerpath-patternquery-string 条件的匹配评估中包含通配符。每条规则的通配符上限为五个。

规则仅应用于可见的 ASCII 字符;不包括控制字符(0x00 到 0x1f 和 0x7f)。

有关演示,请参阅高级请求路由

HTTP 标头条件

您可以使用 HTTP 标头条件来配置基于请求的 HTTP 标头路由请求的规则。您可以指定标准或自定义 HTTP 标头字段的名称。标头名称和匹配评估不区分大小写。比较字符串支持以下通配符:*(匹配 0 个或多个字符)和 ?(完全匹配 1 个字符)。标头名称不支持通配符。

例 AWS CLI HTTP 标头条件示例

您可以在创建或修改规则时指定条件。有关更多信息,请参阅 create-rulemodify-rule 命令。具有与指定字符串之一匹配的 User-Agent 标头的请求满足以下条件。

[ { "Field": "http-header", "HttpHeaderConfig": { "HttpHeaderName": "User-Agent", "Values": ["*Chrome*", "*Safari*"] } } ]

HTTP 请求方法条件

您可以使用 HTTP 请求方法条件来配置基于请求的 HTTP 请求方法路由请求的规则。您可以指定标准或自定义 HTTP 方法。匹配评估区分大小写。不支持通配符;因此,方法名称必须完全匹配。

我们建议您以相同的方式路由 GET 和 HEAD 请求,因为这样可以缓存对 HEAD 请求的响应。

例 AWS CLI HTTP 方法条件示例

您可以在创建或修改规则时指定条件。有关更多信息,请参阅 create-rulemodify-rule 命令。使用指定方法的请求满足以下条件。

[ { "Field": "http-request-method", "HttpRequestMethodConfig": { "Values": ["CUSTOM-METHOD"] } } ]

主机条件

您可以使用主机条件来定义基于主机标头中的主机名路由请求的规则(也称为基于主机的路由)。这使您能够使用单个负载均衡器支持多个子域和不同的顶级域。

主机名不区分大小写,长度上限为 128 个字符,并且可包含以下任何字符:

  • A-Z、a-z、0-9

  • - .

  • *(匹配 0 个或多个字符)

  • ?(完全匹配 1 个字符)

您必须包含至少一个“.”字符。在最后一个“.”字符之后只能包含字母数字字符。

主机名示例
  • example.com

  • test.example.com

  • *.example.com

规则 *.example.comtest.example.com 匹配,但与 example.com 不匹配。

例 AWS CLI 主机标头条件示例

您可以在创建或修改规则时指定条件。有关更多信息,请参阅 create-rulemodify-rule 命令。具有与指定字符串匹配的主机标头的请求满足以下条件。

[ { "Field": "host-header", "HostHeaderConfig": { "Values": ["*.example.com"] } } ]

路径条件

您可以使用路径条件来定义基于请求中的 URL 路由请求的规则(也称为基于路径的路由)。

路径模式仅应用于 URL 的路径,而不应用于其查询参数。它仅应用于可见的 ASCII 字符;不包括控制字符(0x00 到 0x1f 和 0x7f)。

只有在 URI 标准化之后,才会执行规则评估。

路径模式区分大小写,长度最多为 128 个字符,并且可包含以下任何字符。

  • A-Z、a-z、0-9

  • _ - . $ / ~ " ' @ : +

  • &(使用 &)

  • *(匹配 0 个或多个字符)

  • ?(完全匹配 1 个字符)

如果协议版本是 gRPC,则条件可特定于程序包、服务或方法。

示例 HTTP 路径模式
  • /img/*

  • /img/*/pics

示例 gRPC 路径模式
  • /package

  • /package.service/

  • /package.service/method

路径模式用于路由请求,而不是更改请求。例如,如果一个规则的路径模式为 /img/*,此规则会将 /img/picture.jpg 的请求作为 /img/picture.jpg 的请求转发给指定目标组。

例 AWS CLI 路径模式条件示例

您可以在创建或修改规则时指定条件。有关更多信息,请参阅 create-rulemodify-rule 命令。具有包含指定字符串的 URL 的请求满足以下条件。

[ { "Field": "path-pattern", "PathPatternConfig": { "Values": ["/img/*"] } } ]

查询字符串条件

您可以使用查询字符串条件来配置基于查询字符串中的键/值对或值路由请求的规则。匹配评估不区分大小写。支持以下通配符:*(匹配 0 个或多个字符)和 ?(完全匹配 1 个字符)。

例 AWS CLI 查询字符串条件示例

您可以在创建或修改规则时指定条件。有关更多信息,请参阅 create-rulemodify-rule 命令。具有包括键/值对“version=v1”或任意键设置为“example”的查询字符串的请求满足以下条件。

[ { "Field": "query-string", "QueryStringConfig": { "Values": [ { "Key": "version", "Value": "v1" }, { "Value": "*example*" } ] } } ]

源 IP 地址条件

您可以使用源 IP 地址条件来配置基于请求的源 IP 地址路由请求的规则。必须以 CIDR 格式指定 IP 地址。可以使用 IPv4 和 IPv6 地址。不支持通配符。不能为源 IP 规则条件指定 255.255.255.255/32 CIDR。

如果客户端位于代理之后,则这是代理的 IP 地址,而不是客户端的 IP 地址。

X-Forwarded-For 标头中的地址不满足此条件。要搜索 X-Forwarded-For 标头中的地址,请使用 http-header 条件。

例 AWS CLI 源 IP 条件示例

您可以在创建或修改规则时指定条件。有关更多信息,请参阅 create-rulemodify-rule 命令。源 IP 地址位于某个指定的 CIDR 块中的请求满足以下条件。

[ { "Field": "source-ip", "SourceIpConfig": { "Values": ["192.0.2.0/24", "198.51.100.10/32"] } } ]