Gerçekte ne yapar
Her ziyaretçi istek yapar. Rate limit şunu söyler: tek bir istemciden bu kadar saniyede bu kadar isteği kabul ederim, fazlası reddedilir. Fikrin tamamı bu — sonucu olan bir sayaç.
Değerli kılan şey asimetridir. Bir kazıyıcı, bir kimlik-doldurma script'i ya da kontrolden çıkmış bir entegrasyon, tek bir istek düzeyinde tarayıcıdan ayırt edilemez; tek isteği inceleyerek anlayamazsınız. Ama zaman içinde tamamen farklı davranırlar: insan bir sayfa okuyup dakikada birkaç bağlantıya tıklar, script yüzlerce istek yapar. Rate limiting içeriği değil **davranışı** yakalar; hiçbir imzanın tanıyamayacağı saldırıları durdurmasının sebebi budur.
Canınızı yakmayacak sayıyı seçmek
Hata, limiti sezgiyle seçmektir. Gerçek trafiğinizin zaten ne yaptığından başlayın: normal bir saatteki en yoğun meşru ziyaretçinize bakın, limiti onun rahatça üstüne koyun. Yalnızca bir botun ulaşabileceği limit işini görünmeden yapar; hevesli bir müşterinin takılabildiği limit ise kendi yarattığınız destek talebidir.
İki ayrıntı yanlış pozitiflerin çoğundan kurtarır. Birincisi, birden çok kişi tek adresi paylaşabilir — bir ofis, bir okul, bir mobil operatörün NAT'ı — yani "tek insana" göre ayarlanmış limit koca bir binayı cezalandırır. İkincisi, kendi trafiğinizi unutmayın: izleme, sağlık kontrolleri, bir iş ortağı entegrasyonu ve CI'ınız az sayıda adresten yüksek sıklıkta gelir ve yeni bir limitin ilk kırdığı meşru istemciler bunlardır.
Bilinçli olarak gevşek başlayın. Bir hafta izledikten sonra sıktığınız limit, müşteri şikâyet ettikten sonra gevşettiğinizden çok daha ucuzdur.
Her yol aynı limiti hak etmez
Site geneli tek bir sayı, kimsenin memnun olmadığı bir uzlaşmadır — gezinmeye yetecek kadar gevşek olan giriş formunda işe yaramaz, girişe yetecek kadar sıkı olan ürün sayfasını bozar.
Bir isteğin size maliyetini ve kötüye kullanımının saldırgana kazandırdığını düşünün. Giriş, parola sıfırlama ve ödeme uçları istemesi ucuz, saldırması değerlidir; en sıkı limitler onlarındır — insan dakikada kırk kez değil bir kez giriş yapar. Arama ve API uçları sunması pahalı, kazıması cazip: gerçek bir entegrasyonun ihtiyacına göre sınırlayın. Sıradan sayfalar ve statik varlıklar ucuzdur ve gerçek insanlar tarafından yoğun kullanılır; cömert limit isterler ya da hiç istemezler, çünkü CDN önbelleği onları zaten emiyordur.
cdn.com.tr'de istek limiti hem hesap genelinde hem **dağıtım kuralı bazında** ayarlanabilir; bunu pratik kılan da budur: giriş yolunuzla eşleşen sıkı bir kural, sitenin geri kalanı için daha gevşek bir kural.
Neden doğru yer edge
Uygulamanızın içindeki rate limiting çalışır — kod koşar anlamında. Ama uygulamanız bir isteği sayabildiği anda bağlantıyı çoktan kabul etmiş, bir worker'ı meşgul etmiş ve muhtemelen veritabanına dokunmuştur; saldırı, korumaya çalıştığınız kaynağı zaten harcamıştır. Sel altında limitleyicinin kendisi de çöken şeyin parçası olur.
Edge'de uygulandığında ret, istemciye yakın bir yerde, trafik origin'inize hiç ulaşmadan gerçekleşir. Sunucunuz onu hiç görmez, yani maliyet sizin değildir. Edge rate limiting'in, origin'iniz zaten zorlanırken çalışmaya devam etmesinin sebebi de budur: limit, savunduğu kaynaklarla yarışmaz.
Rate limiting vs WAF vs DDoS koruması
Bu üçü birbirinin yerine kullanılıyor ama gerçekten farklı işler yapıyorlar.
Rate limiting **sayar**. İstemcinin ne sıklıkta sorduğunu bilir, ne sorduğunu bilmez. Brute force, kazıma ve kazara dövmeyi durdurur.
WAF **inceler**. İsteği okur ve SQL enjeksiyonu, XSS ya da bilinen bir istismar gibi görünenleri engeller — tek bir kötü niyetli istek, ne kadar yavaş gelirse gelsin ilk denemesinde yakalanır.
DDoS koruması **soğurur**. Trafik, yalnızca saymanın bile sizi boğacağı kadar büyüdüğünde, hacmin birçok noktaya yayılmış ağ kapasitesiyle emilmesi gerekir.
Üçü de gerekir çünkü her biri diğerlerinin kör noktasını kapatır: sayacın geçireceği tek zekice istek, WAF'ın hiçbir sorun görmediği bin masum görünümlü istek, ve tek bir makinenin değerlendiremeyeceği bir milyon istek. cdn.com.tr'de üçü de aynı edge'in parçasıdır, tek panelden ayarlanır.
Hiçbir şeyi bozmadan devreye almak
Limiti, hiç tetiklenmeyeceğini düşündüğünüz kadar yüksek koyun, sonra izleyin. Gerçekte neyin reddedildiğine bakın: kazıyıcı ya da giriş script'iyse güvenle sıkın; kendi izlemeniz ya da bir müşterinin entegrasyonuysa, bu size bir şikâyete mal olmadan önce bir şey öğrettiniz demektir.
İstisnaları dürüst ve az tutun — izlemeniz ve bilinen iş ortağı entegrasyonları, "en yüksek sesle şikâyet eden" değil. Ve limiti yaşayan bir sayı olarak görün: trafik büyür, bir mobil uygulama çıkar, bir entegrasyon yoklama sıklığını ikiye katlar. Geçen yıl cömert olan limit, sessizce bir özelliğin bozuk hissettirmesinin sebebi olabilir.
Sık sorulan sorular
İyi bir başlangıç limiti nedir?
Evrensel bir sayı yok — gerçek kullanıcılarınızın ne yaptığına bağlı. Normal bir saatteki en yoğun meşru ziyaretçinizi ölçün, limiti rahatça onun üstüne koyun ve ancak neyin reddedildiğini izledikten sonra sıkın. Sıkı limitler giriş ve parola sıfırlama yollarına aittir, sıradan sayfalara değil.
Rate limiting gerçek müşterileri engeller mi?
Fazla sıkı ayarlanırsa engelleyebilir — özellikle birçok kişinin tek adresi paylaştığı yerlerde (ofis, okul, mobil ağ) ya da kendi izleme ve entegrasyonlarınız sık yoklama yapıyorsa. Gevşek başlayıp gözlemlenen trafiğe göre sıkmak bunun neredeyse tamamını önler.
DDoS saldırısını durdurmak için rate limiting yeter mi?
Hayır. Rate limiting, yönetilebilir sayıda istemciden gelen kötüye kullanımı halleder. Dağıtık bir saldırı, yalnızca saymanın yardımcı olamayacağı kadar çok kaynaktan trafik gönderir — bunun için origin'inizin önünde DDoS emilim kapasitesi gerekir; rate limiting arkasında daha ince işi yapar.
Bunun yerine uygulamamda mı sınırlamalıyım?
Uygulama düzeyi limitler hesap bazlı iş kuralları için yararlıdır ("bu paket günde 1000 API çağrısı alır"). Kötüye kullanım koruması içinse edge daha iyidir: istek sunucunuza ulaşmadan reddedilir, size hiçbir şeye mal olmaz ve origin'iniz baskı altındayken çalışmaya devam eder.