服務頻率限制政策可讓您在可能耗用過多資源的信任用戶端之間，維持服務可用性。政策會優先處理服務過載期間的重要用戶端流量，並節流超過預先定義門檻的用戶端，藉此達成上述目標。
您可以將服務頻率限制政策與其他類型的頻率限制結合，例如明確禁止不受信任用戶端，以防濫用的 Cloud Armor 安全性政策。如要進一步瞭解安全性政策，請參閱「安全性政策總覽」和 Cloud Armor「頻率限制總覽」。
您可以將服務頻率限制政策附加至支援的負載平衡器轉送規則，或附加至 Secure Web Proxy 閘道資源。如要進一步瞭解如何搭配使用服務頻率限制政策與 Secure Web Proxy 執行個體，請參閱「設定服務頻率限制政策」。
支援的目標
下列目標適用服務頻率限制政策：
- 區域性內部應用程式負載平衡器
- Secure Web Proxy
要求篩選順序
服務頻率限制政策只是套用至要求的其中一種篩選器。下圖顯示篩選器的套用順序：
規則
每項服務頻率限制政策都包含 HTTP 規則清單。每項規則都會指定比對條件和一組頻率限制動作。當要求符合規則的比對條件時，系統會根據您設定的一或多個頻率限制值區評估要求。
比對條件
比對條件及其屬性如下。每個屬性都可以比對確切字串、前置字串、後置字串或子字串：
Source：要求的來源。principal：從用戶端憑證衍生的身分清單。只要有任何主體符合規則，即為相符。如要進一步瞭解如何使用主體限制服務頻率，請參閱「使用主體限制服務頻率」。
Destination：要求的目的地。如果指定多個屬性，系統會使用邏輯AND運算子結合這些屬性。header_set：HTTP 標頭清單。如果header_set中的「所有」標頭都符合規則，即視為相符。hosts：HTTP 主機清單。當要求傳送至清單中任何指定的主機時，就會發生相符情況。paths：網址路徑清單。如果要求使用清單中「任何」指定的路徑，即視為相符。methods：有效 HTTP 方法清單 (例如GET或POST)。如果要求使用清單中的「任何」指定方法，即視為相符。
請注意，來源和目的地屬性會與邏輯 AND 運算子結合，以判斷規則是否與要求相符。也就是說，如果您指定來源和目的地，要求必須同時符合這兩者，才算符合比對條件。此外，空白規則會比對所有要求。
規則評估順序
系統會依序評估政策中定義的規則，從第一項規則到最後一項規則。如果有多條規則與要求相符，系統會套用第一條規則的速率限制動作，並停止評估其他規則。如果規則有多個頻率限制動作，且其中任何一個動作超過設定的門檻，系統就會限制要求。
頻率限制值區
您可以設定一或多個頻率限制值區，每個值區都有一或多個頻率限制鍵。如果要求符合規則的比對條件，系統會根據您設定的一或多個頻率限制 bucket 評估要求。接著，bucket 會套用設定的頻率限制金鑰，識別個別用戶端並強制執行限制。
除了金鑰類型外，您還可以設定下列值區屬性：
- 模擬測試：在模擬測試模式下，系統會評估規則並追蹤相符項目，但不會套用規則動作。這樣一來，您就能測試頻率限制規則，而不會對用戶端造成節流，或影響實際工作環境流量。
- 使用者覆寫：您可以覆寫特定鍵值的預設要求限制。舉例來說，假設您有一個 bucket，每個用戶端每分鐘的預設要求數上限為 100 個，且該 bucket 使用
SOURCE_IP金鑰類型，您可以為特定 IP 位址覆寫上限，改為每分鐘 200 個要求。
金鑰類型
您可以透過下列鍵類型彙整要求並強制執行速率限制，識別個別用戶端以進行速率限制：
- ALL：單一金鑰，適用於符合規則比對條件的所有要求。
- SOURCE_IP：每個用戶端 IP 位址的專屬金鑰，其要求符合規則比對條件。
- HTTP_HEADER：每個不重複 HTTP 標頭值的專屬索引鍵，其名稱已設定。鍵值會截斷為標頭值的前 128 個位元組。如果沒有這類標頭，金鑰類型預設為 ALL。
- HTTP_PATH：HTTP 要求的網址路徑。鍵值會截斷為前 128 個位元組。
- 主體：代表身分的字串，衍生自用戶端憑證。唯一支援的主體類型是
CLIENT_CERT_COMMON_NAME。
您可以在每項規則中指定一或多個金鑰類型。如果指定多個金鑰類型，系統會將每個用戶端的金鑰總組合視為不重複金鑰。舉例來說，您可以結合使用 SOURCE_IP 和 HTTP_PATH，針對特定 IP 位址存取特定端點的頻率套用速率限制。
使用主體限制服務頻率
如要以高精細度識別流量來源，您可以根據從用戶端憑證衍生的身分識別，設定服務頻率限制政策。這個方法需要在負載平衡器上啟用前端 mTLS，並使用用戶端憑證一般名稱 (CLIENT_CERT_COMMON_NAME) 屬性做為識別資訊的主體選取器。
如未指定用於識別的主體選取器，系統會使用 CLIENT_CERT_URI_SAN 做為預設主體選取器。也就是說，系統在決定頻率限制時，會評估用戶端憑證的 URI SAN。
如要依主體限制頻率，必須符合下列條件：
必須啟用前端 mTLS。如果未啟用前端 mTLS，用戶端就不會提供憑證。因此，服務頻率限制政策中任何以主體為基礎的規則，都找不到可評估的憑證資訊。舉例來說，檢查
CLIENT_CERT_URI_SAN的規則會看到空值。必須有有效的用戶端憑證。即使啟用 mTLS，如果連線是使用遺失或無效的憑證建立，系統也不會使用用戶端憑證進行頻率限制。當 mTLS 用戶端驗證模式設為寬鬆模式
ALLOW_INVALID_OR_MISSING_CLIENT_CERT時，就會發生這種情況。在這種情況下，服務頻率限制政策中任何以主體為基礎的規則，也找不到可評估的憑證資訊。舉例來說，檢查CLIENT_CERT_URI_SAN的規則會看到空值。
屬性大小限制的影響
Rate Limiting 決策會受到用戶端憑證屬性大小的影響。如果屬性超出大小限制，且政策設定為驗證該特定屬性，要求就會遭到拒絕。
如果政策根據 CLIENT_CERT_COMMON_NAME 進行驗證，且憑證的主體 (包含一般名稱) 超過大小限制，就可能遭到拒絕。