Bir Set-Cookie başlığı cache’ini nasıl mahveder
Introducing Cache Response Rules · Alex Krivit, Anthony Turcios
Cloudflare yeni bir kural tipi duyuruyor: origin sunucusu cevap verdikten sonra, ama Cloudflare içeriği cache’e almadan önce çalışan kurallar. Ürün duyurusu ama içindeki HTTP cache anlatımı başlı başına iyi bir ders.
Foundation model şu: CDN cache’i ile origin sunucu bir çift olarak çalışır. Amaç mümkün olan her yerde cache’ten cevap vermek ve yalnızca uç (edge) cevap veremediğinde origin'e gitmek. Cache hit ratio’daki (cache hit ratio) her puan, bu iş bölümünü doğru kurmaktan geliyor. Gereksiz yere cache’e bakarsan zaten ıskalayacak bir arama boşa gider; çok az bakarsan uç katmanın emmesi gereken trafiği origin karşılar ve performans kazancı buharlaşır.
Kritik nokta: origin, cache’i yönlendirir. Önbelleklenebilir bir varlık döndürdüğünde, cevap başlıkları Cloudflare'e ne kadar süre sunabileceğini, ne zaman ve nasıl yeniden doğrulayacağını, hatta cache’e alınıp alınmayacağını söyler. Cache ancak origin'i kadar verimlidir.
Yazının çözdüğü problem tam da burada: çoğu cache uygunluk sorunu istek anında değil, origin cevap verdikten sonra ortaya çıkar. Klasik senaryo: ziyaretçi /static/app.js ister, cache ıskalar, istek origin'e gider ve origin dosyayı döndürürken cevap başlıklarının arasına sessizce bir Set-Cookie sıkışır. Her uç noktada cache’lenmesi gereken varlık, artık cache’lenemez hâle gelir.
Öne çıkanlar
- Aynı problemin varyasyonları çok: origin güvenle cache’lenebilecek varlıklara
Cache-Control: no-cachegönderir, ya da tarayıcı için doğru olan direktifleri CDN'e de yollar. - Bu başlıkları origin'in kendisinde temizlemek çoğu zaman zor, bazen imkânsız — araya giren bir katman gerekiyor.
- Yeni kurallar tam doğru anda çalışıyor: origin cevabından sonra, cache’e yazmadan önce.
Neden önemli?
Cache hit ratio, bir web sisteminin en yüksek kaldıraçlı metriklerinden biri: %70'ten %90'a çıkmak origin trafiğini üçte birine indirir. Ve bu oranı bozan şey genelde büyük bir mimari hata değil, yanlışlıkla eklenmiş tek bir başlıktır. Küçük detayların büyük sistemleri belirlemesine iyi bir örnek.
Pratikte
Bunu bugün kendi projende kontrol edebilirsin. Session yönetimi açıksa, statik kaynak isteklerine bile Set-Cookie eklenmesi çok yaygın bir hatadır. Sonuç: CDN hiçbir şeyi cache’lemez ve sebebini aylarca bulamazsın. Kontrol basit: curl -I https://siten/static/app.js çalıştır ve cevap header’larına bak. Set-Cookie görüyorsan sorun var. API’nde de aynısını yap: Cache-Control header’larını bilinçli ayarla; değişmeyen varlıklara uzun max-age, kullanıcıya özel cevaplara private, no-store. Bu ayrımı yapmamak ya performans ya da güvenlik kaybettirir.
Sözlük
- cache hit ratio
- Toplam isteklerin yüzde kaçının cache’ten karşılandığı; CDN verimliliğinin ana ölçüsü.
- origin server
- İçeriğin asıl üretildiği sunucu; CDN cache’leyemediğinde isteği buraya iletir.
- Cache-Control
- Bir cevabın ne kadar süre, kim tarafından ve nasıl cache’lenebileceğini belirten HTTP başlığı.
- revalidation
- Cache’teki kopyanın hâlâ güncel olup olmadığını origin'e sorup, güncelse tam içeriği indirmeden kullanma.