Hatalı bir komut dosyası, API’nizi sıkı bir döngüde çağırır. Sınırsız bir şekilde, diğer tüm kullanıcılar için hizmeti yavaşlatabilir veya büyük bir bulut faturasına neden olabilir. API hız sınırlaması, tek bir müşterinin adil payından fazlasını almasını engelleyen bir korumadır.

Yaygın algoritmaların nasıl davrandığını göstermek için küçük Python versiyonları yazdık ve bunları simüle edilmiş istek zamanlamalarıyla besledik. Aşağıdaki çıktılar bu çalıştırmadan geliyor. Bunlar üretim kodunu değil modelleri öğretiyorlar ve gerçek ağ geçitleri daha fazla özelliğe sahip.

Hız sınırlaması nedir?

Hız sınırlama, istemci başına istekleri sayar ve kabul edilen bir sınırın (örneğin, dakikada 100 istek) üzerindeki istekleri reddeder veya geciktirir. İlgili bir fikir olan kısma, genellikle istekleri reddetmek yerine yavaşlatmak anlamına gelir. Kota genellikle daha uzun bir süre boyunca verilen daha büyük bir ödenektir (örneğin, bir fiyatlandırma planında ayda 10.000 çağrı).

API’lerin buna neden ihtiyacı var?

• Kararlılık: trafik artışları veritabanlarını veya aşağı yöndeki hizmetleri zorlayamaz.
• Adillik: ağır bir müşteri diğerlerini aç bırakamaz.
• Güvenlik: kaba kuvvetle giriş denemelerini ve kazımayı yavaşlatmayı sınırlar.
• Maliyet kontrolü: Yapay zeka model çağrıları gibi pahalı işlemler bütçe dahilinde kalır.

Hız sınırlama, sınırsız kaynak tüketimi altında OWASP API Güvenliği İlk 10’da yer alan temel bir kontroldür. Postacı ile API test etme kılavuzumuz, kontrol etmek için gereken tekrarlanan isteklerin nasıl gönderileceğini gösterir.

Jeton paketi

En fazla 5 jeton tutan bir kova hayal edin. Her istek bir jeton alır. Jetonlar saniyede 1 oranında yeniden doldurulur ve pakette hiçbir zaman 5’ten fazla jeton tutulmaz. Paket boşsa istek reddedilir.

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

Aynı anda 7 istek gönderdik, ardından daha fazlasını daha sonra gönderdik:

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

İlk 5’i patlamayla geçti, ardından kova boşaldı. İki saniye sonra 2 jeton yeniden dolduruldu ve böylece 2 istek daha iletildi. Uzun bir duraklamanın ardından paket tekrar doldu ancak 5 ile sınırlandı. Bu patlama ve ardından sabit davranış davranışı gerçek trafiğe uygundur, bu nedenle jeton paketlerinin API ağ geçitlerinde yaygın olarak kullanılmasının nedeni budur. Sızdıran paket, istekleri sabit bir hızda işleyen ve patlamalara izin vermek yerine çıktıyı yumuşatan yakın bir akrabadır.

Sabit pencere ve kayan pencere

Sabit pencere sayacı en basit yaklaşımdır: Dakikada 10 isteğe izin verin ve dakika değiştiğinde sayacı sıfırlayın. Sınırda bilinen bir kusuru var. 60 saniyelik pencere başına 10’luk bir sınırla, 59,9 saniyede 10 istek ve 60,0 saniyede 10 istek daha gönderdik:

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

Sabit pencere, saniyenin onda biri kadar bir sürede 20 isteğin tümüne izin verdi; bu, amaçlanan oranın iki katıydı çünkü bunlar iki farklı pencereye düşüyordu. Kayan günlük her yeni isteğin zamanını hatırlar ve son 60 saniyedekileri sayar, dolayısıyla yalnızca 10’a doğru bir şekilde izin verir.

Takas hafızadır. Kayan günlük, istek başına bir zaman damgası saklar. Kayan pencere sayacı popüler bir orta yoldur. Mevcut ve önceki pencere sayımlarını harmanlayarak, az miktarda bellek kullanarak iyi bir doğrulukla oranı tahmin eder.

Algoritma karşılaştırması

Neyle sınırlandırılmalı

• API anahtarı veya kullanıcı kimliği: kimliği doğrulanmış API’ler için en adil seçenek.
• IP adresi: genel uç noktalar için kullanışlıdır, ancak birçok kullanıcı bir IP’yi paylaşabilir ve saldırganlar bunları dönüşümlü olarak kullanabilir.
• Uç nokta: Arama, dışa aktarma veya oturum açma gibi pahalı işlemler daha sıkı sınırları hak eder.
• Plan katmanı: Ücretsiz ve ücretli müşterilere genellikle farklı limitler uygulanır.

Oturum açma uç noktalarının özel bakıma ihtiyacı vardır. Hem hesaba hem de IP’ye göre sınırlama yapın, böylece saldırganlar tahminlerini çok sayıda IP’ye veya çok sayıda hesaba yayamaz.

429 yanıtı

Bir istemci sınırı aştığında, 500 veya 403 yerine HTTP 429 Çok Fazla İstek döndürün. Müşteriye ne olduğunu ve ne zaman tekrar denemesi gerektiğini söyleyen başlıklar ekleyin. Simülasyonumuz bu seti hiçbir isteği kalmayan bir müşteri için üretti:

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

Retry-After standart bir HTTP başlığıdır. RateLimit-* başlıkları bir IETF taslağından gelir ve birçok API kendi X-RateLimit-* varyantlarını kullanır. Neyi seçerseniz seçin, belgeleyin. Durum kodları hakkında daha fazla bilgi için HTTP durum kodları özet sayfamıza bakın.

İstemci olarak sınırları ele alma

429’dan hemen sonra yeniden denemek işleri daha da kötüleştirir. Binlerce istemci aynı anda bunu yaparsa, sunucuya senkronize dalgalar halinde vururlar. Çözüm, titreşimli üstel geri çekilmedir: her başarısızlıktan sonra daha uzun süre bekleyin ve rastgelelik ekleyin.

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]

Bu “tam titreşim”dir: sıfır ile katlanarak büyüyen tavan arasında rastgele bir bekleme. Beklemeler düzensiz görünüyor ve mesele de bu. Müşteriler birlikte yeniden denemek yerine dağılırlar. Çıktının yeniden üretilebilmesi için rastgele oluşturucuyu tohumladık.

Dağıtılmış hız sınırlaması

Bir yük dengeleyicinin arkasında birden fazla API sunucusu bulunduğunda, her sunucunun kendi başına sayılması, istemcinin istekleri sunuculara yayarak sınırı aşmasına olanak tanır. Ekipler genellikle sayaçları Redis gibi paylaşılan bir depoda atomik işlemlerle veya kısa bir komut dosyasıyla tutar, böylece iki sunucu son jetonu alamaz. Kong, NGINX, Envoy gibi ağ geçitleri ve bulut API ağ geçitleri bunu yapılandırma olarak sağlar. Bu makale için dağıtılmış bir kurulum çalıştırmadık.

Hız sınırlarını test etme

• Sınıra kadar istek gönderin ve başarılı olduklarını onaylayın.
• Bir tane daha gönderin ve doğru başlıklarla 429’u onaylayın.
• Sıfırlama süresini bekleyin ve isteklerin tekrar başarılı olduğunu onaylayın.
• Anahtar başına sınırları kontrol edin: Bir istemcinin kullanımı diğerini engellememelidir.
• Çift patlama sorunu için pencereler arasındaki sınırı test edin.
• Yoğun eşzamanlılık altındaki davranışı kontrol etmek için yük testi ve stres testi bölümünde anlatıldığı gibi bir yükleme aracı kullanın.

Birim testlerinde, simülasyonumuzun now ile yaptığı gibi geçerli saati girin, böylece testlerin asla uyuması gerekmez.

Kullanıcıların yaşayabileceği sınırları tasarlamak

Sayıları seçmek, algoritmayı seçmek kadar önemlidir. Gerçek trafikten başlayın: En yoğun meşru müşterilerinizin dakikada kaç istekte bulunduğuna bakın ve bunun üzerine rahatça sınırlar koyun. Normal kullanımı engelleyen bir limit, güvenlik değil destek biletleri oluşturur.

• Uç nokta ve plan başına sınırları API belgelerinizde yayınlayın.
• Engellemeden önce uyar. Kalan istekleri gösteren başlıklar, iyi niyetli istemcilerin kendi başlarına yavaşlamalarına olanak tanır.
• Yoğun oylamaya alternatifler sunun; örneğin web kancaları, toplu uç noktalar veya daha büyük sayfalar.
• 429 oranlarını izleyin. Ani bir artış, bir saldırı, sorunlu bir istemci sürümü veya artık çok sıkı olan limitler anlamına gelebilir.
• Kasıtlı olarak istisnalar verin; örneğin bir iş ortağı için artırılmış limitler, sabit kod yerine yapılandırmayla kaydedilir.

Ayrıca sınırı aşan taleplere ne olacağına da karar verin. Bazı API’ler az sayıdaki ekstra istekleri reddetmek yerine kısa süreliğine sıraya koyar, bu da kısa süreli ani artışları düzeltir. Diğerleri, ödemeler gibi temel uç noktalara, analitik gibi daha az kritik olanlara göre öncelik verir, böylece sistem baskı altındayken önemli trafik akmaya devam eder.

Son sözler

İyi oran sınırlaması, API ile müşteri arasındaki bir sözleşmedir. Sunucu, genellikle bir token kovası veya kayan pencere gibi adil bir algoritma seçer ve sınırlarını 429 ve Yeniden Dene-Sonra ile net bir şekilde açıklar. Müşteri bu sinyallere saygı duyar ve heyecanla geri çekilir. API anahtarı başına cömert sınırlarla başlayın, gerçek kullanımı izleyin ve yalnızca ihtiyacınız olduğu yerde sıkılaştırın.

Sık sorulan sorular

Öğrenmeye devam et