本文將深入探討外部應用程式負載平衡器如何處理連線、路由流量及維持工作階段親和性。
連結的運作方式
Trusted 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.1 或 HTTP/2 通訊協定與負載平衡器進行通訊。
- 使用 HTTPS 時，現代的用戶端預設為使用 HTTP/2。這是在用戶端上控制的，而不是在 HTTPS 負載平衡器上控制的。
- 您無法透過變更負載平衡器的設定來停用 HTTP/2。不過，您可以將部分用戶端設定為使用 HTTP 1.1 而非 HTTP/2。舉例來說，搭配
curl使用--http1.1參數。 - 外部應用程式負載平衡器支援
HTTP/1.1 100 Continue回應。
如要查看外部應用程式負載平衡器在各模式下轉送規則支援的完整通訊協定清單，請參閱負載平衡器功能。
用戶端封包的來源 IP 位址
後端看到的封包來源 IP 位址「不是」負載平衡器的外部 IP 位址。Trusted Cloud 換句話說，會有兩個 TCP 連線。
連線 1：從原始用戶端到負載平衡器 (僅限 Proxy 的子網路)：
- 來源 IP 位址：原始用戶端 (或外部 IP 位址，如果用戶端位於 NAT 閘道或轉送 Proxy 後方)。
- 目的地 IP 位址：負載平衡器的 IP 位址。
連線 2：從負載平衡器 (僅限 Proxy 子網路) 到後端 VM 或端點：
來源 IP 位址：僅限 Proxy 的子網路中的 IP 位址，與部署在相同地區和網路的負載平衡器共用。
目的地 IP 位址：虛擬私有雲網路中後端 VM 或容器的內部 IP 位址。
特殊轉送路徑
Trusted Cloud 會使用虛擬私有雲網路中未定義的特殊路徑，為下列類型的流量傳送封包：
- 健康狀態檢查 (分散式 Envoy 健康狀態檢查除外)。詳情請參閱健康狀態檢查的路徑。
Trusted Cloud 會使用僅限 Proxy 的子網路的子網路路徑，為下列類型的流量傳送封包：
- 使用分散式 Envoy 健康狀態檢查時。
如果是區域性外部應用程式負載平衡器， Trusted Cloud 會使用開放原始碼 Envoy Proxy 終止用戶端對負載平衡器的要求。負載平衡器會終止 TCP 工作階段，並從區域的僅限 Proxy 子網路開啟新的 TCP 工作階段，連至後端。虛擬私有雲網路中定義的路徑可協助 Envoy Proxy 與後端通訊，以及後端與 Envoy Proxy 通訊。
傳輸層安全標準 (TLS) 終止
下表摘要說明外部應用程式負載平衡器如何處理 TLS 終止作業。
| 負載平衡器模式 | 傳輸層安全標準 (TLS) 終止 |
|---|---|
| 區域性外部應用程式負載平衡器 | TLS 會在使用者所選區域的僅限 Proxy 子網路中，於 Envoy Proxy 上終止。如果需要對 TLS 終止的地區進行地理位置控制，請使用這個負載平衡器模式。 |
逾時和重試
後端服務逾時
可設定的後端服務逾時代表負載平衡器等待後端處理 HTTP 要求並傳回相應 HTTP 回應的時間上限。除了無伺服器 NEG 以外，後端服務逾時的預設值為 30 秒。
舉例來說，如果您想下載 500 MB 的檔案，而後端服務逾時值為 90 秒，則負載平衡器會預期後端在 90 秒內傳送整個 500 MB 的檔案。後端服務逾時設定可能不足，導致後端無法傳送完整的 HTTP 回應。在這種情況下，如果負載平衡器至少已從後端收到 HTTP 回應標頭，負載平衡器就會傳回完整的回應標頭，以及在後端服務逾時前盡可能取得的回應內文。
建議您將後端服務逾時時間設為最長，也就是後端處理 HTTP 回應所需的時間。如果後端執行的軟體需要更多時間處理 HTTP 要求並傳回完整的回應，建議您增加後端服務逾時時間。
後端服務逾時接受介於 1 和 2,147,483,647 秒之間的值，但較大的值並非實用的設定選項。此外，Trusted Cloud 也無法保證基礎 TCP 連線在後端服務逾時值的整個期間內保持開啟狀態。用戶端系統必須實作重試邏輯，而不是依賴長時間開啟的 TCP 連線。
如要設定後端服務逾時，請使用下列其中一種方法：
控制台
修改負載平衡器後端服務的「逾時」欄位。
gcloud
使用
gcloud compute backend-services update 指令修改後端服務資源的 --timeout 參數。
用戶端 HTTP 保持運作逾時
負載平衡器的用戶端 HTTP 保持連線逾時必須大於下游用戶端或 Proxy 使用的 HTTP 保持連線 (TCP 閒置) 逾時。如果下游用戶端的 HTTP 保持連線 (TCP 閒置) 逾時時間大於負載平衡器的用戶端 HTTP 保持連線逾時時間，就可能發生競爭條件。從下游用戶端的角度來看，已建立的 TCP 連線閒置時間可長於負載平衡器允許的時間。也就是說，在負載平衡器認為 TCP 連線已關閉後，下游用戶端仍可傳送封包。發生這種情況時，負載平衡器會以 TCP 重設 (RST) 封包回應。
用戶端 HTTP 保持運作逾時到期時，GFE 或 Envoy Proxy 會將 TCP FIN 傳送至用戶端，以正常關閉連線。
後端 HTTP 保持運作逾時
負載平衡器的次要 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; |
GKE Ingress 支援 WebSocket 通訊協定。
不合法的要求和回應處理
負載平衡器會許多原因，而阻止用戶端要求到達後端，也會阻止後端回應到達用戶端。有些原因完全是為了達成 HTTP/1.1 法規遵循，有些則是為了避免資料意外往返於後端。所有檢查都無法停用。
負載平衡器會封鎖下列要求，以確保符合 HTTP/1.1 法規遵循要求：
- 無法解析要求的第一行。
- 標頭缺少半形冒號 (
:) 分隔符號。 - 標頭或第一行含有無效字元。
- 內容長度不是有效數字，或有多個內容長度標頭。
- 有多個傳輸編碼鍵，或是有無法識別的傳輸編碼值。
- 有未分為區塊的主體，且未指定內容長度。
- 主體區塊無法解析，這是部分資料會到達後端的唯一情況。負載平衡器收到無法解析的區塊時，會關閉連至用戶端和後端的連線。
處理要求
如果符合以下任一條件，則負載平衡器將封鎖該要求：
- 要求標頭和要求網址的總大小超過外部應用程式負載平衡器的要求標頭大小上限。
- 要求方法不允許主體，但要求含有主體。
- 要求中包含
Upgrade標頭，但未使用Upgrade標頭來啟用 WebSocket 連線。 - HTTP 版本未知。
處理回應
如果符合以下任一條件，負載平衡器就會封鎖後端的回應：
- 回應標頭總大小超過外部應用程式負載平衡器的回應標頭大小上限。
- HTTP 版本未知。
處理要求和回應時，負載平衡器可能會移除或覆寫 HTTP/1.1 中的逐段標頭，然後再轉送至預期目的地。
流量分配
將後端執行個體群組或 NEG 新增至後端服務時，請指定平衡模式，定義測量後端負載的方法和目標容量。外部應用程式負載平衡器支援兩種負載平衡模式：
RATE，例如例項群組或 NEG，是每秒要求 (查詢) 數上限 (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 位址相同。
- 如果封包在傳遞至 Trusted 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。
健康狀態良好的後端執行個體或端點總數必須維持不變。發生下列任一事件時，健康狀態良好的後端執行個體或端點數量會變更，工作階段相依性可能會中斷：
- 任何執行個體或端點通過健康狀態檢查，從健康狀態不良轉為健康狀態良好。
- 任何執行個體或端點未通過健康狀態檢查，從健康狀態良好轉為健康狀態不良或逾時。