HTTP-gyorsítótár és CDN a gyakorlatban

Célok

A lecke végére el tudod magyarázni a Cache-Control fő direktíváit, a frissesség és az újraellenőrzés (ETag, 304) működését, meg tudod különböztetni a privát és a megosztott gyorsítótárat, és tudod, miért a rosszul beállított megosztott gyorsítótár adatvédelmi incidens lehet.

Miért kell ugyanazt újra elkérni?

Egy látogató megnyitja a kezdőoldalt: a böngésző letölti a HTML-t, a stíluslapot, a szkripteket, a logót és a fényképeket. A következő oldalon ugyanaz a logó, betűkészlet és stíluslap szerepel. Felesleges volna ezeket minden kattintásnál újra átküldeni. Ha pedig tízezer látogató ugyanazt a 200 kilobájtos képet kéri, a kiszolgáló és a hálózat értelmetlenül sok ismétlődő munkát végez. A gyorsítótár (cache) a korábbi eredményt megőrzi egy későbbi felhasználásra.

A gyorsítótár azonban nem „hazudhat” korlátlanul. Egy tegnapi hír még hasznos lehet, de egy vizsgaidőpont vagy egy készlet régi értéke kárt okozhat. A cache-tervezés ezért kompromisszum a frissesség, a sebesség, a költség és a terhelhetőség között.

Rétegek: privát és megosztott gyorsítótár

Az MDN két fajtát különböztet meg:

• Privát gyorsítótár: egy klienshez kötött, jellemzően a böngészőé. Tárolhat személyre szabott választ is (Cache-Control: private). Nagyon gyors, de csak egy felhasználót segít.
• Megosztott gyorsítótár: a kliens és a szerver között áll, és több felhasználót szolgál ki. Idetartoznak a proxyk és a kezelt gyorsítótárak (reverse proxy, CDN, service worker, lásd 4.4 és 6.6). Személyre szabott választ nem szabad itt tárolni.

Egy harmadik réteg a szerver saját (alkalmazás- vagy adat-) gyorsítótára: egy költséges lekérdezés eredménye, amit a program pár percig memóriában tart. Ennek hibája gyakran látványos: ha a tárgyfelvétel után percekig régi létszám látszik, az valószínűleg frissítési kérdés, nem „rossz internet”.

flowchart LR
    B[Böngésző-cache: privát] --> E[CDN / reverse proxy: megosztott]
    E --> A[Alkalmazás-cache]
    A --> O[Eredeti szerver és adatbázis]

Friss, elavult, újraellenőrzött

A tárolt válasz friss (fresh), amíg az életkora kisebb, mint az élettartama; utána elavult (stale). A fejlécek közlik az élettartamot:

Cache-Control: public, max-age=300

Az MDN szerint a max-age=N azt jelenti, hogy a válasz N másodpercig friss. A megosztott gyorsítótár az Age fejlécben közli, mennyi ideje van nála a válasz (RFC 9111, lásd az example.com példáját a 4.4 leckében: age: 1950). A max-age nem azt jelenti, hogy az erőforrás nem változhat, hanem azt, hogy a szerver vállalja: az adott ideig a korábbi változat elfogadható.

Ha Cache-Control nincs, a gyorsítótár akkor is tárolhat és használhat egy választ, heurisztika alapján (az MDN szerint tipikusan a Last-Modified óta eltelt idő kb. 10%-áig). Ezért mindig érdemes kifejezetten megadni a szabályt.

A fő direktívák

Direktíva	Jelentése (MDN, RFC 9111 alapján)
max-age=N	N másodpercig friss.
no-cache	Tárolható, de minden felhasználás előtt újra kell ellenőrizni a szerverrel. (Nem azt jelenti, hogy „ne tárold”.)
no-store	Nem tárolható sehol. A privát gyorsítótárban sem; nem megbízható adatvédelmi eszköz, és más előnyöket (például bfcache) is elveszít.
private	Csak az egyéni felhasználó privát gyorsítótára tárolhatja.
public	Akkor is tárolható, ha Authorization fejléc van a kérésben; csak szükség esetén használd.
immutable	A tartalom az élettartama alatt nem változik; a frissítés (reload) nem kell újraellenőrizzen.

Az MDN tipikus beállításai:

# Dinamikus HTML, mindig friss legyen
Cache-Control: no-cache

# Bejelentkezett felhasználó személyes oldala
Cache-Control: no-cache, private

# Soha el nem tárolandó érzékeny adat
Cache-Control: no-store

# Verziózott statikus fájl (például app.4f8a2c.js)
Cache-Control: public, max-age=31536000, immutable

Újraellenőrzés: ETag és 304

Az elavult válasz újraellenőrizhető (revalidation) feltételes kéréssel. A szerver az ETag fejlécben azonosítót ad a válasz egy adott változatához. A kliens később elküldheti az If-None-Match fejlécben: „Nálam ez az ETag-ű változat van; megváltozott?” Ha nem, a szerver 304 Not Modified választ küld, törzs nélkül, a böngésző pedig a tárolt másolatot újra frissnek tekintheti. Így van hálózati kör, de nem kell újra letölteni a tartalmat. A Last-Modified / If-Modified-Since ugyanezt a dátumokkal teszi.

Kipróbálva a kipróbáló szerveren (Cache-Control: no-cache + ETag):

$ curl -i localhost:8092/kurzusok                                 # 1. kérés
HTTP/1.1 200 OK
Content-Type: application/json
ETag: "c5b2f274e35f"
Cache-Control: no-cache

[{"id":"webprog","szabad":9}]

$ curl -i localhost:8092/kurzusok -H 'If-None-Match: "c5b2f274e35f"'   # 2. kérés
HTTP/1.1 304 Not Modified
ETag: "c5b2f274e35f"
Cache-Control: no-cache

A második válasz üres törzsű: a kliens megtudta, hogy a másolata még jó, anélkül hogy újra letöltötte volna.

Verziózott URL (cache busting)

Az MDN szerint a főoldal HTML-jét nem lehet jól gyorsítótárazni, mert a címe nem változik; ezért no-cache kell rá. A statikus erőforrásokat viszont (JavaScript, CSS, képek) úgy lehet nagyon hosszan gyorsítótárazni, ha a fájlnév tartalmazza a verziót vagy a lenyomatot: app.4f8a2c.js. Új kiadásnál új fájlnév (app.91bd77.js) keletkezik, amelyet a HTML már az új néven hivatkozik, így a régi tárolt példány senkit nem zavar. A kipróbált fejléc: Cache-Control: public, max-age=31536000, immutable (egy év).

A megosztott gyorsítótár veszélye: személyes adat kiszivárgása

Képzeljük el, hogy a Kurzuspont személyre szabott „Saját jelentkezéseim” oldala nem kap private jelölést, sőt valaki public, max-age=60 értéket állít be „a gyorsítás kedvéért”. Egy megosztott gyorsítótár (CDN vagy reverse proxy) az URL alapján tárolja a választ. Kipróbáltunk egy egyszerű megosztott gyorsítótárat, amely csak az URL-t használja kulcsként, két felhasználóval:

Origin beállítás: Cache-Control: public, max-age=60  (HIBÁS)
  Anna kéri : X-Cache: MISS   <p>Üdv, anna! Jelentkezéseid: ...anna adatai...</p>
  Béla kéri : X-Cache: HIT    <p>Üdv, anna! Jelentkezéseid: ...anna adatai...</p>   <-- Béla Anna adatát látja

Origin beállítás: Cache-Control: private  (HELYES)
  Anna kéri : X-Cache: MISS   <p>Üdv, anna! ...</p>
  Béla kéri : X-Cache: MISS   <p>Üdv, bela! ...</p>

Az első esetben Béla Anna adatait kapta, mert a megosztott gyorsítótár az első kérés válaszát mindenkinek odaadta. Ez adatvédelmi incidens (9.6), amelynek oka egyetlen hibás fejléc volt. Az MDN is hangsúlyozza: a személyre szabott választ private-tal kell megjelölni (a Vary a cookie-ra nem megoldás), és a megosztott gyorsítótárak az azonos, egyidejű kéréseket egy kéréssé is összevonhatják, ami személyre szabott tartalomnál tovább rontja a helyzetet.

A Vary fejléc külön gyorsítótár-bejegyzést ír elő a megadott kérésfejlécek értéke szerint (például Vary: Accept-Language). Az MDN a Vary: User-Agent használatát nem javasolja, mert túl sok változatot hoz létre.

CDN a gyakorlatban: edge-gyorsítótár

A CDN-t a 4.4 lecke mutatta be. A gyorsítótár szempontjából a CDN megosztott gyorsítótár, amely a felhasználóhoz közeli csomópontokon (edge) tárol. A válaszok életkora (Age) és a találat jelzése (az example.com válaszában cf-cache-status: HIT) mutatja, hogy a válasz a gyorsítótárból érkezett. A CDN előnye feltételes: statikus, nyilvános, verziózott fájloknál a legnagyobb, személyre szabott vagy adatbázis-igényes válasznál nem old meg semmit, ha a lassúság az origin alkalmazásban keletkezik.

A földrajzi távolság számít (4.6), mert a jel nem teleportál, de a CDN azért is hasznos, mert az eredeti szervert védi a tömeges terheléstől: egy népszerű bejelentés idején az edge csomópontok sok azonos kérést elnyelnek. A CDN ilyenkor is lehet hasznos TLS-lezárásra vagy támadások szűrésére, de a dinamikus üzleti döntést (jogosultság, 7.4) nem veheti át gondolkodás nélkül.

Érvénytelenítés

Az MDN megjegyzése: a közbülső gyorsítótárakban már eltárolt válaszokat nem lehet „visszavonni”. Ha egy hibás fájlt javítani kell, kockázatos ugyanarra az URL-re újat tölteni (egyesek még a régit láthatják). Biztosabb új URL-t adni (például tajekoztato-2026-09-v2.pdf), vagy a CDN érvénytelenítési (purge) funkcióját használni, és gyakran változó erőforrásnál no-cache-t adni, hogy a szerver kezében maradjon az irányítás.

Végigvezetett példa: a Kurzuspont gyorsítótár-szabályai

Erőforrás	Szabály	Indok
app.4f8a2c.js, stilus.9b1e.css, a logó	public, max-age=31536000, immutable	Verziózott fájlnév: új kiadásnál új URL.
Szabályzat PDF-ben (Portable Document Format, szabalyzat-2026-09.pdf)	public, max-age=86400	Kiadás után nem változik; javításkor új név.
Kurzusleírás (nyilvános HTML)	public, max-age=300 + ETag	Ritkán változik, öt perc eltérés elfogadható.
/kurzusok API (nyilvános adat)	no-cache + ETag	Mindig ellenőrizzük, de a 304 olcsó.
„Saját jelentkezéseim”	private, no-cache	Személyes adat: megosztott gyorsítótárba nem kerülhet.
Fizetési oldal és válaszai	no-store	Érzékeny, visszafordíthatatlan művelet.
Szabad helyek száma	nincs gyorsítótár / pár másodperc	Élő adat; a szerver dönt (5.5, 6.5).

A jó megoldás nem az, hogy „mindent kikapcsolunk”, hanem hogy a tartalom természetéhez választunk szabályt.

Gyakori tévhitek

Állítás	Pontosítás
„A cache mindig gyorsabb, tehát mindent tároljunk.”	Személyes, érzékeny vagy gyorsan változó válasznál a régi adat veszélyes.
„A no-cache azt jelenti, hogy ne tárolja.”	Azt jelenti: tárolhatja, de használat előtt újra kell ellenőrizni. A tiltás a no-store.
„Ha feltöltöttem az új fájlt, mindenki azonnal azt látja.”	Csak ha a régi másolatok szabályai, az érvénytelenítés vagy az új URL ezt biztosítja.
„A CDN minden oldalt felgyorsít.”	A személyre szabott, adatbázis-igényes válasz lassúságát nem oldja meg.
„A gyorsítótár csak teljesítményoptimalizálás.”	Adatkezelési szabály: a helyességet és az adatvédelmet is érinti.

Röviden

• A privát gyorsítótár egy klienst, a megosztott több felhasználót szolgál; személyes válasz csak privátba kerülhet.
• A válasz a max-age ideig friss, utána újraellenőrizhető ETag/If-None-Match alapján; a 304 törzs nélküli, olcsó válasz.
• no-cache = újraellenőrzés használat előtt; no-store = ne tárold.
• Verziózott fájlnévvel a statikus erőforrás egy évre is gyorsítótárazható.
• A hibás public fejléc a kipróbált példán Béla számára kiadta Anna adatait.

Ellenőrző kérdések

1. Mi a különbség a no-cache és a no-store között?
2. Mit csinál a 304 Not Modified, és miért olcsó?
3. Miért veszélyes a public, max-age=60 egy személyre szabott oldalon?
4. Hogyan lehet egy statikus fájlt egy évre gyorsítótárazni úgy, hogy az új kiadás mégis azonnal érvényesüljön?

Tanulási források

• HTTP caching (MDN) — a Cache-Control, a frissesség, az újraellenőrzés, a verziózott URL, angolul.
• HTTP Caching, RFC 9111 — a hivatalos szabvány (Age, Cache-Control).