外部 HTTP(S) 负载平衡概览

本文档介绍了配置 Google Cloud 外部 HTTP(S) 负载平衡时需要了解的概念。

如需了解各种 Google Cloud 负载平衡器之间的具体区别,请参阅以下文档:

使用场景

外部 HTTP(S) 负载平衡器适用于许多使用场景。本部分提供了一些概要示例。

使用多种后端类型实现负载平衡

外部 HTTP(S) 负载平衡支持以下后端类型:

一种常见的使用场景是在服务之间对流量进行负载平衡。在以下示例中,外部 IPv4 和 IPv6 客户端可以使用同一基准网址及路径 /api/video/images 来请求 API、视频、图片内容。

外部 HTTP(S) 负载平衡器的网址映射指定:

  • 针对路径 /api 的请求会转到具有虚拟机实例组区域 NEG 后端的后端服务。
  • 针对路径 /images 的请求会转到具有 Cloud Storage 后端的后端存储分区
  • 针对路径 /video 的请求会转到指向互联网 NEG 的后端服务;该互联网 NEG 包含位于 Google Cloud 外部的本地的外部端点。

当客户端将请求发送到负载平衡器的外部 IPv4 或 IPv6 地址时,负载平衡器会根据网址映射评估请求,并将请求发送到正确的服务。

下图说明了此使用场景。

带有自定义源站的负载平衡图(点击放大)
带有自定义源站的负载平衡图(点击放大)

在每个后端服务中,您都可以选择启用 Cloud CDN 和 Google Cloud Armor。如果您将 Google Cloud Armor 与 Cloud CDN 配合使用,则仅对动态内容请求、缓存未命中或其他发往您的源站服务器的请求强制执行安全政策。即使下游 Google Cloud Armor 安全政策会阻止该请求到达 CDN 源站服务器,系统也会提供缓存命中。

在后端存储分区中,系统支持 Cloud CDN,但不支持 Google Cloud Armor。

三层 Web 服务

您可以使用外部 HTTP(S) 负载平衡来支持传统的三层 Web 服务。以下示例展示了如何使用三种类型的 Google Cloud 负载平衡器来为以下三个层级调节流量。每个层级的负载平衡器类型取决于流量类型:

图中显示了流量在各层级之间的移动方式:

  1. 外部 HTTP(S) 负载平衡器(本概览的主题)将来自互联网的流量分配到多个不同地区的一组 Web 前端实例组。
  2. 这些前端会将 HTTP(S) 流量发送到一组地区内部 HTTP(S) 负载平衡器。
  3. 内部 HTTP(S) 负载平衡器将流量分配到中间件实例组。
  4. 这些中间件实例组将流量发送到内部 TCP/UDP 负载平衡器,进而将流量负载平衡到数据存储集群。
多层应用中内部层的基于第 7 层的路由(点击放大)
多层应用中内部层的基于第 7 层的路由

跨地区负载平衡

跨地区负载平衡的表示

在优质层级中配置外部 HTTP(S) 负载平衡器时,它会使用全局外部 IP 地址,并且可以根据邻近度,智能地将用户的请求路由到最近的后端实例组或 NEG。例如,如果您在北美、欧洲和亚洲设置实例组,并将其关联到负载平衡器的后端服务,则系统会自动将世界各地的用户请求发送到离用户最近的虚拟机,其中假设虚拟机通过运行状况检查并具有足够的容量(由平衡模式定义)。如果最近的虚拟机都运行状况不佳,或者最近的实例组已达到容量上限,而另一个实例组未达到容量上限,则负载平衡器会自动将请求发送到具有容量的次近地区。


基于内容的负载平衡

基于内容的负载平衡的表示

HTTP(S) 负载平衡使用网址映射根据请求的主机名和/或请求路径选择后端服务,从而支持基于内容的负载平衡。例如,您可以使用一组实例组或 NEG 来处理视频内容,而使用另一组实例组来处理其他所有内容。

您还可以将 HTTP(S) 负载平衡与 Cloud Storage 存储分区搭配使用。设置负载平衡器后,便可向其中添加 Cloud Storage 存储分区


创建组合式负载平衡器

基于内容的跨地区负载平衡的表示

您可以在优质层级中配置外部 HTTP(S) 负载平衡器,以使用多个后端服务同时提供基于内容的跨地区负载平衡,其中每个后端服务在多个地区都有后端实例组或 NEG。您可以组合和扩展使用场景,以配置满足您需求的外部 HTTP(S) 负载平衡器。


配置示例

如果您想直接构建有效的负载平衡器以用于测试,请参阅设置简单的外部 HTTP 负载平衡器设置简单的外部 HTTPS 负载平衡器

如需查看使用基于内容的跨地区负载平衡的更复杂示例,请参阅创建 HTTPS 负载平衡器

连接在 HTTP(S) 负载平衡中的工作原理

外部 HTTP(S) 负载平衡是一种服务,由许多称为 Google Front End (GFE) 的代理实现。不只一个代理。在优质层级中,从各个接入点通告相同的全局外部 IP 地址,并将流量定向到离客户端最近的 GFE。

根据您的客户端位置,多个 GFE 可以启动与后端的 HTTP(S) 连接。从 GFE 发送的数据包的来源 IP 地址,来自运行状况检查探测器所用的同一范围:35.191.0.0/16130.211.0.0/22

根据后端服务配置,每个 GFE 用于连接到后端的协议可以是 HTTP、HTTPS 或 HTTP/2。如果是 HTTP 或 HTTPS,则 HTTP 版本为 HTTP 1.1。根据 HTTP 1.1 规范的规定,HTTP keepalive 默认处于启用状态。GFE 使用 keepalive 超时 600 秒,您无法配置此项。但是,您可以通过设置后端服务超时来配置请求/响应超时。如需了解详情,请参阅超时和重试

HTTP keepalive 会尝试高效使用相同的 TCP 会话;但无法保证。虽然密切相关,但 HTTP keepalive 和 TCP 空闲超时并不相同。

HTTP 连接和 TCP 会话的数量因连接的 GFE 数量、连接到 GFE 的客户端数量、后端协议以及后端部署位置而异。

如需了解详情,请参阅解决方案指南中的 HTTP(S) 负载平衡的工作原理:使用全局负载平衡进行应用容量优化。

架构和资源

下图显示了外部 HTTP(S) 负载平衡器所需的 Google Cloud 资源。

HTTP(S) 负载平衡组件(点击放大)
HTTP(S) 负载平衡组件

外部 HTTP(S) 负载平衡器由以下资源定义:

  • 外部转发规则指定外部 IP 地址、端口和全局目标 HTTP(S) 代理。客户端使用 IP 地址和端口连接到负载平衡器。

  • 全局目标 HTTP(S) 代理接收来自客户端的请求。HTTP(S) 代理使用网址映射确定如何路由流量,从而实现对请求的评估。代理还可以使用 SSL 证书对通信进行身份验证。

  • 如果您使用的是 HTTPS 负载平衡,则目标 HTTPS 代理会使用全局 SSL 证书向客户端证明其身份。目标 HTTPS 代理支持最多一个记录在案的 SSL 证书编号

  • HTTP(S) 代理使用全局网址映射根据 HTTP 特性(例如请求路径、Cookie 或标头)确定路由。根据确定的路由,代理会将客户端请求转发到特定的后端服务或后端存储分区。网址映射可以指定其他操作,例如向客户端发送重定向。

  • 后端服务后端存储分区将请求分配到运行状况良好的后端

  • 必须有一个或多个后端连接到后端服务或后端存储分区。后端可以是采用以下任一配置的实例组、NEG 或存储分区:

    • 代管式实例组(区域或地区)
    • 非代管实例组(区域性)
    • 网络端点组(区域)
    • 网络端点组(互联网)
    • Cloud Storage 存储分区

    您不能在同一后端服务上同时具有实例组和 NEG。

  • 全局运行状况检查会定期监控您的后端的就绪情况。这样可以降低向无法处理请求的后端发送请求的风险。

  • 防火墙,可让您的后端接受运行状况检查探测。

来源 IP 地址

每个后端虚拟机 (VM) 实例或容器所识别的数据包的来源 IP 地址是以下范围内的 IP 地址:

  • 35.191.0.0/16
  • 130.211.0.0/22

经过负载平衡处理的实际流量的来源 IP 地址与运行状况检查探测 IP 地址范围相同。

后端所识别的流量的来源 IP 地址不是负载平衡器的 Google Cloud 外部 IP 地址。换句话说,存在两个 HTTP:SSL 或 TCP 会话:

  • 会话 1(从原始客户端到负载平衡器 (GFE)):

    • 来源 IP 地址:原始客户端(如果客户端位于 NAT 后面,则为外部 IP 地址)。
    • 目的地 IP 地址:您的负载平衡器的 IP 地址。
  • 会话 2(从负载平衡器 (GFE) 到后端虚拟机或容器):

    • 来源 IP 地址:以下范围之一的某个 IP 地址:35.191.0.0/16130.211.0.0/22

      您无法预测实际的来源地址。

    • 目的地 IP 地址:Virtual Private Cloud (VPC) 网络中的后端虚拟机或容器的内部 IP 地址。

客户端与负载平衡器的通信

  • 客户端可以使用 HTTP 1.1 或 HTTP/2 协议与负载平衡器进行通信。
  • 使用 HTTPS 时,新型客户端默认使用 HTTP/2。此配置是在客户端而非 HTTPS 负载平衡器上控制的。
  • 您无法通过更改负载平衡器的配置来停用 HTTP/2。不过,您可以将某些客户端配置为使用 HTTP 1.1 而不是 HTTP/2。例如,在 curl 中,请使用 --http1.1 参数。
  • HTTPS 负载平衡器不支持基于客户端证书的身份验证(也称为双向 TLS 身份验证)。

开放端口

外部 HTTP(S) 负载平衡器是反向代理负载平衡器。负载平衡器终结传入的连接,然后打开从负载平衡器通向后端的新连接。反向代理功能由 Google Front End (GFE) 提供。

您设置的防火墙规则会阻止从 GFE 流向后端的流量,但不会阻止流向 GFE 的传入流量。

外部 HTTP(S) 负载平衡器具有许多开放端口,可支持在同一架构上运行的其他 Google 服务。如果您针对 Google Cloud 外部 HTTP(S) 负载平衡器的外部 IP 地址运行安全或端口扫描,可能有其他端口看上去处于开放状态。

这不会对外部 HTTP(S) 负载平衡器造成影响。在定义外部 HTTP(S) 负载平衡器时使用的外部转发规则只能引用 TCP 端口 80、8080、443。目的地端口为其他 TCP 端口的流量不会转发到负载平衡器的后端。

组件

以下是外部 HTTP(S) 负载平衡器的组件。

转发规则和地址

转发规则会按照 IP 地址、端口和协议将流量路由到由目标代理、网址映射和一个或多个后端服务组成的负载平衡配置。

每条转发规则都会提供一个 IP 地址,可用于应用的 DNS 记录。不需要基于 DNS 的负载平衡。 您可以指定要使用的 IP 地址,也可以让 Cloud Load Balancing 为您分配一个。

  • HTTP 负载平衡器的转发规则只能引用 TCP 端口 80 和 8080。
  • HTTPS 负载平衡器的转发规则只能引用 TCP 端口 443。

外部 HTTP(S) 负载平衡器所需的转发规则类型取决于负载平衡器所属的网络服务层级

  • 优质层级中的外部 HTTP(S) 负载平衡器使用全局外部转发规则。
  • 标准层级中的外部 HTTP(S) 负载平衡器使用地区外部转发规则。

目标代理

目标代理会终结来自客户端的 HTTP(S) 连接。一条或多条转发规则会将流量定向到目标代理,目标代理会查询网址映射以确定如何将流量路由到后端。

代理将 HTTP 请求/响应标头设置为如下内容:

  • Via: 1.1 google(请求和响应)
  • X-Forwarded-Proto: [http | https](仅限于请求)
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options>(仅限请求)
    包含 Cloud Trace 的参数。

如果默认标头无法满足您的需要,您可以创建自定义请求和响应标头。如需详细了解此功能,请参阅创建自定义标头

请勿依赖代理来保留请求或响应标头名称的大小写。例如,Server: Apache/1.0 响应标头可能会在客户端显示为 server: Apache/1.0

主机标头

当负载平衡器发出 HTTP 请求时,负载平衡器会保留原始请求的主机标头。

X-Forwarded-For 标头

负载平衡器会将两个 IP 地址附加到 X-Forwarded-For 标头:

  • 连接到负载平衡器的客户端的 IP 地址

  • 负载平衡器的 IP 地址

如果传入请求中没有 X-Forwarded-For 标头,则这两个 IP 地址为整个标头值。如果请求具有 X-Forwarded-For 标头,则两个 IP 地址前保留其他信息(例如代理在连接到负载平衡器时记录的 IP 地址)。负载平衡器不会验证此标头中最后两个 IP 地址之前的任何 IP 地址。

如果您在后端实例上运行代理,则此代理通常会向 X-Forwarded-For 标头附加更多信息,您的软件可能需要考虑这一点。来自负载平衡器的代理请求来自 130.211.0.0/2235.191.0.0/16 范围内的 IP 地址,后端实例上的代理可能记录此地址以及后端实例自己的 IP 地址。

网址映射

网址映射定义了匹配模式,以便根据网址将请求路由到相应的后端服务。定义默认服务是为了处理所有与指定的主机规则或路径匹配规则不相符的请求。在某些情况(例如跨地区负载平衡示例)下,您可能不会定义任何网址规则,仅依赖于默认服务。对于基于内容的流量路由,网址映射可让您通过检查网址的各部分来分流您的流量,从而将请求发送到不同组的后端。

SSL 证书

如果您使用的是基于 HTTPS 的负载平衡,则必须在目标 HTTPS 代理上安装一个或多个 SSL 证书

目标 HTTPS 代理使用这些证书来保护负载平衡器和客户端之间的通信。

如需了解 SSL 证书限制和配额,请参阅负载平衡配额页面上的 SSL 证书

为获得最佳安全性,请为 HTTPS 负载平衡器部署使用端到端加密。如需了解详情,请参阅从负载平衡器到后端的加密

如需了解有关 Google 如何对用户流量进行加密的一般信息,请参阅 Google Cloud 中的传输加密白皮书。

SSL 政策

利用 SSL 政策,您可以控制 HTTPS 负载平衡器与 HTTPS 客户端协商的 SSL 的功能。

默认情况下,HTTPS 负载平衡所用的一组 SSL 功能具有良好的安全性和广泛的兼容性,但某些应用需要更好地控制用于其 HTTPS 或 SSL 连接的 SSL 版本和加密方式。您可以定义 SSL 政策来控制负载平衡器协商的 SSL 的功能,并将 SSL 政策与目标 HTTPS 代理相关联。

控制 TLS 终结的地理位置

HTTPS 负载平衡器可在全球各处的地理位置终结 TLS,从而最大程度减少客户端与负载平衡器之间的延迟时间。如果您需要控制 TLS 终结的地理位置,应改用 Google Cloud 网络负载平衡,并在位于所需地区的后端上终结 TLS。

后端服务

后端服务向负载平衡器提供配置信息。外部 HTTP(S) 负载平衡器必须具有至少一个后端服务,并且可以具有多个后端服务。

负载平衡器使用后端服务中的信息将传入的流量定向到一个或多个挂接的后端。

后端服务的后端可以是实例组网络端点组 (NEG),但不能是这两者的组合。添加后端实例组或 NEG 时,您可以指定平衡模式,用于定义分配请求的方法和目标容量。如需了解详情,请参阅负载分配算法

HTTP(S) 负载平衡支持 Cloud Load Balancing 自动扩缩器,通过该自动扩缩器,用户可以对后端服务中的实例组进行自动扩缩。如需了解详情,请参阅根据 HTTP(S) 负载平衡服务容量进行扩缩

您可以在后端服务上启用连接排空,以确保在终结、手动移除或由自动扩缩器移除正在处理流量的实例时,对用户的干扰最小。如需了解详情,请参阅启用连接排空

对外部 HTTP(S) 负载平衡器的关联后端服务的更改不是瞬时更改。更改可能需要几分钟才能在整个网络中传播。

负载平衡器在不同网络服务层级中的行为

使用优质网络服务层级时,HTTP(S) 负载平衡是一项全球性服务。您可以在一个地区中使用多个后端服务,并且可以在多个地区中创建后端服务,这些后端全部由同一全球负载平衡器提供服务。流量将按如下方式分配给后端服务:

  1. 当用户请求传入时,负载平衡服务根据来源 IP 地址确定请求的大致来源。
  2. 负载平衡服务了解后端服务所拥有的实例的位置、实例的总体容量以及实例当前的总体使用率。
  3. 如果距离用户最近的实例具有可用容量,则请求会被转发给最近的一组实例。
  4. 发送到指定地区的传入请求会在该地区中的所有可用后端服务和实例之间均匀分配。不过,如果负载非常小,则分配可能看上去就不均匀。
  5. 如果指定地区中没有运行状况良好且有可用容量的实例,负载平衡器会改为将请求发送到具有可用容量的次近地区。

使用标准网络服务层级时,HTTP(S) 负载平衡是一种地区服务。其后端实例组或 NEG 必须全部位于负载平衡器的外部 IP 地址和转发规则使用的地区内。

运行状况检查

每个后端服务还会针对每个可用的实例指定执行哪种运行状况检查。为了让运行状况检查探测能够正常进行,您必须创建一条防火墙规则,以允许来自 130.211.0.0/2235.191.0.0/16 的流量到达您的实例。

如需详细了解运行状况检查,请参阅创建运行状况检查

后端协议

为外部 HTTP(S) 负载平衡器配置后端服务时,您需要设置后端服务用来与后端通信的协议。您可以选择 HTTP、HTTPS 或 HTTP/2。负载平衡器仅使用您指定的协议。如果负载平衡器无法使用指定的协议与后端协商连接,将不会回退为使用其他两种协议之一。

如果您使用 HTTP/2,则必须使用 TLS。系统不支持未加密的 HTTP/2。

您最好使用协议与后端服务的协议相匹配的运行状况检查,不过这并非强制性要求。例如,HTTP/2 运行状况检查能够最准确地测试后端的 HTTP/2 连接性。

将 gRPC 与您的 Google Cloud 应用搭配使用

gRPC 是远程过程调用的开源框架。它基于 HTTP/2 标准运行。适合使用 gRPC 的场景如下:

  • 延迟时间短、扩缩能力强的分布式系统
  • 开发与云服务器通信的移动客户端
  • 设计必须准确、高效并且独立于语言的新协议
  • 支持扩展、身份验证和日志记录的分层设计

如需将 gRPC 与您的 Google Cloud 应用搭配使用,您必须通过 HTTP/2 以端到端方式对请求进行代理。如需使用外部 HTTP(S) 负载平衡器实现此目的,请执行以下操作:

  1. 配置 HTTPS 负载平衡器。
  2. 启用 HTTP/2 作为从负载平衡器到后端的协议。

在进行 SSL 握手过程中,负载平衡器会通过使用 ALPN TLS 扩展程序与客户端协商 HTTP/2。

负载平衡器仍然可以与某些客户端协商 HTTPS,或接受配置为在负载平衡器和后端实例之间使用 HTTP/2 的外部 HTTP(S) 负载平衡器上的不安全 HTTP 请求。这些 HTTP 或 HTTPS 请求由负载平衡器进行转换,以便通过 HTTP/2 将请求代理到后端实例。

如果要将 HTTP/2 与 Google Kubernetes Engine Ingress 搭配使用或者将 gRPC 和 HTTP/2 与 Ingress 搭配使用来配置外部 HTTP(S) 负载平衡器,请参阅 HTTP/2 与 Ingress 搭配使用实现负载平衡

如需了解如何排查 HTTP/2 问题,请参阅排查后端 HTTP/2 问题

如需了解 HTTP/2 限制,请参阅 HTTP/2 限制

后端存储分区

后端存储分区将传入的流量定向到 Cloud Storage 存储分区

如下图所示,您可以让负载平衡器向存储分区发送路径为 /static 的流量,向其他后端发送所有其他请求。

使用 HTTP(S) 负载平衡将流量分配到各种后端类型(点击可放大)
使用 HTTP(S) 负载平衡将流量分配到各种后端类型(点击放大)

如需查看展示如何将存储分区添加到现有负载平衡器的示例,请参阅使用后端存储分区设置负载平衡器

防火墙规则

后端实例必须允许来自负载平衡器 GFE/运行状况检查范围的连接。这意味着您必须创建防火墙规则以允许来自 130.211.0.0/2235.191.0.0/16 的流量到达您的后端实例或端点。这些 IP 地址范围将用作运行状况检查数据包以及发送到后端的所有负载平衡数据包的来源。

您为此防火墙规则配置的端口必须允许流量传入后端实例或端点:

  • 您必须允许每个转发规则使用的端口
  • 您必须允许针对每个后端服务配置的每个运行状况检查所使用的端口

防火墙规则在虚拟机实例级层(而不是在 Google Front End (GFE) 代理上)实现。您无法使用 Google Cloud 防火墙规则来阻止流量到达负载平衡器。

如需详细了解运行状况检查探测以及必须允许来自 130.211.0.0/2235.191.0.0/16 的流量的原因,请参阅探测 IP 地址范围和防火墙规则

返回路径

Google Cloud 会使用未在您的 VPC 网络中定义的特殊路由来执行运行状况检查。如需了解详情,请参阅负载平衡器返回路径

负载分配算法

将后端实例组或 NEG 添加到后端服务时,您可指定一种平衡模式,用于定义衡量后端负载和目标容量的方法。外部 HTTP(S) 负载平衡支持两种平衡模式:

  • 对于实例组或 NEG,RATE 是每秒的目标最大请求次数 (RPS) 或查询次数 (QPS)。如果所有后端都达到或超过容量,则实际 RPS/QPS 可以超过目标最大 RPS/QPS。

  • UTILIZATION 是实例组中虚拟机的后端利用率。

在 Google Front End (GFE) 向后端实例发送请求之前,GFE 会估算哪些后端实例的容量可用于接收请求。系统会主动进行此容量估算,而不是在收到请求的同时进行估算。GFE 会定期接收有关可用容量的信息,并相应地分配传入请求。

容量的含义部分取决于平衡模式。对于 RATE 模式,它相对简单:GFE 精确地确定它每秒可以分配的请求数。基于 UTILIZATION 的负载平衡更复杂:负载平衡器检查实例的当前利用率,然后估算每个实例可以处理的查询负载。此估算值会随着时间的推移随实例利用率和流量模式的变化而变化。

这两个因素(容量估算和主动分配)都会影响各个实例之间的分布。因此,Cloud Load Balancing 的行为与简单的轮询负载平衡器不同,后者在两个实例之间精确地 (50:50) 分布请求。相反,Google Cloud 负载平衡会尝试针对每个请求优化后端实例选择。

如需了解详情,请参阅流量分配

如需详细了解平衡模式,请参阅平衡模式

Network Service Tiers

当外部 HTTP(S) 负载平衡器属于优质层级时,发送到负载平衡器的请求会传递到最靠近用户的地区中的后端实例组或 NEG(如果该地区中的后端有可用容量)。(可用容量由负载平衡器的平衡模式配置。)

当外部 HTTP(S) 负载平衡器属于标准层级时,其后端实例组或 NEG 必须全部位于负载平衡器的外部 IP 地址和转发规则使用的地区内。

地区和区域

选择地区后:

  • 在地区内的多个区域中配置后端时,外部 HTTP(S) 负载平衡器会尝试尽可能跨区域均匀平衡请求,具体取决于后端实例容量和会话亲和性部分。

  • 在区域内,外部 HTTP(S) 负载平衡器会尝试使用负载平衡算法来平衡请求,具体取决于可用容量和会话亲和性。

会话亲和性

只要后端运行状况良好且有可用容量,会话亲和性就会根据配置的平衡模式,尽力尝试将来自特定客户端的请求发送到同一个后端。

Google Cloud HTTP(S) 负载平衡提供三种类型的会话亲和性:

  • 无。没有为负载平衡器设置会话亲和性。
  • 客户端 IP 亲和性将来自同一客户端 IP 地址的请求发送到同一个后端。
  • 生成的 Cookie 亲和性会在发出第一个请求时设置客户端 Cookie,然后将带有该 Cookie 的请求发送到同一后端。

使用会话亲和性时,我们建议您使用 RATE 平衡模式,而不是 UTILIZATION。如果您将平衡模式设置为每秒请求次数 (RPS),则会话亲和性的效果最佳。

WebSocket 支持

当您使用 HTTP 或 HTTPS 作为后端协议时,基于 Google Cloud HTTP(S) 的负载平衡器可以为 WebSocket 协议提供原生支持。负载平衡器无需进行任何配置即可代理 WebSocket 连接。

WebSocket 协议提供客户端和服务器之间的全双工通信通道。该通道由 HTTP(S) 请求发起。如需详细了解该协议,请参阅 RFC 6455

如果负载平衡器识别到来自 HTTP(S) 客户端的 WebSocket Upgrade 请求,并且后端实例为该请求返回了成功的 Upgrade 响应,则负载平衡器会在当前连接期间代理双向流量。如果后端实例未返回成功的 Upgrade 响应,则负载平衡器会关闭连接。

WebSocket 连接的超时时间取决于负载平衡器的可配置后端服务超时,默认为 30 秒。该超时适用于 WebSocket 连接,无论其是否正在使用。如需详细了解后端服务超时及其配置方式,请参阅超时和重试

WebSocket 的会话亲和性与其他任何请求的运作方式相同。如需了解详情,请参阅会话亲和性

HTTPS 负载平衡对 QUIC 协议的支持

HTTPS 负载平衡支持负载平衡器和客户端之间连接的 QUIC 协议。QUIC 为传输层协议,可提供与 TCP 类似的拥塞控制和与用于 HTTP/2 的 SSL/TLS 相当的安全性,同时具有更高的性能。QUIC 可以更快地启动客户端连接,消除了多路复用流中的队头阻塞,并且支持客户端 IP 地址更改时的连接迁移。

QUIC 会影响客户端与负载平衡器之间的连接,但不会影响负载平衡器与其后端之间的连接。

目标代理的 QUIC 覆盖设置可让您启用以下功能之一:

  • 如有可能,为负载平衡器协商 QUIC。
  • 始终为负载平衡器停用 QUIC。

如果您没有为 QUIC 覆盖设置指定值,则允许 Google 对何时使用 QUIC 进行管理。只有在 gcloud 命令行工具中的 --quic-override 标志设置为 ENABLE 或者 REST API 中的 quicOverride 标志设置为 ENABLE 时,Google 才会启用 QUIC。

如需了解如何启用和停用 QUIC 支持,请参阅目标代理。您可以按以下方式启用或停用 QUIC 支持:

如何协商 QUIC

如果启用了 QUIC,负载平衡器可以向客户端通告其 QUIC 功能,以便支持 QUIC 的客户端尝试与 HTTPS 负载平衡器建立 QUIC 连接。实施得当的客户端在无法建立 QUIC 连接时始终回退为使用 HTTPS 或 HTTP/2。因此,在负载平衡器中启用或停用 QUIC 不会影响负载平衡器连接到客户端的能力。

当您在 HTTPS 负载平衡器中启用 QUIC 时,某些情况会导致您的客户端回退为使用 HTTPS 或 HTTP/2 而不是协商 QUIC。这些情况包括:

  • 客户端支持的 QUIC 版本与 HTTPS 负载平衡器支持的 QUIC 版本不兼容。
  • 负载平衡器检测到 UDP 流量阻塞或速率受限以致 QUIC 无法工作。
  • 为 HTTPS 负载平衡器暂时停用 QUIC,以解决 Bug、漏洞或其他问题。

当由于这些情况,连接回退到 HTTPS 或 HTTP/2 时,我们不会将此视为负载平衡器故障。

在启用 QUIC 之前,请确保您的工作负载可接受上述行为。

SSL 证书

您必须针对目标 HTTPS 代理引用一个或多个 SSL 证书

目标 HTTPS 代理会使用这些证书来保护 Google Front End (GFE) 和客户端之间的通信。这些证书可以是自行管理的 SSL 证书或 Google 管理的 SSL 证书。

如需了解 SSL 证书限制和配额,请参阅负载平衡配额页面上的 SSL 证书

为了获得最佳安全性,您还可以加密从 GFE 到后端的流量。如需了解详情,请参阅从负载平衡器到后端的加密

如需了解有关 Google 如何对用户流量进行加密的一般信息,请参阅 Google Cloud 中的传输加密白皮书。

TLS 支持

默认情况下,HTTPS 目标代理在终结客户端 SSL 请求时仅接受 TLS 1.0、1.1、1.2 和 1.3。您可以使用 SSL 政策来更改此默认行为并控制负载平衡器与客户端协商 SSL 的方式。

当负载平衡器使用 HTTPS 作为后端服务协议时,它可以跟后端协商使用 TLS 1.0、1.1 或 1.2。

超时和重试

HTTP(S) 负载平衡有两种截然不同的超时:
  • 可配置的 HTTP 后端服务超时:表示负载平衡器等待您的后端返回完整 HTTP 响应的时间。后端服务超时的默认值为 30 秒。在以下任一情况下,请考虑延长此超时:

    • 您预计后端需要更长时间才能返回 HTTP 响应。
    • 您看到带有 jsonPayload.statusDetail client_timed_out 的 HTTP 408 响应。
    • 连接升级到 WebSocket

    对于通过负载平衡器发送的 WebSocket 流量,后端服务超时被解释为 WebSocket 连接可以保持打开状态(无论是否空闲)的最长时间。如需了解详情,请参阅后端服务设置

  • TCP 会话超时:其值固定为 10 分钟(600 秒)。此会话超时有时称为 keepalive 或空闲超时,并且其值无法通过修改后端服务进行配置。为了防止后端过早关闭连接,您必须配置后端使用的 Web 服务器软件,设置大于 600 秒的 keepalive 超时。此超时不适用于 WebSocket

下表说明了修改常用 Web 服务器软件的 keepalive 超时需要进行的更改:

Web 服务器软件 参数 默认设置 推荐设置
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

负载平衡器在特定情况(例如达到后端服务超时时间时)下会重试失败的 GET 请求。它不会重试失败的 POST 请求。重试次数以两次为限。重试请求仅会为最终响应生成一个日志条目。

如需了解详情,请参阅 HTTP(S) 负载平衡日志记录和监控

Ingress 支持 WebSocket 协议。

非法的请求和响应处理

外部 HTTP(S) 负载平衡器会因为许多原因阻止客户端请求和后端响应到达后端或客户端。有些是为了严格遵循 HTTP/1.1 合规要求,有些则是为了避免数据意外传入或传出后端。您无法停用这些检查。

为了满足 HTTP/1.1 合规要求,负载平衡器会阻止具有以下特征的请求和/或响应:

  • 它无法解析请求的第一行。
  • 标头缺少 : 分隔符。
  • 标头或第一行包含无效字符。
  • 内容长度不是有效数字,或者有多个内容长度标头。
  • 存在多个传输编码密钥,或者存在无法识别的传输编码值。
  • 存在非数据块正文且没有指定内容长度。
  • 正文数据块无法解析。这是某些数据到达后端的唯一情况。负载平衡器会在收到无法解析的数据块时关闭与客户端和后端的连接。

如果存在以下任一情况,负载平衡器便会阻止请求:

  • 请求标头和请求网址的总大小超过外部 HTTP(S) 负载平衡的请求标头大小上限。
  • 请求方法不允许有正文,但请求有正文。
  • 请求包含 Upgrade 标头,但 Upgrade 标头并没有用来启用 WebSocket 连接。
  • HTTP 版本未知。

如果存在以下任一情况,负载平衡器便会阻止后端的响应:

  • 响应标头的总大小超过外部 HTTP(S) 负载平衡的响应标头大小上限。
  • HTTP 版本未知。

规范和限制

  • HTTP(S) 负载平衡支持 HTTP/1.1 100 Continue 响应。

HTTP/2 限制

  • 在负载平衡器和实例之间使用 HTTP/2 时,需要与实例之间建立的 TCP 连接数量要比使用 HTTP(S) 时多得多。目前,HTTP/2 不支持连接池;连接池是一项优化功能,可通过 HTTP(S) 减少这些连接的数量。
  • 在负载平衡器和后端之间使用 HTTP/2 时,不支持以下功能:
    • 服务器推送
    • WebSocket
  • Google Cloud API 或 Cloud Console 中不显示 gRPC 错误率和请求量。如果 gRPC 端点返回错误,则负载平衡器日志和监控数据会报告“OK 200”HTTP 响应代码。

使用 Cloud CDN 的限制

  • 您无法使用相同的后端服务启用 Identity-Aware Proxy 或 Cloud CDN。如果您尝试这样做,配置过程会失败。

后续步骤