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

本文將介紹設定外部應用程式負載平衡器時需瞭解的概念。

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

運作模式

您可以使用下列模式設定外部應用程式負載平衡器：

• 全域外部應用程式負載平衡器。這是全球負載平衡器，會在 Google Front Ends (GFE) 上做為代管服務實作。它使用開放原始碼 Envoy Proxy 支援進階流量管理功能，例如流量鏡射、以權重為準的流量拆分、以要求或回應為準的標頭轉換等。
• 傳統版應用程式負載平衡器。這是傳統外部應用程式負載平衡器，在進階級為全域，但可在標準級設定為區域性。這個負載平衡器是在 Google Front End (GFE) 上實作。GFE 遍布全球，並使用 Google 的全球網路和控制層共同運作。
• 區域性外部應用程式負載平衡器。這是一種區域負載平衡器，會在開放原始碼 Envoy Proxy 上做為代管服務導入。這項功能包含進階流量管理功能，例如流量鏡射、以權重為依據的流量拆分、以要求或回應為依據的標頭轉換等等。

識別模式

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

架構

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

• 僅限區域性外部應用程式負載平衡器：系統會使用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 會將用戶端要求轉送至特定後端服務或後端值區。網址對應可指定其他動作，例如向用戶端傳送重新導向。

• 後端服務會將要求分配給健康狀態良好的後端。 全域外部應用程式負載平衡器也支援後端值區。一或多個後端必須連線至後端服務或後端值區。

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

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

全球

下圖顯示全域外部應用程式負載平衡器部署作業的元件。這項架構適用於全域外部應用程式負載平衡器，以及進階級的傳統版應用程式負載平衡器。

地區性

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

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 位址是由外部受管理的轉送規則定義，如下所述。

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

轉送規則和 IP 位址

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

IP 位址規格。每個轉送規則都會提供一個 IP 位址，供您用於應用程式的 DNS 記錄。您不需要進行 DNS 型負載平衡。您可以指定要使用的 IP 位址，或由 Cloud Load Balancing 為您指派 IP 位址。

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

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

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

轉送規則和 VPC 網路

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

目標 Proxy

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

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

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

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

• 全域外部應用程式負載平衡器：要求和回應標頭可能會轉換為小寫。

  唯一的例外狀況是，您使用全球網際網路 NEG 後端搭配 HTTP/1.1。如要進一步瞭解如何透過全球網際網路 NEG 處理 HTTP/1.1 標頭，請參閱「網際網路 NEG 總覽」。

• 對於傳統版應用程式負載平衡器，除了使用 HTTP/1.1 以外，要求和回應標頭都會轉換為小寫。在 HTTP/1.1 中，標頭會改為使用正確的大小寫。標頭鍵的第一個字母和連字號 (-) 後面的每個字母都會大寫，以便與 HTTP/1.1 用戶端保持相容性。舉例來說，user-agent 會變更為 User-Agent，content-encoding 則變更為 Content-Encoding。

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

主機標頭

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

X-Forwarded-For 標頭

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

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 軟體，該軟體可能會在 X-Forwarded-For 標頭結尾處附加下列一或兩個 IP 位址：

1. 連線至後端的 GFE IP 位址。GFE IP 位址位於 130.211.0.0/22 和 35.191.0.0/16 範圍內。

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

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

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

Cloud Trace 支援

應用程式負載平衡器不支援追蹤記錄。如果 X-Cloud-Trace-Context 標頭不存在，全域和傳統版應用程式負載平衡器會新增該標頭。區域性外部應用程式負載平衡器不會加入這個標頭。如果 X-Cloud-Trace-Context 標頭已存在，則會在經過負載平衡器時保持不變。不過，負載平衡器不會匯出任何追蹤或區間。

網址對應

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

在某些情況下，例如在多區域負載平衡的範例中，您可能無法定義任何網址規則，而只能使用預設服務。

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

• 全球外部應用程式負載平衡器的流量管理總覽

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

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

SSL 憑證

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

• Google Cloud 提供兩種設定方法，可將私密金鑰和 SSL 憑證指派給目標 HTTPS Proxy：Compute Engine SSL 憑證和憑證管理工具。如需各項設定的說明，請參閱 SSL 憑證總覽中的「憑證設定方法」。

• Google Cloud 提供兩種憑證類型：自行管理和 Google 代管。如要瞭解各類型的說明，請參閱 SSL 憑證總覽中的「憑證類型」。

外部應用程式負載平衡器的類型 (全域、區域或傳統版) 會決定支援哪些設定方法和憑證類型。詳情請參閱 SSL 憑證總覽中的「憑證和 Google Cloud 負載平衡器」。

安全資料傳輸層 (SSL) 政策

SSL 政策可指定 Google Cloud 負載平衡器與用戶端協調安全資料傳輸層 (SSL) 時使用的 SSL 功能組合。

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

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

後端服務

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

如需設定具有後端服務和 Compute Engine 後端的負載平衡器的範例，請參閱「設定具有 Compute Engine 後端的外部應用程式負載平衡器」。

後端服務範圍

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

後端的通訊協定

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

• HTTP：使用 HTTP/1.1，且未使用 TLS
• 使用 HTTP/1.1 和 TLS 的 HTTPS
• HTTP/2，使用 HTTP/2 和 TLS (系統不支援未加密的 HTTP/2)。
• H2C，透過 TCP 使用 HTTP/2。不需要傳輸層安全標準 (TLS)。傳統版應用程式負載平衡器不支援 H2C。

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

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

後端值區

後端值區會將傳入流量導向至 Cloud Storage 值區。如需示範如何將值區新增到外部應用程式負載平衡器的範例，請參閱「設定含有後端值區的負載平衡器」一文。如要瞭解 Cloud Storage 的一般資訊，請參閱「什麼是 Cloud Storage？」

後端

下表列出各模式中外部應用程式負載平衡器支援的後端和相關功能。

後端和虛擬私有雲網路

後端可位於何處的限制，取決於負載平衡器的類型。

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

• 後端執行個體 (針對執行個體群組後端) 和後端端點 (針對 NEG 後端) 可位於同一個機構的任何 VPC 網路中。不同 VPC 網路不需要透過虛擬私有雲網路對等互連連線，因為 GFE 會直接與各自 VPC 網路中的後端通訊。

• Cloud Storage 值區不會與 VPC 網路建立關聯。這些資料夾可位於同一機構的任何專案中。

  全球外部應用程式負載平衡器也支援共用 VPC 環境，可讓您在專案之間共用 VPC 網路及其相關資源。不過，如果是全球外部應用程式負載平衡器，您不需要設定共用虛擬私有雲，即可參照貴機構中其他專案的後端服務或後端儲存格。

針對傳統版應用程式負載平衡器後端，適用下列規定：

• 執行個體群組後端的所有後端執行個體，以及 NEG 後端的所有後端端點，都必須位於同一個專案中。不過，執行個體群組後端或 NEG 可以在該專案中使用不同的虛擬私人雲端網路。不同 VPC 網路不需要透過 VPC 網路對等互連連線，因為 GFE 會直接與各自 VPC 網路中的後端通訊。

• Cloud Storage 值區不會與 VPC 網路建立關聯。不過，這些項目必須與負載平衡器位於相同專案中。

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

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

  後端網路定義

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

  後端網路需求

  後端網路必須符合下列任一網路需求：

  • 後端的 VPC 網路必須與轉送規則的 VPC 網路完全一致。

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

• 後端的 VPC 網路和轉送規則的 VPC 網路都必須是VPC 輻條，且連結至相同的 Network Connectivity Center 中樞。匯入和匯出篩選器必須允許轉送規則 VPC 網路中代理專用子網路，與後端執行個體或端點使用的子網路之間的通訊。

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

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

後端和網路介面

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

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

健康狀態檢查

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

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

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

健康狀態檢查通訊協定

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

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

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

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

防火牆規則

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

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

防火牆規則是在 VM 執行個體層級實作，而非在 GFE Proxy 上。您無法使用 Google Cloud 防火牆規則來阻止流量傳送至負載平衡器。 針對全域外部應用程式負載平衡器和傳統版應用程式負載平衡器，您可以使用 Google Cloud Armor 來達成這項目標。

這些防火牆規則的通訊埠必須依下列方式設定：

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

• 針對執行個體群組後端：透過後端服務的已命名通訊埠與各個執行個體群組中與該已命名通訊埠相關聯的通訊埠編號之間的對應關係，判斷要設定的通訊埠。在指派給相同後端服務的執行個體群組中，連接埠號碼可能會有所不同。

• 如果是 GCE_VM_IP_PORT NEG 後端：允許流量傳送至端點的通訊埠編號。

下表摘要說明防火牆規則所需的來源 IP 位址範圍：

GKE 支援

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

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

• 使用 GKE Ingress 控制器建立的外部 Ingress 一律是傳統應用程式負載平衡器。GKE Ingress 控制器偏好使用 GCE_VM_IP_PORT 區域 NEG 後端，但也支援執行個體群組後端。

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

共用 VPC 架構

外部應用程式負載平衡器支援使用共用虛擬私有雲的網路。共用虛擬私有雲可讓機構將多個專案的資源連線至通用的虛擬私有雲網路，以便使用該網路中的內部 IP 位址，安全又有效率地相互通訊。如果您不熟悉共用虛擬私人雲端，請參閱 共用虛擬私人雲端總覽。

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

雖然您可以在共用虛擬私人雲端主機專案中建立所有負載平衡元件和後端，但這類部署作業不會區分網路管理和服務開發職責。

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

下圖顯示標準的共用虛擬私人雲端部署作業，其中所有負載平衡器元件和後端都位於服務專案中。所有應用程式負載平衡器都支援這類部署方式。

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

共用虛擬私有雲環境中的無伺服器後端

如果負載平衡器使用無伺服器 NEG 後端，後端 Cloud Run 或 Cloud Run 函式服務必須與無伺服器 NEG 位於相同專案中。

此外，如果是支援跨專案服務參照的區域性外部應用程式負載平衡器，後端服務、無伺服器 NEG 和 Cloud Run 服務必須一律位於相同的服務專案中。

跨專案服務參照

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

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

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

服務擁有者可以自行決定服務的曝光程度，並透過負載平衡器控管哪些使用者可以存取服務。這項功能是透過名為 Compute 負載平衡器服務使用者角色的特殊 IAM 角色 (roles/compute.loadBalancerServiceUser) 達成。

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

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

• 區域性外部應用程式負載平衡器：您必須在共用虛擬私有雲環境中建立負載平衡器。負載平衡器的前端和網址對應項目必須位於主機或服務專案中，而負載平衡器的後端服務和後端可分散至相同共用虛擬私有雲環境中的主機或服務專案。

如要瞭解如何為區域性外部應用程式負載平衡器設定共用虛擬私有雲 (無論是否有跨專案服務參照)，請參閱「使用共用虛擬私有雲設定區域性外部應用程式負載平衡器」。

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

• 跨專案服務參照可與執行個體群組、無伺服器 NEG 和大多數其他支援的後端類型搭配使用。但請注意，本功能有以下限制：

  • 如果後端服務含有 App Engine 的無伺服器 NEG 後端，您就無法透過全域外部應用程式負載平衡器參照跨專案後端服務。

  • 如果後端服務含有區域性網際網路 NEG 後端，您就無法使用區域性外部應用程式負載平衡器參照跨專案後端服務。
• 傳統版應用程式負載平衡器不支援跨專案服務參照。
• Google Cloud 不會區分在多個專案中使用相同名稱的資源 (例如後端服務)。因此，在使用跨專案服務參照時，建議您在貴機構的各專案中使用不重複的後端服務名稱。
• 如果您看到「Cross-project references for this resource are not allowed」(不允許這項資源的跨專案參照) 等錯誤訊息，請確認您有使用該資源的權限。擁有資源的專案管理員必須授予您 Compute 負載平衡器服務使用者角色 (roles/compute.loadBalancerServiceUser)。這個角色可在專案層級或資源層級授予。如需範例，請參閱「授予 Compute Load Balancer 管理員權限，以便使用後端服務或後端值區」。

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

以下是共用虛擬私有雲部署的範例，其中負載平衡器的前端和網址對應是在服務專案 A 中建立，而網址對應會參照服務專案 B 中的後端服務。

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

示例 2：主專案中的負載平衡器前端，以及服務專案中的後端

以下是共用虛擬私有雲部署的範例，其中負載平衡器的前端和網址對應項目是在主專案中建立，而後端服務則是在服務專案中建立。

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

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

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

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

連線的運作方式

全域外部應用程式負載平衡器連線

全域外部應用程式負載平衡器是由許多稱為 Google Front End (GFE) 的 Proxy 實作。不只一個 Proxy。在 Premium Tier 中，相同的全球外部 IP 位址會從各個服務據點宣傳，而用戶端要求會導向用戶端最近的 GFE。

視用戶端所在位置而定，多個 GFE 可以啟動與後端的 HTTP(S) 連線。從 GFE 傳送的封包來源 IP 位址來自健康狀態檢查探針使用的相同範圍：35.191.0.0/16 和 130.211.0.0/22。

根據後端服務設定，每個 GFE 用來連線至後端的通訊協定可以是 HTTP、HTTPS 或 HTTP/2。對於 HTTP 或 HTTPS 連線，使用的 HTTP 版本為 HTTP 1.1。

根據 HTTP 1.1 規格，預設會啟用 HTTP 保持運作功能。HTTP 保持運作會嘗試有效地使用相同的 TCP 工作階段，但無法保證。GFE 會使用 610 秒的用戶端 HTTP 保持運作逾時時間，以及 600 秒的預設後端保持運作逾時時間值。您可以更新用戶端 HTTP 保持運作逾時，但後端保持運作逾時值是固定的。您可以設定後端服務逾時時間，藉此設定要求/回應逾時時間。雖然兩者密切相關，但 HTTP 保持運作和 TCP 閒置逾時並非相同的概念。詳情請參閱「逾時和重試」一文。

為確保流量負載平衡均勻，負載平衡器可能會在完成包含 Connection: close 標頭的回應後，傳送 FIN ACK 封包，藉此乾淨地關閉 TCP 連線，或是在完成回應後發出 HTTP/2 GOAWAY 框架。這項行為不會干擾任何有效的要求或回應。

HTTP 連線和 TCP 工作階段的數量會因連線的 GFEs 數量、連線至 GFEs 的用戶端數量、後端的通訊協定，以及後端部署位置而異。

如需更多資訊，請參閱解決方案指南：利用全域負載平衡進行應用程式容量最佳化中的「外部應用程式負載平衡器運作方式」。

區域性外部應用程式負載平衡器連線

區域性外部應用程式負載平衡器是在 Envoy Proxy 上實作的代管服務。區域性外部應用程式負載平衡器會使用稱為 Proxy 專用子網路的共用子網路，來佈建一組 IP 位址，供 Google 代您執行 Envoy Proxy。這個僅限 Proxy 子網路的 --purpose 旗標已設為 REGIONAL_MANAGED_PROXY。特定網路和區域中的所有區域 Envoy 型負載平衡器都會共用這個子網路。

用戶端會使用負載平衡器的 IP 位址和通訊埠連線至負載平衡器。用戶端要求會導向與用戶端位於相同區域的 Proxy 專用子網路。負載平衡器會終止用戶端要求，然後從僅限 Proxy 的子網路開啟連至後端的新連線。因此，從負載平衡器傳送的封包會具有來自僅限 Proxy 子網路的來源 IP 位址。

視後端服務組態而定，Envoy Proxy 用於連線至後端的通訊協定可以是 HTTP、HTTPS 或 HTTP/2。如果是 HTTP 或 HTTPS，HTTP 版本為 HTTP 1.1。根據 HTTP 1.1 規格，HTTP 保持運作功能預設為啟用。Envoy Proxy 會將用戶端 HTTP 保持連線逾時時間和後端保持連線逾時時間都設為預設值，即各自為 600 秒。您可以更新用戶端 HTTP 保持運作逾時值，但後端保持運作逾時值是固定的。您可以設定後端服務逾時時間，藉此設定要求/回應逾時時間。詳情請參閱「逾時和重試」。

用戶端與負載平衡器的通訊

• 用戶端可使用 HTTP 1.1 或 HTTP/2 通訊協定與負載平衡器進行通訊。
• 使用 HTTPS 時，現代的用戶端預設為使用 HTTP/2。這是在用戶端上控制的，而不是在 HTTPS 負載平衡器上控制的。
• 您無法透過變更負載平衡器的設定來停用 HTTP/2。不過，您可以將部分用戶端設定為使用 HTTP 1.1 而非 HTTP/2。例如，搭配 curl 使用 --http1.1 參數。
• 外部應用程式負載平衡器支援 HTTP/1.1 100 Continue 回應。

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

用戶端封包的來源 IP 位址

後端看到的封包來源 IP 位址「不是」負載平衡器的Google Cloud 外部 IP 位址。換句話說，有兩個 TCP 連線。

• 連線 1：從原始用戶端連線至負載平衡器 (GFE)：

  • 來源 IP 位址：原始用戶端 (如果用戶端位於 NAT 閘道或轉送 Proxy 後方，則為外部 IP 位址)。
  • 目的地 IP 位址：負載平衡器的 IP 位址。

• 連線 2：從負載平衡器 (GFE) 到後端 VM 或端點：

  • 來源 IP 位址：在防火牆規則中指定的任一範圍內的 IP 位址。

  • 目的地 IP 位址：虛擬私有雲網路中後端 VM 或容器的內部 IP 位址。

• 連線 1：從原始用戶端連線至負載平衡器 (僅限 Proxy 子網路)：

  • 來源 IP 位址：原始用戶端 (如果用戶端位於 NAT 閘道或轉送 Proxy 後方，則為外部 IP 位址)。
  • 目的地 IP 位址：負載平衡器的 IP 位址。

• 連線 2：從負載平衡器 (僅限 Proxy 子網路) 到後端 VM 或端點：

  • 來源 IP 位址：僅限 Proxy 的子網路中的 IP 位址，在與負載平衡器相同的地區和網路中，由所有以 Envoy 為基礎的負載平衡器共用。

  • 目的地 IP 位址：虛擬私有雲網路中後端 VM 或容器的內部 IP 位址。

特殊轉送路徑

Google Cloud 會使用虛擬私有雲網路中未定義的特殊路徑，為下列類型的流量路由封包：

• 健康狀態檢查 (不含分散式 Envoy 健康狀態檢查)。詳情請參閱「健康狀態檢查路徑」。

• 全域外部應用程式負載平衡器和傳統應用程式負載平衡器的 GFE 與後端之間。詳情請參閱「Google 前端和後端之間的路徑」。

Google Cloud 會使用僅限 Proxy 的子網路子網路路徑，為下列類型的流量路由封包：

• 使用分散式 Envoy 健康狀態檢查時。

針對區域性外部應用程式負載平衡器， Google Cloud 會使用開源 Envoy 代理程式終止負載平衡器的用戶端要求。負載平衡器會終止 TCP 工作階段，並從地區的 Proxy 專用子網路開啟至後端的新 TCP 工作階段。在虛擬私有雲端網路中定義的路徑可協助 Envoy Proxy 與後端，以及後端與 Envoy Proxy 之間的通訊。

開放的通訊埠

GFE 具有多個開啟的通訊埠，可支援在同一架構上執行的其他 Google 服務。執行通訊埠掃描時，您可能會看到在 GFE 上執行的其他 Google 服務的其他開放通訊埠。

從稽核的角度來看，在以 GFE 為基礎的負載平衡器 IP 位址上執行通訊埠掃描作業並無實用性，原因如下：

• 執行 TCP SYN 探測時，一般不會在埠掃描 (例如使用 nmap) 時傳回回應封包或 TCP RST 封包。GFE 只會針對已設定轉送規則的通訊埠，傳送 SYN-ACK 封包回應 SYN 探測。GFE 只會在回應傳送至負載平衡器 IP 位址和其轉送規則中設定的目的地通訊埠的封包時，將封包傳送至後端。傳送至不同 IP 位址或通訊埠的封包不會傳送至後端。

  GFE 會實作 Google Cloud Armor 等安全防護功能。透過 Google Cloud Armor Standard，GFEs 可全天候防範巨流量和通訊協定型 DDoS 攻擊，以及 SYN 洪水。即使您未明確設定 Google Cloud Armor，也能使用這項防護機制。只有在您設定安全性政策或註冊 Managed Protection Plus 時，才會向您收費。

• 傳送至負載平衡器 IP 位址的封包，可由 Google 車隊中的任何 GFE 回應；不過，掃描負載平衡器 IP 位址和目的地連接埠組合，只會針對每個 TCP 連線查詢單一 GFE。負載平衡器的 IP 位址不會指派給單一裝置或系統。因此，掃描以 GFE 為基礎的負載平衡器 IP 位址，並不會掃描 Google 機群中的所有 GFE。

有鑑於此，以下是稽核後端執行個體安全性的更有效方法：

• 安全性稽核人員應檢查負載平衡器的轉送規則設定。轉送規則會定義負載平衡器接受封包的目的地通訊埠，並將封包轉送至後端。對於以 GFE 為基礎的負載平衡器，每個外部轉送規則只能參照單一目的地 TCP 通訊埠。如果負載平衡器使用 TCP 通訊埠 443，連線升級為 QUIC (HTTP/3) 時，就會使用 UDP 通訊埠 443。

• 安全稽核人員應檢查適用於後端 VM 的防火牆規則設定。您設定的防火牆規則會封鎖 GFE 到後端 VM 的流量，但不會封鎖傳入 GFE 的流量。如需最佳做法，請參閱防火牆規則章節。

傳輸層安全標準 (TLS) 終止

下表概略說明外部應用程式負載平衡器如何處理 TLS 終止作業。

逾時和重試

外部應用程式負載平衡器支援下列 HTTP 或 HTTPS 流量的逾時類型：

後端服務逾時

可設定的後端服務逾時：代表負載平衡器等待後端處理 HTTP 要求並傳回對應 HTTP 回應的時間上限。除了無伺服器網路端點群組 (NEG) 以外，後端服務的逾時預設值為 30 秒。

舉例來說，如果您要下載 500 MB 的檔案，而後端服務逾時值為 90 秒，負載平衡器就會預期後端會在 90 秒內傳送整個 500 MB 的檔案。您可以將後端服務逾時時間設為不足，讓後端無法傳送完整的 HTTP 回應。在這種情況下，如果負載平衡器至少已從後端收到 HTTP 回應標頭，則會傳回完整的回應標頭，以及後端服務逾時前所能取得的回應內文。

建議您將後端服務逾時時間設為後端處理 HTTP 回應所需的最長時間。如果後端執行的軟體需要更多時間處理 HTTP 要求並傳回完整回應，建議您增加後端服務逾時時間。舉例來說，如果您看到 HTTP 408 狀態碼回應，且包含 jsonPayload.statusDetail client_timed_out 錯誤，建議您提高逾時時間。

後端服務逾時值可接受的值介於 1 和 2,147,483,647 秒之間，但較大的值並非實用的設定選項。Google Cloud 也無法保證基礎 TCP 連線可在後端服務逾時值的整個期間保持開啟。 如果是全球和傳統應用程式負載平衡器，GFEs 會強制執行有效的後端服務逾時上限 86,400 秒 (1 天)。 用戶端系統必須實作重試邏輯，而非依賴 TCP 連線長時間保持開啟狀態。

如要設定後端服務逾時時間，請使用下列其中一種方法：

區域性外部應用程式負載平衡器會使用已設定的網址對應 routeActions.timeout 參數，並忽略後端服務逾時時間。如果未設定 routeActions.timeout，系統會使用後端服務逾時的值。提供 routeActions.timeout 時，系統會忽略後端服務逾時，並改用 routeActions.timeout 的值做為要求和回應逾時時間。

用戶端 HTTP 保持運作逾時

用戶端 HTTP 保持運作逾時值代表 (下游) 用戶端與下列其中一種 Proxy 之間 TCP 連線可閒置的時間長度上限：

• 全域外部應用程式負載平衡器或傳統版應用程式負載平衡器：第一層 Google 前端

• 區域性外部應用程式負載平衡器：Envoy Proxy

用戶端 HTTP 保持運作逾時時間代表基礎 TCP 連線的 TCP 閒置逾時時間。用戶端 HTTP 保持運作逾時機制不適用於 WebSocket。

用戶端 HTTP 保持運作逾時時間的預設值為 610 秒。針對全球和區域性外部應用程式負載平衡器，您可以設定用戶端 HTTP keepalive 逾時值，範圍為 5 到 1200 秒。

如要設定用戶端 HTTP keepalive 逾時，請使用下列任一方法：

負載平衡器的用戶端 HTTP keepalive 逾時時間必須大於下游用戶端或 Proxy 使用的 HTTP keepalive (TCP 閒置) 逾時時間。如果下游用戶端的 HTTP keepalive (TCP 閒置) 逾時時間大於負載平衡器的用戶端 HTTP keepalive 逾時時間，就可能發生競爭狀態。從下游用戶端的角度來看，已建立的 TCP 連線可閒置的時間，可超過負載平衡器允許的時間。這表示負載平衡器認為 TCP 連線已關閉後，下游用戶端就能傳送封包。發生這種情況時，負載平衡器會回應 TCP 重設 (RST) 封包。

當用戶端 HTTP 保持運作逾時，GFE 或 Envoy Proxy 會向用戶端傳送 TCP FIN，以便妥善關閉連線。

後端 HTTP 保持運作逾時

外部應用程式負載平衡器是使用至少兩個 TCP 連線的 Proxy：

• 對於全域外部應用程式負載平衡器或傳統版應用程式負載平衡器，在 (下游) 用戶端和第一層 GFE 之間會存在第一個 TCP 連線。第一層 GFE 會連線至第二層 GFE，然後第二層 GFE 會開啟第二個 TCP 連線至後端。

• 對於區域性外部應用程式負載平衡器，在 (下游) 用戶端和 Envoy Proxy 之間存在第一個 TCP 連線。接著，Envoy 代理程式會開啟第二個 TCP 連線，連線至後端。

負載平衡器的次要 TCP 連線可能不會在每次要求後關閉；這些連線可以保持開啟狀態，以便處理多個 HTTP 要求和回應。後端 HTTP 保持運作逾時值會定義負載平衡器與後端之間的 TCP 閒置逾時值。後端 HTTP 保持運作逾時時間不適用於 WebSocket。

後端保留連線逾時時間固定為 10 分鐘 (600 秒)，無法變更。這有助於確保負載平衡器維持閒置連線至少 10 分鐘。在這個期間過後，負載平衡器可隨時將終止封包傳送至後端。

負載平衡器的後端保活逾時時間必須小於後端執行軟體使用的保活逾時時間。這可避免競爭狀態，也就是後端的作業系統可能會透過 TCP 重設 (RST) 關閉 TCP 連線。由於負載平衡器的後端保持運作逾時時間無法設定，因此您必須設定後端軟體，使其 HTTP 保持運作 (TCP 閒置) 逾時時間值大於 600 秒。

當後端 HTTP 保持運作逾時時間到期時，GFE 或 Envoy Proxy 會傳送 TCP FIN 至後端 VM，以便妥善關閉連線。

下表列出修改常見網路伺服器軟體的「保持運作」逾時值所需的變更。

QUIC 工作階段閒置逾時

QUIC 工作階段閒置逾時代表 QUIC 工作階段在用戶端與全域外部應用程式負載平衡器或傳統版應用程式負載平衡器的 GFE 之間閒置的最大時間。

QUIC 工作階段閒置逾時值的定義為用戶端閒置逾時時間或 GFE 閒置逾時時間 (300 秒) 的較小值。GFE 閒置逾時時間固定為 300 秒。可設定用戶端閒置逾時。

重試

重試邏輯的支援情形取決於外部應用程式負載平衡器的模式。

GKE Ingress 支援 WebSocket 通訊協定。

不合法的要求和回應處理

負載平衡器會因多種原因，阻止用戶端要求到達後端，也會阻止後端回應到達用戶端。有些原因完全是為了達成 HTTP/1.1 法規遵循，有些則是為了避免資料意外往返於後端。無法停用任何檢查。

負載平衡器會封鎖下列要求，以確保符合 HTTP/1.1 法規遵循要求：

• 無法解析要求的第一行。
• 標頭缺少冒號 (:) 分隔符號。
• 標頭或第一行含有無效字元。
• 內容長度不是有效數字，或有多個內容長度標頭。
• 有多個傳輸編碼鍵，或是有無法識別的傳輸編碼值。
• 有未分為區塊的主體，且未指定內容長度。
• 主體區塊無法解析，這是部分資料會到達後端的唯一情況。負載平衡器收到無法解析的區塊時，會關閉連至用戶端和後端的連線。

處理要求

如果符合以下任一條件，則負載平衡器將封鎖該要求：

• 要求標頭和要求網址的總大小超過 外部應用程式負載平衡器的最大要求標頭大小限制。
• 要求方法不允許主體，但要求含有主體。
• 要求中包含 Upgrade 標頭，但未使用 Upgrade 標頭來啟用 WebSocket 連線。
• HTTP 版本未知。

回應處理

如果符合以下任一條件，負載平衡器就會封鎖後端的回應：

• 回應標頭的總大小超過外部應用程式負載平衡器的回應標頭大小上限。
• HTTP 版本未知。

在處理要求和回應時，負載平衡器可能會先移除或覆寫 HTTP/1.1 中的跳躍式標頭，再將標頭轉送至預期目的地。

流量分配

將後端執行個體群組或 NEG 新增至後端服務時，您必須指定平衡模式，以便定義評估後端負載和目標容量的方法。外部應用程式負載平衡器支援兩種平衡模式：

• RATE (針對群組或 NEG) 是每秒目標要求 (查詢) 數量上限 (RPS、QPS)。如果所有後端的容量達到或超過上限，則可超出目標上限的 RPS/QPS。

• UTILIZATION 是執行個體群組中 VM 的後端使用率。

流量在後端之間的分配方式取決於負載平衡器的模式。

全域外部應用程式負載平衡器

在 Google Front End (GFE) 將要求傳送至後端執行個體之前，GFE 會預估哪些後端執行個體有能力接收要求。系統會主動進行這項容量估算，而不是在要求抵達時進行。GFE 會定期接收可用容量相關資訊，並據此分配傳入的要求。

「容量」的意思部分取決於平衡模式。RATE 模式相對簡單：GFE 會精確決定每秒可指派多少要求。以 UTILIZATION 為基礎的負載平衡功能較為複雜：負載平衡器會檢查執行個體目前的使用率，然後估算每個執行個體可處理的查詢負載。隨著執行個體的使用率和流量模式變化，這項預估值也會隨之變動。

容量估計和主動指派這兩個因素都會影響執行個體之間的分配情形。因此，Cloud Load Balancing 的運作方式與簡單的循環制負載平衡器不同，後者會將要求以 50:50 的比例分配給兩個執行個體。 Google Cloud 負載平衡功能會嘗試為每個要求最佳化後端執行個體選項。

全域外部應用程式負載平衡器的負載平衡機制分為兩層，平衡模式會決定傳送至每個後端 (執行個體群組或 NEG) 的流量權重或比例。接著，負載平衡政策 (LocalityLbPolicy) 會決定如何將流量分配給群組內的執行個體或端點。詳情請參閱「負載平衡區域政策 (後端服務 API 說明文件)」。

對於傳統版應用程式負載平衡器，平衡模式會用來選取最合適的後端 (執行個體群組或 NEG)。接著，流量會以輪流方式，在後端的執行個體或端點之間分配。

要求的發布方式

以 GFE 為基礎的外部應用程式負載平衡器會使用下列程序分配傳入的要求：

1. 從用戶端到第一層 GFE。邊緣路由器會在 Google 網路的邊界宣告轉送規則的外部 IP 位址。每個廣告都會列出第 3 層和第 4 層負載平衡系統 (Maglev) 的下一個躍點。Maglev 系統會將流量導向第一層 Google Front End (GFE)。
   • 使用進階級時，Google 會在全球所有服務據點宣傳負載平衡器的 IP 位址。每個負載平衡器 IP 位址都是全球 Anycast。
   • 使用標準級時，Google 會從與轉送規則所在地區相關聯的服務據點宣傳負載平衡器的 IP 位址。負載平衡器使用地區性外部 IP 位址。使用標準級轉送規則時，您只能使用與負載平衡器轉送規則相同區域的執行個體群組和區域 NEG 後端。
2. 從第一層 GFE 到第二層 GFE。第一層 GFE 會視需要終止 TLS，然後根據下列程序將流量轉送至第二層 GFE：
   • 第一層 GFE 會剖析網址對應，並選取後端服務或後端值區。
   • 對於具有網際網路 NEG 的後端服務，第一層 GFE 會選取與第一層 GFE 同處的第二層外部轉送閘道。轉送閘道會將要求傳送至網際網路 NEG 端點。這就是網路端點群組 (NEG) 的請求分配程序。
   • 如果後端服務含有無伺服器 NEG 和 Private Service Connect (PSC) NEG，以及單一區域的後端值區，第一層 GFE 會在與 NEG 或值區所在區域相符的區域中選取第二層 GFE。對於多區域 Cloud Storage 值區，第一層 GFE 會選取第二層 GFE，這些 GFE 位於值區所在區域，或盡可能靠近多區域值區的區域 (由網路往返時間定義)。
   • 如果後端服務含有執行個體群組、含有 GCE_VM_IP_PORT 端點的區域 NEG 和混合 NEG，Google 的容量管理系統會向第一層 GFE 通知每個後端的使用和設定容量。後端的設定容量是由平衡模式、平衡模式的目標容量和容量配置器定義。
     • 標準級：第一層 GFE 會在包含後端的區域中選取第二層 GFE。
     • 高級層級：第一層級 GFEs 會從一組適用區域中選取第二層級 GFEs。適用的區域是指已設定後端的所有區域，但不含已設定後端但容量為零的區域。第一層 GFE 會選取適用區域中最近的第二層 GFE (由網路往返時間定義)。如果後端是在兩個或更多區域中設定，如果第一個選擇的區域已滿，第一層 GFEs 可以將要求溢出至其他適用的區域。如果第一選擇區域的所有後端都已達到容量上限，系統就會溢流至其他區域。
3. 第二層 GFE 選取後端。第二層 GFE 位於區域的可用區中。他們會使用下列程序選取後端：
   • 如果後端服務含有無伺服器 NEG、Private Service Connect NEG 和後端儲存格，第二層 GFE 會將要求轉送至 Google 的正式版系統。這會完成這些後端的要求分配程序。

   • 如果後端服務含有執行個體群組、含有 GCE_VM_IP_PORT 端點的區域 NEG 和混合 NEG，Google 的健康狀態檢查探測系統會向第二層 GFE 通知後端執行個體或端點的健康狀態檢查狀態。

     僅限 Premium 等級：如果第二層 GFE 在其所在區域中沒有健康的後端執行個體或端點，可能會將要求傳送至其他適用區域的另一個第二層 GFE，並在該區域中設定後端。不同地區的第二層 GFEs 之間的溢出效應並不會耗盡所有可能的地區對地區組合。如果您需要將流量從特定區域的後端移除，請改為將後端設為無法通過健康狀態檢查，並將後端的容量縮放器設為零，這樣第一層 GFE 就會在前一個步驟中排除該區域。

   接著，第二層 GFE 會將要求導向所屬區域內區域的後端執行個體或端點，如下一個步驟所述。

4. 第二層 GFE 會選取區域。根據預設，第二層 GFE 會使用 WATERFALL_BY_REGION 演算法，其中每個第二層 GFE 會優先選取與包含第二層 GFE 的區域相同的後端執行個體或端點。由於 WATERFALL_BY_REGION 可將區域間的流量降至最低，因此在低要求率下，每個第二層 GFE 可能會專門將要求傳送至與第二層 GFE 位於同一區域的後端。

   僅限全球外部應用程式負載平衡器，可使用 serviceLbPolicy 將第二層 GFE 設定為使用下列任一替代演算法：

   • SPRAY_TO_REGION：第二層 GFE 不建議選取與第二層 GFE 位於同一區域的後端執行個體或端點。第二層 GFE 會嘗試將流量分配給該區域所有區域中的所有後端執行個體或端點。這麼做可以讓負載分布更均勻，但會增加區域間的流量。
   • WATERFALL_BY_ZONE：第二層 GFE 強烈建議選取與第二層 GFE 位於同一區域的後端執行個體或端點。當目前區域中的所有後端都已達到所設定的容量，第二層 GFE 才會將要求導向不同區域的後端。
5. 第二層 GFE 會選取區域中的執行個體或端點。根據預設，第二層 GFE 會以循環制方式將要求分配給後端。僅限全域外部應用程式負載平衡器，您可以使用負載平衡位置政策 (localityLbPolicy) 變更這項設定。負載平衡位置政策僅適用於先前步驟中所述所選區域內的後端。

區域性外部應用程式負載平衡器

對於區域性外部應用程式負載平衡器，流量分配會根據負載平衡模式和負載平衡地區政策。

平衡模式會決定傳送至各群組 (執行個體群組或 NEG) 的流量權重和比率。負載平衡地區政策 (LocalityLbPolicy) 會決定群組內的後端負載平衡方式。

後端服務收到流量時，會先根據後端的平衡模式，將流量導向後端 (執行個體群組或 NEG)。選取後端後，系統會根據負載平衡局部位置政策，將流量分配到該後端群組中的執行個體或端點。

如要瞭解詳情，請參考下列資源：

• 平衡模式
• 負載平衡地區政策 (區域後端服務 API 說明文件)。

工作階段相依性

工作階段相依性會盡力嘗試將來自特定用戶端的要求傳送至同一個後端，只要後端的健康狀態良好且具有容量，即可根據設定的平衡模式。

使用工作階段相依性時，建議使用 RATE 平衡模式，而非 UTILIZATION。工作階段相依性在平衡模式也設為每秒要求數 (RPS) 時可發揮最佳效果。

外部應用程式負載平衡器提供下列工作階段相依性類型：

• 無。未為負載平衡器設定工作階段相依性。
• 用戶端 IP 相依性
• 產生的 Cookie 相依性
• 標頭欄位相依性
• HTTP Cookie 相依性
• 有狀態 Cookie 型工作階段相依性

下表列出外部應用程式負載平衡器支援的工作階段相依性選項：

高可用性和容錯移轉

您可以在負載平衡器層級設定外部應用程式負載平衡器的高可用性和容錯功能。您可以在需要備份的任何區域中建立備份區域性外部應用程式負載平衡器，以便處理這項問題。

下表說明備援行為。

支援 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 用戶端向Google Cloud 負載平衡器宣傳的值實際上毫無意義，因為負載平衡器不會向用戶端啟動串流。

如果負載平衡器使用 HTTP/2 與在 VM 上執行的伺服器通訊，則會遵循伺服器宣傳的 SETTINGS_MAX_CONCURRENT_STREAMS 值。如果宣告的值為零，負載平衡器就無法將要求轉送至伺服器，這可能會導致錯誤。

HTTP/2 限制

• 負載平衡器和執行個體之間的 HTTP/2 可能需要比 HTTP 或 HTTPS 多上許多的 TCP 連線。連線集區 (一種可減少 HTTP 或 HTTPS 連線數量的最佳化方式) 不適用於 HTTP/2。因此，後端連線頻率會提高，導致後端延遲時間變長。
• 負載平衡器和後端之間的 HTTP/2 不支援透過單一 HTTP/2 連線串流執行 WebSocket 通訊協定 (RFC 8441)。
• 負載平衡器和後端之間的 HTTP/2 不支援伺服器推送。
• Google Cloud API 或 Google Cloud 主控台不會顯示 gRPC 錯誤率和要求量。如果 gRPC 端點傳回錯誤，負載平衡器記錄和監控資料會回報 200 OK HTTP 狀態碼。

透過 TCP 傳輸明文 HTTP/2 (H2C)

透過 TCP 傳輸的純文字 HTTP/2 (也稱為 H2C) 可讓您在沒有 TLS 的情況下使用 HTTP/2。下列兩種連線都支援 H2C：

• 用戶端與負載平衡器之間的連線。無須進行特殊設定。

• 負載平衡器與後端之間的連線。

  如要為負載平衡器與其後端之間的連線設定 H2C，請將後端服務通訊協定設為 H2C。

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

傳統版應用程式負載平衡器不支援 H2C。

支援 HTTP/3

HTTP/3 是新一代的網際網路通訊協定。它是以 IETF QUIC 為基礎，這是以原始 Google QUIC 通訊協定為基礎所開發的通訊協定。外部應用程式負載平衡器、Cloud CDN 和用戶端之間支援 HTTP/3。

具體情況如下：

• IETF QUIC 是一種傳輸層通訊協定，提供類似 TCP 的擁塞控制和可靠性，並使用 TLS 1.3 提供安全性，且效能更佳。
• HTTP/3 是建立在 IETF QUIC 之上的應用程式層，且會依賴 QUIC 處理多工處理、壅塞控制、損失偵測和重傳。
• HTTP/3 可加快用戶端連線的啟動速度、能避免多工串流發生隊頭阻塞問題，並且可在用戶端的 IP 位址變更時支援連線遷移。
• 系統支援用戶端與負載平衡器之間的 HTTP/3 連線，但不支援負載平衡器與其後端之間的連線。
• HTTP/3 連線會使用 BBR 壅塞控制演算法。

負載平衡器上的 HTTP/3 可縮短網頁載入時間、減少影片重新緩衝情形，並提高高延遲連線的處理量。

下表列出各模式中外部應用程式負載平衡器的 HTTP/3 支援情形。

HTTP/3 的協商方式

啟用 HTTP/3 後，負載平衡器會將這項支援功能宣傳給用戶端，讓支援 HTTP/3 的用戶端嘗試與 HTTPS 負載平衡器建立 HTTP/3 連線。

• 正確實作的用戶端若無法建立 HTTP/3 連線，一律會改回使用 HTTPS 或 HTTP/2。
• 支援 HTTP/3 的用戶端會使用先前快取的 HTTP/3 支援知識，以便日後省去不必要的來回傳輸。
• 由於有這樣的備用機制，所以在負載平衡器中啟用或停用 HTTP/3 不會破壞負載平衡器連線到用戶端的能力。

支援功能會在 Alt-Svc HTTP 回應標頭中宣傳。啟用 HTTP/3 後，負載平衡器的回應會包含下列 alt-svc 標頭值：

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000"

如果已明確將 HTTP/3 設為 DISABLE，回應就不會包含 alt-svc 回應標頭。

在 HTTPS 負載平衡器中啟用 HTTP/3 後，某些情況可能導致用戶端改回使用 HTTPS 或 HTTP/2，而不是進行 HTTP/3 交涉。其中包括：

• 用戶端支援的 HTTP/3 版本與 HTTPS 負載平衡器支援的 HTTP/3 版本不相容。
• 負載平衡器偵測到 UDP 流量遭到封鎖或速率受限制，且這樣的封鎖或限制會導致 HTTP/3 無法運作
• 用戶端完全不支援 HTTP/3，因此不會嘗試協商 HTTP/3 連線。

當連線改回使用 HTTPS 或 HTTP/2 時，我們不會將此視為負載平衡器失敗。

啟用 HTTP/3 前，請確認您的工作負載可接受先前所述的行為。

設定 HTTP/3

NONE (預設) 和 ENABLE 都會為負載平衡器啟用 HTTP/3 支援功能。

啟用 HTTP/3 後，負載平衡器會將 HTTP/3 公告給用戶端，讓支援 HTTP/3 的用戶端與負載平衡器協商 HTTP/3 版本。不支援 HTTP/3 的用戶端不會協商 HTTP/3 連線。除非您發現有錯誤的用戶端實作，否則不需要明確停用 HTTP/3。

外部應用程式負載平衡器提供三種設定 HTTP/3 的方式，如下表所示。

如要明確啟用 (或停用) HTTP/3，請按照下列步驟操作。

gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
    --global \
    --quic-override=QUIC_SETTING

POST https://www.googleapis.com/v1/compute/projects/PROJECT_ID/global/targetHttpsProxies/TARGET_PROXY_NAME/setQuicOverride

{
  "quicOverride": QUIC_SETTING
}

WebSocket 支援

Google Cloud 當您使用 HTTP 或 HTTPS 做為後端的通訊協定時，以 HTTP(S) 為基礎的負載平衡器會支援 WebSocket 通訊協定。負載平衡器不需要任何設定，即可透過 Proxy 進行 WebSocket 連線。

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

WebSocket 通訊協定的運作方式如下：

1. 負載平衡器會辨識來自 HTTP 或 HTTPS 用戶端的 WebSocket Upgrade 要求。要求包含 Connection: Upgrade 和 Upgrade: websocket 標頭，後面接著其他相關的 WebSocket 要求標頭。
2. 後端傳送 WebSocket Upgrade 回應。後端執行個體會傳送 101 switching protocol 回應，其中包含 Connection: Upgrade 和 Upgrade: websocket 標頭，以及其他 WebSocket 相關的回應標頭。
3. 負載平衡器會在目前連線期間代理雙向流量。

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

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

gRPC 支援

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

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

如要將 gRPC 與應用程式搭配使用，端到端皆必須透過 HTTP/2 經由 Proxy 傳送要求。 Google Cloud 如要這麼做，請使用下列任一設定建立應用程式負載平衡器：

• 針對端對端未加密流量 (不含 TLS)：您需要建立 HTTP 負載平衡器 (使用目標 HTTP Proxy 設定)。此外，您可以將後端服務通訊協定設為 H2C，讓負載平衡器在負載平衡器與其後端之間使用 HTTP/2 進行未加密連線。

• 針對端對端加密流量 (使用 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 交涉。

支援相互傳輸層安全性

相互傳輸層安全性 (mTLS) 是用於用戶端和伺服器之間相互驗證的業界標準通訊協定。mTLS 可確保用戶端和伺服器都持有由信任的憑證授權單位 (CA) 核發的有效憑證，藉此驗證彼此身分。與只驗證伺服器的標準 TLS 不同，mTLS 要求用戶端和伺服器都出示憑證，在建立通訊之前確認雙方的身分。

所有應用程式負載平衡器都支援 mTLS。使用 mTLS 時，負載平衡器會要求用戶端在與負載平衡器進行 TLS 握手期間傳送憑證，以便驗證自身。您可以設定 憑證管理工具信任儲存庫，讓負載平衡器日後用於驗證用戶端憑證的信任鏈結。

如要進一步瞭解 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 425 Too Early 狀態碼，拒絕含有 HTTP Early-Data: 1 標頭的要求。

含有早期資料的要求會將 HTTP 早期資料標頭設為 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 (不建議用於多數工作負載)。這項設定可啟用 TLS 1.3 早期資料，適用於採用任何 HTTP 方法 (包括 POST 等非冪等方法) 的要求。這個模式不會強制執行任何其他限制。這個模式對 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 回應中看到 HTTP 425 Early 狀態碼：

  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>
  

限制

• HTTPS 負載平衡器在終止 SSL 連線時，不會傳送 close_notify 關閉警示。也就是說，負載平衡器會關閉 TCP 連線，而非執行 SSL 關機作業。
• HTTPS 負載平衡器只支援憑證的通用名稱 (CN) 屬性或主體別名 (SAN) 屬性中網域的英文字母小寫。只有在目標 Proxy 中設為主要憑證時，系統才會傳回網域中含有大寫字元的憑證。
• 除了採用網際網路 NEG 後端的負載平衡器以外，HTTPS 負載平衡器不會使用伺服器名稱指示 (SNI) 擴充功能連線至後端。詳情請參閱「從負載平衡器到後端的加密」。

• 在共用虛擬私有雲環境中，如果使用區域性外部應用程式負載平衡器搭配 Cloud Run，服務專案中的獨立虛擬私有雲網路就能將流量傳送至同一個共用虛擬私有雲環境中任何其他服務專案中部署的任何其他 Cloud Run 服務。這是已知問題。

• Google Cloud 無法保證基礎 TCP 連線可在後端服務逾時值的整個期間保持開啟。用戶端系統必須實作重試邏輯，而非依賴 TCP 連線長時間保持開啟。

• 您無法使用Google Cloud 控制台在進階級中建立區域性外部應用程式負載平衡器。 此外，只有支援標準級的地區，才能在 Google Cloud 控制台中使用這些負載平衡器。請改用 gcloud CLI 或 API。

• 您可以透過要求快取無效化，強制讓快取忽略某個物件或一組物件。如果您使用全球外部應用程式負載平衡器，並搭配共用虛擬私有雲跨專案服務參照，則服務專案管理員預設不會具備要求的權限，無法要求快取無效化。這是因為快取無效作業是在前端專案中設定 (也就是負載平衡器的轉送規則、目標 Proxy 和網址對應)。因此，只有具有 IAM 角色的主體 (例如運算網路管理員角色)，才能在前端專案中設定負載平衡器相關資源，並發出快取無效作業。負責控管在個別專案中佈建後端服務的服務管理員，需要與前端專案的負載平衡器管理員合作，為跨專案服務發出快取無效化命令。

後續步驟

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

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

• 如果您是傳統版應用程式負載平衡器的現有使用者，請務必在規劃全域外部應用程式負載平衡器的新部署作業時，查看遷移概觀。

• 如要瞭解如何使用 Terraform 自動設定外部應用程式負載平衡器，請參閱「外部應用程式負載平衡器的 Terraform 模組範例」。

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

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

• 如要瞭解如何提供網站內容，請參閱「提供網站內容」。

• 如要查看 Google PoP 的位置，請參閱 GFE 位置。

• 如要瞭解容量管理，請參閱利用負載平衡進行容量管理教學課程和利用全域負載平衡進行應用程式容量最佳化。

• 如要瞭解如何使用憑證管理工具來佈建及管理 SSL 憑證，請參閱 憑證管理工具總覽。

• 如要將自訂邏輯插入負載平衡資料路徑，請設定 Service Extensions 外掛程式或呼叫。

• 僅限區域外部 Application Load Balancer，您可以嘗試使用 Apigee Shadow API Discovery，在現有的Google Cloud 基礎架構中尋找 shadow API (也稱為未記錄的 API)。請務必先詳閱相關限制，再啟用 Shadow API Discovery。