Rate Limit คืออะไร?
การจำกัดจำนวนครั้งที่ผู้ใช้สามารถเรียกใช้ API หรือหน้าเว็บของเราได้ในช่วงเวลาหนึ่งๆ เปรียบเหมือน รถไฟฟ้าให้ขึ้นได้แค่ 100 คนต่อขบวน ป้องกันไม่ให้แน่นจนระบบล่ม
ทำไมต้องมี Rate Limit?
- ป้องกันบอทหรือผู้ไม่ประสงค์ดีสแปมข้อมูล
- ป้องกันการดึงข้อมูลหมดระบบในครั้งเดียว (เช่น ดาวน์โหลดฐานข้อมูลทั้งตัว)
- ทำให้ระบบเสถียร ใช้ทรัพยากรได้เท่าๆกันทุกคน
- ประหยัดค่าใช้จ่าย (ลดการเรียกใช้ฐานข้อมูลหรือ API ภายนอกแบบฟุ่มเฟือย)
เทคนิคพื้นฐานที่ควรรู้ (เลือกใช้อันใดอันหนึ่ง)
| เทคนิค | หลักการ | เหมาะกับ |
|---|---|---|
| Fixed Window | นับจำนวน request ใน 1 นาที เช่น 100 ครั้ง พอครบนาทีถัดไปเริ่มนับใหม่ | ระบบทั่วไป ใช้งานง่ายที่สุด |
| Sliding Window | สมมติจำกัด 100 ครั้งต่อ 60 วินาที คุณส่งครั้งแรกเวลา 10:00:30 ครั้งที่ 101 จะส่งได้ตอน 10:01:30 เป็นต้นไป (ไม่ใช่รอแค่ข้ามนาที) | API ที่ต้องแม่นยำสูง, ระบบ payment, login, หรือระบบที่คนพยายามเล่นช่องโหว่เรื่องเวลา |
| Token Bucket | มีโทเค็น 100 อัน แต่ละ request ใช้ 1 อัน โทเค็นเติมทีละ 10 อันทุกวินาที | รองรับการใช้งานเป็นพักๆ (burst) เช่น ตอนเปิดแอปแล้วโหลดพร้อมกันหลายอย่าง |
| Leaky Bucket | Request เข้ามาเท่าไหร่ก็ได้ แต่ส่งออกไปที่เซิร์ฟเวอร์ด้วยอัตราคงที่ | ระบบที่ต้องรักษาจังหวะ steady เช่น การสตรีมข้อมูล |
แนะนำสำหรับมือใหม่: เริ่มจาก Fixed Window หรือ Token Bucket ง่ายต่อการเข้าใจและ implement
ควรจำกัดที่ระดับไหนบ้าง? (เลือกให้เหมาะกับแอป)
จำกัดตาม IP ใช้ง่ายที่สุด แต่คนใช้ WiFi ร่วมกันอาจโดนจำกัดพร้อมกัน ตัวอย่าง: 100 req/min ต่อ IP
จำกัดตาม User ID (หรือ API Key) แม่นยำกว่า เหมาะกับแอปที่มีการล็อกอิน ตัวอย่าง: 500 req/min ต่อ user
จำกัดแยกตาม endpoint endpoint เสี่ยงสูง เช่น /login อาจให้แค่ 5 ครั้ง/นาที ส่วน /search ให้ 100 ครั้ง/นาที
แบบผสม เช่น จำกัด IP ไว้ 200 req/min แต่ถ้าเป็น user พรีเมียมให้ 1000 req/min
ภาพประกอบ: 1