HTTP(S) 負載平衡概念

本文將介紹設定 HTTP 或 HTTPS 負載平衡時需瞭解的概念。

基礎知識

HTTP(S) 負載平衡器由數個元件組成。下圖顯示一個完整 HTTP(S) 負載平衡器的架構:

以內容為基礎的跨地區負載平衡圖 (按一下可放大)
以內容為基礎的跨地區負載平衡圖 (按一下可放大)

下列各節將說明各元件如何搭配運作,以組成各種負載平衡器。如需各個元件的詳細說明,請參閱下方的元件一節。

HTTP 負載平衡

一個完整 HTTP 負載平衡器的結構如下:

  1. 轉送規則將傳入要求導向至目標 HTTP Proxy
  2. 目標 HTTP Proxy 根據網址對應檢查每個要求,以決定適合要求的後端服務
  3. 後端服務根據連接之後端的負載能力、區域和執行個體健康狀態,將每個要求導向至適合的後端。系統會使用 HTTP 健康狀態檢查、HTTPS 健康狀態檢查或 HTTP/2 健康狀態檢查,驗證每個後端執行個體的健康狀態。如果將後端服務設定為使用 HTTPS 或 HTTP/2 健康狀態檢查,則要求會在前往後端執行個體的途中進行加密。
  4. 負載平衡器和執行個體之間的工作階段可以使用 HTTP、HTTPS 或 HTTP/2 通訊協定。如果您使用 HTTPS 或 HTTP/2,後端服務中的每個執行個體都必須具備 SSL 憑證。

HTTPS 負載平衡

HTTPS 負載平衡器的基本結構與 HTTP 負載平衡器的相同 (如前文所述),但這兩者在以下方面不同:

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

  • 用戶端可透過 HTTP 1.1 或 HTTP/2 通訊協定與負載平衡器進行通訊。
  • 使用 HTTPS 時,現代的用戶端預設為使用 HTTP/2。這是在用戶端上控制的,而不是在 HTTPS 負載平衡器上控制的。
  • 您無法透過變更負載平衡器本身的設定來停用 HTTP/2。不過,您可以將部分用戶端設定為使用 HTTP 1.1 而非 HTTP/2。例如,搭配 curl 使用 --http1.1 參數。
  • HTTPS 負載平衡器不支援以用戶端憑證為基礎的驗證,這種驗證方式又稱為雙向 TLS 驗證。

開啟的通訊埠

HTTP(S) 負載平衡器是反向 Proxy 負載平衡器。這類的負載平衡器會終止連入的連線,然後從負載平衡器開啟連至後端的新連線。反向 Proxy 功能由 Google Front Ends (GFE) 提供。

您設定的防火牆規則會封鎖 GFE 到後端的流量,但不會封鎖傳入 GFE 的流量。

HTTP(S) 負載平衡器具有多個開啟的通訊埠,以支援在同一架構上執行的其他 Google 服務。如果對 GCP HTTP(S) 負載平衡器的外部 IP 位址執行安全性或通訊埠掃描,則其他通訊埠會顯示為開啟。

這不會影響 HTTP(S) 負載平衡器。用於定義 HTTP(S) 負載平衡器的外部轉送規則只能參照 TCP 通訊埠 80、8080 和 443。使用不同 TCP 目標通訊埠的流量不會轉送至負載平衡器的後端。

元件

以下是 HTTP(S) 負載平衡器的元件。

轉送規則和位址

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

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

  • HTTP 負載平衡器的轉送規則只能參照 TCP 通訊埠 80 和 8080。
  • HTTPS 負載平衡器的轉送規則只能參照 TCP 通訊埠 443。

目標 Proxy

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

Proxy 會如下設定 HTTP 要求/回應標頭:

  • Via: 1.1 google (要求和回應)
  • X-Forwarded-Proto: [http | https] (僅限要求)
  • X-Forwarded-For: <unverified IP(s)>, <immediate client IP>, <global forwarding rule external IP>, <proxies running in GCP> (僅限要求) 由要求所經過的中繼項目附加的 IP 位址清單 (以逗號分隔)。如果您在 GCP 內部執行的 Proxy 會將資料附加至 X-forwarded-For 標頭,軟體就必須將這些 Proxy 的存在和數量列入考量。負載平衡器僅提供 <immediate client IP> 和 <global forwarding rule external IP> 項目。清單中所有其他項目都會在未經過驗證的情況下傳送。<immediate client IP> 項目是直接連線至負載平衡器的用戶端。<global forwarding rule external IP> 項目是負載平衡器轉送規則的外部 IP 位址。如果有更多項目,清單中的第一個項目就是原始用戶端的位址。<immediate client IP> 項目之前的其他項目代表將要求轉送到負載平衡器的其他 Proxy。
  • X-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (僅限要求)
    Stackdriver Trace 的參數。

如果預設標頭不符合需求,您可以建立自訂要求標頭。如要進一步瞭解這項功能,請參閱建立使用者定義的要求標頭

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

網址對應

網址對應會定義比對模式,這些模式可透過網址將要求轉送到合適的後端服務。系統會定義預設服務來處理任何不符合指定主機規則或路徑比對規則的要求。在某些情況下,例如在跨地區負載平衡的範例中,您可能無法定義任何網址規則,而只能使用預設服務。如果是以內容為基礎來轉送流量,網址對應可讓您透過檢查網址元件來劃分流量,以便將要求傳送到不同的後端組合。

SSL 憑證

如果您使用 HTTPS 負載平衡,則必須在目標 HTTPS Proxy 上安裝一或多個 SSL 憑證,最多可以安裝 15 個 SSL 憑證。目標 HTTPS Proxy 會使用這些憑證來驗證負載平衡器和用戶端之間的通訊。這些憑證可以是 Google 代管或自行管理的憑證

如要進一步瞭解如何為 HTTPS 負載平衡器安裝 SSL 憑證,請參閱 SSL 憑證的相關說明。

如果從負載平衡器到後端的通訊是使用 HTTPS 或 HTTP/2,則必須在每個 VM 執行個體上安裝 SSL 憑證。如要在 VM 執行個體上安裝 SSL 憑證,請使用應用程式說明文件中的操作說明。這些憑證可以自行簽署的憑證。

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

SSL 政策可讓您控管 HTTPS 負載平衡器與 HTTPS 用戶端交涉的 SSL 功能。

根據預設,HTTPS 負載平衡會使用一組提供良好安全性和廣泛相容性的 SSL 功能。有些應用程式需要進一步控制 HTTPS 或 SSL 連線使用的 SSL 版本和加密方式。您可以定義控管負載平衡器交涉之 SSL 功能的 SSL 政策,並將 SSL 政策與目標 HTTPS Proxy 建立關聯。

對 TLS 終止位置進行地理位置控制

HTTPS 負載平衡器終止 TLS 的位置分散在世界各地,這樣可縮短用戶端與負載平衡器之間的延遲。如果需要對 TLS 終止位置進行地理位置控制,則應使用 GCP 網路負載平衡,並在適合您需求之地區中的後端終止 TLS。

後端服務

後端服務會將設定資訊提供給負載平衡器,HTTP(S) 負載平衡器必須至少具備一個後端服務,並且可有多個後端服務。

負載平衡器利用後端服務中的資訊,將傳入流量導向至一或多個連接的後端。

每個後端都是由一個執行個體群組和其他負載能力中繼資料組成。後端負載能力可以依據 CPU 或每秒要求數 (RPS)

HTTP(S) 負載平衡支援 Cloud Load Balancing Autoscaler,允許使用者對後端服務中的執行個體群組執行自動調度資源作業。詳情請參閱根據 HTTP 負載平衡服務規模執行資源調度的相關說明。

您可以在後端服務上啟用連線排除功能,以確保提供流量服務的執行個體終止、遭手動移除或由自動配置器移除時,使用者遭遇的中斷情形能降到最低。如要進一步瞭解連線排除功能,請參閱啟用連線排除功能說明文件。

健康狀態檢查

每個後端服務也會指定要對每個可用執行個體執行哪個健康狀態檢查。如要讓健康狀態檢查探測正常運作,您必須建立防火牆規則,讓 130.211.0.0/2235.191.0.0/16 的流量可到達您的執行個體。

如要進一步瞭解健康狀態檢查,請參閱健康狀態檢查概念建立健康狀態檢查

後端的通訊協定

為 HTTP(S) 負載平衡器設定後端服務時,也要設定後端服務用來與後端通訊的通訊協定。您可以選擇 HTTP、HTTPS 或 HTTP/2。負載平衡器只會使用您指定的通訊協定。如果負載平衡器無法使用指定的通訊協定與後端交涉建立連線,將不會改回使用任何其他通訊協定。

如果您使用 HTTP/2 與後端 VM 通訊,請使用 HTTP/2 健康狀態檢查。

將 gRPC 與您的 Google Cloud Platform 應用程式搭配使用

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

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

如要將 gRPC 與 Google Cloud Platform 應用程式搭配使用,端到端皆必須透過 HTTP/2 經由 Proxy 傳送要求。透過 HTTP(S) 負載平衡器進行此操作的說明如下:

  1. 設定 HTTPS 負載平衡器。
  2. 啟用 HTTP/2 做為從負載平衡器與後端進行通訊的通訊協定。

負載平衡器會使用 ALPN TLS 擴充功能,在 SSL 握手過程中與用戶端進行 HTTP/2 交涉。

負載平衡器可能仍會與某些用戶端進行 HTTPS 交涉,或在設定為在負載平衡器和後端執行個體之間使用 HTTP/2 的 HTTP(S) 負載平衡器上接受不安全的 HTTP 要求。負載平衡器會轉換這些 HTTP 或 HTTPS 要求,以透過 HTTP/2 經由 Proxy 將要求傳送至後端執行個體。

如果您想使用 HTTP/2 搭配 Google Kubernetes Engine Ingress 來設定 HTTP(S) 負載平衡器,請參閱用於與 Ingress 進行負載平衡的 HTTP/2 一文。

您也可以將 gRPC 和 HTTP/2 與 Ingress 搭配使用。詳情請參閱用於與 Ingress 進行負載平衡的 HTTP/2 一文。

如要瞭解如何排除 HTTP/2 問題,請參閱排除後端的 HTTP/2 問題的相關說明。如要瞭解 HTTP/2 的限制,請參閱 HTTP/2 限制的相關說明。

後端值區

後端值區會將傳入流量導向至 Google Cloud Storage 值區。如需示範如何將值區新增到現有負載平衡器的範例,請參閱將 Cloud Storage 值區新增至負載平衡器一文。

防火牆規則

您必須建立防火牆規則,讓 130.211.0.0/2235.191.0.0/16 的流量可到達您的執行個體,這些是負載平衡器用於連線到後端執行個體的 IP 位址範圍。這項規則讓負載平衡器和健康狀態檢查工具可傳送流量。規則必須允許全域轉送規則設定要使用的通訊埠可傳送和接收流量,且您的健康狀態檢查工具應設為使用相同的通訊埠。如果您的健康狀態檢查工具使用不同的通訊埠,則必須為該通訊埠建立另一個防火牆規則。

請注意,防火牆規則會封鎖或允許執行個體層級的流量,而不是網路邊緣的流量。規則無法防止流量到達負載平衡器本身。

如果您需要在特定時間確定外部 IP 位址,請使用 Google Compute Engine 常見問題中的操作說明。

傳回路徑

GCP 使用 VPC 網路中未定義的特殊路徑來進行健康狀態檢查。如需完整相關資訊,請參閱負載平衡器傳回路徑的相關說明。

負載分配演算法

HTTP(S) 負載平衡提供兩種判斷執行個體負載的方法。在後端服務資源中,balancingMode 屬性會在每秒要求數 (RPS) 和 CPU 使用率模式之間進行選擇。這兩種模式都可以指定最大值;HTTP(S) 負載平衡器會設法確保負載保持限制內,但在容錯移轉或負載尖峰事件期間,可能會發生超過限制的短暫突發情況。

如果該地區具有可用容量,則系統會將傳入要求傳送到最接近使用者的地區。如果一個地區中有多個區域設定了後端,則演算法的預設行為是根據每個群組的容量,將容量分配到每個區域的執行個體群組之間。在區域內,系統會使用循環演算法將要求平均分散在執行個體中。您可以透過設定工作階段相依性來覆寫循環分配。但請注意,工作階段相依性在平衡模式也設為每秒要求數 (RPS) 時可發揮最佳效果。

如需負載分配演算法的具體範例,請參閱 HTTP(S) 負載平衡的運作原理一節。

工作階段相依性

工作階段相依性會將同一個用戶端的所有要求傳送到同一個虛擬機器執行個體,只要該執行個體保持良好健康狀態並具有容量即可。

GCP HTTP(S) 負載平衡提供兩種類型的工作階段相依性:

WebSocket Proxy 支援

HTTP(S) 負載平衡對 WebSocket 通訊協定提供原生支援。使用 WebSocket 與用戶端通訊的後端可以使用 HTTP(S) 負載平衡器做為前端,以取得擴充性和可用性。負載平衡器不需要任何其他設定,即可透過 Proxy 進行 WebSocket 連線。

WebSocket 通訊協定 (於 RFC 6455 中定義) 提供用戶端與伺服器之間的全雙工通訊通道,此通道是從 HTTP(S) 要求啟動的。

當 HTTP(S) 負載平衡辨識出 WebSocket Upgrade 要求是來自 HTTP(S) 用戶端,且要求之後是來自後端執行個體的成功 Upgrade 回應時,負載平衡器就會在目前連線期間透過 Proxy 進行雙向流量傳送。如果後端未成功傳回 Upgrade 回應,負載平衡器就會關閉連線。

WebSocket 連線的逾時時間取決於可為負載平衡器設定的「回應逾時」(預設為 30 秒)。此逾時一律會套用於 WebSocket 連線,無論有無使用連線。如要進一步瞭解回應逾時及其設定方式,請參閱逾時和重試

如果您已為 HTTP(S) 負載平衡器設定了用戶端 IP 或已產生 Cookie 工作階段相依性,則只要該執行個體繼續通過健康狀態檢查並具有容量,則來自用戶端的所有 WebSocket 連線都會傳送到同一個後端執行個體。

Ingress 支援 WebSocket 通訊協定。

QUIC 通訊協定支援 HTTPS 負載平衡

HTTPS 負載平衡支援在負載平衡器和用戶端之間的連線上使用 QUIC 通訊協定。QUIC 是一種傳輸層通訊協定,提供類似 TCP 的擁塞控制,安全性與 HTTP/2 的 SSL/TLS 相當,但效能更好。QUIC 可加快用戶端連線的啟動速度、能避免多工串流發生隊頭阻塞問題,並且可在用戶端的 IP 位址變更時支援連線遷移。

QUIC 會影響用戶端與負載平衡器之間的連線,不會影響負載平衡器與後端之間的連線。

目標 Proxy 的 QUIC 覆寫設定能讓您啟用以下其中一個功能:

  • 如有可能,請為負載平衡器進行 QUIC 交涉,或
  • 一律為負載平衡器停用 QUIC。

如果您未指定 QUIC 覆寫,將會允許 Google 在使用 QUIC 時進行管理。未指定覆寫時,Google 將不會啟用 QUIC。如要瞭解如何啟用及停用 QUIC 支援,請參閱目標 Proxy 一文。使用 Google Cloud Platform Console 建立 HTTPS 負載平衡器時,也可以啟用 QUIC,或使用 Google Cloud Platform Console 編輯負載平衡器設定,將 QUIC 停用。

QUIC 的交涉方式

啟用 QUIC 時,負載平衡器可以將其 QUIC 功能公告給用戶端,以允許支援 QUIC 的用戶端嘗試與 HTTPS 負載平衡器建立 QUIC 連線。正確實作的用戶端若無法建立 QUIC 連線,一律會改回使用 HTTPS 或 HTTP/2。由於有這樣的備用機制,所以在負載平衡器中啟用或停用 QUIC 將不會破壞負載平衡器連線到用戶端的能力。

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

  • 用戶端支援的 QUIC 版本與 HTTPS 負載平衡器支援的 QUIC 版本不相容
  • 負載平衡器偵測到 UDP 流量遭到封鎖或速率受限制,且這樣的封鎖或限制會導致 QUIC 無法運作
  • 因為錯誤、安全漏洞或其他問題而暫時停用 HTTPS 負載平衡器的 QUIC。

當連線因為這些情況而改回使用 HTTPS 或 HTTP/2 時,我們不會將此視為負載平衡器失敗。

啟用 QUIC 前,請確認您的工作負載可接受上述行為。

介面

您可以透過下列介面設定及更新 HTTP(S) 負載平衡服務:

  • gcloud 指令列工具:包含在 Cloud SDK 中的指令列工具。HTTP(S) 負載平衡說明文件經常使用此工具來完成工作。如需工具的完整總覽,請參閱 gcloud 工具指南。您可以在 gcloud compute 指令群組中找到與負載平衡相關的指令。

    您也可以使用 --help 旗標取得任何 gcloud 指令的詳細說明:

    gcloud compute http-health-checks create --help
    
  • Google Cloud Platform Console:您可以透過 Google Cloud Platform Console 完成負載平衡工作。

  • REST API:所有負載平衡工作均可透過 Google Cloud Load Balancing API 完成。API 參考文件說明了您可使用的資源和方法。

TLS 支援

根據預設,HTTPS 目標 Proxy 在終止用戶端 SSL 要求時,只接受 TLS 1.0、1.1 和 1.2。您可以使用 SSL 政策來變更這項預設行為,並控制負載平衡器如何與用戶端進行 SSL 交涉。

當負載平衡器使用 HTTPS 做為後端服務通訊協定時,就可以與後端進行 TLS 1.0、1.1 或 1.2 交涉。

逾時和重試

HTTP(S) 負載平衡具有兩種不同的逾時類型:

  • 可設定的 HTTP 回應逾時:代表負載平衡器等待後端傳回完整 HTTP 回應的時間,這不是 HTTP 閒置 (保持運作) 逾時。預設值是 30 秒。在下列情況下,請考慮提高逾時:

    • 如果您預期後端需要較長的時間才能傳回 HTTP 回應,或是
    • 如果連線已升級為 WebSocket。

    對於透過 GCP HTTP(S) 負載平衡器傳送的 WebSocket 流量,後端服務逾時會被解讀為 WebSocket 連線可保持開啟的最長時間 (無論是否閒置)。詳情請參閱後端服務設定一節。

  • TCP 工作階段逾時:這個項目的值固定為 10 分鐘 (600 秒)。此工作階段逾時有時稱為「保持運作」或「閒置」逾時,並且無法透過修改後端服務來設定其值。您必須設定後端使用的網路伺服器軟體,使其保持運作逾時時間超過 600 秒,才能避免後端過早關閉連線。此逾時「不適用於 WebSocket」

下表說明修改常見網路伺服器軟體的「保持運作」逾時所需的變更:

網路伺服器軟體 參數 預設設定 建議設定
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

HTTP(S) 負載平衡會在特定情況下重試失敗的 GET 要求,例如在回應逾時時間結束時,但不會重試失敗的 POST 要求。重試次數限制為兩次。重試的要求只會針對最終回應產生一個記錄項目。詳情請參閱記錄的相關說明。

不合法的要求和回應處理

HTTP(S) 負載平衡器會許多原因,而阻止用戶端要求到達後端,也會阻止後端回應到達用戶端。有些原因完全是為了達成 HTTP/1.1 法規遵循,有些則是為了避免資料意外往返於後端。

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

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

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

  • 要求網址和標頭的組合長度超過約 15 KB。
  • 要求方法不允許主體,但要求含有主體。
  • 要求中包含 Upgrade 標頭,但未使用 Upgrade 標頭來啟用 WebSocket 連線。
  • HTTP 版本未知。

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

  • 回應標頭的總大小大於 128 KB 左右。
  • HTTP 版本未知。

後續步驟

本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Load Balancing