速率限制 是什麼？

Rate Limiting — 速率限制 的完整解釋

一種控制請求頻率的機制，防止系統過載或濫用，確保服務穩定性與資源公平分配。

核心概念

速率限制（Rate Limiting）是資訊系統中一項關鍵的流量管理策略，其核心目標是控制特定實體（例如用戶、IP位址、應用程式）在特定時間範圍內發出請求的頻率。這項技術的引入，旨在維護系統的穩定性、可用性和公平性。在沒有速率限制的情況下，惡意攻擊者可能會發動拒絕服務（DoS）或分散式拒絕服務（DDoS）攻擊，透過洪水般的請求耗盡伺服器資源，導致合法用戶無法存取服務。即使是無意的程式錯誤或用戶行為，也可能因過度請求而使系統不堪重負。因此，速率限制不僅是防禦性措施，也是確保服務品質（QoS）和資源有效分配的基礎。它透過設定明確的閾值，如「每分鐘最多100個請求」，來規範流量，一旦請求量超過這些閾值，系統將採取相應措施，例如拒絕額外請求、延遲處理、或暫時封鎖來源。

運作原理

速率限制的運作原理通常涉及計數和時間窗的概念。最常見的演算法包括：

1. 固定窗口計數器 (Fixed Window Counter)：這是最簡單的實現方式。系統將時間劃分為固定的窗口（例如，每分鐘），並為每個窗口維護一個計數器。當請求到達時，計數器增加。如果計數器在當前窗口內超過預設閾值，則拒絕請求。窗口結束時，計數器重置。其缺點是在窗口邊界處可能出現「雙倍請求」問題，即在一個窗口結束前和下一個窗口開始後立即發出大量請求，導致在短時間內處理的請求量超過實際限制。
2. 滑動窗口日誌 (Sliding Window Log)：這種方法記錄每個請求的時間戳。當新請求到達時，系統會移除所有超出當前時間窗（例如，過去一分鐘）的舊時間戳，然後計算剩餘時間戳的數量。如果數量超過閾值，則拒絕請求。這種方法更精確，但需要儲存大量時間戳，記憶體開銷較大。
3. 滑動窗口計數器 (Sliding Window Counter)：這是固定窗口和滑動窗口日誌的折衷方案。它將時間劃分為多個固定窗口，並為每個窗口維護一個計數器。當請求到達時，它會根據當前時間點，按比例計算前一個窗口的剩餘請求數，並加上當前窗口的請求數。這種方法在精度和記憶體效率之間取得了較好的平衡。
4. 令牌桶 (Token Bucket)：系統以固定速率向「桶」中添加令牌。每個請求需要消耗一個令牌。如果桶中沒有令牌，請求必須等待或被拒絕。桶的大小限制了可以突發處理的最大請求量。這種方法允許一定程度的請求突發，同時平滑平均速率。
5. 漏桶 (Leaky Bucket)：請求像水一樣進入桶中，並以固定速率從桶中「漏出」。如果桶滿了，新的請求將被丟棄。這種方法強制請求以恆定速率處理，即使輸入速率波動很大。 無論採用哪種演算法，速率限制通常部署在反向代理、API閘道器、負載平衡器或應用程式層。當請求被拒絕時，通常會返回HTTP 429 Too Many Requests狀態碼，並可能包含Retry-After頭部，指示客戶端何時可以再次嘗試。

實際應用

速率限制在現代網路服務和AI應用中無處不在：

1. API管理：對於提供給第三方開發者的API，速率限制是必不可少的。它防止單一應用程式耗盡API資源，確保所有用戶都能獲得服務，並有助於實施基於使用量的計費模型。例如，Google Maps API、Twitter API等都有嚴格的速率限制。
2. 防止惡意攻擊：有效抵禦暴力破解密碼嘗試、爬蟲抓取、DDoS攻擊等。透過限制來自單一IP地址或用戶的請求頻率，可以顯著降低這些攻擊的成功率和影響。
3. 資源保護：保護後端資料庫、計算資源、記憶體等免受過度請求的壓力。當系統資源有限時，速率限制可以作為一種過載保護機制，防止系統崩潰。
4. 公平使用策略：確保所有用戶都能公平地使用共享資源。如果沒有速率限制，少數活躍用戶可能會佔用大部分資源，影響其他用戶的體驗。
5. 成本控制：在雲端環境中，許多服務是按使用量計費的。實施速率限制可以幫助控制API調用、資料庫查詢或計算資源的使用成本，避免意外的費用激增。
6. AI模型部署：在部署大型語言模型（LLM）或其他AI模型作為服務時，速率限制尤為重要。推理請求可能消耗大量GPU或CPU資源。限制每個用戶或每個應用程式的請求頻率，可以確保模型服務的穩定性，防止單一用戶的請求洪水導致服務品質下降，同時也能優化硬體資源的利用率。

常見誤區

1. 過於寬鬆或過於嚴格：設定不當的速率限制閾值會帶來問題。過於寬鬆可能無法有效保護系統，而過於嚴格則可能阻礙合法用戶的正常使用，導致用戶體驗下降。閾值應基於對系統容量、預期流量和用戶行為的深入理解來設定。
2. 僅在邊緣實施：雖然在API閘道器或負載平衡器層實施速率限制是常見做法，但僅在這些地方實施可能不足。惡意用戶可能會繞過這些外部防禦，直接攻擊內部服務。因此，在應用程式層甚至微服務層實施更細粒度的速率限制也是必要的。
3. 缺乏用戶通知：當請求被速率限制時，如果沒有清晰的錯誤訊息或重試建議（例如HTTP 429狀態碼和Retry-After頭），用戶或客戶端應用程式可能會感到困惑，並可能導致不必要的重試，進一步加劇系統壓力。
4. 未考慮分散式環境：在分散式系統中，簡單的單一計數器無法有效工作。需要使用分散式緩存（如Redis）來同步不同服務實例之間的計數器狀態，確保速率限制在整個系統中保持一致。
5. 未考慮突發流量：某些速率限制演算法（如固定窗口）對突發流量的處理不佳。如果業務場景允許短時間內的突發流量，應選擇令牌桶或漏桶等演算法，或在固定窗口基礎上增加突發容量。

與相關技術的比較

1. 負載平衡 (Load Balancing)：負載平衡旨在將傳入流量分發到多個伺服器實例，以提高系統的吞吐量和可用性。它關注的是流量的「分發」，而速率限制關注的是流量的「控制」。兩者通常協同工作，負載平衡器可以在分發流量之前或之後應用速率限制。
2. 防火牆 (Firewall)：防火牆主要基於IP地址、埠號或協定來過濾網路流量，提供網路層的安全保護。速率限制則更側重於應用層的請求頻率控制。防火牆可以阻止惡意IP，而速率限制可以防止合法IP的濫用。
3. 斷路器 (Circuit Breaker)：斷路器是一種容錯模式，用於防止應用程式在呼叫失敗的遠端服務時持續重試，從而導致資源耗盡或級聯故障。它關注的是「下游服務的健康狀況」，當服務故障時，斷路器會「打開」以阻止進一步的請求。速率限制關注的是「上游請求的頻率」，即使下游服務健康，也會限制請求。兩者都是保護系統穩定性的重要機制。
4. 流量整形 (Traffic Shaping)：流量整形是一種網路流量管理技術，用於延遲或丟棄某些資料包，以確保網路流量符合預定義的速率。它通常在網路層或資料鏈結層操作，目標是平滑流量模式，減少網路擁塞。速率限制則更常在應用層操作，針對的是請求的邏輯頻率。

速率限制 在 iPAS 考試中的重點

根據歷年統計，速率限制 相關題目 屬於未分類考範圍。

常見問題