本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
編輯 Application Load Balancer 的屬性
建立 Application Load Balancer 之後，您可以編輯其屬性。
連線閒置逾時
連線閒置逾時是指在負載平衡器關閉連線之前，現有用戶端或目標連線可以保持非作用中狀態且未傳送或接收資料的時間。
為了確保檔案上傳等冗長操作有時間完成，請在每個閒置逾時期間經過之前傳送至少 1 個位元組的資料，並視需要增加閒置逾時期間的長度。也建議您將應用程式的閒置逾時設定為大於負載平衡器所設定的閒置逾時。否則，如果應用程式不正常地關閉與負載平衡器的 TCP 連線，負載平衡器可能會在收到指示連線已關閉的封包之前傳送請求給應用程式。如果是這種情況，則負載平衡器會向用戶端傳送「HTTP 502 錯誤閘道」錯誤。
Application Load Balancer 不支援 HTTP/2 PING 影格。這些不會重設連線閒置逾時。
預設情況下，Elastic Load Balancing 會將負載平衡器的閒置逾時設為 60 秒。
HTTP 用戶端保持連線持續時間
HTTP 用戶端保持連線持續時間是 Application Load Balancer 與用戶端維持持久性 HTTP 連線的時間長度上限。經過設定的 HTTP 用戶端保持連線持續時間後，Application Load Balancer 會接受另一個請求，然後傳回可正常關閉連線的回應。
負載平衡器傳送的回應類型取決於用戶端連線所使用的 HTTP 版本。
對於使用 HTTP 1.x 連線的用戶端，負載平衡器會傳送包含 欄位 的 HTTP 標頭。
Connection: close對於使用 HTTP/2 連線的用戶端，負載平衡器會傳送
GOAWAY影格。
根據預設，Application Load Balancer 會將負載平衡器的 HTTP 用戶端持續作用持續時間值設定為 3600 秒或 1 小時。HTTP 用戶端保持連線持續時間無法關閉或設定為低於最短 60 秒，但您可以增加 HTTP 用戶端保持連線持續時間，最長可達 604800 秒，或 7 天。Application Load Balancer 會在最初建立與用戶端的 HTTP 連線時，開始 HTTP 用戶端保持連線持續時間。當沒有流量時，持續時間會繼續，且在建立新連線之前不會重設。
當負載平衡器流量使用區域轉移或區域自動轉移從受損的可用區域轉移時，具有現有開放連線的用戶端可能會繼續對受損位置提出請求，直到用戶端重新連線為止。若要支援更快的復原，請考慮設定較低的持續作用持續時間值，以限制用戶端與負載平衡器保持連線的時間量。如需詳細資訊，請參閱《Amazon Application Recovery Controller (ARC) 開發人員指南》中的限制用戶端與您的端點保持連線的時間。
注意
當負載平衡器將 Application Load Balancer 的 IP 地址類型切換至 時dualstack-without-public-ipv4，負載平衡器會等待所有作用中連線完成。若要減少切換 Application Load Balancer IP 地址類型所需的時間，請考慮降低 HTTP 用戶端保持連線持續時間。
Application Load Balancer 會在初始連線期間指派 HTTP 用戶端保持連線持續時間值。當您更新 HTTP 用戶端保持連線持續時間時，這可能會導致與不同 HTTP 用戶端保持連線持續時間值的同時連線。現有的連線會保留初始連線期間套用的 HTTP 用戶端持續作用持續時間值。新連線會收到更新的 HTTP 用戶端保持連線持續時間值。
刪除保護
為避免您的負載平衡器上遭意外刪除，您可以啟用刪除保護。您的負載平衡器的刪除保護預設為停用。
如果您為負載平衡器啟用刪除保護，則必須先停用才可刪除負載平衡器。
去同步緩解模式
去同步緩解模式可保護應用程式免於因 HTTP 去同步而發生問題。負載平衡器會根據其威脅層級對每個要求進行分類，允許安全要求，然後根據您指定的緩和模式來降低風險。非同步緩和模式分為監控、防禦性和最嚴格。預設值為防禦模式，可針對 HTTP 非同步提供持久的緩和措施，同時維持應用程式的可用性。您可以切換至最嚴格模式，以確保應用程式只接收符合 RFC 7230
http_desync_guardian 程式庫會分析 HTTP 請求，以防止 HTTP 去同步攻擊。如需詳細資訊，請參閱 GitHub 上的 HTTP Desync Guardian
分類
分類如下：
-
合規 — 要求符合 RFC 7230，不會造成任何已知的安全威脅。
-
可接受 — 要求不符合 RFC 7230，但不會造成已知的安全威脅。
-
不明確 — 要求不符合 RFC 7230，但造成風險，因為各種 Web 伺服器和代理的處理方式不同。
-
嚴重 — 要求造成高安全性風險。負載平衡器會封鎖要求，傳送提供 400 回應至用戶端，並關閉用戶端連線。
如果要求不符合 RFC 7230，負載平衡器會增加 DesyncMitigationMode_NonCompliant_Request_Count 指標。如需詳細資訊，請參閱Application Load Balancer 指標。
每個請求的分類都包含在負載平衡器存取日誌中。如果請求不符合規定，存取日誌會包含分類原因代碼。如需詳細資訊，請參閱分類原因。
模式
下表說明 Application Load Balancer 如何根據模式和分類處理請求。
| 分類 | 監控模式 | 防禦性模式 | 最嚴格模式 |
|---|---|---|---|
| 合規 | 允許 | 已允許 | 允許 |
| 可接受 | 允許 | 允許 | 封鎖 |
| 不明確 | 允許 | 允許¹ | 封鎖 |
| 嚴重 | 允許 | 封鎖 | 封鎖 |
¹ 路由傳送要求，但關閉用戶端和目標連接。如果負載平衡器在防禦模式下收到大量「不明確」請求，則可能會產生額外費用。這是因為每秒增加的新連線數目會提高每小時使用的負載平衡器容量單位 (LCU)。您可以使用 NewConnectionCount 指標，來比較負載平衡器在監控模式和防禦模式下建立新連線的方式。
主機標頭保留
啟用保留主機標頭屬性後，Application Load Balancer 會保留 HTTP 請求中的 Host 標頭，並將標頭傳送到目標，而不進行任何修改。如果 Application Load Balancer 收到多個 Host 標頭，則會全部保留。只會將接聽程式規則套用至收到的第一個 Host 標頭。
依預設，如果未啟用保留主機標頭屬性，則 Application Load Balancer 會以下列方式修改 Host 標頭：
未啟用主機標頭保留，且接聽程式連接埠不是預設連接埠時：未使用預設連接埠 (連接埠 80 或 443) 時，如果用戶端尚未附加連接埠號碼，則我們會將該號碼附加至主機標頭。例如，如果接聽程式連接埠不是預設連接埠 (例如 8080)，則內含 Host:
www.example.com 之 HTTP 請求中的 Host 標頭會修改為 Host: www.example.com:8080。
未啟用主機標頭保留，且接聽程式連接埠為預設連接埠 (連接埠 80 或 443) 時：對於預設的接聽程式連接埠 (連接埠 80 或 443)，我們不會將連接埠號碼附加至傳出主機標頭。已存在於傳入主機標頭中的任何連接埠號碼都會遭到移除。
下表顯示更多範例，說明 Application Load Balancer 如何根據接聽程式連接埠處理 HTTP 請求中的主機標頭。
| 接聽程式連接埠 | 範例請求 | 請求中的主機標頭 | 主機標頭保留已停用 (預設行為) | 主機標頭保留已啟用 |
|---|---|---|---|---|
| 在預設的 HTTP/HTTPS 接聽程式上傳送請求。 | GET /index.html HTTP/1.1 Host: example.com |
example.com | example.com | example.com |
| 請求會在預設 HTTP 接聽程式上傳送，而主機標頭具有連接埠 （例如 80 或 443)。 | GET /index.html HTTP/1.1 Host: example.com:80 |
example.com:80 | example.com | example.com:80 |
| 請求具有絕對路徑。 | GET https://dns_name/index.html HTTP/1.1 Host:
example.com |
example.com | dns_name | example.com |
| 請求會在非預設接聽程式連接埠 （例如 8080) 上傳送 | GET /index.html HTTP/1.1 Host: example.com |
example.com | example.com:8080 | example.com |
| 在非預設接聽程式連接埠上傳送請求，並且主機標頭具有連接埠 (例如 8080)。 | GET /index.html HTTP/1.1 Host: example.com:8080 |
example.com:8080 | example.com:8080 | example.com:8080 |
