Rate limiting từng là thứ chúng tôi ước một khách hàng của mình biết đến sớm hơn. Website bán hàng của họ sập giữa đêm, đúng lúc đang chạy chương trình khuyến mãi lớn nhất năm. Thủ phạm là một con bot dò mật khẩu, gửi request đăng nhập liên tục không nghỉ. Server gánh không nổi, và cả khách hàng thật cũng không vào được web. Nói dễ hiểu, rate limiting giống như người bảo vệ đứng ở cửa, chỉ cho một số lượng khách nhất định vào trong mỗi phút.
Chúng tôi kể lại chuyện này không phải để dọa ai. Chỉ là muốn bạn hiểu vì sao một khái niệm nghe có vẻ khô khan lại quan trọng đến vậy. Bất kỳ ai đang vận hành một website hay ứng dụng cũng nên biết qua, kể cả khi chưa từng viết một dòng code nào.
Rate Limiting Là Gì Trong Hệ Thống Web
Nói một cách đơn giản, rate limiting là kỹ thuật giới hạn số lượng yêu cầu gửi tới hệ thống. Giới hạn này tính trong một khoảng thời gian nhất định, ví dụ mỗi phút hay mỗi giờ. Máy chủ có thể chỉ cho phép mỗi địa chỉ IP gửi tối đa 100 yêu cầu mỗi phút. Vượt qua con số đó, hệ thống sẽ từ chối hoặc bắt chờ. Chúng tôi hay ví nó như vòi nước có van điều tiết, chứ không phải cái cửa đóng kín hoàn toàn.
Không có rate limiting, một server tầm trung vẫn gánh được vài trăm người dùng cùng lúc mà không sao. Nhưng chỉ cần một kịch bản tự động gửi liên tục hàng chục nghìn request, tài nguyên máy chủ cạn kiệt trong vài giây. Đây là dạng tấn công mà dân kỹ thuật gọi là từ chối dịch vụ. Nó làm sập hệ thống bằng lưu lượng khổng lồ, thay vì bằng lỗ hổng bảo mật. Đặt giới hạn tần suất truy cập giúp hệ thống lọc bớt phần lưu lượng bất thường, giữ chỗ cho người dùng thật.
Nếu bạn từng đọc bài API là gì mà chúng tôi từng viết, sẽ dễ hình dung hơn. Rate limiting thường được gắn ngay tại cổng API, nơi ứng dụng bên ngoài gửi yêu cầu vào hệ thống. Một API công khai mà không có giới hạn, sớm muộn cũng bị khai thác quá mức. Dù ý đồ ban đầu của người gọi không hề xấu, hệ thống vẫn có thể quá tải. Chỉ cần một đoạn code lỗi chạy lặp vô tội vạ là đủ.
Sai Lầm Thường Gặp Khi Mới Bắt Đầu Đặt Giới Hạn
Sai lầm chúng tôi thấy nhiều bạn mới hay mắc là đặt giới hạn quá thấp ngay từ đầu. Điều đó khiến người dùng thật cũng bị chặn oan, dù họ chẳng làm gì sai. Kinh nghiệm của đội ngũ là bắt đầu với ngưỡng rộng, theo dõi log thực tế trong vài ngày. Sau đó mới siết dần cho vừa với lưu lượng thật của hệ thống. Một mẹo nhỏ là luôn thông báo rõ ràng khi chặn, thay vì để trang trắng xóa không lời giải thích. Người dùng thật sẽ đỡ hoang mang hơn nhiều.
Cơ Chế Giới Hạn Yêu Cầu Vận Hành Ra Sao
Ví dụ dễ thấy nhất nằm ở form đăng nhập. Nhiều hệ thống chỉ cho phép nhập sai mật khẩu tối đa 5 lần trong 15 phút. Vượt quá, tài khoản tạm khóa hoặc phải chờ thêm mới thử lại được. Cách làm này chặn được kiểu tấn công dò mật khẩu hàng loạt. Dân kỹ thuật gọi nó là brute force, tức thử hết khả năng có thể cho tới khi trúng.
Khi một yêu cầu vượt ngưỡng, hệ thống thường trả về mã lỗi 429, nghĩa là quá nhiều yêu cầu. Nhiều người mới thấy mã lỗi này hay tưởng do mạng chậm hoặc web bị lỗi thật sự. Bản chất đó là hệ thống đang chủ động từ chối, không phải sự cố kỹ thuật. Một hệ thống làm tốt sẽ kèm theo thời gian chờ cụ thể, để trình duyệt hoặc ứng dụng biết lúc nào được thử lại.
Một tình huống dễ gây hiểu lầm là nhiều người dùng thật lại chung một địa chỉ IP. Ví dụ cùng một văn phòng, hoặc cùng nhà mạng di động. Nếu đặt giới hạn theo IP quá cứng nhắc, cả nhóm người vô tội có thể bị chặn oan. Chỉ vì họ đứng chung mạng với một ai đó đang gửi request bất thường. Chúng tôi thường khuyên kết hợp thêm định danh theo tài khoản đăng nhập, không chỉ dựa vào mỗi địa chỉ IP.
Các Kiểu Giới Hạn Không Giống Nhau Hoàn Toàn
Không phải mọi cách áp dụng rate limiting đều giống nhau. Có nơi đếm số yêu cầu trong một khung giờ cố định. Có nơi tính theo cửa sổ trượt liên tục. Có nơi lại phát ra một lượng token nhất định rồi trừ dần mỗi khi có yêu cầu tới.
- Giới hạn theo khung cố định: đơn giản, dễ làm. Nhược điểm là dễ bị lách nếu người dùng canh đúng lúc khung giờ mới bắt đầu để gửi dồn yêu cầu.
- Giới hạn theo cửa sổ trượt: tính toán liên tục, không reset đột ngột từng phút. Cách này phù hợp với hệ thống cần độ công bằng cao.
- Giới hạn kiểu token: mỗi request tiêu tốn một token trong kho dự trữ. Token được nạp lại dần theo thời gian, hợp với lưu lượng dao động thất thường.
Chọn kiểu nào phụ thuộc vào mức độ traffic của bạn. Website nhỏ, lượng truy cập ổn định thì giới hạn theo khung cố định là đủ dùng, không cần phức tạp hóa. Hệ thống lớn, traffic dao động mạnh theo giờ cao điểm thì nên cân nhắc kiểu token, vì nó linh hoạt hơn nhiều.
Mã lỗi 429 hay bị hiểu nhầm là lỗi phía người dùng. Nó giống nhiều thuật ngữ kỹ thuật hay bị hiểu sai mà chúng tôi từng gặp khi tư vấn cho các bạn mới vào nghề. Hiểu đúng bản chất giúp lập trình viên xử lý lỗi hợp lý hơn. Thay vì gọi lại liên tục làm tình hình tệ thêm.
Ứng Dụng Của Nó Trong Một Dự Án Web Thực Tế
Một khách hàng của chúng tôi từng mở API cho đối tác lấy dữ liệu sản phẩm tự động. Ban đầu mọi thứ ổn, cho tới khi một đối tác viết script chạy vòng lặp gửi liên tục, không nghỉ. Server chậm hẳn, ảnh hưởng luôn cả người dùng bình thường trên web chính. Chúng tôi phải thêm giới hạn tần suất ngay trong tuần đó để cứu tình hình.
Tình huống tương tự cũng hay xảy ra với các website bán hàng vào mùa sale lớn. Nhiều khách nhờ chúng tôi thiết kế website bán hàng đều lo một chuyện: bot săn hàng giảm giá gửi request đặt hàng dồn dập. Khách thật vì vậy không mua được, do server nghẽn đúng lúc cao điểm. Giới hạn hợp lý giúp phần lớn request thật vẫn đi qua, còn phần bất thường bị chặn bớt.
Nếu bạn mới học lập trình, không cần làm gì phức tạp ngay từ đầu. Một biến đếm đơn giản lưu trong bộ nhớ, reset mỗi phút, đã đủ cho một dự án nhỏ chạy ổn. Chúng tôi từng chia sẻ lộ trình tự học lập trình 6 tháng cho người mới. Trong đó, phần thực hành với API nhỏ có bài tập tương tự, giúp làm quen dần trước khi động vào hệ thống lớn hơn.
Kinh nghiệm của đội ngũ là luôn ghi log mỗi lần hệ thống chặn bớt request. Nhờ vậy sau này mới biết mình đang chặn đúng đối tượng hay đang chặn oan người dùng thật. Thiếu bước ghi log này, rất khó biết giới hạn mình đặt ra có hợp lý hay không.
Điều Chúng Tôi Muốn Bạn Nhớ Sau Cùng
Rate limiting không phải công nghệ cao siêu, chỉ là một lớp phòng thủ đơn giản mà hiệu quả. Nếu bạn đang xây dựng một dự án web, dù nhỏ, hãy dành ra một buổi để thêm giới hạn tần suất. Ưu tiên những endpoint quan trọng nhất, nhất là đăng nhập và thanh toán.
Đừng đợi đến khi hệ thống sập mới nghĩ tới nó, giống câu chuyện khách hàng chúng tôi kể ở đầu bài. Bắt đầu từ mức giới hạn vừa phải, theo dõi thực tế rồi tinh chỉnh dần theo đúng lưu lượng của mình. Đó là cách làm bền nhất mà đội ngũ chúng tôi vẫn áp dụng cho tới giờ.