Először is, mi a gyorsítótár?
Általánosságban elmondható, hogy a gyorsítótár (kiejtve: "készpénz") egyfajta adattár. Gondolhat egy tárolóra, mint egy tárolóra. A katonaságban ez fegyverek, élelmiszerek és egyéb felszerelések tárolása lenne a küldetés folytatásához.
A számítástechnikában ezeket a "kellékeket" erőforrásoknak nevezik, ahol az erőforrások szkriptek, kódok és dokumentumtartalmak. Ez utóbbit néha konkrétabban "eszközöknek" nevezik, mint például szöveg, statikus adatok, média és hiperhivatkozások, de itt csak az erőforrások kifejezést használom .
A gyorsítótár és más típusú tárak közötti különbségtétel
A gyorsítótár elsődleges célja a weboldal-erőforrások visszakeresésének felgyorsítása, az oldalak betöltési idejének csökkentése. A gyorsítótár másik kritikus szempontja annak biztosítása, hogy viszonylag friss adatokat tartalmazzon.
Ez a cikk a gyorsítótár két elterjedt módszerével foglalkozik: a böngésző gyorsítótárazásával és a tartalomszolgáltató hálózatokkal (CDN).
A gyorsítótárak mellett más adattárak is szerepet játszanak a webarchitektúrákban; gyakran ezeket hatalmas mennyiségű adat tárolására tervezték. Ezek azonban nem annyira a visszakeresési teljesítményre koncentrálnak.
Például az Amazon Glacier olyan adattár, amelyet úgy terveztek, hogy olcsón tárolja az adatokat, de nem tudja gyorsan visszakeresni. Az SQL adatbázist viszont rugalmasnak, naprakésznek és gyorsnak tervezték, de ritkán olcsó és általában nem olyan gyors, mint egy gyorsítótár.
A böngésző gyorsítótár: memória gyorsítótár
A memória gyorsítótár az erőforrásokat helyileg tárolja azon a számítógépen, ahol a böngésző fut. Amíg a böngésző aktív, a visszakeresett erőforrásokat a számítógép fizikai memóriájában (RAM), esetleg merevlemezén tároljuk.
Később, amikor pontosan ugyanazokra az erőforrásokra van szükség a weboldal újbóli megtekintésekor, a böngésző a távoli kiszolgáló helyett a gyorsítótárból fogja kihúzni azokat. Mivel a gyorsítótár helyileg van tárolva, a gyors memóriában, az erőforrások gyorsabban beolvasódnak, és az oldal gyorsabban betöltődik.
Az erőforrás-visszakeresés sebessége a legfontosabb, de az erőforrások frissességének szükségessége is. Az elavult erőforrás elavult és lehet, hogy már nem érvényes.
A böngésző feladata annak felismerése, hogy a gyorsítótárazott erőforrások elavultak-e, és újból be kell szereznie azokat. Mivel egy weboldal tipikusan tartalmazhat erőforrásokat, a gyorsítótárban általában elavult és friss verziók keverednek.
Honnan tudja a böngésző, hogy mi az elavult a gyorsítótárban?
A válasz nem egyszerű, de két fő megközelítés létezik: gyorsítótár-törés és HTTP fejléc mezők.
gyorsítótár-letörés
A gyorsítótár-törlés egy szerveroldali technika, amely biztosítja, hogy a böngésző csak friss erőforrásokat szerezzen be. Ezt közvetett módon teszi.
Bár a gyorsítótár-törlés drámai hangzású lehet, valójában nem tesz le semmit, és nem is érinti a böngészőben már tároltakat. A gyorsítótár-törlés csak annyit tesz, hogy megváltoztatja az eredeti erőforrás URI-ját oly módon, hogy a böngésző számára úgy tűnik, hogy az erőforrás teljesen új. Mivel újnak tűnik, nem lesz a böngésző gyorsítótárában. A gyorsítótárazott erőforrás régi verziója továbbra is gyorsítótárban lesz, de végül elsorvad és meghal, soha többé nem lehet hozzájuk férni.
Tegyük fel, hogy van egy weboldalam, www.foobar.com/about.htmlamely mindent elmond a foobar.com-ról, amit valaha is szeretne tudni. Miután meglátogatta az oldalt, a böngésző gyorsítótárba helyezi azt és az ahhoz társított erőforrásokat.
Később a foobar.com webhelyet a Quxbaz vállalat megvásárolja, és a körülbelül oldal tartalma jelentős változásokon megy keresztül. A böngésző gyorsítótárában nem lesz az új tartalom, mégis úgy gondolhatja, hogy a meglévő tartalom aktuális, és soha nem próbálja meg újratölteni.
Ön, a Quxbaz webadminisztrátora mit tesz annak érdekében, hogy minden új tartalom kiszoruljon?
Mivel a böngésző az URI-ra támaszkodik az elemek megtalálásához a gyorsítótárban, ha egy erőforrás URI megváltozik, akkor olyan, mintha a böngésző még soha nem látta volna, mielőtt az erőforrást lekérné a szerverről.
Így az erőforrás-URI- www.foobar.com/about.htmlról www.foobar.com/about2.html(vagy -ra www.quxbaz.com/about.html) változtatással a böngésző nem talál az URI-hoz társított gyorsítótár-erőforrást, és teljes letöltést hajt végre a szerverről. Lehet, hogy az erőforrás lényegében megegyezik az eredetivel a régi URI alatt, de a böngésző ezt nem tudja.
Nem kell azonban megváltoztatnia az oldal nevét. Mivel az URI tartalmaz egy query string definíció, akkor adjunk hozzá egy változata paramétert az URI: www.foobar.com/about.html?v=2hef9eb1.
Ebben az esetben a v verzióparaméter újként egy új generált kivonatolási értéket állít be, amikor a tartalom megváltozik, vagy valamilyen más folyamat, például a szerver újraindítása váltja ki. A böngésző úgy látja, hogy a lekérdezési karakterlánc megváltozott, és mivel a lekérdezési karakterláncok befolyásolhatják a visszaadandó adatokat, naprakész erőforrást fog lekérni a szerverről.
Ezek a technikák nem működnek, ha a régi URI-t közvetlenül elérik egy könyvjelzőből. Hacsak a böngészőt nem utasították arra, hogy érvényesítse az URI-t az utolsó gyorsítótárazott kérelemnél (vagy a gyorsítótárazott erőforrás lejárt), nem hajt végre teljes letöltést a gyorsítótár frissítéséhez. Ezzel eljutottunk a következő témához.
HTTP fejléc mezők
Minden erőforrás-kérés tartalmaz meta-információt, amelyet fejlécnek neveznek. Ezzel szemben minden válasz fejlécinformációval is rendelkezik.
Bizonyos esetekben a böngésző látja a válasz fejléc értékeit, és megváltoztatja a megfelelő értékeket a következő kérelem fejlécekben. Ezen fejlécértékek között vannak azok, amelyek befolyásolják az erőforrás-gyorsítótárazás végrehajtását a böngészőben.
HEAD és feltételes kérések
A HEAD kérés olyan, mint egy csonka GET vagy egy POST kérés. A teljes erőforrás kérése helyett a HEAD kérés csak azokat a fejléc mezőket kéri, amelyeket egyébként teljes kérés esetén adnának vissza.
Az erőforrás fejléce általában sokkal kisebb lesz (az összes bájt számában), mint a hozzá társított erőforrás adatai (a válasz "törzse"). A fejléc információja elég informatív ahhoz, hogy a böngésző meghatározhassa az erőforrás frissességét a gyorsítótárában.
A HEAD kéréseket gyakran használják egy kiszolgáló erőforrás érvényességének ellenőrzésére (vagyis létezik-e még az erőforrás, és ha igen, frissült-e azóta, hogy a böngésző utoljára elérte?). A böngésző akkor használja a gyorsítótárában lévő tartalmat, ha a HEAD kérés jelzi, hogy az erőforrás érvényes, különben teljes GET vagy POST kérést hajt végre, és frissíti a gyorsítótárát a visszaküldött adatokkal.
Feltételes kéréssel a böngésző mezőket küld a fejlécben, amelyek leírják a gyorsítótárazott erőforrás frissességét. Ezúttal a kiszolgáló határozza meg, hogy a böngésző gyorsítótára még mindig friss-e.
Ha igen, akkor a kiszolgáló 304 választ ad vissza, csak az erőforrás fejlécének adataival, és nincs erőforrás törzs (az adatok). Ha a böngésző gyorsítótárát elavultnak találják, akkor a szerver egy teljes 200 OK választ ad vissza.
Ez a mechanizmus gyorsabb, mint a HEAD kérések használata, mivel ez kiküszöböli annak lehetőségét, hogy egy helyett két kérést kelljen kiadni.
A fentiek leegyszerűsítik azt, ami elég bonyolult lehet. A gyorsítótár sokféle finomhangolást tartalmaz, de az egészet fejlécmezőkön keresztül lehet vezérelni, amelyek közül a legfontosabb a gyorsítótár-vezérlés.
Gyorsítótár-vezérlés
Amikor válaszol egy kérésre, a kiszolgáló fejléc mezőket küld a böngészőnek, jelezve, hogy milyen viselkedésnek kell alkalmazkodnia a gyorsítótárba. Ha a következő helyre töltöm be az oldalt //en.wikipedia.org/wiki/Uniform_Resource_Identifier, a válasz ezt tartalmazza a fejlécrekordjában:
cache-control: private, s-maxage=0, max-age=0, must-revalidate privát azt jelenti, hogy csak a böngésző tárolhatja a dokumentum tartalmát.
Az s-maxage és a max-age értéke 0 . Az s-maxage érték a gyorsítótárral rendelkező proxy szerverekre vonatkozik, míg a max-age a böngésző számára készült. Önmagában a max-age beállításának az a hatása, hogy a gyorsítótárban tárolt erőforrás azonnal lejár, mégis felhasználható (még ha elavult is) az oldal újratöltésekor ugyanabban a böngésző munkamenetben.
Az elavult erőforrás lehet a HEAD kérés útján történő újbóli érvényesítés, amelyet a választól függően GET vagy POST kérés követhet. A must-revalidate direktíva utasítja a böngészőt, hogy érvényesítse a gyorsítótárazott erőforrást, ha elavult.
Mivel ebben az esetben a max-age értéke 0 , a gyorsítótárazott erőforrás azonnal elavult, miután megkapta. A két irányelv kombinációja egyenértékű az egyetlen, gyorsítótár nélküli irányelvvel .
A két beállítás biztosítja, hogy a böngésző mindig újból érvényesítse a gyorsítótárazott erőforrást, függetlenül attól, hogy ugyanabban a munkamenetben van-e vagy sem.
A gyorsítótár-vezérlésről szóló irányelvek nagyon átfogóak és időnként zavaróak - önmagukban is téma. Az irányelvek teljes dokumentált listája itt található.
E-tag
Ez egy token, amelyet a szerver küld, és a böngésző megtartja a következő kérésig. Ezt csak akkor használják, ha a böngésző tudja, hogy az erőforrás gyorsítótárának élettartama lejárt.
Az e-címkék a kiszolgáló által létrehozott kivonatértékek, amelyek gyakran az erőforrás fizikai fájlnevét és a szerveren utoljára módosított dátumot használják alapként. Az erőforrásfájl frissítésekor a módosított dátum megváltozik, és egy új kivonatérték keletkezik, és elküldésre kerül a kérelem válaszfejlécében.
A fejlécet érintő egyéb fejléccímkék
A fejléccímkék lejárnak és a legutóbb módosítottak elavultak, de a legtöbb szerver továbbra is elküldi őket a régebbi böngészőkkel való visszafelé való kompatibilitás érdekében. Egy példa:
expires: Thu, 01 Jan 1970 00:00:00 GMT last-modified: Sun, 01 Mar 2020 17:59:02 GMT Itt a lejárat nulladik dátumra van állítva (történelmileg a UNIX operációs rendszerből származik). Ez azt jelzi, hogy az erőforrás azonnal lejár, mint a max-age = 0 . A Last-modied megmondja a böngészőnek, hogy mikor történt az erőforrás legújabb frissítése, amelyet aztán használhat annak eldöntésére, hogy a gyorsítótár értéke helyett inkább újra kell-e töltenie.
A gyorsítótár frissítésének kényszerítése a böngészőből
Mi a nehéz újratöltés?
A kemény újratöltés kényszeríti az oldal összes erőforrásának újratöltését, legyen szó tartalomról, szkriptekről, stíluslapokról vagy médiáról. Nagyjából mindent, igaz?
Nos, egyes források nem feltétlenül szerepelnek egy oldalon. Ehelyett dinamikusan lehívhatók, általában miután minden kifejezetten betöltődött.
A böngésző nem tudja előre, hogy ez megtörténik, és amikor mégis megtörténik, a későbbi kérések (általában szkriptek által kezdeményezve) továbbra is az erőforrások gyorsítótárazott másolatait használják, ha rendelkezésre állnak.
Mi az a gyorsítótár és a kemény újratöltés?
Ez a művelet törli a teljes böngésző gyorsítótárát, amelynek ugyanolyan hatása van, mint egy kemény újratöltésnek, de emellett a dinamikusan betöltött erőforrásokat is be kell szereznie - elvégre nincs semmi a gyorsítótárban, így nincs más választás!
Tartalom-szállítási hálózatok: földrajzi elhelyezkedésű gyorsítótár
A CDN nem csupán gyorsítótár, de a gyorsítótár a feladatai közé tartozik. A CDN földrajzilag elosztott helyeken tárolja az adatokat, így csökken az oda-vissza út egy földrajzi böngészőbe és oda.
A böngésző kérelmeket egy közeli CDN-re irányítják, ezáltal lerövidítve a fizikai távolságra vonatkozó válaszadatokat. A CDN-ek nagy mennyiségű forgalmat is képesek kezelni, és biztonságot nyújtanak bizonyos típusú támadásokkal szemben.
A CDN erőforrásait egy Internet Exchange Point (IXP), az Internet gerincének részét képező csomópontok révén kapja meg (nagybetűvel). A kérelemirányítás beállításához lépéseket kell tenni, hogy a gazdagép kiszolgáló helyett CDN-re menjen. A következő lépés annak biztosítása, hogy a CDN tartalmazza az Ön webhelyének aktuális tartalmát.
Régen a legtöbb CDN támogatta a push módszert: egy weboldal új tartalmat juttatott el a CDN hubba, amelyet aztán földrajzilag szétszórt csomópontokba osztottak szét.
Manapság a legtöbb CDN a fent leírt (vagy hasonló) gyorsítótár-protokollokat használja 1) új erőforrások letöltésére és 2) a meglévők frissítésére. A böngésző továbbra is rendelkezik gyorsítótárával, és egyik sem változik. A CDN mindössze annyit tesz, hogy gyorsabbá teszi az új erőforrások átadását.