# Rate Limit Introduction 為何需要 Rate Limit： 1. 對雲端來說，Rate Limit 可以控制流量，可以控管流量費 2. 避免被 DDOS 3. 根據不同的使用者或是 API 去控管流量 :::warning 通常是返回 429，Too Many Requests ::: 常見演算法： * Token Bucket * 對每個 Request 發 Token，當 Token Bucket 裡面的 Token 數量不夠的時候，就不會讓新的 Request 進來 * 隔幾秒會回去 Token Bucket 補特定數量的 Token，直到達到 Token Bucket 達到數量上限 * 超過 Bucket 的上限時，會返回 429 * 如果 Bucket 是滿的，可以應付瞬間的大流量 ![](https://i.imgur.com/uO5UsJm.png) * Leaky Bucket * Bucket 代表最大可承受的 Requests 數量 * 不管當前打進來的 Requests 的頻率多高，都會先匯積在 Buckey 裡，並照著一定頻率往後面的服務轉送 * 超過 Bucket 的上限時，會返回 429 * 跟 Token Bucket 最大的差異是，會控制頻率及速度，Token Bucket 只阻擋數量，不限制速度及頻率 ![](https://i.imgur.com/hwLyCxw.png) * Fixed Window * 控制一個時間區段內，最大的請求數量 ![](https://i.imgur.com/ou3Gqwe.png) * Sliding Window * 會根據 Request 發生的當下，往前回推當前時間點到 Fixed Window 的開始點中間的 Requests 數量是否達到上限，再決定要不要把 Request 拒絕 * 需要花費更多記憶體去儲存時間戳記，且也需要花一些效能在計算 ![](https://i.imgur.com/peC7Qxj.png) ## .Net 6 常用的套件是 AspNetCoreRateLimit，可分為 IP Base 及 Client Id Base https://www.nuget.org/packages/AspNetCoreRateLimit/ ## .Net 7 內建 Rate Limit 套件，並且支援以上 4 種演算法 ## 待思考問題 * 什麼情況下才該把服務加上 Rate Limit? * 使用者可以接受畫面上出現 "當前服務流量太大，請稍後再試"，這種類型的訊息嗎?