Các hệ thống lớn sử dụng Rate Limiting để chống DDOS, hạn chế spam, bảo vệ hệ thống như thế nào? – Phần 2

Ở kì trước, mình đã giới thiệu với các bạn về kĩ thuật Rate Limiting – Một kĩ thuật đơn giản mà hay ho, được khá nhiều hệ thống lớn sử dụng.

Trong kì này, chúng ta sẽ đi sâu vào tìm hiểu cụ thể về cách các hệ thống lớn áp dụng Rate Limiting; cách áp dụng Rate Limiting để bảo vệ hệ thống của chúng ta nhé!

API của Facebook, Google, LinkedIn dùng Rate Limiting như thế nào?

Nhắc lại 1 tí kiến thức ở bài trước, các thuật toán Rate Limiting hay được dùng bao gồm (Các bạn xem lại để hiểu rõ hơn nhé):

  • Leaky Bucket
  • Token Bucket
  • Fixed Window
  • Sliding Window

Những trang web lớn như Google, Facebook đều cung cấp API cho các bên thứ 3 sử dụng. Tuy vậy, đa phần họ đều ghi rõ limit để chống kẻ xấu spam và dùng quá nhiều tài nguyên hệ thống, để người dùng chân chính biết cách sử dụng cho hợp lý.

Hầu hết những hệ thống lớn đều sử dụng Rate Limiting, dựa theo business, requirement của hệ thống và nhiều yếu tố khác nữa!

 

Youtube API: Mỗi application sẽ được cấp 10000 unit 1 ngày. Mỗi lần gọi API sẽ tốn 1 unit nhất định, API tìm kiếm thì tẩm 50 unit, API upload thì tầm 1000 unit. Cách này chắc là dựa theo thuật toán Token Bucket.

https://developers.google.com/youtube/v3/getting-started#quota

 

Github API: Cho phép mỗi người dùng gọi 5000 request mỗi giờ. Nếu chưa đăng nhập thì chỉ được 60 request mỗi giờ. Có thể họ sử dụng Sliding Window hoặc Fixed Window.

https://developer.github.com/v3/#rate-limiting

 

Facebook API: Facebook cung cấp rất nhiều API: Lấy thông tin cá nhân, quản lý page, chạy quảng cáo… Phần lớn API dùng Platform Rate Limit, các API liên quan tới Marketing và Instagram sẽ có rate limit riêng.

Rate Limit của Facebook không fix cứng mà khá là… ngộ nghĩnh, phụ thuộc vào số lượng user trong app của bạn. App càng nhiều user thì gọi API càng nhiều lần, thấy có vẻ cũng hợp lý đấy chứ!

https://developers.facebook.com/docs/graph-api/overview/rate-limiting/#platform-rate-limits

 

Tuy nhiên, dân Việt Nam rất trâu nên nhiều khi họ tìm được các API ngầm, hoặc chạy automation để làm nhiều trò … API không cho phép.

Do đó, những trang lớn như Facebook, Google đôi khi họ còn dùng cả AI/ML, dựa theo behaviour người dùng để xác định xem là người hay máy automation. Tuy nhiên, do cái này nằm ngoài phạm vi bài viết nên mình xin bỏ qua.

Áp dụng Rate Limit vào hệ thống

Về cơ bản, áp dụng Rate Limiting vào hệ thống là một chuyện … không quá phức tạp, nhất là với các hệ thống nhỏ.

Đa phần các web framework (Spring, ExpressJS, Ruby on Rails, …) đều có thư viện hỗ trợ. Chỉ cần gắn vào, tinh chỉnh vài dòng code là xong. (Các bạn muốn tự implement thì kéo xuống dưới bài có link có code sample nha)

Theo kinh nghiệm, thường người ta sẽ setup Rate Limiting ở tầm Load Balancer hoặc Web Server. Lý do là vì web app của bạn chỉ nên tập trung vào business logic, những thứ như SSL Termination, Rate Limiting để Web Server quản lý sẽ tốt hơn, dễ thay đổi mà không cần sửa code.

Với nginx, chỉ cần vài dòng config là ta đã setup xong rate limiting. Khi muốn tăng/giảm chỉ cần config là xong! https://docs.nginx.com/nginx/admin-guide/security-controls/controlling-access-proxied-http/

 

Tuy nhiên, khó khăn nằm ở chỗ tinh chỉnh các tham số sao cho phù hợp. Chặn quá lỏng lẻo thì vô tác dụng, chặn quá chặt thì user sẽ thấy bị chậm, khó chịu, không gọi được API.

Dưới đây là 1 số kinh nghiệm của mình khi dùng Rate Limit:

  • Public API là những API có thể gọi mà không cần token: Đăng nhập, Gửi tin nhắn, quên mật khẩu, search… API càng public hoặc càng quan trọng thì rate limit càng thấp.  Lý do là những API này rất dễ bị lợi dụng để spam, cào thông tin hệ thống.
  • Cân bằng giữa việc tăng Rate Limit và trải nghiệm người dùng. Nên cho phép tăng limit nếu người dùng đã đăng nhập, có nhiều quyền, trả phí v…v
  • Khi người dùng gọi API quá limit thì làm gì?
    • Throttle: nginx có khái niệm burst khá hay, những request vượt limit sẽ được đưa vào 1 queue, xử lý từ từ. Người dùng chỉ thấy bị chậm nhưng không bị lỗi. Kĩ thuật này gọi là throttle
    • Return Error: Server trả về HTTP Code 429 – Too Many Requests để phía client biết mà xử lý
    • Shadow Ban: Đôi khi bạn sẽ bị hacker chơi xấu, gọi API quá trời, khi gặp lỗi 429 thì tạo account mới để gọi. Lúc này ta có thể dùng Shadow Ban, vẫn trả về HTTP 200 nhưng … không làm gì hết, để đánh lừa hacker.
429 Too Many Requests: The user has sent too many requests in a given amount of time. Intended for use with rate limiting schemes. Proposed in an Internet-Draft.

Điều quan trọng nhất là bạn phải dựa vào business và requirement của hệ thống để ra quyết định nhé! Ví dụ web ngân hàng thì đăng nhập sai 3 lần là khoá và cảnh báo liền; còn web xem pỏn thì đăng nhập lộn 5-10 lần cũng chẳng chết ai đâu.

Tạm kết

Các bạn thấy đấy,  Rate Limiting là một trong những kĩ thuật/thuật toán đơn giản, hay ho nhưng lại ít được nhắc tới trong sách hay chương trình học.

Tuy nhiên, chúng lại là những người hùng thầm lặng, bảo vệ chúng ta khỏi bị DDOS, chống spam, đảm bảo người dùng có thể gọi API một cách trơn tru.

Đấy, nếu bạn quan tâm đến những bài viết dạng kĩ thuật/thuật toán thế này, nhớ để lại comment nha. Nếu nhiều bạn quan tâm mình sẽ viết nhiều hơn nhé ahihi.

 

Tham khảo thêm:

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s