Network Load Balancer 接聽程式 - Elastic Load Balancing

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

Network Load Balancer 接聽程式

接聽程式是檢查連線請求的程序,必須使用您已設定的通訊協定與連接埠。開始使用 Network Load Balancer 之前,您必須新增至少一個接聽程式。如果負載平衡器沒有接聽程式,就無法接收來自用戶端的流量。您為接聽程式定義的規則,將決定負載平衡器將請求路由到已註冊目標 (例如 EC2 執行個體) 的方法。

接聽程式組態

接聽程式支援下列通訊協定與連接埠:

  • 通訊協定:TCP、TLS、UDP、TCP_UDP、QUIC、TCP_QUIC

  • Ports (連接埠):1-65535

您可以使用 TLS 接聽程式來將加密和解密的工作卸載到您的負載平衡器,使得您的應用程式可以專注在商業邏輯上。如果接聽程式通訊協定是 TLS,您必須在接聽程式上部署至少一個 SSL 伺服器憑證。如需詳細資訊,請參閱伺服器憑證

如果您必須確保目標解密的是 TLS 流量 (而不是負載平衡器),則可以在連接埠 443 建立 TCP 接聽程式,而非建立 TLS 接聽程式。使用 TCP 接聽程式時,負載平衡器會將加密的流量傳遞給目標,而不需要加其解密。

您可以使用 QUIC 接聽程式來接受 QUIC 流量。Network Load Balancer 根據 RFC9000 做為通過負載平衡器。利用 QUIC 接聽程式和啟用 QUIC 的後端,為行動裝置啟用無縫連線遷移。

若要在相同的連接埠上同時支援 TCP 和 UDP,請建立 TCP_UDP 接聽程式。TCP_UDP 接聽程式的目標群組必須使用 TCP_UDP 通訊協定。

若要在同一連接埠上同時支援 TCP 和 QUIC,請建立 TCP_QUIC 接聽程式。TCP_QUIC 接聽程式的目標群組必須使用 TCP_QUIC 通訊協定。

雙堆疊負載平衡器的 UDP 接聽程式需要 IPv6 目標群組。

只有 TCP、TLS、TCP_UDP 和 TCP_QUIC 接聽程式才支援 WebSockets。

QUIC 流量不支援版本交涉。QUIC v1 是唯一支援的 QUIC 版本。

傳送至設定之接聽程式的所有網路流量皆分類為預期流量。對於已設定的接聽程式,任何不匹配的網路流量皆分類為非預期流量。類型 3 以外的 ICMP 請求也會視為非預期流量。Network Load Balancer 會捨棄非預期流量,而不會將其轉送至任何目標。傳送至接聽程式連接埠的 TCP 資料封包會遭到 TCP 重設 (RST) 拒絕,該接聽程式連接埠適用的已設定接聽程式不是新連線或作用中 TCP 連線一部分。

如需詳細資訊,請參閱《Elastic Load Balancing 使用者指南》中的請求路由

預設動作

當您建立接聽程式時,您可以指定路由請求的預設動作。預設動作會將請求轉送至您指定的目標群組。

將流量分配至多個目標群組

如果您為預設動作指定多個目標群組,請求會根據其相對權重分佈到這些目標群組。您必須為每個目標群組指定從 0 到 999 的權重。權重為 0 的目標群組不會接收流量。新增目標群組或更新目標群組權重後,會根據新的目標群組權重路由新的連線。現有的連線不會受到影響並繼續,直到照常關閉為止。

例如,如果您指定兩個目標群組,每個群組的權重為 10,則每個目標群組都會收到一半的請求。如果您指定兩個目標群組,一個具有 10 權重,另一個具有 20 權重,則具有 20 權重的目標群組會收到比具有 10 權重之目標群組多兩倍的請求。

常見的使用案例是將流量從一個目標群組遷移到另一個目標群組。這表示您會逐漸增加新目標群組的權重,同時減少原始目標群組的權重,直到達到 0。如果您將目標群組的權重更新為 0,在短時間內,目標群組不會收到新的連線,且現有的連線會關閉。

黏性工作階段和加權目標群組

接聽程式上的轉送動作可以指定是否啟用目標群組黏性。啟用時,目標群組黏性會導致來自相同來源 IP 地址的後續連線偏好先前選擇的目標群組。

考量事項
  • 對於 TLS 接聽程式,您無法同時將 TCP 目標群組和 TLS 目標群組新增至接聽程式規則。所有目標群組都必須使用相同的通訊協定。

  • 對於 TLS 接聽程式,不支援目標群組黏性。

  • 對於雙堆疊負載平衡器,您無法同時將 IPv4 目標群組和 IPv6 目標群組新增至相同的預設動作。預設動作中的所有目標群組都必須使用相同的 IP 地址類型。

  • 對於接聽程式,如果轉送動作包含多個目標群組,且其中任何一個已啟用黏性,則轉送動作也必須啟用目標群組黏性。

接聽程式屬性

以下是 Network Load Balancer 的接聽程式屬性:

tcp.idle_timeout.seconds

tcp 閒置逾時值,以秒為單位。有效範圍為 60-6000 秒。預設值為 350 秒。

如需詳細資訊,請參閱更新閒置逾時

安全接聽程式

若要使用 TLS 接聽程式,您必須在負載平衡器上部署至少一個伺服器憑證。負載平衡器使用伺服器憑證終止前端連接,然後解密用戶端的請求,再將它們傳送到目標。請注意,如您需要傳送加密流量至目標,而不需要負載平衡器將其解密,請在連接埠 443 建立 TCP 接聽程式,而非建立 TLS 接聽程式。負載平衡器會依現狀傳遞請求至目標,而不會將其解密。

Elastic Load Balancing 使用 TLS 交涉組態 (稱為安全政策),在用戶端與負載平衡器之間交涉 TLS 連線。安全政策為通訊協定與加密的組合。通訊協定會在用戶端和伺服器之間建立安全連線,並確保用戶端和負載平衡器之間傳遞的所有資料都是私有的。密碼是一種加密演算法,使用加密金鑰來建立編碼的訊息。通訊協定使用多個密碼來加密網際網路上的資料。在連線交涉程序期間,用戶端與負載平衡器會出示它們分別支援的加密和通訊協定的清單 (以偏好的順序)。系統會針對安全連線選取伺服器清單上符合任何用戶端加密的第一個加密。

Network Load Balancer 不支援交互 TLS 身分驗證 (mTLS)。如需 mTLS 支援,請建立 TCP 接聽程式,而非 TLS 接聽程式。負載平衡器會依現狀傳遞請求,因此您可在目標實作 mTLS。

Network Load Balancer 支援使用 PSK for TLS 1.3 的 TLS 恢復,以及 TLS 1.2 及更舊版本的工作階段票證。不支援使用工作階段 ID 的恢復,或在接聽程式中使用 SNI 設定多個憑證時。0-RTT 資料功能和 early_data 延伸未實作。

如需相關示範,請參閱《Network Load Balancer 的 TLS 支援》與《Network Load Balancer 的 SNI 支援》。

ALPN 政策

應用程式層通訊協定交涉 (ALPN) 是在初始 TLS 信號交換您好訊息上傳送的 TLS 延伸。ALPN 使應用程式層能夠協商哪些通訊協定的使用透過安全的連接 (如 HTTP/1 和 HTTP/2) 來進行。

當用戶端起始 ALPN 連線時,負載平衡器會將用戶端 ALPN 喜好設定清單與其 ALPN 政策進行比較。如果用戶端支援來自 ALPN 政策的通訊協定,則負載平衡器會根據 ALPN 政策的喜好設定清單來建立連線。否則,負載平衡器不會使用 ALPN。

支援的 ALPN 政策

以下是支援的 ALPN 政策:

HTTP1Only

只交涉 HTTP/1.*。ALPN 喜好設定清單為 http/1.1、http/1.0。

HTTP2Only

只協商 HTTP/2。ALPN 喜好設定清單為 h2。

HTTP2Optional

偏好 HTTP/1.*,而不是 HTTP/2 (這對於 HTTP/2 測試可能有用)。ALPN 喜好設定清單包括:http/1.1、http/1.0、h2。

HTTP2Preferred

偏好 HTTP/2,而不是 HTTP/1.*。ALPN 喜好設定清單是 h2、http/1.1、http/1.0。

None

不要交涉 ALPN。這是預設值。

啟用 ALPN 連線

您可以在建立或修改 TLS 接聽程式時啟用 ALPN 連線。如需詳細資訊,請參閱新增接聽程式更新 ALPN 政策