Hvad er cachelagrede data? Hvad betyder Clear Cache, og hvad betyder det?

For det første, hvad er en cache?

Generelt er en cache (udtalt "kontant") en type arkiv. Du kan tænke på et lager som et lagerlager. I militæret ville dette være at holde våben, mad og andre forsyninger, der var nødvendige for at udføre en mission.

I datalogi kaldes disse "forsyninger" ressourcer, hvor ressourcerne er scripts, kode og dokumentindhold. Sidstnævnte kaldes undertiden mere specifikt som "aktiver" såsom tekst, statiske data, medier og hyperlinks, men her bruger jeg bare det ene udtryk ressourcer .

Sondringen mellem en cache og andre typer arkiver

En caches primære formål er at fremskynde hentningen af ​​websidens ressourcer og reducere sidens indlæsningstid. Et andet kritisk aspekt ved en cache er at sikre, at den indeholder relativt friske data.

Denne artikel dækker to udbredte metoder til caching: browser-caching og Content Delivery Networks (CDN'er).

Udover cacher kommer andre arkiver ind i webarkitekturer; ofte er disse designet til at rumme enorme mængder data. De er dog ikke så fokuserede på hentningspræstationer.

For eksempel er Amazon Glacier et datalager, der er designet til at gemme data billigt, men ikke hente dem hurtigt. En SQL-database er derimod designet til at være fleksibel, opdateret og hurtig, men er sjældent billig og normalt ikke så hurtig som en cache.

Browser-cachen: en hukommelsescache

En hukommelsescache gemmer ressourcer lokalt på den computer, hvor browseren kører. Mens browseren er aktiv, vil hentede ressourcer blive gemt på computerens fysiske hukommelse (RAM) og muligvis også på harddisken.

Senere, når nøjagtigt de samme ressourcer er nødvendige, når du besøger en webside igen, trækker browseren dem fra cachen i stedet for fjernserveren. Da cachen er gemt lokalt i hurtig hukommelse, hentes disse ressourcer hurtigere, og siden indlæses hurtigere.

Hastighed ved ressourceudtagning er afgørende, men det er også nødvendigheden af, at ressourcerne er friske. En forældet ressource er forældet og muligvis ikke længere gyldig.

En del af jobbet i browseren er at identificere, hvilke cachelagrede ressourcer der er forældede, og hente dem der er. Da en webside typisk har mange ressourcer, vil der normalt være en blanding af uaktuelle og friske versioner i cachen.

Hvordan ved browseren, hvad der er uaktuelt i cachen?

Svaret er ikke simpelt, men der er to hovedtilgange: cache-busting og HTTP-headerfelter.

cache-busting

Italienere

Cache-busting er en server-side teknik, der sikrer, at browseren kun henter nye ressourcer. Det gør det indirekte.

Mens cache-busting måske lyder dramatisk, bryder det virkelig ikke noget og rører ikke engang det, der allerede er cache i en browser. Alt cache-busting gør er at ændre den oprindelige ressource URI på en måde, der får det til at se ud til browseren, at ressourcen er helt ny. Da det ser nyt ud, vil det ikke være i en browsers cache. Den gamle version af den cachelagrede ressource vil stadig blive cachelagret, men til sidst vil den visne og dø for aldrig at få adgang til den igen.

Sig, at jeg har en webside, www.foobar.com/about.htmlder siger alt om foobar.com, som du nogensinde vil vide. Når du besøger denne side, cachelagres den og de ressourcer, der er knyttet til den, af browseren.

Senere er foobar.com købt ud af Quxbaz-selskabet, og sidens indhold gennemgår betydelige ændringer. Browserens cache har ikke det nye indhold, men alligevel tror det muligvis stadig, at det indhold er aktuelt og vil aldrig forsøge at hente det igen.

Hvad gør du, Quxbaz webadministrator, for at sikre, at alt nyt indhold skubbes ud?

Da browseren er afhængig af URI for at finde emner i cachen, hvis URI for en ressource ændres, er det som om browseren aldrig har set det før det henter den ressource fra serveren.

Ved at ændre ressource-URI fra www.foobar.com/about.htmltil www.foobar.com/about2.html(eller til www.quxbaz.com/about.html) finder browseren ikke nogen cache-ressource, der er knyttet til den URI, og foretager en fuld hentning fra serveren. Ressourcen kan være stort set den samme som originalen under den gamle URI, men browseren ved det ikke.

Du behøver dog ikke ændre sidens navn. Da URI også omfatter en søgestrengen per definition, kan du tilføje en version parameter til URI: www.foobar.com/about.html?v=2hef9eb1.

I dette tilfælde er versionsparameteren v indstillet ny, en ny genereret hash-værdi, når indholdet ændres, eller udløses af en anden proces, såsom en servergenstart. Browseren ser, at forespørgselsstrengen er ændret, og fordi forespørgselsstrenge kan påvirke, hvad der returneres, henter den en opdateret ressource fra serveren.

Ingen af ​​disse teknikker fungerer, hvis den gamle URI er direkte tilgængelig fra et bogmærke. Medmindre browseren blev bedt om at revalidere URI på den sidste cachelagrede anmodning (eller den cachelagrede ressource udløb), udfører den ikke fuldstændig for at opdatere dens cache. Dette bringer os til det næste emne.

HTTP-headerfelter

Hver ressourceanmodning kommer med nogle metaoplysninger kendt som header. Omvendt har hvert svar også tilknyttet headeroplysninger.

I nogle tilfælde ser browseren svarets headerværdier og ændrer tilsvarende værdier i efterfølgende anmodningsoverskrifter. Blandt disse headerværdier er dem, der påvirker, hvordan ressourcecaching udføres i browseren.

HEAD-anmodninger og betingede anmodninger

En HEAD-anmodning er som en afkortet GET eller en POST-anmodning. I stedet for at anmode om den komplette ressource anmoder en HEAD-anmodning kun om overskriftsfelterne, der ellers ville blive returneret på en fuld anmodning.

Overskriften på en ressource vil generelt være meget mindre (i antal bytes i alt) end de ressourcedata, der er knyttet til den ("kroppen" i svaret). Overskriftsinformationen er tilstrækkelig informativ til, at browseren kan bestemme ressourcens friskhed i dens cache.

HEAD-anmodninger bruges ofte til at verificere gyldigheden af ​​en serverressource (det vil sige, eksisterer ressourcen stadig, og er den i så fald opdateret, siden browseren sidst fik adgang til den?). Browseren bruger hvad der er i cachen, hvis HEAD-anmodningen angiver, at ressourcen er gyldig, ellers udfører den en fuld GET- eller POST-anmodning og opdaterer dens cache med det, der returneres.

Med en betinget anmodning sender browseren felter i overskriften, der beskriver friskheden af ​​dens cachelagrede ressource. Denne gang bestemmer serveren, om browserens cache stadig er frisk.

Hvis det er tilfældet, returnerer serveren et 304-svar med kun ressourceens headeroplysninger og ingen ressourceorgan (dataene). Hvis browserens cache er bestemt for at være forældet, returnerer serveren et fuldt svar på 200 OK.

Denne mekanisme er hurtigere end at bruge HEAD-anmodninger, da den eliminerer muligheden for at skulle udstede to anmodninger i stedet for en.

Ovenstående forenkler, hvad der kan være en ret kompliceret proces. Der er meget finjustering involveret i caching, men det hele styres gennem headerfelter, hvoraf det vigtigste er cache-kontrol.

Cache-kontrol

Når du svarer på en anmodning, sender serveren overskriftsfelter til browseren, der angiver, hvilken adfærd der skal tilpasses ved cache. Hvis jeg indlæser siden kl. //en.wikipedia.org/wiki/Uniform_Resource_Identifier, Indeholder svaret dette i dets overskrift:

cache-control: private, s-maxage=0, max-age=0, must-revalidate 

privat betyder, at kun browseren skal cache dokumentindholdet.

s-maxage og max-age er indstillet til 0 . Den s-maxage værdi for proxy-servere med caches, hvorimod maxage er beregnet til browseren. Effekten af ​​at indstille maksimal alder alene er, at den cachelagrede ressource udløber med det samme, men alligevel kan den stadig bruges (selvom den er uaktuel) under sideindlæsning, mens den er i samme browsersession.

En forældet ressource kan være forlængelse gennem en HEAD-anmodning, som muligvis efterfølges af en GET- eller POST-anmodning, afhængigt af svaret. Direktivet om must-validering kommanderer browseren til at revalidere den cachelagrede ressource, hvis den er uaktuel.

Da max-age er indstillet til 0 i dette tilfælde, er den cachelagrede ressource straks uaktuel, når den først er modtaget. Kombinationen af ​​de to direktiver svarer til det enkelte direktiv uden cache .

De to indstillinger sikrer, at browseren altid genvaliderer den cachelagrede ressource, uanset om den stadig er i den samme session eller ej.

Direktiver om cache-kontrol er meget omfattende og til tider forvirrende - de er et emne i sig selv. En komplet dokumenteret liste over direktiver kan findes her.

E-tag

Dette er et token, som serveren sender, og browseren bevarer indtil den næste anmodning. Dette bruges kun, når browseren ved, at ressourceens cache-levetid er udløbet.

E-tags er servergenererede hash-værdier, som ofte bruger ressourcens fysiske filnavn og sidst ændrede dato på serveren som et frø. Når en ressourcefil opdateres, ændres den ændrede dato, og der genereres en ny hash-værdi og sendes i svaroverskriften til anmodningen.

Andre header-tags, der påvirker caching

Overskriftstags udløber og sidst modificerede er alt forældede, men sendes stadig af de fleste servere for bagudkompatibilitet med ældre browsere. Et eksempel:

expires: Thu, 01 Jan 1970 00:00:00 GMT last-modified: Sun, 01 Mar 2020 17:59:02 GMT 

Her er udløbet indstillet til nul-datoen (historisk fra UNIX-operativsystemet). Det indikerer, at ressourcen udløber med det samme, ligesom max-age = 0 gør. Sidst ændret fortæller browseren, hvornår den seneste opdatering blev foretaget til ressourcen, som den derefter kan bruge til at beslutte, om den skal hente den i stedet for at bruge cacheværdien.

Tvinger en cache-opdatering fra browseren

Hvad er en hård genindlæsning?

En hård genindlæsning tvinger hentning af alle ressourcer på en side, uanset om de er indhold, scripts, typografiark eller medier. Næsten meget alt, ikke?

Nogle ressourcer er muligvis ikke eksplicit inkluderet på en side. I stedet kan de hentes dynamisk, normalt efter at alt eksplicit er indlæst.

Browseren ved ikke på forhånd, at dette vil ske, og når det sker, vil de senere anmodninger (normalt initieret af scripts) stadig bruge cachelagrede kopier af disse ressourcer, hvis de er tilgængelige.

Hvad er klar cache og hård genindlæsning?

Denne handling rydder hele browserens cache, hvilket har den samme effekt som en hård genindlæsning, men derudover får også dynamisk indlæste ressourcer hentet - når alt kommer til alt er der intet i cachen, så der er intet valg!

Content Delivery Networks: en geo-lokaliseret cache

En CDN er mere end bare en cache, men cache er et af dens opgaver. En CDN lagrer data på geografisk distribuerede steder, så rundetider til og fra en geografisk lokal browser reduceres.

Browseranmodninger dirigeres til et nærliggende CDN og derved forkorter de fysiske afstandsresponsdata, der skal rejse. CDN'er er også i stand til at håndtere store mængder trafik og yde sikkerhed mod visse typer angreb.

En CDN får sine ressourcer gennem et Internet Exchange Point (IXP), noder, der er en del af rygraden på Internettet (med store bogstaver). Der er skridt, der skal tages for at konfigurere anmodningsrute til at gå til et CDN i stedet for værtsserveren. Det næste trin er at sikre, at CDN har det aktuelle indhold på dit websted.

I gamle dage understøttede de fleste CDN'er push-metoden: et websted ville skubbe nyt indhold til et CDN-hub, som derefter blev distribueret til geografisk spredte noder.

I dag bruger de fleste CDN'er cachingprotokollerne beskrevet ovenfor (eller lignende) til 1) download nye ressourcer og 2) opdater eksisterende. Browseren har stadig sin cache, og intet af det ændres. Alt, hvad en CDN gør, er at gøre disse overførsler af nye ressourcer hurtigere.