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