Hva er bufrede data? Hva betyr Clear Cache og hva gjør det?

Først, hva er en cache?

Generelt sett er en cache (uttalt "kontanter") en type lager. Du kan tenke på et depot som et lagringsdepot. I militæret ville dette være å holde våpen, mat og andre forsyninger som trengs for å gjennomføre et oppdrag.

I informatikk kalles disse "forsyninger" ressurser, der ressursene er skript, kode og dokumentinnhold. Sistnevnte blir noen ganger mer spesifikt referert til som "eiendeler" som tekst, statiske data, media og hyperkoblinger, men her bruker jeg bare det ene begrepet ressurser .

Skillet mellom en cache og andre typer arkiver

Et hurtigbuffers hovedformål er å fremskynde henting av nettsidens ressurser, redusere sidetiden. Et annet kritisk aspekt ved en cache er å sikre at den inneholder relativt ferske data.

Denne artikkelen vil dekke to vanlige metoder for hurtigbufring: nettleserbuffering og innholdsleveringsnettverk (CDN).

Foruten cacher, spiller andre arkiver inn i nettarkitekturer; ofte er disse designet for å inneholde enorme mengder data. De er imidlertid ikke like fokusert på gjenvinningsytelse.

For eksempel er Amazon Glacier et datalager som er designet for å lagre data billig, men ikke hente dem raskt. En SQL-database er derimot designet for å være fleksibel, oppdatert og rask, men er sjelden billig og vanligvis ikke så rask som en cache.

Nettleserbufferen: en minnebuffer

En minnebuffer lagrer ressurser lokalt på datamaskinen der nettleseren kjører. Mens nettleseren er aktiv, vil hentede ressurser bli lagret på datamaskinens fysiske minne (RAM), og muligens også på harddisken.

Senere, når nøyaktig samme ressurser er nødvendig når du besøker en webside på nytt, vil nettleseren trekke dem fra hurtigbufferen i stedet for den eksterne serveren. Siden hurtigbufferen er lagret lokalt, i raskt minne, blir disse ressursene hentet raskere, og siden lastes raskere.

Hurtighet med ressursinnhenting er avgjørende, men det er også nødvendigheten av at ressursene er friske. En foreldet ressurs er en som er foreldet og kanskje ikke lenger er gyldig.

En del av jobben til nettleseren er å identifisere hvilke bufrede ressurser som er foreldede, og hente de som er. Siden en webside vanligvis har ressurser, vil det vanligvis være en blanding av foreldede og ferske versjoner i hurtigbufferen.

Hvordan vet nettleseren hva som er foreldet i hurtigbufferen?

Svaret er ikke enkelt, men det er to hovedtilnærminger: cache-busting og HTTP header-felt.

cache-busting

Italienere

Cache-busting er en server-side teknikk som sikrer at nettleseren bare henter nye ressurser. Det gjør dette indirekte.

Selv om hurtigbuffer kan høres dramatisk ut, bryter det virkelig ingenting, og berører ikke engang det som allerede er bufret i en nettleser. Alt cache-busting gjør er å endre den opprinnelige ressursens URI på en måte som gjør at det ser ut til nettleseren at ressursen er helt ny. Siden det ser nytt ut, vil det ikke være i en nettlesers cache. Den gamle versjonen av den hurtigbufrede ressursen vil fortsatt bli hurtigbufret, men til slutt vil den visne og dø, for aldri å få tilgang til den igjen.

Si at jeg har en webside www.foobar.com/about.htmlder det står alt om foobar.com som du noen gang vil vite. Når du har besøkt denne siden, blir den og ressursene som er knyttet til den, bufret av nettleseren.

Senere blir foobar.com kjøpt ut av Quxbaz-konsernet, og innholdet på om siden gjennomgår betydelige endringer. Nettleserens cache har ikke det nye innholdet, men det kan likevel tro at innholdet den har er oppdatert og vil aldri prøve å hente det tilbake.

Hva gjør du, Quxbaz nettadministrator, for å sikre at alt nytt innhold blir presset ut?

Siden nettleseren er avhengig av URI for å finne elementer i hurtigbufferen, hvis URI for en ressurs endres, er det som om nettleseren aldri har sett den før den henter den ressursen fra serveren.

Dermed, ved å endre ressurs-URI fra www.foobar.com/about.htmltil www.foobar.com/about2.html(eller til www.quxbaz.com/about.html), vil nettleseren ikke finne noen cache-ressurs tilknyttet den URI-en, og gjøre en full henting fra serveren. Ressursen kan være i det vesentlige den samme som originalen under den gamle URI, men nettleseren vet ikke det.

Du trenger ikke å endre sidenavnet. Siden URI per definisjon også inneholder en spørringsstreng, kan du legge til en versjonsparameter i URI : www.foobar.com/about.html?v=2hef9eb1.

I dette tilfellet, er versjonen parameteren v er satt ny en ny generert hash-verdi når innholdet endres, eller blir utløst av en annen prosess, slik som en server omstart. Nettleseren ser at spørringsstrengen er endret, og fordi spørringsstrenger kan påvirke det som skal returneres, vil den hente en oppdatert ressurs fra serveren.

Ingen av disse teknikkene fungerer hvis den gamle URI er direkte tilgjengelig fra et bokmerke. Med mindre nettleseren ble bedt om å revidere URI på den siste hurtigbufrede forespørselen (eller den hurtigbufrede ressursen utløp), vil den ikke fullstendig hente for å oppdatere hurtigbufferen. Dette bringer oss til neste tema.

HTTP-overskriftsfelt

Hver ressursforespørsel kommer med noe metainformasjon kjent som overskriften. Omvendt har hvert svar også headerinformasjon knyttet til seg.

I noen tilfeller ser nettleseren svarverdiene og endrer tilsvarende verdier i påfølgende forespørselsoverskrifter. Blant disse topptekstverdiene er de som påvirker hvordan ressursbufring utføres i nettleseren.

HEAD-forespørsler og betingede forespørsler

En HEAD-forespørsel er som en avkortet GET eller en POST-forespørsel. I stedet for å be om den komplette ressursen, ber en HEAD-forespørsel bare overskriftsfeltene som ellers ville bli returnert på en full forespørsel.

Overskriften til en ressurs vil generelt være mye mindre (i antall totale byte) enn ressursdataene som er knyttet til den ("kroppen" til svaret). Overskriftsinformasjonen er tilstrekkelig informativ til at nettleseren kan bestemme ressursens friskhet i cachen.

HEAD-forespørsler brukes ofte til å verifisere gyldigheten til en serverressurs (det vil si at ressursen fortsatt eksisterer, og i så fall er den oppdatert siden nettleseren sist fikk tilgang til den?). Nettleseren vil bruke det som ligger i hurtigbufferen hvis HEAD-forespørselen indikerer at ressursen er gyldig, ellers vil den utføre en full GET- eller POST-forespørsel og oppdatere hurtigbufferen med det som returneres.

Med en betinget forespørsel sender nettleseren felt i overskriften som beskriver friskheten til den bufrede ressursen. Denne gangen bestemmer serveren om nettleserens cache fortsatt er fersk.

Hvis det er, returnerer serveren et 304-svar med bare ressursens topptekstinformasjon, og ingen ressurskropp (dataene). Hvis nettleserens cache er bestemt for å være utdatert, vil serveren returnere hele 200 OK-svaret.

Denne mekanismen er raskere enn å bruke HEAD-forespørsler, siden den eliminerer muligheten for å måtte utstede to forespørsler i stedet for en.

Ovennevnte forenkler det som kan være en ganske komplisert prosess. Det er mye finjustering involvert i caching, men det hele styres gjennom topptekstfelter, hvorav det viktigste er cache-kontroll.

Cache-kontroll

Når du svarer på en forespørsel, vil serveren sende overskriftsfelt til nettleseren som indikerer hvilken oppførsel som skal tilpasse seg når den caches. Hvis jeg laster inn siden på //en.wikipedia.org/wiki/Uniform_Resource_Identifier, inneholder svaret dette i toppteksten:

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

privat betyr at bare nettleseren skal cache dokumentinnholdet.

s-maxage og max-age er satt til 0 . Den s-MaxAge verdi er for proxy-servere med hurtigbuffere, mens MaxAge er beregnet for leseren. Effekten av å sette max-alder alene er at bufrede ressursen utløper umiddelbart, men det kan fortsatt brukes (selv om foreldet) under siden lastes på nytt, mens i samme nettleserøkt.

En foreldet ressurs kan være forlengelse gjennom en HEAD-forespørsel, som kan følges av en GET- eller POST-forespørsel, avhengig av svaret. Den må revalidate direktiv kommandoer nettleseren for å forlenge den bufrede ressurs hvis det er uinteressant.

Siden maksalderen er satt til 0 i dette tilfellet, blir hurtigbufret ressurs straks foreldet når den er mottatt. Kombinasjonen av de to direktivene tilsvarer det enkeltdirektivet uten cache .

De to innstillingene sørger for at nettleseren alltid revaliderer den hurtigbufrede ressursen, enten den fortsatt er i samme økt eller ikke.

Retningslinjer for cache-kontroll er veldig omfattende, og til tider forvirrende - de er et tema i seg selv. En komplett dokumentert liste over direktiver finner du her.

E-tag

Dette er et token som serveren sender, og nettleseren beholder til neste forespørsel. Dette brukes bare når nettleseren vet at ressurens cache-levetid er utløpt.

E-koder er servergenererte hash-verdier, som ofte bruker ressursens fysiske filnavn og sist endrede dato på serveren som et frø. Når en ressursfil oppdateres, endres den endrede datoen, og en ny hash-verdi genereres og sendes i svarhodet til forespørselen.

Andre topptekster som påvirker hurtigbufring

Overskriftskodene utløper og sist modifiserte er alt annet enn foreldede, men sendes fortsatt av de fleste servere for bakoverkompatibilitet med eldre nettlesere. Et eksempel:

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

Her er utløpet satt til nulldatoen (historisk fra UNIX-operativsystemet). Det indikerer at ressursen utløper umiddelbart, akkurat som max-age = 0 gjør. Sist endret forteller nettleseren når den siste oppdateringen ble gjort av ressursen, som den deretter kan bruke til å bestemme om den skal hente den i stedet for å bruke hurtigbufferverdien.

Tvinge en hurtigoppdatering fra nettleseren

Hva er en vanskelig omlasting?

En hard omlasting tvinger henting av alle ressurser på en side, enten de er innhold, skript, stilark eller media. Stort sett alt, ikke sant?

Noen ressurser er kanskje ikke eksplisitt inkludert på en side. I stedet kan de hentes dynamisk, vanligvis etter at alt eksplisitt er lastet inn.

Nettleseren vet ikke på forhånd at dette vil skje, og når det skjer, vil de senere forespørslene (vanligvis initiert av skript) fortsatt bruke hurtigbufrede kopier av disse ressursene hvis de er tilgjengelige.

Hva er klar hurtigbuffer og hard innlasting?

Denne operasjonen tømmer hele nettleserbufferen, som har samme effekt som en hard innlasting, men som i tillegg fører til at også dynamisk lastede ressurser hentes - tross alt er det ingenting i hurtigbufferen, så det er ikke noe valg!

Content Delivery Networks: en geolokalisert cache

En CDN er mer enn bare en cache, men caching er en av jobbene. En CDN lagrer data på geografisk distribuerte steder slik at rundturstider til og fra en geografisk lokal nettleser reduseres.

Nettleserforespørsler blir dirigert til et nærliggende CDN, og dermed forkortet den fysiske avstandsresponsdataen må reise. CDN er også i stand til å håndtere store mengder trafikk, og gir sikkerhet mot noen typer angrep.

En CDN får sine ressurser gjennom et Internet Exchange Point (IXP), noder som er en del av ryggraden i Internett (i store bokstaver). Det er trinn å ta for å konfigurere ruteforespørsel for å gå til en CDN i stedet for vertsserveren. Det neste trinnet er å sørge for at CDN har det nåværende innholdet på nettstedet ditt.

I gamle dager støttet de fleste CDN-er push-metoden: et nettsted vil skyve nytt innhold til et CDN-hub, som deretter blir distribuert til geografisk spredte noder.

I dag bruker de fleste CDN-er hurtigbufferprotokollene beskrevet ovenfor (eller lignende) for å 1) laste ned nye ressurser, og 2) oppdatere eksisterende. Nettleseren har fortsatt cachen sin, og ingenting av det endres. Alt en CDN gjør er å gjøre disse overføringene av nye ressurser raskere.