Nettleserbuffer

Nettleserbuffer [

Hver gang innholdet i en URL er nødvendig for å vise en side, sjekkes hurtigbufferen for å se om den allerede eksisterer.

Fordelen er at nettverkstrafikk og tiden det tar å laste ned alle komponenter på et nettsted er sterkt redusert. Ulempen er at dataene som er lagret i hurtigbufferen, kan være utdaterte hvis nettstedet har blitt oppdatert i mellomtiden.

Bruksområder

"Ressurs" er alt som kan hentes fra en bestemt URL. Ulike innhold kan eksistere under samme URL til forskjellige tider. Det siste kjente innholdet er tilordnet hver URL i hurtigbufferen.

Det samme konseptet for en nettleserbuffer på en brukers PC brukes også av såkalte proxy-servere for hele datanettverk , for eksempel for en bedriftssted eller et universitet ved tilkoblingspunktet til Internett eller for alle kunder til en (fysisk) telekommunikasjonsleverandør i et forsyningsområde. De leverer ofte forespurte filer (for eksempel WP -kloden ) direkte til alle tilkoblede deltakere i dette nettverket, uten først å måtte gå gjennom selve Internett.

Bufring er i utgangspunktet et alternativ for enhver protokoll som gjør ressurser tilgjengelige. I praksis brukes den imidlertid bare for HTTP / HTTPS . Hvis du ber om en nedlasting av filer med nettleseren din via FTP , vil du motta en ny versjon på dette tidspunktet; Imidlertid kan en proxy -server beholde kopier av ofte etterspurte filer. mailto: sender data og henter dem ikke. Andre protokoller for ressurser tilbyr ingen spesiell støtte for versjonsbehandling, og brukes også sjelden i dag.

Brukerkontroll

Med en nettleser har brukerne vanligvis følgende alternativer for å påvirke oppførselen til hurtigbufferen via konfigurasjonsinnstillinger eller interaktivt:

• Angi maksimal størrelse på harddiskplassen; hvis det er null, er det ingen bufring.
• Hent gjeldende side fra serveren igjen (dette vil påvirke URL -adressen som er synlig på adresselinjen, enkeltside eller grafikk).
• Hent gjeldende side og alle ressursene den inneholder (bilder, skript, stiler, etc.) (dette vil stort sett bare påvirke HTML -sider).
• Tøm hele hurtigbufferen, muligens også selektivt for alle ressurser på et bestemt domene (den nåværende siden).
• På slutten (eller alternativt i begynnelsen) av hver økt, tøm hele cachen.
• Angi maksimal alder for ressurser.

Cache -håndtering

Følgende prinsipper gjelder for nettleseren eller proxy -serveren:

• Ingen system er nødvendig for å følge noen indikasjoner på ressursens opprinnelse.
• Av interesse for et attraktivt tilbud er nettleserutviklere interessert i å evaluere informasjon om hurtigbufferhåndtering for å vise sidene både raskt og oppdatert.

Omfattende forslag ble gitt i 1997 i RFC 2068 og i 1999 i RFC 2616 , men trenger ikke å bli fullstendig implementert.

Internett server

En webserver bør gi hurtigbufferinformasjon ( metadata ) for hver enkelt ressurs for å garantere brukeren en oppdatert visning og for å oppnå lavest mulig kommunikasjonsinnsats for både brukeren og serveren.

Operatøren av webserveren drar fordel av det faktum at han ikke trenger å svare på spørsmål om uendrede ressurser og bruke datamaskin- og nettverkskapasitet til dette.

For å få hyppigheten av besøkte sider og informasjon om leserne, brukes derimot svært små innebygde biter , som er hensiktsmessig forhindret fra å bli inkludert i hurtigbufferen og tvunget til å bli ringt opp hver gang siden vises.

Versjonsidentifikasjon

For hurtigbufferhåndtering brukes en av to identifikatorer eventuelt for hver enkelt ressurs, hvis den leveres av serveren:

Tidsstempel

Banalt tidsstempel i UTC

Felt : Last-Modified

ETag ^[1]

Differensiering av vesentlig forskjellige versjoner av en ressurs når det gjelder innhold.
Kan i utgangspunktet også være et tidsstempel; men også et kontinuerlig tellet versjonsnummer eller en hash -kode .

Felt: ETag

Hvis slik informasjon mangler, vet hurtigbufferadministrasjonen bare tidspunktet for den siste vellykkede hentingen.

Metoder

Følgende metoder er tilgjengelige:

Heuristiske estimater

Cachebehandlingen bruker sine egne algoritmer for å bestemme hvilke ressurser som skal forbli og hvilke som skal fjernes. Dette brukes spesielt hvis ressursen ikke har fått passende informasjon.

• La ressurser være på ubestemt tid hvis den tillatte harddiskplassen er tilstrekkelig; slett bare på riktig måte hvis det er plassproblemer.
• Ressurser som nylig ble brukt, kan snart være nødvendige igjen. Ressurser som ikke har vært adressert på lenge må slettes.
• Ressurser som det ofte refereres til, bør beholdes. Ressurser som sjelden og ikke er etterspurt på lang tid, må slettes.
• Filstørrelse - slett veldig store ressurser som ikke har blitt brukt på lenge og som sjelden brukes totalt; legg igjen mange små ressurser i stedet.
• Stabilitet - innhold som har blitt endret flere ganger er kandidat for sletting. Ressurser som ikke har blitt endret over år og flere validitetskontroller bør beholdes hvis de brukes ofte. Korte gjenværende vilkår er en indikasjon på volatilitet, selv om den nåværende utløpet av minimum holdbarhet ikke nødvendigvis betyr at den er ubrukelig.
• POST -data i tillegg til URL -en betyr vanligvis at slike sider ikke kan hentes gjentatte ganger og vanligvis ikke lagres i hurtigbufferen. Dette vil også være ganske farlig fordi slik informasjon ofte endrer innholdet på målsiden og en nødvendig bekreftelse ikke vil bli sendt til serveren.
• Er i url på ? Når en spørring ble gjenkjent (f.eks. Under en databasespørring), hadde algoritmer opprinnelig avstått fra å lagre den, fordi en kombinasjon av spørringsparameterne resulterte i mange forskjellige nettadresser uten å bli gjenbrukt. I økende grad blir imidlertid alle sider statisk presentert av CMS i dette URL -formatet, slik at denne antagelsen ikke lenger er pålitelig.

"Utløpsdato"

Ressursen er utstyrt med en utløpsdato (tidspunkt) eller en holdbarhetsperiode etter at den har blitt forespurt (for eksempel "tre dager"), hvorfra tidspunktet for utløpet kan beregnes. ^[2]

• Enger:

• Expires: ^[3] med et bestemt tidspunkt og
• Cache-Control: max-age= ^[4] i sekunder som relativ spesifikasjon ^[5]

Eksempel: værmelding; alltid gyldig i de følgende 15 minuttene.

• Ugyldigheten til ressursen fører imidlertid ikke nødvendigvis til at den blir slettet fra hurtigbufferen, men bare en kontroll av gyldigheten, noe som kan føre til en forlengelse av gyldighetsperioden med uendret innhold.
• Hvis tiden som er angitt som Expires allerede er tidligere da spørringen ble gjort, kan denne versjonen ikke bufres. Informasjon om denne nettadressen må slettes.
• Hvis serveren ikke gir informasjon om gyldighetsperioden, kan den konkluderes fra tidspunktet for den siste endringen, om nødvendig fra oppførselen registrert av hurtigbufringen, om ressursen endres ofte eller er konstant: Hvis den sist ble endret i tre år siden, er ressursen sannsynligvis ganske stabil; hvis den er et kvarter gammel eller hvis den har endret seg to ganger den siste dagen, bør den sjekkes for aktualitet på kort varsel. Hvordan cache-styringen nøyaktig håndterer manglende metainformasjon, overlates til programmereren. Det ville være klønete og tidkrevende, så vel som nettverkskapasitet å hente en stor fil fra webserveren hver gang hvis informasjonen mangler.
• En maksimal alder kunne ha blitt spesifisert i brukerkonfigurasjonen, rundt to uker.

Ingen cache ^[6]

En ressurs kunngjør at den ikke skal oppbevares i hurtigbufferen, og at den kan nås fersk fra serveren hver gang en side åpnes.

Enger:

• Cache-Control: no-cache
• Cache-Control: max-age=0

Tradisjonelt overføres disse to feltene samtidig, om enn overflødig, i håp om at nettleseren vil forstå minst ett av dem. Dette kombineres ofte med “utløpsdatoen” 1. januar 1970; dette vil også ha samme effekt.

Eksempel: børskurser ; endre hvert sekund.

Mer presist: Med Cache-Control: no-cache , vil en nettleser få lov til å beholde ressursen i hurtigbufferen; Før hver tilgang måtte han imidlertid sørge for at den fremdeles er oppdatert ved å spørre serveren. Det overlates til nettleserimplementørens skjønn å håndtere dette på denne måten eller ikke å inkludere slik informasjon, som er forutsigbar raskt utdatert, i hurtigbufferen.

Det er ingen forskjell i effekten på leseren eller i presentasjonen ønsket av leverandøren.

Versjonssammenligning

Basert på en utløpstid antar nettleseren at ressursen som er i hurtigbufferen, kan være utdatert (engelsk: stale , stale, stale '). Det er da to alternativer:

• Spør den korte HEAD -informasjonen til ressursen fra serveren (først uten komplett innhold), evaluer resultatet selv, og be om innhold (GET) om nødvendig.
• Send den kjente versjonsinformasjonen (Sist modifisert / ETag) til serveren. Serveren svarer enten med HTTP -statuskoden 304 Not Modified (versjonen er fortsatt gyldig) eller sender en ny versjon ( 200 OK ) - i verste fall nå 404 Not Found .

Ugyldighet ^[7]

Hvis en av de relativt sjelden forekommende metodene for POST-, PUT- eller SLETT -HTTP -forespørsel blir funnet for en URL senere, slik den brukes i skjemaer eller WebDAV , må oppføringen for denne URL -en slettes fra hurtigbufferen, fordi dette ville resultere i denne ressursen kan ha blitt endret på serveren.

Ingen butikk ^[8]

Som standard lagres hver vellykkede overførte ressurs som en enkelt fil på harddisken. Hvis overføringen brytes eller datamaskinen krasjer, kan siden lastes inn med de mellomliggende resultatene. I de første årene av nettleseren var ekte kjerneminne også begrenset, nettverkene trege, slik at denne tilnærmingen neppe kunne unngås. Dette gjelder alle ressurser på sidene som vises for øyeblikket, uavhengig av bruk av hurtigbuffer.

• Etter at siden har blitt vist, blir filene som kan gjenbrukes på et senere tidspunkt overført til datastrukturen i hurtigbufferen; alle andre filer markeres som midlertidige og slettes etter hvert.
• Når det gjelder spesielt sensitive ressurser (som finansielle transaksjoner, kontodata), kan det være igjen spor på harddisken; for eksempel fordi "sletting" av en fil bare betyr å fjerne den fra det synlige filsystemet , og ikke umiddelbart overskrive den fysisk. Hvis nettleseren eller datamaskinen krasjer, kan filer stå igjen; Selv etter en tilsynelatende sletting kan den fysiske harddisken fortsatt inneholde sensitiv informasjon som fremdeles vil være lesbar når den er logget på den aktuelle brukerkontoen.
• Ressurser merket med Cache-Control: no-store bør ikke buffres av en nettleser på harddisken, men bør bare holdes flyktig i kjerneminnet.
• Imidlertid har konseptet et hull: Bare sjelden operativsystemet gir en applikasjon muligheten til å be om kjerneminne, som lovet å ikke lagre personsøkingsfil, blir sendt til harddisken.

Sikkerhetsaspekter

En brukers cache gjør det mulig å trekke konklusjoner om hvilke emner som kalles.

• En bruker bør bruke en individualisert hurtigbuffer på datamaskinen; for hver brukerkonto et eget område som er beskyttet mot lesing av andre brukere.
  • Rundt 2000/2005 ble de tidligere vanlige sentrale hurtigbufferkatalogene, som ble delt av alle brukere av en PC og også kan leses av hver bruker, erstattet av individualiserte hurtigbuffere hvis tilgangsrettigheter er begrenset til brukeren som er logget på operativsystemet, er også begrenset til én brukerprofil i nettleseren.
  • De fleste nettlesere har en "privat modus". Blant annet er det satt opp en ekstra cachedatastruktur her, som tar opp alle ressursene som nå er hentet opp. Den "normale" cachen kan brukes til å lese parallelt, men det kan ikke skrives informasjon der. Når privat modus avsluttes, slettes den ekstra hurtigbufferen.
• Proxy -servere, som brukes til åpen kommunikasjon, lagrer sidene de har brukt og tilgangsstatistikken for alle nettverksbrukere.
• Nettadresser som du får tilgang til via HTTPS, kan ikke lagres på proxy -servere; det tilhørende innholdet og til og med URL -baner er kryptert.
  • HTTPS, derimot, har ingen innflytelse på bufringen til den enkelte brukeren, som kjenner nettadressen og det dekrypterte innholdet. Noen nettlesere har imidlertid en individuell konfigurasjonsinnstilling der informasjon hentet via HTTPS ikke skal lagres i hurtigbufferen. På grunn av den utbredte bruken av HTTPS også for trådløse tilkoblinger, tillater bruken av denne protokollen neppe noen konklusjon om et spesielt behov for konfidensialitet for sidene som sendes med den.
• Serverresponsen Cache-Control: private skal ha den effekten at denne ressursen bare kan lagres i den individuelle bufferen til en bruker, men ikke på proxy-servere eller delt nettleserbuffer.

Proxy-server

Noen felt er spesielt rettet mot proxy -servere, dvs. mellomliggende stasjoner mellom nettleseren og serveren med den faktiske opprinnelsen til dataene. Mellomstasjonene kan inneholde ofte forespurte ressurser tilgjengelig på en "delt cache" for alle deltakere i nettverket (eller brukere av datamaskinen).

Felt i ressursen

• Cache-Control: s-maxage= nSeconds ^[9]
  Som max-age , men bare på delt (“s” = “delt”) cache.
• Cache-Control: private
  Ikke lagre på delt cache.
• Cache-Control: public
  Eksplisitt utgitt for lagring på delt cache.

En nettleser kan sende inn forespørselen

Pragma: no-cache
En proxy -server som oppstår underveis, bør sende forespørselen videre til opprinnelsen og ikke svare på den fra hurtigbufferen. Det anbefales også å merke ressursen for denne nettadressen som foreldet (best-før-dato er utløpt), da det er åpenbare tvil om den er oppdatert.

HTTP -hurtigbufring

Oppsummert påvirker spesielt følgende HTTP -felt hurtigbufring - hvis den leveres av webserveren eller hvis grunnlaget ble opprettet:

Internett server

• Last-Modified: tidsstempel
• ETag: versjon
• Expires: tidsstempel
• Cache-Control:
  • max-age
  • must-revalidate
  • no-cache
  • no-store
  • private
  • public
  • s-maxage
  • … og mer
• Vary

Forespørsel om nettleser

• If-Modified-Since for sist-modifisert
• If-None-Match for ETag
• Pragma: no-cache omgå proxy-server Pragma: no-cache

Den samme informasjonen som en webserver overfører i tillegg til innholdet, kan også integreres i et HTML -dokument ^[10] og om nødvendig overskrive standardinformasjonen til serveren:

 < meta http-equiv = "Last-Modified" content = "..." />

weblenker

• Instruksjoner for tømming av hurtigbufferen for vanlige nettlesere på www.browser-cache.de
• Instruksjoner for å slette hurtigbufferen til populære nettlesere på clear-my-browser-cache.com
• RFC: 2616 HTTP 1.1 (1999) - spesielt avsnitt 13 og 14; grunnleggende teknikker for utvikling av nettlesere
• Hjelp: Cache - om hurtigbufreproblemet i Wikipedia
• Cachekontroll: uforanderlig

Individuelle referanser og kommentarer

1. ^ RFC 2616 14.19
2. ^ RFC 2616 13.2.4
3. ^ RFC 2616 14.21
4. ↑ RFC 2616 14.9.3, 14.9.4
5. ↑ &max-age= -Noen webservere sender det tilsvarende Cache-Control feltet til en URL-parameter som denne i svaret.
6. ↑ RFC 2616 14.9.1
7. ↑ RFC 2616 13. oktober
8. ^ RFC 2616 14.9.2
9. ↑ RFC 2616 14.9.3
10. ↑ HTML. 4