Một tập lệnh có lỗi gọi API của bạn theo một vòng lặp chặt chẽ. Không có giới hạn, nó có thể làm chậm dịch vụ của mọi người dùng khác hoặc tiêu tốn một khoản chi phí lớn trên đám mây. Giới hạn tốc độ API là rào chắn ngăn không cho một khách hàng nào lấy nhiều hơn mức chia sẻ công bằng của nó.

Để hiển thị cách hoạt động của các thuật toán phổ biến, chúng tôi đã viết các phiên bản Python nhỏ và cung cấp cho chúng thời gian yêu cầu mô phỏng. Các kết quả đầu ra dưới đây đến từ lần chạy đó. Chúng là các mô hình giảng dạy chứ không phải mã sản xuất và các cổng thực có nhiều tính năng hơn.

Giới hạn tỷ lệ là gì?

Giới hạn tốc độ tính các yêu cầu trên mỗi khách hàng và từ chối hoặc trì hoãn các yêu cầu vượt quá giới hạn đã thỏa thuận, chẳng hạn như 100 yêu cầu mỗi phút. Một ý tưởng liên quan, điều tiết, thường có nghĩa là làm chậm lại các yêu cầu thay vì từ chối chúng. hạn ngạch thường là mức trợ cấp lớn hơn trong thời gian dài hơn, chẳng hạn như 10.000 cuộc gọi mỗi tháng theo gói giá.

Tại sao API cần nó

• Tính ổn định: lưu lượng truy cập tăng đột biến không thể làm quá tải cơ sở dữ liệu hoặc các dịch vụ hạ nguồn.
• Công bằng: một khách hàng nặng ký không thể bỏ đói những khách hàng khác.
• Bảo mật: các giới hạn làm chậm các nỗ lực đăng nhập và tìm kiếm thô bạo.
• Kiểm soát chi phí: các hoạt động tốn kém, chẳng hạn như lệnh gọi mô hình AI, luôn nằm trong ngân sách.

Giới hạn tốc độ là một biện pháp kiểm soát cốt lõi trong Top 10 Bảo mật API OWASP, với mức tiêu thụ tài nguyên không hạn chế. Hướng dẫn kiểm tra API với Postman của chúng tôi cho biết cách gửi các yêu cầu lặp lại cần thiết để kiểm tra nó.

Nhóm mã thông báo

Hãy tưởng tượng một cái xô chứa tối đa 5 mã thông báo. Mỗi yêu cầu cần một mã thông báo. Mã thông báo được nạp lại với tốc độ 1 mỗi giây và nhóm không bao giờ chứa nhiều hơn 5. Nếu nhóm trống, yêu cầu sẽ bị từ chối.

class TokenBucket:
    def __init__(self, capacity, refill_per_sec):
        self.capacity = capacity
        self.rate = refill_per_sec
        self.tokens = capacity
        self.last = 0.0

    def allow(self, now):
        elapsed = now - self.last
        self.tokens = min(self.capacity, self.tokens + elapsed * self.rate)
        self.last = now
        if self.tokens >= 1:
            self.tokens -= 1
            return True
        return False

Chúng tôi đã gửi 7 yêu cầu cùng một lúc, sau đó nhiều hơn nữa:

burst of 7 at t=0:  [True, True, True, True, True, False, False]
t=2.0:              [True, True, False]
t=10:               5 allowed of 10

5 cái đầu tiên trôi qua như một vụ nổ, sau đó cái xô trống rỗng. Hai giây sau, 2 mã thông báo đã được nạp lại, vì vậy có thêm 2 yêu cầu nữa được thông qua. Sau một thời gian dài tạm dừng, nhóm đã đầy trở lại nhưng bị giới hạn ở mức 5. Hoạt động liên tục rồi ổn định này phù hợp với lưu lượng truy cập thực, đó là lý do tại sao nhóm mã thông báo lại phổ biến trong các cổng API. nhóm bị rò rỉ là một họ hàng gần có khả năng xử lý các yêu cầu ở tốc độ cố định, làm trơn tru đầu ra thay vì cho phép bùng nổ.

Cửa sổ cố định và cửa sổ trượt

Bộ đếm cửa sổ cố định là cách tiếp cận đơn giản nhất: cho phép 10 yêu cầu mỗi phút và đặt lại bộ đếm khi phút thay đổi. Nó có một lỗ hổng được biết đến ở ranh giới. Chúng tôi đã gửi 10 yêu cầu ở tốc độ 59,9 giây và 10 yêu cầu khác ở tốc độ 60,0 giây, với giới hạn là 10 yêu cầu trên mỗi cửa sổ 60 giây:

fixed window allowed around boundary: 20 of 20
sliding log allowed around boundary:  10 of 20

Cửa sổ cố định cho phép tất cả 20 yêu cầu trong một phần mười giây, gấp đôi tốc độ dự kiến, vì chúng rơi vào hai cửa sổ khác nhau. Nhật ký trượt ghi nhớ thời gian của mỗi yêu cầu gần đây và đếm những yêu cầu đó trong 60 giây qua, do đó, nó chỉ cho phép chính xác 10.

Sự đánh đổi là bộ nhớ. Nhật ký trượt lưu trữ dấu thời gian cho mỗi yêu cầu. Bộ đếm cửa sổ trượt là một vị trí trung gian phổ biến. Nó ước tính tốc độ bằng cách trộn số lượng cửa sổ hiện tại và trước đó, sử dụng ít bộ nhớ với độ chính xác cao.

So sánh thuật toán

Hạn chế bằng cách nào

• Khóa API hoặc ID người dùng: tùy chọn công bằng nhất cho các API được xác thực.
• Địa chỉ IP: hữu ích cho các điểm cuối công cộng nhưng nhiều người dùng có thể chia sẻ một IP và những kẻ tấn công có thể xoay vòng chúng.
• Điểm cuối: các hoạt động tốn kém, chẳng hạn như tìm kiếm, xuất hoặc đăng nhập, xứng đáng có giới hạn chặt chẽ hơn.
• Cấp gói: khách hàng miễn phí và trả phí thường có các giới hạn khác nhau.

Điểm cuối đăng nhập cần được chăm sóc đặc biệt. Giới hạn cả theo tài khoản và IP, vì vậy những kẻ tấn công không thể đơn giản truyền bá các dự đoán trên nhiều IP hoặc nhiều tài khoản.

Phản hồi 429

Khi khách hàng vượt quá giới hạn, hãy trả về HTTP 429 Quá Nhiều Yêu cầu, chứ không phải 500 hoặc 403. Hãy bao gồm các tiêu đề cho khách hàng biết điều gì đã xảy ra và khi nào cần thử lại. Mô phỏng của chúng tôi đã tạo ra bộ này cho một khách hàng không còn yêu cầu nào:

HTTP/1.1 429 Too Many Requests
RateLimit-Limit: 100
RateLimit-Remaining: 0
RateLimit-Reset: 30
Retry-After: 30

Retry-After là tiêu đề HTTP tiêu chuẩn. Các tiêu đề RateLimit-* đến từ bản nháp IETF và nhiều API sử dụng các biến thể X-RateLimit-* của riêng chúng. Dù bạn chọn gì, hãy ghi lại nó. Để biết thêm về mã trạng thái, hãy xem Bảng tóm tắt mã trạng thái HTTP của chúng tôi.

Xử lý giới hạn với tư cách là khách hàng

Việc thử lại ngay sau 429 sẽ khiến mọi việc trở nên tồi tệ hơn. Nếu hàng nghìn khách hàng thực hiện việc đó cùng lúc, họ sẽ tấn công máy chủ theo từng đợt đồng bộ. Cách khắc phục là thời gian chờ theo cấp số nhân kèm theo hiện tượng giật hình: đợi lâu hơn sau mỗi lần thất bại và thêm tính ngẫu nhiên.

def backoff(attempt, base=0.5, cap=30, rng=random.Random(4)):
    return round(min(cap, base * 2 ** attempt) * rng.random(), 2)

[backoff(a) for a in range(6)]
# [0.12, 0.1, 0.79, 0.62, 0.53, 6.43]

Đây là tình trạng “jitter hoàn toàn”: thời gian chờ ngẫu nhiên giữa số 0 và mức trần tăng theo cấp số nhân. Sự chờ đợi có vẻ bất thường, và đó chính là vấn đề. Khách hàng tản ra thay vì thử lại cùng nhau. Chúng tôi đã tạo hạt giống cho trình tạo ngẫu nhiên để có thể sao chép đầu ra.

Giới hạn tỷ lệ phân phối

Với một số máy chủ API phía sau bộ cân bằng tải, mỗi máy chủ tự đếm sẽ cho phép máy khách vượt quá giới hạn bằng cách phân bổ các yêu cầu trên chúng. Các nhóm thường giữ bộ đếm trong một cửa hàng dùng chung chẳng hạn như Redis, với các hoạt động nguyên tử hoặc một tập lệnh ngắn để hai máy chủ không thể cùng lấy mã thông báo cuối cùng. Các cổng như Kong, NGINX, Envoy và cổng API đám mây cung cấp cấu hình này. Chúng tôi không chạy thiết lập phân tán cho bài viết này.

Giới hạn tỷ lệ thử nghiệm

• Gửi yêu cầu đến giới hạn và xác nhận chúng thành công.
• Gửi thêm một lần nữa và xác nhận 429 với tiêu đề chính xác.
• Đợi thời gian đặt lại và xác nhận yêu cầu thành công lần nữa.
• Kiểm tra giới hạn cho mỗi khóa: việc sử dụng của một khách hàng không được chặn một khóa khác.
• Kiểm tra ranh giới giữa các cửa sổ để tìm sự cố bùng phát kép.
• Sử dụng công cụ tải, như được đề cập trong kiểm tra tải và kiểm tra sức chịu đựng, để kiểm tra hành vi trong điều kiện đồng thời nhiều.

Trong các thử nghiệm đơn vị, hãy thêm thời gian hiện tại, giống như mô phỏng của chúng tôi thực hiện với now, để các thử nghiệm không bao giờ phải ngủ.

Thiết kế các giới hạn mà người dùng có thể chấp nhận

Việc chọn số cũng quan trọng như việc chọn thuật toán. Bắt đầu từ lưu lượng truy cập thực tế: xem xét số lượng yêu cầu mà khách hàng hợp pháp nặng nhất của bạn thực hiện mỗi phút và đặt giới hạn một cách thoải mái trên mức đó. Giới hạn chặn việc sử dụng bình thường sẽ tạo ra các phiếu hỗ trợ chứ không phải sự an toàn.

• Công bố các giới hạn trong tài liệu API của bạn, theo từng điểm cuối và theo từng gói.
• Cảnh báo trước khi chặn. Tiêu đề hiển thị các yêu cầu còn lại cho phép các ứng dụng khách hoạt động tốt tự giảm tốc độ.
• Cung cấp các lựa chọn thay thế cho việc bỏ phiếu nhiều, chẳng hạn như webhook, điểm cuối hàng loạt hoặc các trang lớn hơn.
• Theo dõi tỷ lệ 429. Sự gia tăng đột ngột có thể đồng nghĩa với một cuộc tấn công, một bản phát hành ứng dụng khách có lỗi hoặc các giới hạn hiện quá chặt chẽ.
• Cố tình cấp các ngoại lệ, chẳng hạn như nâng cao giới hạn cho đối tác, được ghi lại trong cấu hình thay vì mã hóa cứng.

Đồng thời quyết định điều gì sẽ xảy ra với các yêu cầu đến vượt quá giới hạn. Một số API xếp hàng nhanh một số lượng nhỏ yêu cầu bổ sung thay vì từ chối chúng, điều này giúp giảm bớt các đột biến ngắn. Những người khác ưu tiên cho các điểm cuối thiết yếu, chẳng hạn như thanh toán, hơn các điểm cuối ít quan trọng hơn như phân tích, để lưu lượng truy cập quan trọng tiếp tục được lưu chuyển khi hệ thống chịu áp lực.

Lời kết

Giới hạn tỷ lệ tốt là một hợp đồng giữa API và khách hàng. Máy chủ chọn một thuật toán hợp lý, thường là nhóm mã thông báo hoặc cửa sổ trượt và giải thích rõ ràng các giới hạn của nó bằng 429 và Thử lại sau. Máy khách tôn trọng những tín hiệu đó và lùi lại với tình trạng jitter. Bắt đầu với các giới hạn hào phóng cho mỗi khóa API, theo dõi mức sử dụng thực tế và chỉ thắt chặt ở những nơi bạn cần.

Câu hỏi thường gặp

Tiếp tục học hỏi