本文將深入探討外部應用程式負載平衡器如何處理連線、轉送流量及維護工作階段相依性。
連結的運作方式
Google Cloud的外部應用程式負載平衡器 (全域和區域) 使用分散式 Proxy (GFE) 或 Envoy 代管子網路，簡化轉送作業。這類負載平衡器提供可設定的逾時、TLS 終止和內建安全性，可確保在全球或區域內，以符合法規且可擴充的方式推送應用程式。
區域性外部應用程式負載平衡器連線
區域性外部應用程式負載平衡器是以 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，從原始用戶端到負載平衡器 (僅限 Proxy 的子網路)：
- 來源 IP 位址：原始用戶端 (如果用戶端位於網路位址轉譯 (NAT) 閘道或轉送 Proxy 後方，則為外部 IP 位址)。
- 目的地 IP 位址：負載平衡器的 IP 位址。
連線 2，從負載平衡器 (僅限 Proxy 子網路) 到後端 VM 或端點：
來源 IP 位址：僅限 Proxy 子網路中的 IP 位址，由部署在與負載平衡器相同區域和網路中的所有 Envoy 型負載平衡器共用。
目的地 IP 位址：虛擬私有雲網路中後端 VM 或容器的內部 IP 位址。
特殊轉送路徑
Google Cloud 會使用未在虛擬私有雲網路中定義的特殊路由，轉送下列類型的流量封包：
- 健康狀態檢查，但分散式 Envoy 健康狀態檢查除外。詳情請參閱「健康狀態檢查路徑」。
Google Cloud 會使用僅限 Proxy 子網路的子網路路由，轉送下列類型的流量封包：
- 使用分散式 Envoy 健康狀態檢查時。
如果是區域性外部應用程式負載平衡器， Google Cloud 會使用開放原始碼 Envoy Proxy，終止用戶端傳送至負載平衡器的要求。負載平衡器會終止 TCP 工作階段，並從區域的僅限 Proxy 子網路開啟新的 TCP 工作階段，連至後端。在虛擬私有雲網路中定義的路由，可促進 Envoy Proxy 與後端之間的通訊。
傳輸層安全標準 (TLS) 終止
下表摘要說明外部應用程式負載平衡器如何處理 TLS 終止。
| 負載平衡器模式 | 傳輸層安全標準 (TLS) 終止 |
|---|---|
| 區域性外部應用程式負載平衡器 | 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 要求)。
|
|
|||
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 連線在整個後端服務逾時時間內都能保持開啟。
用戶端系統必須實作重試邏輯，而非依賴長時間開啟的 TCP 連線。
如要設定後端服務逾時，請使用下列其中一種方法：
控制台
修改負載平衡器後端服務的「Timeout」(逾時) 欄位。
gcloud
使用
gcloud compute backend-services update 指令修改後端服務資源的 --timeout 參數。
API
如果是區域性外部應用程式負載平衡器，請修改
regionBackendServices 資源的 timeoutSec 參數。
| 負載平衡器模式 | 預設值 | WebSocket 逾時說明 |
|---|---|---|
| 區域性外部應用程式負載平衡器 | 後端服務逾時：30 秒 | 使用中的 WebSocket 連線不會採用負載平衡器的後端服務逾時設定。 後端服務逾時後，閒置的 WebSocket 連線會關閉。 Google Cloud 會定期重新啟動或變更提供服務的 Envoy 軟體工作數量。後端服務逾時值越長，Envoy 工作就越有可能重新啟動或終止 TCP 連線。 |
區域性外部應用程式負載平衡器會使用網址對應中設定的 routeAction.timeout 參數，並忽略後端服務逾時。如未設定 routeAction.timeout，系統會使用後端服務逾時值。如果提供 routeAction.timeout，系統會忽略後端服務逾時，並改用 routeAction.timeout 的值做為要求和回應逾時。
用戶端 HTTP 保持運作逾時
「用戶端 HTTP 保持運作逾時」是指 TCP 連線在 (下游) 用戶端與下列其中一種 Proxy 之間，可閒置的時間長度上限：
- 區域性外部應用程式負載平衡器：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：
- 如果是區域性外部應用程式負載平衡器，(下游) 用戶端和 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; |
重試次數
是否支援重試邏輯，取決於外部應用程式負載平衡器的模式。
| 負載平衡器模式 | 重試邏輯 |
|---|---|
| 區域性外部應用程式負載平衡器 |
您可以在網址對應中使用重試政策進行設定。預設重試次數 ( 如果沒有重試政策，系統會重試一次沒有 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 的後端使用率。
流量在後端之間的分配方式取決於負載平衡器的模式。
區域性外部應用程式負載平衡器
如果是區域性外部應用程式負載平衡器，流量分配會依據負載平衡模式和負載平衡地區政策。
平衡模式會決定要傳送至各群組 (執行個體群組或 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。
健康狀態良好的後端執行個體或端點總數必須保持不變。發生下列至少一項事件時，健康狀態良好的後端執行個體或端點數量會變更，工作階段相依性可能會中斷：
- 任何執行個體或端點通過健康狀態檢查，從健康狀態不良轉為良好。
- 任何執行個體或端點未通過健康狀態檢查，從健康狀態良好轉為不良或逾時。