外部應用程式負載平衡器簡介

本文介紹的概念，有助於您瞭解如何設定外部應用程式負載平衡器。

外部應用程式負載平衡器是以 Proxy 為基礎的第 7 層負載平衡器，可讓您透過單一外部 IP 位址執行服務及調度服務資源。外部應用程式負載平衡器會將 HTTP 和 HTTPS 流量分配給託管於各種Cloud de Confiance 平台 (例如 Compute Engine、Google Kubernetes Engine (GKE) 和 Cloud Storage) 的後端，以及透過網際網路或混合式連線連線的外部後端。詳情請參閱「應用程式負載平衡器總覽：使用案例」。

運作模式

這個負載平衡器可在區域模式中使用，以下稱為區域性外部應用程式負載平衡器。負載平衡器是以開放原始碼 Envoy Proxy 為基礎的代管服務。這項服務提供進階流量管理功能，例如流量鏡像、依權重分割流量，以及依據要求或回應轉換標頭。區域模式可確保所有用戶端和後端都位於指定區域。如要從單一地理位置提供內容 (例如為了遵守法規)，請使用這個負載平衡器。

架構

部署外部應用程式負載平衡器時，需要下列資源：

• 僅限區域性外部應用程式負載平衡器：Proxy 專用子網路用於將連線從負載平衡器傳送至後端。

• 外部轉送規則會指定外部 IP 位址、通訊埠和目標 HTTP(S) Proxy。用戶端會使用 IP 位址和通訊埠連線至負載平衡器。

• 目標 HTTP(S) Proxy 會接收來自用戶端的要求。HTTP(S) Proxy 會使用網址對應評估要求，做出流量轉送決策。Proxy 也可以使用 SSL 憑證驗證通訊。

  • 如果是 HTTPS 負載平衡，目標 HTTPS Proxy 會使用 SSL 憑證向用戶端證明自己的身分。目標 HTTPS Proxy 最多支援記錄數量的 SSL 憑證。

• HTTP(S) Proxy 會使用網址對應，根據 HTTP 屬性 (例如要求路徑、Cookie 或標頭) 判斷轉送路徑。根據轉送決策，Proxy 會將用戶端要求轉送至特定後端服務或後端 bucket。網址對應可指定其他動作，例如將重新導向傳送至用戶端。

• 後端服務會將要求分配至健康狀態良好的後端。

• 健康狀態檢查會定期監控後端的準備度。這樣可降低要求傳送至無法處理要求的後端的風險。

• 後端的防火牆規則，用於接受健康狀態檢查探測。區域性外部應用程式負載平衡器需要額外的防火牆規則，才能允許流量從僅限 Proxy 的子網路傳送至後端。

區域

這張圖表顯示區域性外部應用程式負載平衡器部署作業的元件。

Proxy 專用子網路

Proxy 專用子網路提供一組 IP 位址，供 Google 代表您執行 Envoy Proxy。在您使用區域性外部應用程式負載平衡器的虛擬私有雲網路中，每個區域都必須建立一個僅限 Proxy 的子網路。這個僅限 Proxy 的子網路的 --purpose 旗標已設為 REGIONAL_MANAGED_PROXY。在相同區域和虛擬私有雲網路中，所有區域 Envoy 型負載平衡器都會共用來自相同僅限 Proxy 子網路的 Envoy Proxy 集區。進一步：

• Proxy 專用子網路僅用於 Envoy Proxy，不適用於後端。
• 區域和虛擬私有雲網路中，所有區域外部應用程式負載平衡器的後端 VM 或端點，都會從僅限 Proxy 的子網路接收連線。
• 區域性外部應用程式負載平衡器的 IP 位址並非位於 Proxy 專用子網路中。負載平衡器的 IP 位址是由外部代管轉送規則定義，詳情請參閱下文。
• Proxy-only 子網路可設定為 IPV4_IPV6 或 IPV4_ONLY 堆疊類型。

如果您先前使用 --purpose=INTERNAL_HTTPS_LOAD_BALANCER 建立 Proxy 專用子網路，請先將子網路的用途遷移至 REGIONAL_MANAGED_PROXY，才能在虛擬私有雲網路的相同區域中，建立其他 Envoy 型負載平衡器。

轉送規則和 IP 位址

轉送規則會依據 IP 位址、通訊埠和通訊協定，將流量轉送至由目標 Proxy、網址對應和一或多項後端服務組成的負載平衡設定。

IP 位址規格。每項轉送規則都會提供單一 IP 位址，可用於應用程式的 DNS 記錄。不需要以 DNS 為基礎的負載平衡。您可以指定要使用的 IPv4 或 IPv6 位址，也可以讓 Cloud Load Balancing 指派位址。

通訊埠規格。應用程式負載平衡器的每項轉送規則，都可以參照 1 到 65535 之間的單一通訊埠。如要支援多個連接埠，請設定多個轉送規則。您可以設定多個轉送規則，使用相同的外部 IP 位址 (VIP) 並參照相同的目標 HTTP(S) Proxy，只要每個轉送規則的 IP 位址、通訊埠和通訊協定整體組合不重複即可。這樣一來，您就能使用單一負載平衡器和共用網址對應，做為多個應用程式的 Proxy。

外部應用程式負載平衡器使用的轉送規則類型、IP 位址和負載平衡配置，取決於負載平衡器的模式和負載平衡器所在的網路服務級別。

如需外部應用程式負載平衡器在各模式下轉送規則支援的完整通訊協定清單，請參閱「負載平衡器功能」。

轉送規則和虛擬私有雲網路

本節說明外部應用程式負載平衡器使用的轉送規則，如何與虛擬私有雲網路建立關聯。

目標 Proxy

目標 Proxy 會終止來自用戶端的 HTTP(S) 連線。一或多個轉送規則會將流量導向目標 Proxy，目標 Proxy 則會參考網址對應，決定如何將流量轉送至後端。

請勿依賴 Proxy 來維持要求或回應標頭名稱的大小寫。舉例來說，Server: Apache/1.0 回應標頭在用戶端可能會顯示為 server: Apache/1.0。

下表列出外部應用程式負載平衡器所需的目標 Proxy 類型。

除了目標 Proxy 新增的標頭外，負載平衡器還會以以下方式調整其他 HTTP 標頭：

• 部分標頭會合併。如果有多個相同標頭鍵的執行個體 (例如 Via)，負載平衡器會將這些值合併為單一標頭鍵的逗號分隔的清單。只有值可表示為逗號分隔的清單的標頭才會合併。其他標頭 (例如 Set-Cookie) 則一律不會合併。

主機標頭

負載平衡器發出 HTTP 要求時，會保留原始要求的 Host 標頭。

X-Forwarded-For 標頭

負載平衡器會在 X-Forwarded-For 標頭中附加兩個 IP 位址，並以半形逗號分隔，順序如下：

1. 連線至負載平衡器的用戶端 IP 位址
2. 負載平衡器轉送規則的 IP 位址

如果傳入的要求未包含 X-Forwarded-For 標頭，產生的標頭如下：

X-Forwarded-For: <client-ip>,<load-balancer-ip>

如果傳入的要求已包含 X-Forwarded-For 標頭，負載平衡器會將其值附加至現有標頭：

X-Forwarded-For: <existing-value>,<client-ip>,<load-balancer-ip>

使用自訂要求標頭移除現有標頭值

您可以在後端服務上使用自訂要求標頭，移除現有的標頭值。以下範例使用 --custom-request-header 旗標，透過變數 client_ip_address 和 server_ip_address 重新建立 X-Forwarded-For 標頭。這項設定會將傳入的 X-Forwarded-For 標頭替換為僅包含用戶端和負載平衡器 IP 位址的標頭。

--custom-request-header=x-forwarded-for:{client_ip_address},{server_ip_address}

後端反向 Proxy 軟體如何修改 X-Forwarded-For 標頭

如果負載平衡器的後端執行 HTTP 反向 Proxy 軟體，該軟體可能會將下列一或兩個 IP 位址附加到 X-Forwarded-For 標頭的結尾：

1. 連線至後端的 GFE IP 位址。GFE Proxy 範圍列於「防火牆規則」文件中。

2. 後端系統本身的 IP 位址。

因此，上游系統可能會看到結構如下的 X-Forwarded-For 標頭：

<existing-value>,<client-ip>,<load-balancer-ip>,<GFE-ip>,<backend-ip>

Cloud Trace 支援

Trace 不支援應用程式負載平衡器。如果沒有 X-Cloud-Trace-Context 標頭，全域和傳統版應用程式負載平衡器會新增該標頭。區域性外部應用程式負載平衡器不會新增這個標頭。如果 X-Cloud-Trace-Context 標頭已存在，則會不經修改地通過負載平衡器。不過，負載平衡器不會匯出任何追蹤記錄或 span。

網址對應

網址對應會定義比對模式，這些模式可透過網址將要求轉送到合適的後端服務。網址對應可讓您檢查網址元件，將流量劃分並傳送至不同的後端組合。預設服務會處理不符合指定主機規則或路徑比對規則的要求。

網址對應支援多項進階流量管理功能，例如根據標頭導向流量、根據權重分割流量，以及要求鏡像。如要瞭解詳情，請參考下列資源：

• 區域性外部應用程式負載平衡器的流量管理總覽

下表列出外部應用程式負載平衡器在各模式下所需的網址對應類型。

SSL 憑證

使用目標 HTTPS Proxy 的外部應用程式負載平衡器，需要私密金鑰和 SSL 憑證，才能設定負載平衡器。

使用目標 HTTPS Proxy 的區域外部應用程式負載平衡器，需要私密金鑰和 SSL 憑證做為負載平衡器設定的一部分。

區域性外部應用程式負載平衡器支援自行管理的 Compute Engine SSL 憑證。

SSL 政策

SSL 政策會指定一組 SSL 功能， Cloud de Confiance 負載平衡器與用戶端進行 SSL 通訊時會使用這些功能。

根據預設，HTTPS 負載平衡會使用一組提供良好安全性和廣泛相容性的 SSL 功能。有些應用程式需要進一步控制 HTTPS 或 SSL 連線使用的 SSL 版本和加密方式。您可以定義 SSL 政策，指定負載平衡器與用戶端協商 SSL 時使用的 SSL 功能組合。此外，您也可以將該 SSL 政策套用至目標 HTTPS Proxy。

下表列出各模式中負載平衡器的 SSL 政策支援。

後端服務

後端服務會向負載平衡器提供設定資訊，讓負載平衡器將要求導向後端，例如 Compute Engine 執行個體群組或網路端點群組 (NEG)。如要進一步瞭解後端服務，請參閱「後端服務總覽」。

後端服務範圍

下表說明外部應用程式負載平衡器使用的後端服務資源和範圍：

後端的通訊協定

應用程式負載平衡器的後端服務必須使用下列其中一種通訊協定，將要求傳送至後端：

• HTTP：使用 HTTP/1.1，不使用 TLS
• HTTPS (使用 HTTP/1.1 和 TLS)
• HTTP/2：使用 HTTP/2 和 TLS (不支援未加密的 HTTP/2)。
• H2C，也就是透過 TCP 使用 HTTP/2。不需要 TLS。傳統版應用程式負載平衡器不支援 H2C。

負載平衡器只會使用您指定的後端服務通訊協定，與後端通訊。如果負載平衡器無法使用指定的後端服務通訊協定與後端通訊，則不會改用其他通訊協定。

後端服務通訊協定不必與用戶端用來與負載平衡器通訊的通訊協定相符。舉例來說，用戶端可以使用 HTTP/2 將要求傳送至負載平衡器，但負載平衡器可以使用 HTTP/1.1 (HTTP 或 HTTPS) 與後端通訊。

後端

區域性外部應用程式負載平衡器支援下列類型的後端：

• 執行個體群組
• 區域性 NEG
• 網際網路 NEG

後端和虛擬私有雲網路

區域性外部應用程式負載平衡器後端適用下列規定：

• 如果是執行個體群組、可用區 NEG 和混合式連線 NEG，所有後端都必須與後端服務位於相同的專案和區域。不過，負載平衡器可以參照與後端服務位於相同專案，但使用不同虛擬私有雲網路的後端。您可以使用虛擬私有雲網路對等互連、Cloud VPN 通道或 Cloud Interconnect VLAN 連結，設定負載平衡器虛擬私有雲網路與後端虛擬私有雲網路之間的連線能力。

  後端網路定義

  • 如果是可用區 NEG 和混合型 NEG，您必須在建立 NEG 時明確指定虛擬私有雲網路。
  • 如果是代管執行個體群組，虛擬私有雲網路是在執行個體範本中定義。
  • 對於非代管執行個體群組，執行個體群組的虛擬私有雲網路會設為與新增至執行個體群組的第一個 VM 的 nic0 介面虛擬私有雲網路相符。

  後端網路需求

  後端網路必須符合下列其中一項網路規定：

  • 後端的虛擬私有雲網路必須與轉送規則的虛擬私有雲網路完全相符。

  • 後端的虛擬私有雲網路必須使用虛擬私有雲網路對接，連線至轉送規則的虛擬私有雲網路。您必須設定子網路路徑交換，才能在轉送規則的虛擬私有雲網路中，允許 Proxy 專用子網路與後端執行個體或端點使用的子網路之間進行通訊。

  後端 IPv6 子網路需求

  前端連線使用的 IP 版本與後端連線無關。由於僅限 Proxy 子網路為雙重堆疊 (IPV4_IPV6)，因此僅限 Proxy 子網路可以使用 IPv4 或 IPv6 與後端通訊。

  如果後端執行個體處理 IPv6 流量，後端子網路可以設定為 IPV4_ONLY 或 IPV4_IPV6 (雙重堆疊) 堆疊類型。如果後端子網路的堆疊類型包含 IPv6，您必須明確將子網路的 ipv6-access-type 設為 EXTERNAL。

• 如果是其他後端類型，所有後端都必須位於同一個虛擬私有雲網路和區域。

  區域性外部應用程式負載平衡器也支援 Shared VPC 環境，您可以在專案之間共用虛擬私有雲網路和相關聯的資源。如要讓區域性外部應用程式負載平衡器的後端服務和後端，與轉送規則位於不同專案，則須在Shared VPC 環境中設定負載平衡器，並使用跨專案服務參照。

後端和網路介面

如果您使用執行個體群組後端，封包一律會傳送至 nic0。如要將封包傳送至非 nic0 介面 (vNIC 或動態網路介面)，請改用 NEG 後端。

如果您使用可用區 NEG 後端，封包會傳送至 NEG 中端點代表的任何網路介面。NEG 端點必須與 NEG 明確定義的虛擬私有雲網路位於同一個虛擬私有雲網路。

健康狀態檢查

每項後端服務都會指定健康狀態檢查，定期監控後端是否準備好接收來自負載平衡器的連線。這可降低將要求傳送至無法處理要求的後端的風險。健康狀態檢查不會檢查應用程式本身是否正常運作。

您必須建立輸入允許防火牆規則，允許健康狀態檢查探測連線至後端執行個體。健康狀態檢查探測器通常來自 Google 的集中式健康狀態檢查機制。

使用混合式 NEG 後端的區域外部應用程式負載平衡器是這項規則的例外狀況，因為這類負載平衡器的健康狀態檢查是來自 Proxy 專用子網路，詳情請參閱「混合型 NEG 總覽」。

健康狀態檢查通訊協定

雖然這並非必要，也不一定可行，但最佳做法是使用通訊協定與後端服務通訊協定相符的健康狀態檢查。舉例來說，HTTP/2 健康狀態檢查能最準確地測試後端的 HTTP/2 連線能力。相較之下，使用混合 NEG 後端的區域性外部應用程式負載平衡器不支援 gRPC 健康狀態檢查。如需支援的健康狀態檢查通訊協定清單，請參閱「負載平衡功能」。

下表列出外部應用程式負載平衡器在各模式下支援的健康狀態檢查範圍。

如要進一步瞭解健康狀態檢查，請參閱下列資源：

• 健康狀態檢查總覽
• 建立健康狀態檢查

防火牆規則

負載平衡器需要下列防火牆規則：

• 如果是區域性外部應用程式負載平衡器，則須設定輸入允許規則，允許流量從僅限 Proxy 的子網路傳送至後端。
• 允許健康狀態檢查探測範圍流量的輸入允許規則。如要進一步瞭解健康狀態檢查探測，以及為何必須允許來自這些探測的流量，請參閱「探測 IP 範圍和防火牆規則」。

防火牆規則是在 VM 執行個體層級實作，而非在 GFE Proxy 上。您無法使用 Cloud de Confiance 防火牆規則，阻止流量傳送至負載平衡器。

這些防火牆規則的通訊埠必須設定如下：

• 允許流量傳送至各項後端服務健康狀態檢查的目標通訊埠。

• 執行個體群組後端：根據後端服務的已命名通訊埠與每個執行個體群組中與該已命名通訊埠相關聯的通訊埠編號之間的對應關係，判斷要設定的通訊埠。指派給相同後端服務的執行個體群組，其通訊埠編號可能不同。

• 適用於 GCE_VM_IP_PORT NEG 後端：允許流量傳輸至端點的通訊埠編號。

GKE 支援

GKE 會以下列方式使用外部應用程式負載平衡器：

• 使用 GKE Gateway 控制器建立的外部閘道，可使用外部應用程式負載平衡器的任何模式。您可以選擇 GatewayClass 來控制負載平衡器的模式。GKE Gateway 控制器一律使用 GCE_VM_IP_PORT 可用區 NEG 後端。

  為 GKE Gateway 管理的後端啟用 Cloud CDN 時，快取會使用附加至 HTTPRoute 資源的 GKE GCPHTTPFilter 篩選器設定。如要瞭解如何設定快取，請參閱「設定閘道的 Cloud CDN」。

• 您可以將 GKE 服務建立及管理的可用區 NEG，做為任何應用程式負載平衡器或 Proxy 網路負載平衡器的後端。GCE_VM_IP_PORT詳情請參閱「透過獨立區域 NEG 使用容器原生負載平衡功能」。

Shared VPC 架構

外部應用程式負載平衡器支援使用 Shared VPC 的網路。Shared VPC 可讓組織將多項專案的資源連至共同的虛擬私有雲網路，以便使用該網路的內部 IP 位址，安全有效率地相互通訊。如果您不熟悉 Shared VPC，請參閱「 Shared VPC 總覽」。

在 Shared VPC 網路中，有多種方式可以設定外部應用程式負載平衡器。無論部署類型為何，負載平衡器的所有元件都必須位於同一個組織。

雖然您可以在 Shared VPC 主專案中建立所有負載平衡元件和後端，但這類部署作業不會區分網路管理員和服務開發人員的責任。

服務專案中的所有負載平衡器元件和後端

下列架構圖顯示標準 Shared VPC 部署，其中所有負載平衡器元件和後端都位於服務專案中。所有應用程式負載平衡器都支援這種部署類型。

負載平衡器元件和後端必須使用相同的虛擬私有雲網路。

跨專案參照服務

跨專案服務參照是一種部署模式，其中負載平衡器的前端和網址對應位於一個專案，而負載平衡器的後端服務和後端則位於另一個專案。

透過跨專案服務參照，組織可以設定一個中央負載平衡器，並將流量轉送至分散在多個不同專案中的數百項服務。您可以在單一網址對應中，集中管理所有流量轉送規則和政策。您也可以將負載平衡器與一組主機名稱和 SSL 憑證建立關聯。因此，您可以最佳化部署應用程式所需的負載平衡器數量，並降低管理難度、營運成本和配額需求。

為每個職能團隊建立不同的專案，也能區隔組織內的角色。服務擁有者可以專注於在服務專案中建構服務，網路團隊則可在其他專案中佈建及維護負載平衡器，兩者皆可透過跨專案服務參照功能連結。

服務擁有者可以自主管理服務的公開程度，並透過負載平衡器控管哪些使用者可以存取服務。這是透過稱為「Compute 負載平衡器服務使用者角色」(roles/compute.loadBalancerServiceUser) 的特殊 IAM 角色達成。

跨專案服務參照支援功能會因負載平衡器類型而異：

• 全域外部應用程式負載平衡器：負載平衡器的前端和網址對應，可參照同一組織內任何專案的後端服務或後端 bucket。不適用任何虛擬私有雲網路限制。雖然您可以使用 Shared VPC 環境設定跨專案部署 (如本範例所示)，但這並非必要條件。

• 區域性外部應用程式負載平衡器：您必須在 Shared VPC 環境中建立負載平衡器。負載平衡器的前端和網址對應必須位於主專案或服務專案中，而負載平衡器的後端服務和後端則可分散在相同 Shared VPC 環境中的主專案或服務專案。

如要瞭解如何為區域外部應用程式負載平衡器設定 Shared VPC (包括使用和不使用跨專案服務參照)，請參閱「使用 Shared VPC 設定區域外部應用程式負載平衡器」。

跨專案服務參照的使用注意事項

• Cloud de Confiance 不會區分多個專案中名稱相同的資源 (例如後端服務)。因此，使用跨專案服務參照時，建議您在機構內各專案中使用不重複的後端服務名稱。
• 如果看到「Cross-project references for this resource are not allowed」(不允許跨專案參照這項資源) 等錯誤訊息，請確認您有權使用該資源。資源所屬專案的管理員必須授予您 Compute 負載平衡器服務使用者角色 (roles/compute.loadBalancerServiceUser)。這項角色可在專案或資源層級授予。如需範例，請參閱「授予 Compute Load Balancer 管理員權限，以使用後端服務或後端 bucket」。

範例 1：負載平衡器的前端和後端位於不同的服務專案

以下是 Shared VPC 部署作業的範例，其中負載平衡器的前端和網址對應是在服務專案 A 中建立，而網址對應會參照服務專案 B 中的後端服務。

在這種情況下，服務專案 A 的網路管理員或負載平衡器管理員，需要存取服務專案 B 的後端服務。服務專案 B 管理員將 Compute 負載平衡器服務使用者角色 (roles/compute.loadBalancerServiceUser) 授予服務專案 A 的負載平衡器管理員，後者想參照服務專案 B 的後端服務。

範例 2：負載平衡器前端位於主專案，後端位於服務專案

以下是 Shared VPC 部署範例，其中負載平衡器的前端和網址對應是在主專案中建立，後端服務 (和後端) 則是在服務專案中建立。

在本例中，主專案中的網路管理員或負載平衡器管理員需要存取服務專案中的後端服務。服務專案管理員將 Compute 負載平衡器服務使用者角色 (roles/compute.loadBalancerServiceUser) 授予主專案 A 中的負載平衡器管理員，以便他們參照服務專案中的後端服務。

範例 3：負載平衡器前端和後端位於不同專案

以下是部署範例，其中全域外部應用程式負載平衡器的前端和網址對應，是在與負載平衡器後端服務和後端不同的專案中建立。這類部署作業不會使用 Shared VPC，且僅適用於全域外部應用程式負載平衡器。

如要進一步瞭解這項設定，請參閱「使用後端服務和後端 bucket 設定跨專案服務參照」。

高可用性和容錯移轉

您可以在負載平衡器層級，設定外部應用程式負載平衡器的高可用性和容錯移轉。如要處理這類情況，請在需要備份的任何區域中，建立備份區域外部應用程式負載平衡器。

下表說明容錯移轉行為。

支援 HTTP/2

HTTP/2 是 HTTP/1 通訊協定的重大修訂版本，HTTP/2 支援有 2 種模式：

• HTTP/2 over TLS
• 透過 TCP 的明文 HTTP/2

HTTP/2 over TLS

用戶端與外部應用程式負載平衡器之間的連線，以及負載平衡器與後端之間的連線，都支援透過 TLS 傳輸 HTTP/2。

負載平衡器會使用 ALPN TLS 擴充功能，在 TLS 握手期間自動與用戶端協商 HTTP/2。即使負載平衡器設為使用 HTTPS，新式用戶端仍會預設使用 HTTP/2。這項設定是在用戶端控管，而非負載平衡器。

如果用戶端不支援 HTTP/2，且負載平衡器設定為在負載平衡器和後端執行個體之間使用 HTTP/2，負載平衡器仍可能協商 HTTPS 連線或接受不安全的 HTTP 要求。負載平衡器接著會轉換這些 HTTPS 或 HTTP 要求，透過 HTTP/2 將要求 Proxy 至後端執行個體。

如要透過 TLS 使用 HTTP/2，您必須在後端啟用 TLS，並將後端服務通訊協定設為HTTP2。詳情請參閱「從負載平衡器到後端的加密」。

HTTP/2 並行串流數量上限

HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS 設定說明端點接受的串流數量上限，由對等互連啟動。HTTP/2 用戶端向Cloud de Confiance 負載平衡器通告的值實際上沒有意義，因為負載平衡器不會向用戶端啟動串流。

如果負載平衡器使用 HTTP/2 與在 VM 上執行的伺服器通訊，負載平衡器會遵守伺服器通告的 SETTINGS_MAX_CONCURRENT_STREAMS 值，但不得超過 100。在要求方向 (Cloud de Confiance 負載平衡器 → gRPC 伺服器) 中，負載平衡器會使用 gRPC 伺服器的初始 SETTINGS 框架，判斷每個連線可同時使用的串流數量。如果伺服器宣傳的值高於 100，負載平衡器會將並行串流數量上限設為 100。如果宣傳的值為零，負載平衡器就無法將要求轉送至伺服器，這可能會導致錯誤。

HTTP/2 動態標頭資料表大小

HTTP/2 具備多工處理和 HPACK 標頭壓縮等功能，效能大幅優於 HTTP/1.1。HPACK 使用動態資料表來強化標頭壓縮，加快所有作業的速度。如要瞭解 HTTP/2 中動態標頭表格大小變更的影響、這項功能如何提升效能，以及各種 HTTP 用戶端程式庫中的特定錯誤如何導致 HPACK 標頭壓縮問題，請參閱社群文章。

HTTP/2 限制

• 負載平衡器與執行個體之間的 HTTP/2 可能需要比 HTTP 或 HTTPS 多出許多 TCP 連線。連線集區可減少 HTTP 或 HTTPS 連線數量，但 HTTP/2 不支援這項最佳化功能。因此，後端連線的頻率會提高，導致後端延遲時間較長。
• 負載平衡器與後端之間的 HTTP/2 不支援伺服器推送。
• 您無法在Cloud de Confiance API 或 Cloud de Confiance 控制台中查看 gRPC 錯誤率和要求量。如果 gRPC 端點傳回錯誤，負載平衡器記錄檔和監控資料會回報 200 OK HTTP 狀態碼。

透過明文 TCP 傳送 HTTP/2

根據 RFC 7540，以字串「h2c」表示的明文 TCP 上的 HTTP/2，可讓您使用 HTTP/2，而不需 TLS 加密。支援下列連線：

• 用戶端到負載平衡器：區域性外部應用程式負載平衡器會自動支援，不需特別設定。

• 負載平衡器到後端：將後端服務通訊協定設為 H2C 即可支援。

使用 GKE Gateway 控制器和 Cloud Service Mesh 建立的負載平衡器，也支援 H2C。

WebSocket 支援

Cloud de Confiance 如果使用 HTTP/1.1(HTTP 或 HTTPS) 或 HTTP/2 做為後端通訊協定，HTTP (S) 負載平衡器支援 WebSocket 通訊協定。負載平衡器不需要任何設定，即可代理 WebSocket 連線。

WebSocket 通訊協定可在用戶端和負載平衡器之間提供全雙工通訊管道。詳情請參閱 RFC 6455。

對於 HTTP/1.1 連線，WebSocket 通訊協定會使用 HTTP/1.1 Upgrade 機制，將 TCP 連線從 HTTP 轉換為 WebSocket 連線。透過 HTTP/1.1 的 WebSocket 通訊協定運作方式如下：

1. 負載平衡器會辨識來自 HTTP 或 HTTPS 用戶端的 WebSocket Upgrade 要求。要求包含 Connection: Upgrade 和 Upgrade: websocket 標頭，後面接著其他相關的 WebSocket 相關要求標頭。
2. 後端會傳送 WebSocket Upgrade 回應。這包括含有 Connection: Upgrade 和 Upgrade: websocket 標頭的 101 Switching Protocols 回應，以及其他 WebSocket 相關回應標頭。
3. 在目前連線期間，負載平衡器會透過 Proxy 傳送雙向流量。

如果後端執行個體傳回狀態碼 HTTP 426 或 HTTP 502，負載平衡器就會關閉連線。

如果是 HTTP/2 連線，WebSocket 通訊協定會使用擴充的 CONNECT 方法和虛擬標頭欄位 (例如 :protocol)，在單一 HTTP/2 串流上建立通道，以便傳輸 WebSocket 的資料 (RFC 8441)。透過 HTTP/2 執行的 WebSocket 通訊協定運作方式如下：

1. 後端伺服器會傳送 HTTP/2 SETTINGS 框架，其中包含設為 1 的 SETTINGS_ENABLE_CONNECT_PROTOCOL 參數。這會向負載平衡器宣告後端支援擴充的 CONNECT 方法。

2. 負載平衡器收到這項設定後，會辨識並轉送 WebSocket 升級要求。它會使用擴充的 CONNECT 方法，將升級要求傳送至後端。要求包含 :method: CONNECT 和 :protocol: websocket 虛擬標頭，以及其他相關的 WebSocket 要求標頭。

3. 後端傳送 WebSocket 成功回應。後端伺服器會傳送 200 OK 回應 (而非 HTTP/1.1 中使用的 101 Switching Protocols 回應)，透過 HTTP/2 連線的單一串流建立 WebSocket 通道。

4. 負載平衡器會透過建立的 HTTP/2 串流，對雙向流量進行 Proxy 處理。

如果後端執行個體傳回狀態碼 426 或 502，則不會進行 WebSocket 升級，且狀態碼會傳播至用戶端。

WebSockets 的工作階段相依性與其他要求的運作方式相同。詳情請參閱「工作階段相依性」。

gRPC 支援

gRPC 是用於遠端程序呼叫的開放原始碼架構。它採用 HTTP/2 標準。gRPC 的用途如下：

• 低延遲、高度可擴充的分散式系統
• 開發與雲端伺服器通訊的行動用戶端
• 設計必須準確、有效率且與語言無關的新通訊協定
• 可實現擴充、驗證和記錄功能的分層式設計

如要在 Cloud de Confiance 應用程式中使用 gRPC，您必須透過 HTTP/2 進行 端對端要求 Proxy。如要這麼做，請建立應用程式負載平衡器，並採用下列其中一種設定：

• 用戶端和負載平衡器之間透過 TLS 傳輸 HTTP/2，負載平衡器和後端之間則透過 H2C 傳輸：建立 HTTPS 負載平衡器 (設定目標 HTTPS Proxy 和 SSL 憑證)。此外，您也可以將後端服務通訊協定設為 H2C，將負載平衡器設為使用 HTTP/2，在負載平衡器和後端之間建立未加密連線。

• 使用 HTTP/2 over TLS 的端對端加密流量：建立 HTTPS 負載平衡器 (已設定目標 HTTPS Proxy 和 SSL 憑證)。負載平衡器會使用 ALPN TLS 擴充功能，在 SSL 握手期間與用戶端協商 HTTP/2。

  此外，您必須確保後端可以處理 TLS 流量，並將後端服務通訊協定設為 HTTP2，將負載平衡器設為使用 HTTP/2，在負載平衡器和後端之間建立加密連線。

  負載平衡器可能仍會與部分用戶端協商 HTTPS，或在設定為在負載平衡器和後端執行個體之間使用 HTTP/2 的負載平衡器上接受不安全的 HTTP 要求。負載平衡器會轉換這些 HTTP 或 HTTPS 要求，透過 HTTP/2 將要求 Proxy 至後端執行個體。

如要使用 HTTP/2 設定應用程式負載平衡器，搭配 Google Kubernetes Engine Ingress 使用，或使用 gRPC 和 HTTP/2 搭配 Ingress，請參閱「使用 Ingress 進行負載平衡的 HTTP/2」。

如要透過 HTTP/2 搭配 Cloud Run 設定外部應用程式負載平衡器，請參閱「在負載平衡器後方使用 HTTP/2」。

如要瞭解如何排解 HTTP/2 問題，請參閱「排解 HTTP/2 後端問題」。

如要瞭解 HTTP/2 限制，請參閱「HTTP/2 限制」。

TLS 支援

根據預設，HTTPS 目標 Proxy 終止用戶端 SSL 要求時，只會接受 TLS 1.0、1.1、1.2 和 1.3。

傳統版應用程式負載平衡器使用 HTTPS 做為後端服務通訊協定時，可以與後端協商 TLS 1.0、1.1、1.2 或 1.3。

支援相互傳輸層安全標準 (TLS)

相互傳輸層安全標準 (mTLS) 是業界標準通訊協定，用於在用戶端和伺服器之間進行雙向驗證。mTLS 會驗證用戶端和伺服器是否都持有由信任的憑證授權單位 (CA) 核發的有效憑證，確保雙方互相驗證。與標準 TLS 不同，mTLS 不僅會驗證伺服器，還會要求用戶端和伺服器都提供憑證，在建立通訊前確認雙方身分。

所有應用程式負載平衡器都支援 mTLS。使用 mTLS 時，負載平衡器會在與負載平衡器進行 TLS 握手期間，要求用戶端傳送憑證來驗證自身。您可以設定Certificate Manager信任存放區，讓負載平衡器用來驗證用戶端憑證的信任鏈結。

如要進一步瞭解 mTLS，請參閱「相互傳輸層安全性驗證」。

支援 TLS 1.3 早期資料

下列外部應用程式負載平衡器的目標 HTTPS Proxy 支援 TLS 1.3 早期資料，適用於透過 TCP 傳輸的 HTTPS (HTTP/1.1、HTTP/2) 和透過 QUIC 傳輸的 HTTP/3：

• 全域外部應用程式負載平衡器
• 傳統版應用程式負載平衡器

TLS 1.3 定義於 RFC 8446，並導入「早期資料」的概念，也稱為「零封包往返時間 (0-RTT) 資料」，可將恢復連線的應用程式效能提高 30% 至 50%。

使用 TLS 1.2 時，必須來回兩次才能安全傳輸資料。TLS 1.3 將新連線的往返次數減少為一次 (1-RTT)，讓用戶端在收到第一個伺服器回應後，立即傳送應用程式資料。此外，TLS 1.3 針對恢復的工作階段，導入了早期資料的概念，讓用戶端能透過初始 ClientHello 傳送應用程式資料，進而將有效往返時間縮短至零 (0-RTT)。TLS 1.3 早期資料可讓後端伺服器在與用戶端的交握程序完成前，開始處理用戶端資料，進而縮短延遲時間。不過，您必須謹慎降低重送風險。

由於早期資料是在握手完成前傳送，攻擊者可能會嘗試擷取及重送要求。為減輕這種情況，後端伺服器必須謹慎控管早期資料用量，僅限用於等冪要求。如果 HTTP 方法預期為冪等，但可能會觸發非冪等變更 (例如修改資料庫的 GET 要求)，則不得接受早期資料。在這種情況下，後端伺服器必須拒絕含有 HTTP Early-Data: 1 標頭的要求，並傳回 HTTP 425 Too Early 狀態碼。

含有早期資料的要求會將 HTTP Early-Data 標頭設為 1，向後端伺服器表示要求已透過 TLS 早期資料傳送。這也表示用戶端瞭解 HTTP 425 Too Early 狀態碼。

TLS 早期資料 (0-RTT) 模式

您可以在負載平衡器的目標 HTTPS Proxy 資源上，使用下列其中一種模式設定 TLS 早期資料。

• STRICT：為採用安全 HTTP 方法 (GET、HEAD、OPTIONS、TRACE) 的要求，以及不含查詢參數的 HTTP 要求，啟用 TLS 1.3 早期資料。如果要求傳送的早期資料含有非冪等 HTTP 方法 (例如 POST 或 PUT) 或查詢參數，系統會拒絕要求，並傳回 HTTP 425 狀態碼。

• PERMISSIVE。這會針對使用安全 HTTP 方法 (GET、HEAD、OPTIONS、TRACE) 的要求啟用 TLS 1.3 早期資料。這個模式不會拒絕包含查詢參數的要求。應用程式擁有者必須確保每個要求路徑都能安全使用早期資料，尤其是要求重播可能導致非預期副作用的端點，例如由 GET 要求觸發的記錄或資料庫更新。

• DISABLED。不通告 TLS 1.3 早期資料，並拒絕所有傳送早期資料的 (無效) 嘗試。如果應用程式無法安全處理早期資料要求，請務必停用早期資料。TLS 1.3 早期資料預設為停用。

• UNRESTRICTED (不建議用於大多數工作負載)。這會為採用任何 HTTP 方法 (包括 POST 等非冪等方法) 的要求啟用 TLS 1.3 早期資料。這個模式不會強制執行任何其他限制。這個模式對於 gRPC 用途來說非常實用。不過，除非您已評估資安態勢，並使用其他機制降低重送攻擊的風險，否則不建議採用這種方法。

設定 TLS 早期資料

如要明確啟用或停用 TLS 早期資料，請按照下列步驟操作：

PATCH https://compute.googleapis.com/compute/v1/projects/{project}/global/targetHttpsProxies/TARGET_HTTPS_PROXY
{
    "tlsEarlyData":"TLS_EARLY_DATA_MODE",
    "fingerprint": "FINGERPRINT"
}

設定 TLS 早期資料後，您可以從支援 TLS 早期資料的 HTTP 用戶端發出要求。您會發現恢復的要求延遲時間較短。

如果非 RFC 相容用戶端傳送的要求使用非冪等方法或查詢參數，系統會拒絕要求。負載平衡器記錄中會顯示 HTTP 425 Early 狀態碼，以及下列 HTTP 回應：

  HTTP/1.1 425 Too Early
  Content-Type: text/html; charset=UTF-8
  Referrer-Policy: no-referrer
  Content-Length: 1558
  Date: Thu, 03 Aug 2024 02:45:14 GMT
  Connection: close
  <!DOCTYPE html>
  <html lang=en>
  <title>Error 425 (Too Early)</title>
  <p>The request was sent to the server too early, please retry. That's
  all we know.</p>
  </html>
  

廣告主專用 Google 代碼閘道

Google 代碼閘道可讓網站擁有者透過 Google Cloud 託管及部署 Google 代碼。這些 Google 代碼可協助您分析網站流量。您可以使用全域外部應用程式負載平衡器，透過網域轉送網站上的評估流量，提高評估資料準確度。這可提供更可靠的資料，有助於廣告活動最佳化。

請注意，Google 代碼閘道僅支援全域外部應用程式負載平衡器。如果您使用傳統版應用程式負載平衡器，請將資源從傳統版遷移至全域外部應用程式負載平衡器。

Google 代碼閘道的設定和管理作業是在 Cloud de Confiance 控制台外進行。您必須使用 Google 代碼管理工具介面設定這項功能。

• 在 Cloud de Confiance 控制台的「Load balancer details」(負載平衡器詳細資料) 頁面，會顯示唯讀視覺指標，指出 Google 代碼閘道已啟用。
• 您無法透過Cloud de Confiance 控制台編輯或刪除 Google 代碼閘道設定。

如需廣告主專用 Google 代碼閘道的完整設定說明，請參閱「設定廣告主專用 Google 代碼閘道」。

雖然設定是由 Google Ads 管理，但閘道執行的要求處理和 Google 代碼插入作業，都會記錄在全域外部應用程式負載平衡器的記錄與監控功能中。詳情請參閱「全域外部應用程式負載平衡器記錄與監控」。

如要瞭解如何排解 Google 代碼閘道問題，請參閱「排解 Google 代碼閘道插入問題」。

如果在設定期間遇到問題，且無法透過說明文件解決，請與 Google Ads 支援團隊聯絡。

限制

• 終止 SSL 連線時，HTTPS 負載平衡器不會傳送 close_notify 關閉警示。也就是說，負載平衡器會關閉 TCP 連線，而非執行 SSL 關閉作業。

• HTTPS 負載平衡器僅支援憑證的一般名稱 (CN) 屬性或主體別名 (SAN) 屬性中網域的小寫字元。只有在目標 Proxy 中設為主要憑證時，系統才會傳回網域中含有大寫字元的憑證。

• 連線至後端時，HTTPS 負載平衡器不會使用伺服器名稱指示 (SNI) 擴充功能，但網際網路 NEG 後端的負載平衡器除外。詳情請參閱「從負載平衡器到後端的加密」。

• Cloud de Confiance 不保證基礎 TCP 連線在後端服務逾時期間內，能一直保持開啟狀態。用戶端系統必須實作重試邏輯，而非依賴長時間開啟的 TCP 連線。

• 使用Cloud de Confiance 控制台在進階級建立區域性外部應用程式負載平衡器時， Cloud de Confiance 控制台只會顯示支援標準級的區域。如要存取其他區域，請使用 gcloud CLI 或 API。

後續步驟

• 如要瞭解如何部署區域性外部應用程式負載平衡器，請參閱「使用 Compute Engine 後端設定區域性外部應用程式負載平衡器」。

• 如要瞭解如何設定區域性外部應用程式負載平衡器提供的進階流量管理功能，請參閱「區域性外部應用程式負載平衡器的流量管理總覽」。