IP rate limiting nedir?

IP rate limiting, bir IP adresinin belirli bir süre içinde bir sunucuya gönderebileceği istek sayısını sınırlayan bir mekanizmadır. Limiti aşarsanız, sunucu isteklerinizi geçici olarak reddeder, genellikle HTTP 429 hatası ("Too Many Requests") ile. Sunucuları kötüye kullanıma, hizmet reddi saldırılarına ve otomatik veri kazımaya karşı korumak için en yaygın kullanılan araçlardan biridir.

Muhtemelen farkında olmadan zaten karşılaşmışsınızdır. Bir site birkaç başarısız giriş denemesinden sonra "Çok fazla deneme yaptınız, 5 dakika sonra tekrar deneyin" gösterdiğinde, bu rate limitingdir. Bir API dakikada belirli sayıda çağrıdan sonra hata döndürdüğünde, bu rate limitingdir. Bir arama motoru çok hızlı arama yaptığınız için sorgularınızı geçici olarak engellediğinde, bu da rate limitingdir.

Neden gerekli

Bir web sunucusunun sınırlı kaynakları vardır: CPU, bellek, bant genişliği, veritabanı bağlantıları. Her istek bu kaynakların bir kısmını tüketir. Hiçbir sınırlama olmadan, tek bir kullanıcı (veya otomatik bir betik) saniyede binlerce istek göndererek sunucuyu tekeline alabilir ve hizmeti diğer herkes için erişilemez hale getirebilir.

Rate limiting çeşitli tehdit türlerine karşı korur:

DDoS ve kaba kuvvet saldırıları. Dağıtılmış hizmet reddi saldırısı (DDoS) bir sunucuyu isteklerle boğarak kullanılamaz hale getirir. Rate limiting tek başına büyük bir DDoS saldırısını (binlerce farklı IP'den gelen) engellemek için yeterli değildir, ama tek bir IP'nin verebileceği hasarı sınırlar. Kaba kuvvet saldırıları (binlerce şifre deneme) için rate limiting ilk savunma hattıdır: dakikada 5-10 giriş denemesiyle sınırlamak saldırıyı uygulanamaz kılar.

Kötüye kullanılan kazıma ve tarama. Site içeriğini (fiyatlar, makaleler, veriler) çıkaran botlar saniyede yüzlerce istek gönderir. Rate limiting bu botları toplu çıkarmanın ekonomik olarak sürdürülemez hale geldiği noktaya kadar yavaşlatır (çok yavaş, çok fazla sunucu zamanı gerekli).

API kötüye kullanımı. Genel API'ler (hava durumu, coğrafi konum, yapay zeka, ödemeler) sağlayıcı için istek başına maliyete sahiptir. Rate limiting olmadan, bir kullanıcı orantısız kaynak tüketebilir; ister hatayla (kodundaki bir döngü) ister kasıtlı olarak. Çoğu API, API anahtarı ve IP adresi başına sınırlar koyar.

Kullanıcılar arası adalet. Kötü niyet olmasa bile, "açgözlü" bir kullanıcı (bir sayfayı dakikada 50 kez yenileyen veya kötü yazılmış bir betik) diğerlerinin deneyimini bozabilir. Rate limiting kaynakların adil paylaşımını sağlar.

Teknik olarak nasıl çalışır

Prensip basittir: sunucu her isteği bir IP adresiyle ilişkilendirir, bu IP'den belirli bir zaman penceresinde alınan istek sayısını sayar ve tanımlanan eşiği aşan istekleri reddeder. Ancak somut uygulama kullanılan algoritmaya göre değişir.

Sabit Pencere (Fixed Window). Zaman sabit aralıklara bölünür (örneğin, bir dakikalık pencereler). Sunucu her pencerede IP başına istekleri sayar. Mevcut pencerede 100 isteğe ulaşırsanız, sonraki pencere başlayana kadar diğerleri reddedilir. En basit algoritmadır ama bir kusuru vardır: bir pencerenin sonunda 100 ve bir sonrakinin başında 100 istek gönderirseniz, birkaç saniyede 200 istek göndermiş olursunuz, öngörülen limitin iki katı.

Kayan Pencere (Sliding Window). Sabit pencereler yerine, sunucu herhangi bir anda son N saniyeye bakar. Her istek kayan bir dönem üzerinden sayılır. Bu dağılımı düzleştirir ve sabit pencere sorununu ortadan kaldırır, ama sunucu tarafında daha fazla bellek ve hesaplama gerektirir.

Token Bucket (jeton kovası). Her IP'nin sabit sayıda jeton içeren bir "kovası" vardır. Her istek bir jeton tüketir. Jetonlar sabit bir hızda yenilenir (örneğin, saniyede 10). Kova boşsa istek reddedilir. Bu model kısa patlamalara (burst) izin verir: kovanız doluysa bir seferde çok sayıda istek gönderebilirsiniz, sonra yenilenmeyi beklemeniz gerekir. Hem esnek hem öngörülebilir olduğu için üretimde en çok kullanılan algoritmadır.

Leaky Bucket (sızdıran kova). İstekler bir kuyruğa (kova) girer ve sabit bir hızda (sızıntı hızı) işlenir. Kova doluysa yeni istekler reddedilir. Token Bucket'tan farklı olarak, Leaky Bucket patlamasız, kesinlikle sabit bir çıkış hızı uygular. Mükemmel düzgün bir işleme akışı istediğinizde kullanışlıdır.

Rate limiting nerede uygulanır

Rate limiting ağ altyapısının farklı seviyelerinde uygulanabilir ve pratikte genellikle öyledir: birden fazla katman üst üste biner.

Web sunucusu düzeyinde. Nginx, Apache ve çoğu web sunucusu rate limiting modülleri içerir. Nginx örneğin, limit_req direktifiyle Leaky Bucket algoritmasını kullanır. IP başına saniyedeki istek sayısını tanımlarsınız ve Nginx gerisini halleder. Temel koruma için etkilidir, ama sunucunun yine de her isteği reddetmeden önce alması ve kısmen işlemesi gerekir.

Reverse proxy veya yük dengeleyici düzeyinde. Rate limitingi uygulama sunucularının önüne koymak (Nginx veya HAProxy gibi bir reverse proxy'de veya bir yük dengeleyicide) isteklerin uygulamaya ulaşmadan engellenmesini sağlar. Kaynak açısından daha verimlidir.

CDN veya WAF düzeyinde. Cloudflare, AWS WAF veya Akamai gibi hizmetler rate limitingi ağ kenarında (edge) uygular, istek altyapınıza ulaşmadan önce bile. Hacimsel saldırılara karşı en etkili katmandır, çünkü istek kaynağına mümkün olduğunca yakın engellenir.

Uygulama düzeyinde. Uygulamanın kendisi rate limiting uygulayabilir, genellikle daha fazla ayrıntıyla: oturum açmış kullanıcı başına, endpoint başına, işlem türü başına. Örneğin, bir API dakikada 1.000 GET isteğine izin verebilir ama hesap oluşturma endpoint'inde yalnızca 10 POST isteğine, çünkü kötüye kullanılan hesap oluşturma denemeleri yaygın bir saldırı vektörüdür.

Rate limiting ile ilgili HTTP başlıkları

Bir sunucu rate limiting uyguladığında, genellikle limit bilgilerini yanıttaki HTTP başlıkları aracılığıyla iletir. Evrensel bir standart yoktur, ama en yaygın kurallar şunlardır:

X-RateLimit-Limit: geçerli zaman penceresinde izin verilen maksimum istek sayısı. X-RateLimit-Remaining: limite ulaşmadan önce kalan istek sayısı. X-RateLimit-Reset: pencerenin sıfırlanacağı ve sayacın yeniden başlayacağı an (Unix zaman damgası veya kalan saniye olarak). Retry-After: tekrar denemeden önce ne kadar bekleneceğini belirten standart bir HTTP başlığı, 429 yanıtıyla birlikte döndürülür.

Bir IETF taslağı (429 durum kodu için RFC 6585 ve daha yeni öneriler) bu başlıkları standartlaştırmaya çalışır, ama pratikte her API kendi kuralını kullanır. API tüketen bir uygulama geliştiriyorsanız, limitlerini nasıl ilettiğini öğrenmek için her zaman API belgelerini okuyun.

Neden tek başına IP her zaman yetmez

IP tabanlı rate limitingin temel bir sorunu vardır: bir IP adresi her zaman tek bir kullanıcıya karşılık gelmez.

CGNAT. Birçok mobil operatör ve bazı İSS'ler CGNAT (Carrier-Grade NAT) kullanır; yüzlerce hatta binlerce kullanıcı tek bir genel IPv4 adresini paylaşır. Bir IP'yi dakikada 100 istekle sınırlarsanız, aslında o CGNAT arkasındaki tüm kullanıcıları toplam 100 istekle sınırlamış olursunuz. Tek bir normal kullanıcı herkes için kotayı tüketebilir.

Kurumsal ve üniversite ağları. Binlerce çalışan veya öğrenci tek bir genel IP adresi (veya az sayıda adres) üzerinden internete erişebilir. IP tabanlı rate limiting onları toplu olarak cezalandırır.

VPN ve proxy'ler. VPN kullanıcıları genellikle bir IP adresini yüzlerce diğer kişiyle paylaşır. Sıkı IP tabanlı rate limiting, meşru kullanıcıları sadece bir botla aynı VPN sunucusunu kullandıkları için engelleyebilir.

Dinamik IP adresleri. Tersine, bir saldırgan IP adresini kolayca değiştirebilir (proxy havuzu, botnet veya telefonunda uçak modunu açıp kapatarak) ve IP tabanlı rate limitingi atlatabilir. Limit IP başınaysa ve saldırganın 10.000 adrese erişimi varsa, etkin limit 10.000 ile çarpılır.

Bu yüzden modern rate limiting sistemleri genellikle IP'yi diğer tanımlayıcılarla birleştirir: API anahtarı, kimlik doğrulama tokeni, tarayıcı parmak izi, oturum çerezi. IP yararlı bir kriter olmaya devam eder, ama tek başına nadiren yeterlidir.

Sınırlandığınızda ne olur

En yaygın yanıt HTTP 429 durum kodudur (Too Many Requests). Sunucu ayrıca sınırlamanın bireysel bir aşımdan ziyade genel bir aşırı yüklenmeden kaynaklanması durumunda 503 (Service Unavailable) de döndürebilir.

Bazı hizmetler erişimi tamamen engellemez, bunun yerine hizmeti düşürür: yanıtları yavaşlatır (throttling), sonuç kalitesini azaltır veya insan olduğunuzu doğrulamak için CAPTCHA ekler.

Diğer hizmetler açık bir hata döndürmeden sessizce engeller. 200 (OK) durum koduyla yanıt vermeye devam ederler ama boş veri veya düşürülmüş sonuçlar döndürürler. Bu "sessiz rate limiting" (shadow banning) sosyal ağlarda ve bazı arama motorlarında yaygındır ve botların tespit etmesini zorlaştırmak için tasarlanmıştır.

Geliştiriciler rate limitingi nasıl yönetir

API tüketen bir uygulama geliştiriyorsanız, rate limitingi düzgün yönetmeniz gerekir. Standart yöntem "exponential backoff"tur: 429 yanıtı aldığınızda, tekrar denemeden önce belirli bir süre beklersiniz ve her ardışık başarısızlıkta bu süreyi ikiye katlarsınız. Örneğin: ilk deneme 1 saniye sonra, ikinci 2 saniye sonra, üçüncü 4 saniye sonra, vb.

En iyi uygulamalar şunları içerir:

Retry-After ve X-RateLimit-Reset başlıklarını okuyarak tahmin yerine tam olarak ne zaman tekrar deneneceğini bilmek. Aynı istekleri tekrarlamamak için önbellek uygulamak. API izin verdiğinde istekleri gruplamak (batching). İstekleri toplu göndermek yerine zamana yaymak. 429 hataları birikirse durumu kötüleştirmemek için bir süre API çağrılarını durduran circuit breaker öngörmek.

Rate limiting ve gizlilik

IP tabanlı rate limiting, sunucunun istekleri IP adresine göre tanımladığı ve izlediği anlamına gelir. Bu bir kişisel veri işleme biçimidir (IP adresi birçok yargı alanında, özellikle Avrupa'da GDPR ve Türkiye'de KVKK kapsamında kişisel veri olarak kabul edilir). Rate limiting uygulayan şirketler teoride bu işlemeyi gizlilik politikalarında belirtmelidir.

Kullanıcı açısından, IP tabanlı rate limiting aynı zamanda aktivitenizin sayıldığı anlamına gelir. Gizlilik nedeniyle VPN veya proxy kullanıyorsanız, rate limiting sizi paradoks biçimde cezalandırabilir: bir IP'yi diğer kullanıcılarla paylaşırsınız ve ortak kota daha hızlı tükenir.

Rate limitingi atlatmak

IP adresini değiştirmek (VPN, dönen proxy veya mobilde uçak modu aracılığıyla) yalnızca IP'ye dayalı rate limitingi atlatmayı sağlar. Ticari kazıma hizmetleri istekleri dağıtmak ve IP başına eşiklerin altında kalmak için binlerce konut IP adresi havuzu kullanır.

Ama modern koruma sistemleri IP ile sınırlı değildir. Tarayıcı parmak izi analizi, gezinme davranışı (tıklama ritmi, fare hareketleri, sayfalarda geçirilen süre), CAPTCHA'lar ve istek kalıpları analizini birleştirerek, IP her istekte değişse bile insanları botlardan ayırır.

Rate limiting sistemleri ile atlatma teknikleri arasındaki yarış süreklidir. Bugün çalışan yöntemler yarın tespit edilebilir. Sunucu tarafındaysanız, en iyi strateji yalnızca IP'ye güvenmek yerine birden fazla koruma katmanını birleştirmektir.

Yaygın limit örnekleri

Bu limitler hizmet, fiyat planı ve bağlama göre büyük ölçüde değişir. Ücretli bir API genellikle ücretsiz plandan çok daha yüksek limitler sunar. Hassas bir endpoint (giriş, ödeme, hesap oluşturma) veri okuma endpoint'inden çok daha düşük limitlere sahiptir.

IP rate limiting, internete açık her sunucu için temel bir korumadır. Kötüye kullanımı önler, kaynakları korur ve adil erişim sağlar. Ancak CGNAT, VPN ve proxy'lerle tek başına IP giderek daha az güvenilir bir tanımlayıcıdır. Modern sistemler meşru trafiği kötüye kullanımdan ayırmak için IP'yi diğer sinyallerle birleştirir ve etkili bir koruma ile kolayca atlatılabilen basit bir filtre arasındaki farkı bu kombinasyon oluşturur.