Rate limiting theo IP là gì?

Rate limiting theo IP là cơ chế giới hạn số lượng yêu cầu mà một địa chỉ IP có thể gửi đến máy chủ trong một khoảng thời gian nhất định. Nếu vượt quá giới hạn, máy chủ tạm thời từ chối yêu cầu của bạn, thường với lỗi HTTP 429 ("Too Many Requests"). Đây là một trong những công cụ phổ biến nhất để bảo vệ máy chủ khỏi lạm dụng, tấn công từ chối dịch vụ và scraping tự động.

Bạn có lẽ đã gặp điều này mà không nhận ra. Khi trang web hiển thị "Quá nhiều lần thử, vui lòng thử lại sau 5 phút" sau nhiều lần đăng nhập thất bại, đó là rate limiting. Khi API trả về lỗi sau một số lần gọi nhất định mỗi phút, đó là rate limiting. Khi công cụ tìm kiếm tạm thời chặn truy vấn vì bạn tìm kiếm quá nhanh, đó cũng là rate limiting.

Tại sao cần thiết

Máy chủ web có tài nguyên hữu hạn: CPU, bộ nhớ, băng thông, kết nối cơ sở dữ liệu. Mỗi yêu cầu tiêu tốn một phần tài nguyên. Không có giới hạn nào, một người dùng đơn lẻ (hoặc script tự động) có thể độc chiếm máy chủ bằng cách gửi hàng nghìn yêu cầu mỗi giây, khiến dịch vụ không thể truy cập cho tất cả người khác.

Rate limiting bảo vệ chống lại nhiều loại mối đe dọa:

Tấn công DDoS và brute force. Tấn công từ chối dịch vụ phân tán (DDoS) làm ngập máy chủ bằng yêu cầu để khiến nó không khả dụng. Rate limiting đơn thuần không đủ để chặn DDoS lớn (đến từ hàng nghìn IP khác nhau), nhưng nó giới hạn thiệt hại mà một IP đơn lẻ có thể gây ra. Với tấn công brute force (thử hàng nghìn mật khẩu), rate limiting là tuyến phòng thủ đầu tiên: giới hạn 5-10 lần đăng nhập mỗi phút khiến tấn công trở nên không khả thi.

Scraping và crawling lạm dụng. Bot trích xuất nội dung trang web (giá, bài viết, dữ liệu) gửi hàng trăm yêu cầu mỗi giây. Rate limiting làm chậm các bot đến mức trích xuất hàng loạt trở nên không khả thi về kinh tế (quá chậm, quá nhiều thời gian máy chủ).

Lạm dụng API. API công khai (thời tiết, định vị, AI, thanh toán) có chi phí mỗi yêu cầu cho nhà cung cấp. Không có rate limiting, người dùng có thể tiêu thụ tài nguyên bất cân xứng, do lỗi (vòng lặp trong code) hoặc cố ý. Hầu hết API đặt giới hạn theo khóa API và địa chỉ IP.

Công bằng giữa người dùng. Ngay cả không có ý xấu, người dùng "tham lam" (làm mới trang 50 lần mỗi phút, hoặc script viết kém) có thể làm giảm trải nghiệm cho người khác. Rate limiting đảm bảo chia sẻ tài nguyên công bằng.

Hoạt động kỹ thuật như thế nào

Nguyên lý đơn giản: máy chủ liên kết mỗi yêu cầu với địa chỉ IP, đếm số yêu cầu nhận được từ IP đó trong cửa sổ thời gian, và từ chối yêu cầu vượt ngưỡng. Nhưng triển khai cụ thể khác nhau tùy thuật toán.

Cửa sổ cố định (Fixed Window). Thời gian chia thành khoảng cố định (ví dụ, cửa sổ một phút). Máy chủ đếm yêu cầu mỗi IP trong mỗi cửa sổ. Nếu đạt 100 yêu cầu trong cửa sổ hiện tại, các yêu cầu tiếp theo bị từ chối đến khi cửa sổ tiếp theo bắt đầu. Đơn giản nhất nhưng có khuyết điểm: nếu gửi 100 yêu cầu cuối cửa sổ này và 100 đầu cửa sổ tiếp, bạn đã gửi 200 yêu cầu trong vài giây, gấp đôi giới hạn dự kiến.

Cửa sổ trượt (Sliding Window). Thay vì cửa sổ cố định, máy chủ nhìn N giây gần nhất tại mọi thời điểm. Mỗi yêu cầu được đếm trên khoảng trượt. Điều này làm mịn phân phối và loại bỏ vấn đề cửa sổ cố định, nhưng đòi hỏi nhiều bộ nhớ và tính toán phía máy chủ hơn.

Token Bucket (xô token). Mỗi IP có "xô" chứa số token cố định. Mỗi yêu cầu tiêu tốn một token. Token tái tạo với tốc độ không đổi (ví dụ, 10 mỗi giây). Nếu xô trống, yêu cầu bị từ chối. Mô hình này cho phép đợt ngắn (burst): bạn có thể gửi nhiều yêu cầu cùng lúc nếu xô đầy, sau đó phải đợi tái tạo. Là thuật toán được sử dụng nhiều nhất trong sản xuất vì vừa linh hoạt vừa dễ dự đoán.

Leaky Bucket (xô rò). Yêu cầu vào hàng đợi (xô) và được xử lý với tốc độ không đổi (tốc độ rò). Nếu xô đầy, yêu cầu mới bị từ chối. Khác Token Bucket, Leaky Bucket áp đặt tốc độ đầu ra nghiêm ngặt không đổi, không có burst. Hữu ích khi muốn luồng xử lý hoàn toàn đều đặn.

Rate limiting được áp dụng ở đâu

Rate limiting có thể áp dụng ở nhiều tầng hạ tầng mạng, và thực tế thường là vậy: nhiều lớp chồng lên nhau.

Tầng máy chủ web. Nginx, Apache và hầu hết máy chủ web tích hợp module rate limiting. Nginx dùng thuật toán Leaky Bucket với directive limit_req. Bạn định nghĩa số yêu cầu mỗi giây mỗi IP, Nginx xử lý phần còn lại. Hiệu quả cho bảo vệ cơ bản, nhưng máy chủ vẫn phải nhận và xử lý một phần mỗi yêu cầu trước khi từ chối.

Tầng reverse proxy hoặc load balancer. Đặt rate limiting trước máy chủ ứng dụng (trên reverse proxy như Nginx hoặc HAProxy, hoặc load balancer) cho phép chặn yêu cầu trước khi đến ứng dụng. Hiệu quả hơn về tài nguyên.

Tầng CDN hoặc WAF. Dịch vụ như Cloudflare, AWS WAF hoặc Akamai áp dụng rate limiting ở biên mạng (edge), trước khi yêu cầu đến hạ tầng của bạn. Lớp hiệu quả nhất chống tấn công lưu lượng lớn vì yêu cầu bị chặn càng gần nguồn càng tốt.

Tầng ứng dụng. Ứng dụng có thể tự triển khai rate limiting, thường với độ chi tiết cao hơn: theo người dùng đã đăng nhập, theo endpoint, theo loại thao tác. Ví dụ, API có thể cho phép 1.000 yêu cầu GET mỗi phút nhưng chỉ 10 yêu cầu POST trên endpoint tạo tài khoản vì tạo tài khoản lạm dụng là vector tấn công phổ biến.

Các header HTTP liên quan đến rate limiting

Khi máy chủ áp dụng rate limiting, nó thường truyền thông tin giới hạn qua header HTTP trong phản hồi. Không có tiêu chuẩn phổ quát, nhưng quy ước phổ biến nhất là:

X-RateLimit-Limit: số yêu cầu tối đa được phép trong cửa sổ thời gian hiện tại. X-RateLimit-Remaining: số yêu cầu còn lại trước khi đạt giới hạn. X-RateLimit-Reset: thời điểm (dạng Unix timestamp hoặc giây còn lại) khi cửa sổ reset và bộ đếm về 0. Retry-After: header HTTP tiêu chuẩn chỉ định thời gian chờ trước khi thử lại, trả về cùng phản hồi 429.

Bản nháp IETF (RFC 6585 cho mã 429 và đề xuất mới hơn) cố gắng chuẩn hóa các header này, nhưng thực tế mỗi API dùng quy ước riêng. Nếu bạn phát triển ứng dụng tiêu thụ API, luôn đọc tài liệu API để biết cách nó truyền đạt giới hạn.

Tại sao IP đơn lẻ không phải lúc nào cũng đủ

Rate limiting theo IP có vấn đề cơ bản: địa chỉ IP không phải lúc nào cũng tương ứng với một người dùng duy nhất.

CGNAT. Nhiều nhà mạng di động và một số ISP dùng CGNAT (Carrier-Grade NAT), khiến hàng trăm hoặc hàng nghìn người dùng chia sẻ một IPv4 công cộng. Nếu giới hạn một IP 100 yêu cầu mỗi phút, bạn thực tế giới hạn tất cả người dùng sau CGNAT đó tổng cộng 100 yêu cầu. Một người dùng bình thường có thể cạn kiệt hạn ngạch cho tất cả người khác.

Mạng doanh nghiệp và đại học. Hàng nghìn nhân viên hoặc sinh viên có thể truy cập internet qua một IP công cộng (hoặc vài địa chỉ). Rate limiting theo IP phạt họ tập thể.

VPN và proxy. Người dùng VPN thường chia sẻ IP với hàng trăm người khác. Rate limiting nghiêm ngặt theo IP có thể chặn người dùng hợp pháp chỉ vì họ dùng cùng máy chủ VPN với bot.

Địa chỉ IP động. Ngược lại, kẻ tấn công có thể dễ dàng đổi IP (dùng pool proxy, botnet, hoặc đơn giản bật chế độ máy bay trên điện thoại) và vượt qua rate limiting theo IP. Nếu giới hạn theo IP và kẻ tấn công có 10.000 địa chỉ, giới hạn thực tế nhân với 10.000.

Vì vậy hệ thống rate limiting hiện đại thường kết hợp IP với các định danh khác: khóa API, token xác thực, dấu vân tay trình duyệt, cookie phiên. IP vẫn là tiêu chí hữu ích nhưng hiếm khi đủ một mình.

Điều gì xảy ra khi bạn bị giới hạn

Phản hồi phổ biến nhất là mã HTTP 429 (Too Many Requests). Máy chủ cũng có thể trả 503 (Service Unavailable) nếu giới hạn do quá tải chung thay vì vượt ngưỡng cá nhân.

Một số dịch vụ không chặn hoàn toàn mà giảm chất lượng dịch vụ: làm chậm phản hồi (throttling), giảm chất lượng kết quả, hoặc thêm CAPTCHA để xác minh bạn là con người.

Dịch vụ khác chặn im lặng mà không trả lỗi rõ ràng. Tiếp tục phản hồi mã 200 (OK) nhưng trả dữ liệu rỗng hoặc kết quả giảm chất lượng. "Rate limiting im lặng" (shadow banning) phổ biến trên mạng xã hội và một số công cụ tìm kiếm, được thiết kế để bot khó phát hiện.

Lập trình viên xử lý rate limiting như thế nào

Nếu phát triển ứng dụng tiêu thụ API, bạn cần xử lý rate limiting đúng cách. Phương pháp tiêu chuẩn là "exponential backoff": khi nhận phản hồi 429, đợi một khoảng thời gian trước khi thử lại và nhân đôi thời gian đó sau mỗi lần thất bại liên tiếp. Ví dụ: lần đầu sau 1 giây, lần hai sau 2 giây, lần ba sau 4 giây, v.v.

Thực hành tốt bao gồm:

Đọc header Retry-After và X-RateLimit-Reset để biết chính xác khi nào thử lại thay vì đoán. Triển khai cache để tránh lặp lại cùng yêu cầu. Gom nhóm yêu cầu (batching) khi API cho phép. Phân bố yêu cầu theo thời gian thay vì gửi loạt. Dự phòng circuit breaker ngừng gọi API một lúc nếu lỗi 429 tích lũy, để không làm tình hình tệ hơn.

Rate limiting và quyền riêng tư

Rate limiting theo IP nghĩa là máy chủ nhận diện và theo dõi yêu cầu theo địa chỉ IP. Đây là hình thức xử lý dữ liệu cá nhân (địa chỉ IP được coi là dữ liệu cá nhân ở nhiều khu vực pháp lý, đặc biệt theo GDPR ở châu Âu). Doanh nghiệp triển khai rate limiting về lý thuyết nên đề cập xử lý này trong chính sách bảo mật.

Từ góc độ người dùng, rate limiting theo IP cũng có nghĩa hoạt động của bạn đang được đếm. Nếu dùng VPN hoặc proxy vì quyền riêng tư, rate limiting có thể nghịch lý gây bất lợi cho bạn: chia sẻ IP với người dùng khác và hạn ngạch chung cạn kiệt nhanh hơn.

Vượt qua rate limiting

Đổi địa chỉ IP (qua VPN, proxy xoay, hoặc chế độ máy bay trên di động) cho phép vượt qua rate limiting chỉ dựa trên IP. Dịch vụ scraping thương mại dùng pool hàng nghìn IP residential để phân bố yêu cầu và ở dưới ngưỡng mỗi IP.

Nhưng hệ thống bảo vệ hiện đại không chỉ dựa vào IP. Chúng kết hợp phân tích dấu vân tay trình duyệt, hành vi duyệt web (nhịp click, chuyển động chuột, thời gian trên trang), CAPTCHA và phân tích mẫu yêu cầu để phân biệt người và bot, ngay cả khi IP thay đổi mỗi yêu cầu.

Cuộc chạy đua giữa hệ thống rate limiting và kỹ thuật vượt qua là vĩnh viễn. Phương pháp hoạt động hôm nay có thể bị phát hiện ngày mai. Nếu bạn ở phía máy chủ, chiến lược tốt nhất là kết hợp nhiều lớp bảo vệ thay vì chỉ dựa vào IP.

Ví dụ giới hạn phổ biến

Các giới hạn này thay đổi rất nhiều tùy dịch vụ, gói giá và bối cảnh. API trả phí thường cung cấp giới hạn cao hơn nhiều so với gói miễn phí. Endpoint nhạy cảm (đăng nhập, thanh toán, tạo tài khoản) có giới hạn thấp hơn nhiều so với endpoint đọc dữ liệu.

Rate limiting theo IP là bảo vệ thiết yếu cho mọi máy chủ trên internet. Nó ngăn lạm dụng, bảo vệ tài nguyên và đảm bảo truy cập công bằng. Nhưng địa chỉ IP đơn lẻ ngày càng ít đáng tin cậy với CGNAT, VPN và proxy. Hệ thống hiện đại kết hợp IP với các tín hiệu khác để phân biệt lưu lượng hợp pháp và lạm dụng, và chính sự kết hợp đó tạo nên khác biệt giữa bảo vệ hiệu quả và bộ lọc đơn giản dễ bị vượt qua.