本文將深入探討外部應用程式負載平衡器如何處理連線、路由流量及維持工作階段親和性。
連結的運作方式
Google Cloud的外部應用程式負載平衡器 (全域和區域) 會使用分散式 Proxy (GFE) 或 Envoy 管理的子網路，簡化路由程序。這些閘道提供可設定的逾時、傳輸層安全標準 (TLS) 終止和內建安全性，確保應用程式在全球或區域內都能以符合規範且可擴充的方式交付。
全域外部應用程式負載平衡器連線
全域外部應用程式負載平衡器是由許多稱為 Google Front End (GFE) 的 Proxy 導入。不只有單一 Proxy。在進階層級中，系統會從多個服務據點通告相同的全域外部 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 封包，或在完成回應後發出 HTTP/2 GOAWAY 框架，以乾淨利落地關閉 TCP 連線。這項行為不會干擾任何有效要求或回應。
HTTP 連線和 TCP 工作階段的數量取決於連線的 GFE 數量、連線至 GFE 的用戶端數量、後端的通訊協定，以及後端的部署位置。
詳情請參閱解決方案指南「利用全域負載平衡進行應用程式容量最佳化」中的「外部應用程式負載平衡器運作方式」。
區域性外部應用程式負載平衡器連線
區域性外部應用程式負載平衡器是透過 Envoy Proxy 實作的代管服務。區域外部應用程式負載平衡器會使用名為「僅限 Proxy 的子網路」的共用子網路，佈建一組 IP 位址，供 Google 代表您執行 Envoy Proxy。這個僅限 Proxy 子網路的 --purpose 旗標已設為 REGIONAL_MANAGED_PROXY。特定網路和區域中的所有區域 Envoy 型負載平衡器都會共用這個子網路。
用戶端會使用負載平衡器的 IP 位址和通訊埠連線至負載平衡器。系統會將用戶端要求導向與用戶端位於相同區域的 Proxy 專用子網路。負載平衡器會終止用戶端要求，然後從僅限 Proxy 的子網路開啟連至後端的新連線。因此，負載平衡器傳送的封包來源 IP 位址來自僅限 Proxy 的子網路。
視後端服務設定而定，Envoy Proxy 用於連線至後端的通訊協定可以是 HTTP、HTTPS 或 HTTP/2。如果是 HTTP 或 HTTPS，HTTP 版本為 HTTP 1.1。根據 HTTP 1.1 規格，HTTP 保持運作功能預設為啟用。Envoy Proxy 會將用戶端 HTTP 保持運作逾時和後端保持運作逾時都設為預設值 600 秒。您可以更新用戶端 HTTP 保持運作逾時，但後端保持運作逾時值是固定的。您可以設定後端服務逾時，藉此設定要求/回應逾時。詳情請參閱「逾時和重試」。
用戶端與負載平衡器的通訊
- 用戶端可透過 HTTP/1.0、HTTP/1.1、HTTP/2 或 HTTP/3 通訊協定與負載平衡器進行通訊。
- 使用 HTTPS 時，現代的用戶端預設為使用 HTTP/2。這是在用戶端上控制的，而不是在 HTTPS 負載平衡器上控制的。
- 您無法透過變更負載平衡器的設定來停用 HTTP/2。不過，您可以將部分用戶端設定為使用 HTTP 1.1 而非 HTTP/2。舉例來說，搭配
curl使用--http1.1參數。 - 外部應用程式負載平衡器支援
HTTP/1.1 100 Continue回應。
如要查看外部應用程式負載平衡器在各模式下轉送規則支援的完整通訊協定清單，請參閱負載平衡器功能。
用戶端封包的來源 IP 位址
後端看到的封包來源 IP 位址「不是」負載平衡器的外部 IP 位址。Google Cloud 換句話說，會有兩個 TCP 連線。
全域外部應用程式負載平衡器：連線 1：從原始用戶端到負載平衡器 (GFE)：
- 來源 IP 位址：原始用戶端 (或外部 IP 位址，如果用戶端位於 NAT 閘道或轉送 Proxy 後方)。
- 目的地 IP 位址：負載平衡器的 IP 位址。
連線 2：從負載平衡器 (GFE) 到後端 VM 或端點：
來源 IP 位址：防火牆規則中指定範圍內的 IP 位址。
目的地 IP 位址：虛擬私有雲網路中後端 VM 或容器的內部 IP 位址。
連線 1：從原始用戶端到負載平衡器 (僅限 Proxy 的子網路)：
- 來源 IP 位址：原始用戶端 (或外部 IP 位址，如果用戶端位於 NAT 閘道或轉送 Proxy 後方)。
- 目的地 IP 位址：負載平衡器的 IP 位址。
連線 2：從負載平衡器 (僅限 Proxy 子網路) 到後端 VM 或端點：
來源 IP 位址：僅限 Proxy 的子網路中的 IP 位址，與部署在相同地區和網路的負載平衡器共用。
目的地 IP 位址：虛擬私有雲網路中後端 VM 或容器的內部 IP 位址。
特殊路徑
Google Cloud 會使用虛擬私有雲網路中未定義的特殊路徑，為下列類型的流量傳送封包：
- 健康狀態檢查 (分散式 Envoy 健康狀態檢查除外)。詳情請參閱健康狀態檢查路徑。
- 全域外部應用程式負載平衡器和傳統版應用程式負載平衡器的 GFE 與後端之間。詳情請參閱「Google 前端與後端之間的路徑」。
Google Cloud 會使用僅限 Proxy 的子網路的子網路路徑，為下列類型的流量傳送封包：
- 使用分散式 Envoy 健康狀態檢查時。
如果是區域性外部應用程式負載平衡器， Google Cloud 會使用開放原始碼 Envoy Proxy 終止用戶端對負載平衡器的要求。負載平衡器會終止 TCP 工作階段，並從區域的僅限 Proxy 子網路開啟新的 TCP 工作階段，連至後端。虛擬私有雲網路中定義的路徑可協助 Envoy Proxy 與後端通訊，以及後端與 Envoy Proxy 通訊。
開放的通訊埠
GFE 具有多個開啟的通訊埠，以支援在同一架構上執行的其他 Google 服務。執行通訊埠掃描時，您可能會看到在 GFE 上執行的其他 Google 服務，以及其他開啟的通訊埠。
以 GFE 為基礎的負載平衡器 (全域外部應用程式負載平衡器和傳統版應用程式負載平衡器) 一律會顯示通訊埠 80 和 443 為開啟狀態 (以及您在負載平衡器轉送規則中設定的任何其他通訊埠)。不過，如果您尚未設定通訊埠 80 或通訊埠 443 的轉送規則，系統會拒絕傳送至這些通訊埠的任何連線。反之，區域外部應用程式負載平衡器是使用 Envoy Proxy 實作，掃描時不會顯示額外的開放連接埠。從稽核角度來看，對以 GFE 為基礎的負載平衡器 IP 位址執行通訊埠掃描並無用處，原因如下：
執行 TCP SYN 探測時，連接埠掃描 (例如使用
nmap) 通常不會預期有任何回應封包或 TCP RST 封包。只有在您已為通訊埠設定轉送規則時，GFE 才會傳送 SYN-ACK 封包來回應 SYN 探查。只有在收到傳送至負載平衡器 IP 位址和轉送規則中設定目的地通訊埠的封包時，GFE 才會將封包傳送至後端。傳送至其他 IP 位址或通訊埠的封包不會傳送至後端。GFE 會實作 Google Cloud Armor 等安全功能。透過 Cloud Armor Standard，GFE 可全天候防範巨流量和通訊協定型 DDoS 攻擊，以及 SYN 洪水攻擊。即使您未明確設定 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 終止作業。
| 負載平衡器模式 | 傳輸層安全標準 (TLS) 終止 |
|---|---|
| 全域外部應用程式負載平衡器 | TLS 會在 GFE 上終止，而 GFE 可能位於世界任何地方。 |
| 傳統版應用程式負載平衡器 | TLS 會在 GFE 上終止，而 GFE 可能位於世界任何地方。 |
| 區域性外部應用程式負載平衡器 | TLS 會在使用者所選區域的僅限 Proxy 子網路中，於 Envoy Proxy 上終止。如果需要對 TLS 終止的地區進行地理位置控制，請使用這個負載平衡器模式。 |
逾時和重試
外部應用程式負載平衡器支援下列類型的 HTTP 或 HTTPS 流量逾時：
| 逾時類型和說明 | 預設值 | 支援自訂逾時值 | ||
|---|---|---|---|---|
| 全球 | 傳統版 | 區域 | ||
| 後端服務逾時1
要求和回應逾時。代表負載平衡器將要求的第一個位元組傳送至後端，到後端將 HTTP 回應的最後一個位元組傳回負載平衡器之間，允許的最長時間。如果後端未在時限內將整個 HTTP 回應傳回負載平衡器，系統就會捨棄其餘回應資料。 |
|
|||
| 用戶端 HTTP 保持運作逾時
用戶端與負載平衡器 Proxy 之間的 TCP 連線可閒置的時間長度上限。(多個 HTTP 要求可能會使用相同的 TCP 連線)。
|
610 秒 | |||
| 後端 HTTP 保持運作逾時
負載平衡器 Proxy 與後端之間的 TCP 連線可閒置的時間長度上限。(多個 HTTP 要求可能會使用相同的 TCP 連線)。
|
|
|||
| QUIC 工作階段閒置逾時
QUIC 會話在全域外部應用程式負載平衡器或傳統版應用程式負載平衡器的 (下游) 用戶端和 GFE 之間閒置的最長時間。 |
全域外部應用程式負載平衡器和傳統版應用程式負載平衡器： QUIC 工作階段閒置逾時時間為用戶端閒置逾時時間或 GFE 閒置逾時時間 (300 秒) 的最小值。 GFE 閒置逾時時間固定為 300 秒。您可以設定用戶端閒置逾時。 |
|||
1無法為無伺服器 NEG 後端設定。無法為後端 bucket 設定。
後端服務逾時
可設定的後端服務逾時代表負載平衡器等待後端處理 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 連線在後端服務逾時值的整個期間內保持開啟。 如果是全域和傳統型應用程式負載平衡器，GFE 會強制設定後端服務逾時時間上限為 86,400 秒 (1 天)。
用戶端系統必須實作重試邏輯，而不是依賴長時間開啟的 TCP 連線。
如要設定後端服務逾時，請使用下列其中一種方法：
控制台
修改負載平衡器後端服務的「逾時」欄位。
gcloud
使用
gcloud compute backend-services update 指令修改後端服務資源的 --timeout 參數。
API
如果是全域外部應用程式負載平衡器或傳統版應用程式負載平衡器，請修改全域backendServices資源的 timeoutSec 參數。
如果是區域性外部應用程式負載平衡器，請修改 timeoutSec 參數，以用於
regionBackendServices 資源。
| 負載平衡器模式 | 預設值 | Websocket 的逾時說明 |
|---|---|---|
| 全域外部應用程式負載平衡器 | 後端服務逾時：30 秒 | 作用中的 Websocket 連線不會使用負載平衡器設定的後端服務逾時。連線會在 24 小時 (86,400 秒) 後自動關閉。這個 24 小時的限制是固定的，如果後端服務逾時時間超過 24 小時，系統會覆寫該時間。 後端服務逾時後，閒置的 WebSocket 連線就會關閉。 我們不建議將後端服務逾時值設為超過 24 小時 (86,400 秒)，因為 Google Cloud 系統會定期重新啟動 GFE，進行軟體更新和其他例行維護。後端服務逾時值不會延遲維護活動。後端服務逾時值越長，就越有可能因維護而終止 TCP 連線。 Google Cloud |
| 傳統版應用程式負載平衡器 | 後端服務逾時：30 秒 | 無論是閒置或處於活動狀態，Websocket 連線都會在後端服務逾時後自動關閉。 我們不建議將後端服務逾時值設為超過 24 小時 (86,400 秒)，因為 Google Cloud 系統會定期重新啟動 GFE，進行軟體更新和其他例行維護。後端服務逾時值不會延遲維護活動。後端服務逾時值越長，就越有可能因維護而終止 TCP 連線。 Google Cloud |
| 區域性外部應用程式負載平衡器 | 後端服務逾時：30 秒 | 作用中的 WebSocket 連線不會使用負載平衡器的後端服務逾時。 後端服務逾時後，閒置的 WebSocket 連線就會關閉。 Google Cloud 定期重新啟動或變更服務 Envoy 軟體工作數量。後端服務逾時值越長，Envoy 任務就越有可能重新啟動或終止 TCP 連線。 |
區域外部應用程式負載平衡器會使用網址對應的已設定 routeActions.timeout 參數，並忽略後端服務逾時。如果未設定 routeActions.timeout，系統會使用後端服務逾時值。如果提供 routeActions.timeout，系統會忽略後端服務逾時，並改用 routeActions.timeout 的值做為要求和回應逾時。
用戶端 HTTP 保持運作逾時
用戶端 HTTP 保持運作逾時代表 TCP 連線在 (下游) 用戶端與下列其中一種 Proxy 之間閒置的時間長度上限：
- 全域外部應用程式負載平衡器或傳統版應用程式負載平衡器：第一層 Google Front End
- 區域性外部應用程式負載平衡器：Envoy Proxy
用戶端 HTTP 保持運作逾時代表基礎 TCP 連線的 TCP 閒置逾時。用戶端 HTTP 保持運作逾時不適用於 WebSocket。
用戶端 HTTP 保持運作逾時的預設值為 610 秒。對於全域和區域外部應用程式負載平衡器，您可以將用戶端 HTTP Keep-Alive 超時時間設為 5 到 1200 秒之間的值。
如要設定用戶端 HTTP 保持連線逾時，請使用下列其中一種方法：
控制台
修改負載平衡器前端設定的「HTTP keepalive timeout」(HTTP 保持連線逾時) 欄位。
gcloud
如果是全域外部應用程式負載平衡器，請使用 gcloud compute target-http-proxies update 指令或 gcloud compute target-https-proxies update 指令，修改目標 HTTP Proxy 或目標 HTTPS Proxy 資源的 --http-keep-alive-timeout-sec 參數。
如果是區域型外部應用程式負載平衡器，您無法直接更新區域型目標 HTTP(S) Proxy 的 Keepalive 超時參數。如要更新區域目標 Proxy 的存活逾時參數，請按照下列步驟操作：
- 使用所需的逾時設定建立新的目標 Proxy。
- 將目前目標 Proxy 的所有其他設定鏡像到新的 Proxy。 如果是目標 HTTPS Proxy，這包括將任何 SSL 憑證或憑證對應連結至新的目標 Proxy。
- 更新轉送規則，使其指向新的目標 Proxy。
- 刪除先前的目標 Proxy。
API
如果是全域外部應用程式負載平衡器，請修改
targetHttpProxies 資源或
targetHttpsProxies 資源的 httpKeepAliveTimeoutSec 參數。
如果是區域型外部應用程式負載平衡器，您無法直接更新區域型目標 HTTP(S) Proxy 的 Keepalive 超時參數。如要更新區域目標 Proxy 的存活逾時參數，請按照下列步驟操作：
- 使用所需的逾時設定建立新的目標 Proxy。
- 將目前目標 Proxy 的所有其他設定鏡像到新的 Proxy。 如果是目標 HTTPS Proxy，這包括將任何 SSL 憑證或憑證對應連結至新的目標 Proxy。
- 更新轉送規則，使其指向新的目標 Proxy。
- 刪除先前的目標 Proxy。
負載平衡器的用戶端 HTTP 保持連線逾時必須大於下游用戶端或 Proxy 使用的 HTTP 保持連線 (TCP 閒置) 逾時。如果下游用戶端的 HTTP 保持連線 (TCP 閒置) 逾時時間大於負載平衡器的用戶端 HTTP 保持連線逾時時間，就可能發生競爭條件。從下游用戶端的角度來看，已建立的 TCP 連線閒置時間可長於負載平衡器允許的時間。也就是說，在負載平衡器認為 TCP 連線已關閉後，下游用戶端仍可傳送封包。發生這種情況時，負載平衡器會以 TCP 重設 (RST) 封包回應。
用戶端 HTTP 保持運作逾時到期時，GFE 或 Envoy Proxy 會將 TCP FIN 傳送至用戶端，以正常關閉連線。
後端 HTTP 保持運作逾時
外部應用程式負載平衡器是 Proxy，至少會使用兩個 TCP 連線：
- 如果是全域外部應用程式負載平衡器或傳統版應用程式負載平衡器，(下游) 用戶端與第一層 GFE 之間會建立第一個 TCP 連線。第一層 GFE 會連線至第二層 GFE，然後第二層 GFE 會開啟第二個 TCP 連線至後端。
- 如果是區域性外部應用程式負載平衡器，(下游) 用戶端與 Envoy Proxy 之間會建立第一個 TCP 連線。接著，Envoy Proxy 會開啟第二個 TCP 連線至後端。
負載平衡器的次要 TCP 連線可能不會在每個要求後關閉，而是保持開啟狀態，以處理多個 HTTP 要求和回應。後端 HTTP 保持運作逾時會定義負載平衡器與後端之間的 TCP 閒置逾時。後端 HTTP 保持運作逾時不適用於 WebSocket。
後端保持連線逾時時間固定為 10 分鐘 (600 秒)，無法變更。這有助於確保負載平衡器至少維持閒置連線 10 分鐘。這段時間過後，負載平衡器隨時可將終止封包傳送至後端。
負載平衡器的後端連線存留逾時必須小於後端執行的軟體所用的連線存留逾時。這樣可避免競爭情況，因為後端的作業系統可能會透過 TCP 重設 (RST) 關閉 TCP 連線。由於負載平衡器的後端保持運作逾時無法設定，您必須設定後端軟體，使其 HTTP 保持運作 (TCP 閒置) 逾時值大於 600 秒。
後端 HTTP 保持運作逾時到期時，GFE 或 Envoy Proxy 會將 TCP FIN 傳送至後端 VM，以正常關閉連線。
下表列出修改常見網路伺服器軟體的「保持運作」逾時值所需的變更。
| 網路伺服器軟體 | 參數 | 預設設定 | 建議設定 |
|---|---|---|---|
| Apache | KeepAliveTimeout | KeepAliveTimeout 5 |
KeepAliveTimeout 620 |
| nginx | keepalive_timeout | keepalive_timeout 75s; |
keepalive_timeout 620s; |
QUIC 工作階段閒置逾時
QUIC 工作階段閒置逾時是指用戶端與全域外部應用程式負載平衡器或傳統版應用程式負載平衡器的 GFE 之間，QUIC 工作階段可閒置的最長時間。
QUIC 工作階段閒置逾時值定義為用戶端閒置逾時或 GFE 閒置逾時 (300 秒) 的最小值。 GFE 閒置逾時時間固定為 300 秒。您可以設定用戶端閒置逾時。
重試
重試邏輯的支援情形取決於外部應用程式負載平衡器的模式。
| 負載平衡器模式 | 重試邏輯 |
|---|---|
| 全域外部應用程式負載平衡器 |
您可以在網址對應中，使用重試政策設定這項功能。使用重試政策設定的重試次數上限 ( 如要停用重試功能，請將 如果沒有重試政策，系統會重試一次沒有 HTTP 內容的失敗要求 (例如 不會重試 HTTP 重試的要求只會針對最終回應產生一個記錄項目。 |
| 傳統版應用程式負載平衡器 |
連線重試的重試政策無法變更。 不會重試 HTTP 只要有 80% 以上的後端運作正常，系統一律會重試 HTTP 如果第一個要求在收到後端執行個體的回應標頭前失敗，負載平衡器會重試失敗的 重試的要求只會針對最終回應產生一個記錄項目。詳情請參閱「外部應用程式負載平衡器記錄與監控」。 如果要求失敗，負載平衡器會合成 HTTP |
| 區域性外部應用程式負載平衡器 |
您可以在網址對應中，使用重試政策進行設定。預設重試次數 ( 如果沒有重試政策，系統會重試一次沒有 HTTP 內容 (例如 不會重試 HTTP 重試的要求只會針對最終回應產生一個記錄項目。 |
GKE Ingress 支援 WebSocket 通訊協定。
不合法的要求和回應處理
負載平衡器會許多原因，而阻止用戶端要求到達後端，也會阻止後端回應到達用戶端。有些原因完全是為了達成 HTTP/1.1 法規遵循，有些則是為了避免資料意外往返於後端。所有檢查都無法停用。
負載平衡器會封鎖下列要求，以確保符合 HTTP/1.1 法規遵循要求：
- 無法解析要求的第一行。
- 標頭缺少半形冒號 (
:) 分隔符號。 - 標頭或第一行含有無效字元。
- 內容長度不是有效數字，或有多個內容長度標頭。
- 有多個傳輸編碼鍵，或是有無法識別的傳輸編碼值。
- 有未分為區塊的主體，且未指定內容長度。
- 主體區塊無法解析，這是部分資料會到達後端的唯一情況。負載平衡器收到無法解析的區塊時，會關閉連至用戶端和後端的連線。
處理要求
如果符合以下任一條件，則負載平衡器將封鎖該要求：
- 要求標頭和要求網址的總大小超過外部應用程式負載平衡器的要求標頭大小上限。
- 要求方法不允許主體，但要求含有主體。
- 要求中包含
Upgrade標頭，但未使用Upgrade標頭來啟用 WebSocket 連線。 - HTTP 版本未知。
處理回應
如果符合以下任一條件，負載平衡器就會封鎖後端的回應：
- 回應標頭總大小超過外部應用程式負載平衡器的回應標頭大小上限。
- HTTP 版本未知。
處理要求和回應時，負載平衡器可能會移除或覆寫 HTTP/1.1 中的逐一躍點標頭，然後再轉送至預期目的地。
流量分配
將後端執行個體群組或 NEG 新增至後端服務時，請指定平衡模式，定義測量後端負載的方法和目標容量。外部應用程式負載平衡器支援兩種負載平衡模式：
RATE，例如，針對例項群組或 NEG，這是每秒要求 (查詢) 數上限 (RPS、QPS)。如果所有後端都達到或超過容量上限，可能會超過目標每秒要求數/每秒查詢次數上限。UTILIZATION是執行個體群組中 VM 的後端使用率。
流量在後端之間的分配方式取決於負載平衡器的模式。
全域外部應用程式負載平衡器
Google Front End (GFE) 會先估算哪些後端執行個體有容量可接收要求，再將要求傳送至這些執行個體。這項容量估算作業是主動進行，而不是在收到要求時進行。GFE 會定期接收可用容量的相關資訊，並據此分配傳入的要求。
「容量」的意義取決於平衡模式。如果是 RATE 模式，則相對簡單：GFE 會準確判斷每秒可指派的要求數量。UTILIZATION 型負載平衡較為複雜：負載平衡器會檢查執行個體的目前使用率，然後估算每個執行個體可處理的查詢負載。隨著執行個體用量和流量模式變化，這項預估值也會隨之變動。
這兩項因素 (容量估算和主動指派) 都會影響執行個體之間的分配。因此，Cloud Load Balancing 的行為與簡單的循環制負載平衡器不同，後者會在兩個執行個體之間平均分配要求。而是嘗試為每個要求最佳化後端執行個體選取作業。 Google Cloud
全域外部應用程式負載平衡器採用兩層式負載平衡。平衡模式會決定要傳送至各後端 (執行個體群組或 NEG) 的流量權重或比例。接著，負載平衡政策 (LocalityLbPolicy) 會決定如何將流量分配給群組中的執行個體或端點。詳情請參閱負載平衡區域政策 (後端服務 API 說明文件)。
傳統版應用程式負載平衡器會使用平衡模式，選取最合適的後端 (執行個體群組或 NEG)。然後，流量會以循環方式分配給後端中的執行個體或端點。
要求的分配方式
以 GFE 為基礎的外部應用程式負載平衡器會使用下列程序分配傳入的請求：
- 從用戶端到第一層 GFE。邊緣路由器會在 Google 網路的邊界通告轉送規則的外部 IP 位址。每則廣告都會列出第 3 層和第 4 層負載平衡系統 (Maglev) 的下一個躍點。Maglev 系統會將流量導向第一層的 Google Front End (GFE)。
- 使用進階級網路時，Google 會從全球所有存在點宣傳負載平衡器的 IP 位址。每個負載平衡器 IP 位址都是全域 Anycast。
- 使用標準級時，Google 會從與轉送規則區域相關聯的 PoP 宣傳負載平衡器的 IP 位址。負載平衡器使用地區性外部 IP 位址。使用標準級轉送規則時，您只能使用與負載平衡器轉送規則位於相同地區的執行個體群組和區域 NEG 後端。
- 從第一層 GFE 到第二層 GFE。第一層 GFE 會視需要終止 TLS，然後根據下列程序將流量轉送至第二層 GFE：
- 第一層 GFE 會剖析網址對應，並選取後端服務或後端值區。
- 對於具有網際網路 NEG 的後端服務，第一層 GFE 會選取與第一層 GFE 共置的第二層外部轉送閘道。轉送閘道會將要求傳送至網際網路 NEG 端點。 網際網路 NEG 的要求分配程序到此結束。
- 對於具有無伺服器 NEG 和Private Service Connect (PSC) NEG 的後端服務，以及單一區域後端值區，第一層 GFE 會在與 NEG 或值區區域相符的區域中，選取第二層 GFE。如果是多區域 Cloud Storage bucket，第一層 GFE 會選取 bucket 所在區域的第二層 GFE，或是盡可能靠近多區域 bucket 的區域 (由網路往返時間定義)。
- 對於具有執行個體群組、具有
GCE_VM_IP_PORT端點的區域 NEG 和混合 NEG 的後端服務，Google 的容量管理系統會將每個後端使用的容量和設定的容量通知第一層 GFE。後端的設定容量是由平衡模式、平衡模式的目標容量和容量配置器所定義。- 標準層級：第一層 GFE 會在含有後端的區域中，選取第二層 GFE。
- 進階層級：第一層 GFE 會從一組適用區域中選取第二層 GFE。適用區域是指已設定後端的所有區域，但不包括後端容量為零的區域。第一層 GFE 會在適用區域中選取最接近的第二層 GFE (由網路往返時間定義)。如果後端是在兩個以上的區域中設定，當首選區域已滿時，第一層 GFE 可以將要求溢出至其他適用區域。如果首選區域的所有後端都已達到容量上限，流量可能會溢出至其他區域。
- 第二層 GFE 會選取後端。第二層 GFE 位於區域的可用區中。後端選取程序如下：
- 對於具有無伺服器 NEG、Private Service Connect NEG 和後端儲存空間的後端服務，第二層 GFE 會將要求轉送至 Google 的生產系統。這些後端的要求分配程序就此結束。
對於含有執行個體群組的後端服務、具有
GCE_VM_IP_PORT端點的區域 NEG，以及混合式 NEG，Google 的健康狀態檢查探測系統會將後端執行個體或端點的健康狀態檢查結果，通知第二層 GFE。僅限進階層級：如果第二層 GFE 在其區域中沒有健康狀態良好的後端執行個體或端點，可能會將要求傳送至其他適用區域中已設定後端的第二層 GFE。不同地區的第二層 GFE 之間的溢出不會耗盡所有可能的地區對地區組合。如要將流量從特定區域的後端導向其他位置，請將後端的容量縮放比例設為零，而非將後端設為無法通過健康狀態檢查，這樣第一層 GFE 在上一個步驟中就會排除該區域。
第二層 GFE 接著會將要求導向區域內的後端執行個體或端點，如後續步驟所述。
第二層 GFE 會選取區域。根據預設，第二層 GFE 會使用
WATERFALL_BY_REGION演算法，其中每個第二層 GFE 偏好選取與第二層 GFE 所在區域相同的區域中的後端執行個體或端點。由於WATERFALL_BY_REGION會盡量減少區域間的流量，因此在要求率較低時，每個第二層 GFE 可能只會將要求傳送至與第二層 GFE 位於相同區域的後端。只有全域外部應用程式負載平衡器可以設定第二層 GFE，使用下列替代演算法之一 (透過
serviceLbPolicy)：SPRAY_TO_REGION：第二層 GFE 不會優先選取與第二層 GFE 位於相同區域的後端執行個體或端點。第二層 GFE 會嘗試將流量分配至該區域所有可用區的所有後端執行個體或端點。這可能會導致負載分配更平均，但代價是可用區之間的流量增加。WATERFALL_BY_ZONE：第二層 GFE 會盡量選取與第二層 GFE 位於同一區域的後端執行個體或端點。只有在目前區域的所有後端都達到設定容量後，第二層 GFE 才會將要求導向不同區域的後端。
- 第二層 GFE 會選取區域內的執行個體或端點。根據預設，第二層 GFE 會以循環方式將要求分配給後端。只有全域外部應用程式負載平衡器可以透過負載平衡區域政策 (
localityLbPolicy) 變更這項設定。負載平衡區域政策只會套用至上一個步驟中選取的區域內的後端。
區域性外部應用程式負載平衡器
如果是區域性外部應用程式負載平衡器，流量分配會依據負載平衡模式和負載平衡地區政策。
平衡模式會決定要傳送至各群組 (執行個體群組或 NEG) 的流量權重和比例。負載平衡地區政策 (LocalityLbPolicy) 會決定如何對群組內的後端進行負載平衡。
後端服務收到流量時，會先根據後端的平衡模式，將流量導向後端 (執行個體群組或 NEG)。選取後端後，系統會根據負載平衡區域政策，在該後端群組的執行個體或端點之間分配流量。
如要瞭解詳情，請參考下列資源：
工作階段相依性
在應用程式負載平衡器的後端服務上設定工作階段親和性後，只要健康狀態良好的後端執行個體或端點數量維持不變，且先前選取的後端執行個體或端點未達容量上限，系統就會盡量將特定用戶端的要求傳送至同一個後端。平衡模式的目標容量會決定後端何時達到容量上限。
下表列出不同應用程式負載平衡器支援的工作階段相依性選項。在下一個章節「工作階段相依性類型」中，我們將進一步詳細說明各個工作階段相依性類型。
| 產品 | 工作階段相依性選項 |
|---|---|
另請注意：
|
|
| 傳統版應用程式負載平衡器 |
|
設定工作階段親和性時，請注意下列事項：
請勿將工作階段親和性用於驗證或安全用途。 只要服務和健康狀態良好的後端數量有變，工作階段相依性 (以有狀態 Cookie 為基礎的工作階段相依性除外) 就會中斷。詳情請參閱「失去工作階段親和性」。
--session-affinity和--subsetting-policy旗標的預設值都是NONE，且一次只能將其中一個旗標設為不同值。
工作階段相依性類型
外部應用程式負載平衡器的工作階段相依性可分為下列其中一類：- 以雜湊為準的工作階段相依性 (
NONE、CLIENT_IP) - HTTP 標頭型工作階段相依性 (
HEADER_FIELD) - Cookie 型工作階段相依性 (
GENERATED_COOKIE、HTTP_COOKIE、STRONG_COOKIE_AFFINITY)
雜湊型工作階段相依性
如果是以雜湊為準的工作階段相依性，負載平衡器會使用一致性雜湊演算法選取符合資格的後端。工作階段相依性設定會決定要使用 IP 標頭中的哪些欄位來計算雜湊。
以雜湊為準的工作階段相依性可分為下列類型：
無
工作階段相依性設定為 NONE「不代表沒有工作階段相依性」。這表示未明確設定任何工作階段相依性選項。
一律會執行雜湊作業來選取後端。如果工作階段相依性設定為 NONE，負載平衡器會使用 5 元組雜湊選取後端。5 元組雜湊碼包含來源 IP 位址、來源通訊埠、通訊協定、目的地 IP 位址和目的地通訊埠。
預設值為工作階段親和性 NONE。
用戶端 IP 相依性
用戶端 IP 工作階段相依性 (CLIENT_IP) 是由封包的來源和目的地 IP 位址建立的 2 元組雜湊。只要後端有容量且保持良好健康狀態，用戶端 IP 相依性就會將來自相同用戶端 IP 位址的所有要求轉送至同一個後端。
使用用戶端 IP 相依性時，請注意下列事項：
- 只有在封包直接傳送至負載平衡器時，封包目的地 IP 位址才會與負載平衡器轉送規則的 IP 位址相同。
- 如果封包在傳遞至 Google Cloud 負載平衡器前，會先經過中繼 NAT 或 Proxy 系統處理，則封包來源 IP 位址可能與原始用戶端相關聯的 IP 位址不符。如果許多用戶端共用相同的有效來源 IP 位址，部分後端 VM 收到的連線或要求可能會比其他 VM 多。
HTTP 標頭型工作階段相依性
使用標頭欄位相依性 (HEADER_FIELD) 時，系統會根據後端服務consistentHash.httpHeaderName 欄位中的 HTTP 標頭值，將要求轉送至後端。如要將要求分配給所有可用的後端，每個用戶端都必須使用不同的 HTTP 標頭值。
符合下列條件時，系統會支援標頭欄位關聯性：
- 負載平衡地區政策為
RING_HASH或MAGLEV。 - 後端服務的
consistentHash會指定 HTTP 標頭的名稱 (httpHeaderName)。
以 Cookie 為基礎的工作階段相依性
Cookie 型工作階段相依性可分為下列類型：
產生的 Cookie 相依性
使用產生的 Cookie 型相依性 (GENERATED_COOKIE) 時，負載平衡器會在回應初始 HTTP 要求時，於 Set-Cookie 標頭中加入 HTTP Cookie。
產生的 Cookie 名稱會因負載平衡器類型而異。
| 產品 | Cookie 名稱 |
|---|---|
| 全域外部應用程式負載平衡器 | GCLB |
| 傳統版應用程式負載平衡器 | GCLB |
| 區域性外部應用程式負載平衡器 | GCILB |
產生的 Cookie 路徑屬性一律為正斜線 (/)，因此只要其他後端服務也使用產生的 Cookie 相依性，這項屬性就會套用至相同網址對應中的所有後端服務。
您可以使用 affinityCookieTtlSec 後端服務參數，將 Cookie 的存留時間 (TTL) 值設定在 0 和 1,209,600 秒之間 (含這兩個值)。如未指定 affinityCookieTtlSec，則預設 TTL 值為 0。
當用戶端在 HTTP 要求的 Cookie 要求標頭中加入產生的工作階段相依性 Cookie 時，只要工作階段相依性 Cookie 保持有效，負載平衡器就會將這些要求導向同一個後端執行個體或端點。方法是將 Cookie 值對應至參照特定後端執行個體或端點的索引，並確保符合產生的 Cookie 工作階段相依性需求。
如要使用產生的 Cookie 相依性，請設定下列平衡模式和 localityLbPolicy 設定：
- 如果是後端執行個體群組，請使用
RATE平衡模式。 - 後端服務的
localityLbPolicy請使用RING_HASH或MAGLEV。如果您未明確設定localityLbPolicy，負載平衡器會使用MAGLEV做為隱含預設值。
詳情請參閱失去工作階段相依性。
HTTP Cookie 相依性
使用 HTTP Cookie 型相依性 (HTTP_COOKIE) 時，負載平衡器會在回應初始 HTTP 要求時，於 Set-Cookie 標頭中加入 HTTP Cookie。您可以指定 Cookie 的名稱、路徑和存留時間 (TTL)。
所有應用程式負載平衡器都支援 HTTP Cookie 型相依性。
您可以使用下列後端服務參數和有效值，以秒數、秒數的分數 (以奈秒為單位)，或秒數加上秒數的分數 (以奈秒為單位)，設定 Cookie 的 TTL 值：
consistentHash.httpCookie.ttl.seconds可設為介於0和315576000000之間的值 (含這兩個值)。consistentHash.httpCookie.ttl.nanos可設為介於0和999999999之間的值 (含這兩個值)。由於單位是奈秒，因此999999999代表.999999999秒。
如果未指定 consistentHash.httpCookie.ttl.seconds 和 consistentHash.httpCookie.ttl.nanos，系統會改用 affinityCookieTtlSec 後端服務參數的值。如未指定 affinityCookieTtlSec，則預設 TTL 值為 0。
當用戶端在 HTTP 要求的 Cookie 要求標頭中加入 HTTP 工作階段相依性 Cookie 時，只要工作階段相依性 Cookie 保持有效，負載平衡器就會將這些要求導向同一個後端執行個體或端點。方法是將 Cookie 值對應至參照特定後端執行個體或端點的索引，並確保符合產生的 Cookie 工作階段相依性需求。
如要使用 HTTP Cookie 相依性，請設定下列平衡模式和 localityLbPolicy 設定：
- 如果是後端執行個體群組，請使用
RATE平衡模式。 - 後端服務的
localityLbPolicy請使用RING_HASH或MAGLEV。如果您未明確設定localityLbPolicy，負載平衡器會使用MAGLEV做為隱含預設值。
詳情請參閱失去工作階段相依性。
有狀態的 Cookie 型工作階段相依性
使用具狀態的 Cookie 型相依性 (STRONG_COOKIE_AFFINITY) 時，負載平衡器會在回應初始 HTTP 要求時，於 Set-Cookie 標頭中加入 HTTP Cookie。您可以指定 Cookie 的名稱、路徑和存留時間 (TTL)。
除了傳統版應用程式負載平衡器，所有應用程式負載平衡器都支援以 Cookie 為基礎的具狀態親和性。
您可以設定 Cookie 的 TTL 值，單位為秒、秒數的分數 (以奈秒為單位)，或秒數加上秒數的分數 (以奈秒為單位)。strongSessionAffinityCookie.ttl 代表的時長不得設為超過兩週 (1,209,600 秒) 的值。
Cookie 的值會將所選執行個體或端點編碼至值本身，藉此識別所選的後端執行個體或端點。只要 Cookie 有效，如果用戶端在後續 HTTP 要求的 Cookie 要求標頭中加入工作階段相依性 Cookie，負載平衡器就會將這些要求導向選取的後端執行個體或端點。
與其他工作階段相依性方法不同：
有狀態的 Cookie 型親和性對負載平衡模式或負載平衡地區政策 (
localityLbPolicy) 沒有特定要求。自動調度資源功能在代管執行個體群組中新增執行個體時，不會影響有狀態的 Cookie 型親和性。
自動調度資源從代管執行個體群組移除執行個體時，不會影響有狀態的 Cookie 關聯性，除非移除的是所選執行個體。
自動修復功能從代管執行個體群組中移除執行個體時，有狀態的 Cookie 繫結不會受到影響，除非移除的是所選執行個體。
詳情請參閱失去工作階段相依性。
Cookie 型相依性的零存留時間意義
所有 Cookie 型工作階段相依性 (例如產生的 Cookie 相依性、HTTP Cookie 相依性和有狀態的 Cookie 型相依性) 都有 TTL 屬性。
如果存留時間為零秒，表示負載平衡器不會將 Expires 屬性指派給 Cookie。在這種情況下，用戶端會將 Cookie 視為工作階段 Cookie。工作階段的定義會因用戶端而異：
部分用戶端 (例如網路瀏覽器) 會在整個瀏覽工作階段保留 Cookie。這表示在應用程式關閉前，Cookie 會在多個要求中持續存在。
其他用戶端會將工作階段視為單一 HTTP 要求，並在之後立即捨棄 Cookie。
失去工作階段相依性
所有工作階段相依性選項都必須符合下列條件：
- 選取的後端執行個體或端點必須維持後端設定。發生下列任一事件時，工作階段親和性可能會中斷：
- 從執行個體群組中移除所選執行個體。
- 代管執行個體群組的自動調度資源或自動修復功能，會從代管執行個體群組中移除所選執行個體。
- 從 NEG 移除所選端點。
- 從後端服務中移除包含所選執行個體或端點的執行個體群組或 NEG。
- 所選後端執行個體或端點必須保持正常運作。如果所選執行個體或端點未通過健康狀態檢查，工作階段相依性可能會中斷。
- 如果是全域外部應用程式負載平衡器和傳統應用程式負載平衡器，如果路由路徑變更後，後續要求或連線使用不同的第一層 Google Front End (GFE)，工作階段相依性可能會中斷。如果網際網路上用戶端到 Google 的路徑在要求或連線之間有所變更，系統可能會選取不同的第一層 GFE。
包含所選執行個體或端點的執行個體群組或 NEG，不得達到目標容量上限。(如果是地區代管執行個體群組，包含所選執行個體的執行個體群組區域元件不得已滿)。如果執行個體群組或 NEG 已滿，但其他執行個體群組或 NEG 未滿，工作階段相依性可能會中斷。使用
UTILIZATION平衡模式時，飽和度可能會以無法預測的方式變化，因此您應使用RATE或CONNECTION平衡模式，盡量避免工作階段相依性中斷。設定的後端執行個體或端點總數必須維持不變。發生下列任一事件時，設定的後端執行個體或端點數量會變更，工作階段親和性可能會中斷：
新增執行個體或端點：
- 將執行個體新增至後端服務上現有的執行個體群組。
- 代管執行個體群組自動調度功能會將執行個體新增至後端服務的代管執行個體群組。
- 將端點新增至後端服務中的現有 NEG。
- 將非空白的執行個體群組或 NEG 新增至後端服務。
移除任何執行個體或端點，不只是所選執行個體或端點：
- 從執行個體群組後端移除任何執行個體。
- 代管執行個體群組的自動調度資源或自動修復功能，會從代管執行個體群組後端移除所有執行個體。
- 從 NEG 後端移除任何端點。
- 從後端服務中移除任何現有的非空白後端執行個體群組或 NEG。
健康狀態良好的後端執行個體或端點總數必須維持不變。發生下列任一事件時，健康狀態良好的後端執行個體或端點數量會變更，工作階段相依性可能會中斷：
- 任何執行個體或端點通過健康狀態檢查，從健康狀態不良轉為健康狀態良好。
- 任何執行個體或端點未通過健康狀態檢查，從健康狀態良好轉為健康狀態不良或逾時。