Hız Sınırlama (Rate Limiting) Nedir?
Kısa tanım
Hız sınırlama (rate limiting), bir istemcinin belirli bir zaman aralığında yapabileceği istek sayısına üst sınır koyan tekniktir; örneğin IP adresi başına dakikada 60 istek. Sınır aşıldığında sunucu isteği reddeder, çoğunlukla 429 Too Many Requests durum kodu ve ne kadar beklenmesi gerektiğini bildiren Retry-After başlığıyla. Kaba kuvvet denemelerine ve kötüye kullanıma karşı koruma sağlar, tek bir istemcinin sistemi yavaşlatmasını önler.
Diğer adları: Rate Limiting, Rate limit, Throttling, İstek sınırlama, API limiti
Önce karar: kimi, neye göre sayacaksınız?
Bir hız sınırı üç parçadan oluşur: sayılan anahtar, izin verilen miktar ve zaman penceresi. “IP başına dakikada 60 istek” ya da “API anahtarı başına saatte 5.000 istek” birer kuraldır. Anahtar seçimi sonucu doğrudan etkiler:
- IP adresi: Giriş yapmamış trafik için tek seçenektir, ama bir şirket ağı veya operatörün paylaşımlı IP'si (CGNAT) arkasındaki yüzlerce kullanıcı aynı adresten görünebilir. IPv6'da ise tek bir kullanıcının elinde çok geniş bir adres bloğu olabilir; sayım tek adres yerine blok üzerinden yapılmalıdır.
- Kullanıcı veya API anahtarı: Kimliği belli trafikte en adil ölçüdür ve ücretli planlara göre farklı limit vermeyi kolaylaştırır.
- Endpoint: Her uç noktanın maliyeti farklıdır. Giriş formu, parola sıfırlama ve SMS gönderimi gibi hassas işlemler, ürün listelemekten çok daha sıkı sınırlanmalıdır.
RFC 6585, 429 durum kodunu tanımlarken sunucunun kullanıcıyı nasıl tanıyacağını ve istekleri nasıl sayacağını bilerek açık bırakır; bu kararlar tamamen uygulamaya aittir.
Sayma algoritmaları
| Algoritma | İşleyişi | Güçlü yanı | Zayıf yanı |
|---|---|---|---|
| Sabit pencere | Her dakika için bir sayaç tutulur, dakika dolunca sıfırlanır | Çok basit, az bellek | Pencere sınırında patlama: 12:00:59'da 60, 12:01:00'da 60 istek geçer |
| Kayan pencere (log) | Her isteğin zamanı saklanır, son 60 saniyedekiler sayılır | Kesin sonuç | Yoğun trafikte yüksek bellek tüketimi |
| Kayan pencere (sayaç) | Önceki ve şimdiki pencerenin sayaçları ağırlıklandırılarak birleştirilir | Kesine yakın, ucuz | Yaklaşık bir tahmindir |
| Token bucket | Kova sabit hızla token'la dolar, her istek bir token harcar | Kısa patlamalara izin verirken ortalamayı sınırlar | İki parametrenin (kapasite, dolum hızı) iyi ayarlanması gerekir |
| Leaky bucket | İstekler kuyruğa girer ve sabit hızla işlenir | Arka uca düzgün, öngörülebilir yük | Patlamalar gecikme olarak kullanıcıya yansır |
Örneğin kapasitesi 20, dolum hızı saniyede 5 olan bir token bucket, sayfa açılışında aynı anda gelen 20 isteği geri çevirmez ama uzun vadede saniyede 5'in üstüne çıkılmasına izin vermez. Bu yüzden API'lerde en sık tercih edilen modeldir.
Throttling ile farkı
İki terim sıklıkla birbirinin yerine kullanılsa da vurguları farklıdır. Rate limiting sınırı aşan isteği reddeder. Throttling ise isteği geciktirerek, kuyruğa alarak ya da yanıt kalitesini düşürerek trafiği yavaşlatır; leaky bucket bu anlamda bir throttling tekniğidir. Bir de kota kavramı vardır: “ayda 100.000 istek” gibi uzun dönemli toplam, saniyelik hız sınırından bağımsız olarak faturalama ve plan sınırlarını belirler.
Sınır aşıldığında doğru yanıt
HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/json
{"error": "rate_limited", "message": "Dakikalık istek sınırı aşıldı."}429 Too Many Requests yanıtı, Retry-After başlığıyla saniye cinsinden bir süre ya da bir tarih bildirebilir. Birçok API kalan hakkı X-RateLimit-Remaining gibi özel başlıklarla da gösterir; bunu standartlaştırmak için IETF'te RateLimit ve RateLimit-Policy başlıklarını tanımlayan bir taslak üzerinde çalışılıyor, ancak Ekim 2026 itibarıyla henüz RFC olmadı. İstemci tarafında doğru davranış, Retry-After'a uymak ve yeniden denemeleri üstel olarak artan, rastgele sapma (jitter) eklenmiş aralıklarla yapmaktır; aksi hâlde binlerce istemci aynı saniyede tekrar dener.
Arama motoru tarafında da bir sonucu vardır: Google'ın tarayıcıları 429'u sunucunun aşırı yüklendiğinin işareti sayar ve taramayı geçici olarak yavaşlatır. Hatalar uzun sürerse dizindeki URL'ler de sonunda düşebilir. Googlebot'u yanlışlıkla sınırlayan agresif bir kural bu yüzden SEO sorununa dönüşebilir.
Sınırı nerede uygulamalı?
Katmanlar birbirini tamamlar. CDN veya WAF kaba trafiği daha sunucuya ulaşmadan keser; nginx gibi bir reverse proxy, leaky bucket yöntemini kullanan limit_req modülüyle IP başına sınır koyabilir; kullanıcı ve plan bilgisini gerektiren kurallar ise uygulama katmanında kalır. Uygulama birden fazla sunucuda çalışıyorsa sayaçlar ortak bir yerde, genellikle Redis'te tutulmalıdır; yoksa her sunucu sınırın yalnızca bir kısmını görür. Hız sınırlama kaba kuvvet saldırılarını yavaşlatmada etkilidir, ancak büyük ölçekli bir DDoS saldırısına karşı tek başına yeterli değildir; o ölçekte trafiği ağın kenarında emen bir koruma gerekir.