Cache-Control — mi ez, direktívák és a gyűrűtés kezelése

Mi az a Cache-Control?

Cache-Control — egy HTTP fejléc, amelyet a HTTP/1.1 (RFC 7234) szabványosított, és amely lehetővé teszi a szerver számára, hogy megadja, hogyan és mennyi ideig gyűrűtözhetik az ügyfelek, proxyközvetítők és CDN-ek a választ. Az Expires-től (HTTP/1.0) eltérően a Cache-Control direktívákat használ — szöveges parancsokat, amelyeket vesszővel köt össze: Cache-Control: public, max-age=3600, must-revalidate. A fejléc precíz irányítást biztosít a gyűrűtési lánc minden egyes láncszeme felett.

A gyűrűtés a web és a mobilalkalmazások teljesítményének egyik alapvető mechanizmusa. Nélküle minden felhasználói kérés közvetlenül a szerverhez menne, túlzott terhelést és késleltetést okozva. A Cache-Control három gyűrűtési szintet határoz meg: böngésző/alkalmazás (private cache), proxyközvetítő szerverek (shared cache) és CDN (distributed cache). Minden szint a maga módján értelmezi a direktívákat.

A Cache-Control helytelen beállítása a teljesítményproblémák egyik leggyakoribb oka. A túlzottan agresszív gyűrűtés miatt a felhasználók elavult adatokat látnak. A túl gyenge gyűrűtés túlzott szerverkérésekhez és lassú betöltéshez vezet. Az Akamai (2025) szerint a Cache-Control optimalizálása statikus tartalomhoz 70-90%-kal csökkenti a szerverterhelést, és 40-60%-kal javítja a betöltési időt a mobil felhasználók számára.

A fejléc története

A Cache-Control a HTTP/1.1 (RFC 2616, 1999) részeként jelent meg az Expires helyettesítéseként. Az Expires alapvető problémával küzdött: abszolút dátumot használt, amely a szerver és az ügyfél időzónájától függött. A Cache-Control ezt a problémát a relatív időre való áttéréssel oldotta meg (max-age másodpercekben a válasz kézhezvételétől számítva). Később az RFC 7234 (2014) új direktívákat adott hozzá: immutable a statikusokhoz, stale-while-revalidate és stale-if-error a késleltetett ellenőrzéshez.

Cache-Control direktívák

A Cache-Control több mint 10 direktívát tartalmaz, három csoportba osztva: kérés direktívák (ügyfél → szerver), válasz direktívák (szerver → ügyfél) és kiterjesztések. A gyakorlatban a mobilfejlesztésben 6-7 alapvető válasz direktívát használnak, amelyek a gyűrűtési forgatókönyvek 95%-át lefedik. Vizsgáljuk meg mindegyiket példákkal és ajánlásokkal.

max-age — a legfontosabb direktíva. Megtiltja az ügyfélnek, hogy kérést küldjön a szervernek egy meghatározott ideig. Statikusokhoz (CSS, JS, képek) a max-age általában 1 naptól 1 évig terjed. API-válaszokhoz — 0 másodperctől (mindig friss adatok) 5-10 percig (referenciaadatok). s-maxage lehetővé teszi különböző élettartam beállítását a CDN és a böngésző számára: a CDN 1 napig, a böngésző 1 óráig tárolja a példányt.

no-cache vs no-store

Ezt a két direktívát gyakran összekeverik. A no-cache nem tiltja a gyűrűtést — feltételes kéréssel (If-Modified-Since vagy If-None-Match) ellenőrzést követel meg a gyűrűtárban tárolt példány minden használatakor. Ha a szerver 304-es választ ad — az ügyfél használja a gyűrűtárat. Ha 200-at — frissíti. A no-store viszont teljesen megtiltja a válasz tárolását bármilyen gyűrűtárban, beleértve a lemezt és a memóriát is. A no-store-t csak érzékeny adatokhoz használja — tokenek, fizetési adatok, személyes dokumentumok.

Cache-Control vs Expires

Az Expires fejléc (HTTP/1.0) szintén jelzi az erőforrás élettartamát, de abszolút dátumot használ: Expires: Thu, 03 Jul 2026 12:00:00 GMT. A Cache-Control max-age — relatív idő a válasz pillanatától. A különbség kritikus az elosztott rendszerek számára: ha a szerver és az ügyfél különböző időzónában van, az Expires tévesen értelmezhető. A Cache-Control-nak nincs ez a problémája — 3600 másodperc mindig 3600 másodperc.

Amikor mindkét fejléc jelen van, a Cache-Control elsőbbséget élvez az Expires-szel szemben. Ezt az RFC 7234 határozza meg: „Ha a válasz Cache-Control-t tartalmaz max-age direktívával, a címzett KÖTELES figyelmen kívül hagyni az Expires-t”. A gyakorlatban ajánlott az Expires-t nem visszaküldeni a modern kliensek számára, mivel a Cache-Control lefedi az Expires összes forgatókönyvét. A régi proxykkal és böngészőkkel való visszafelé kompatibilitás érdekében azonban mindkét fejléc visszaküldhető.

Az Expires főleg a statikus tartalomnál maradt meg az Nginx és Apache környezetben — ezek a szerverek automatikusan hozzáadják mindkét fejlécet. Ha a projektjében Expires-t talál Cache-Control nélkül, cserélje le max-age-t tartalmazó Cache-Control-ra: a gyűrűtér kezelésének pontossága nő, és az időzónától való függőség megszűnik. A migrációhoz elegendő a szervert úgy konfigurálni, hogy az Expires helyett Cache-Control-t adjon hozzá.

# Nginx: Cache-Control statikus fájlokhoz
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 30d;
    add_header Cache-Control "public, immutable, max-age=2592000";
}

# Különböző szabályzatok különböző tartalomtípusokhoz
location /api/config {
    expires -1;
    add_header Cache-Control "no-cache, must-revalidate";
}

location /api/static-data {
    expires 5m;
    add_header Cache-Control "public, max-age=300";
}

Az Nginx konfigurációban a statikus fájlokhoz (CSS, JS, képek) 30 napos Cache-Control kerül beállításra az immutable attribútummal — ez az attribútum tájékoztatja a böngészőt, hogy az erőforrás soha nem változik ezen az URL-en (verziózás hash segítségével a fájlnévben). Az API-végpontok a dinamikus adatokhoz no-cache-t, a referenciaadatokhoz pedig public-ot használnak rövid max-age-dzsel — gyakran kért és ritkán változó listák.

Gyűrűtés mobilalkalmazásokban

A mobilalkalmazásokban a Cache-Control különleges szerepet játszik a mobilhálózatok korlátozásai miatt: magas késleltetés, instabil kapcsolat, forgalmi korlátok. A megfelelő gyűrűtés lehetővé teszi a felhasználó számára, hogy az adatokat azonnal, akár offline is lássa, és a háttérben frissítse azokat. Az Androidon az OkHttp és az iOS-en az URLSession beépített gyűrűtési rendszerekkel rendelkezik, amelyek figyelembe veszik a Cache-Control-t.

OkHttp a CacheInterceptor-t használja, amely kiolvassa a Cache-Control-t a válaszból és automatikusan kezeli a gyűrűtést. Ha a szerver Cache-Control: max-age=3600-at küld vissza, az OkHttp egy óráig nem küld kérést a szervernek. A max-age lejárta után az OkHttp feltételes kérést küld If-Modified-Since és If-None-Match értékekkel. A gyűrűtár beállítása az OkHttp-ban: OkHttpClient.Builder().cache(Cache(directory, maxSize)).

fun createCachedClient(cacheDir: File): OkHttpClient {
    return OkHttpClient.Builder()
        .cache(Cache(cacheDir, 10L * 1024 * 1024))
        .addNetworkInterceptor { chain ->
            val response = chain.proceed(chain.request())
            response.newBuilder()
                .header("Cache-Control",
                    "public, max-age=300")
                .removeHeader("Pragma")
                .build()
        }
        .build()
}

A kód létrehoz egy OkHttpClient 10 MB gyűrűtárral és felülírja a Cache-Control-t NetworkInterceptor segítségével. Ha a szerver nem küld vissza Cache-Control-t vagy Expires-t használ, az interceptor hozzáadja a public, max-age=300 (5 perc) értéket. Az interceptor eltávolítja az elavult Pragma fejlécet (HTTP/1.0) a kompatibilitás érdekében. Ugyanezen séma szerint működik a gyűrűtés iOS-en az URLCache.shared-en keresztül a memoryCapacity és diskCapacity beállításokkal.

Offline mód és stale-while-revalidate

A stale-while-revalidate direktíva lehetővé teszi a felhasználó számára, hogy elavult gyűrűtárat (stale) lásson, miközben az alkalmazás a háttérben friss adatokat tölt be. Ez azonnali válaszhatást eredményez: a felhasználó azonnal látja a tartalmat, és egy másodperc múlva az frissülésre kerül. Az OkHttp 3.10-es verziótól és az iOS 14+-es URLCache támogatja. Példa: Cache-Control: max-age=3600, stale-while-revalidate=300 — 1 óra aktuális gyűrűtár, majd 5 perc elavult gyűrűtár megjelenítése háttérfrissítéssel.

Példák a Cache-Control beállítására

A különböző erőforrástípusok eltérő gyűrűtési stratégiákat igényelnek. Tekintsük át az optimális konfigurációkat a mobilfejlesztés tipikus forgatókönyveihez. A hash-t tartalmazó fájlnévvel rendelkező statikus tartalomhoz (bundle.abc123.js) akár 1 éves max-age is beállítható immutable-lal. A ritkán frissülő API listákhoz (katalógusok, kategóriák) — max-age 5 perctől 1 óráig stale-while-revalidate-val.

Fontos megjegyezni a biztonságot: a felhasználó személyes adatait tartalmazó válaszokhoz mindig private-ot állítson be. E direktíva nélkül egy nyilvános proxy (pl. vállalati) eltárolhatja a választ a gyűrűtárban, és átadhatja egy másik felhasználónak. Hitelesítési tokenek és fizetési információk esetén használjon no-store-t — még a privát gyűrűtár sem mentheti ezeket az adatokat lemezre.

Gyűrűtés hibakeresése

Az Age fejléc (hány másodpercig tárolódott a gyűrűtár) és az X-Cache (hit/miss a CDN-nél) segítségével ellenőrizheti a Cache-Control helyességét. A böngészőben — a Network fül, a Size oszlop „from disk cache” vagy „304 Not Modified” értéket mutat. Ha az erőforrásnak gyűrűténődnie kellene, de minden alkalommal betöltődik — ellenőrizze, hogy a szerver nem adja-e hozzá a Cache-Control: no-cache vagy Pragma: no-cache fejléceket az Ön direktíváihoz.