Så fungerar cachelagring
Viktigt!
Azure CDN Standard från Microsoft (klassisk) dras tillbaka den 30 september 2027. För att undvika avbrott i tjänsten är det viktigt att du migrerar dina Azure CDN Standard-profiler från Microsofts (klassiska) profiler till Azure Front Door Standard- eller Premium-nivån senast den 30 september 2027. Mer information finns i Azure CDN Standard från Microsoft (klassisk) tillbakadragning.
Azure CDN från Edgio drogs tillbaka den 15 januari 2025. Mer information finns i Azure CDN från vanliga frågor och svar om Edgio-pensionering.
Den här artikeln innehåller en översikt över allmänna cachelagringsbegrepp och hur Azure Content Delivery Network använder cachelagring för att förbättra prestanda. Om du vill lära dig mer om hur du anpassar cachelagringsbeteendet på slutpunkten för innehållsleveransnätverket kan du läsa Kontrollera cachelagringsbeteendet för Azure Content Delivery Network med cachelagringsregler och Kontrollera cachelagringsbeteendet för Azure Content Delivery Network med frågesträngar.
Introduktion till cachelagring
Cachelagring är processen att lagra data lokalt så att framtida begäranden för dessa data kan nås snabbare. I den vanligaste typen av cachelagring, cachelagring av webbläsare, lagrar en webbläsare kopior av statiska data lokalt på en lokal hårddisk. Genom att använda cachelagring kan webbläsaren undvika att göra flera turer till servern och i stället komma åt samma data lokalt, vilket sparar tid och resurser. Cachelagring passar bra för lokal hantering av små statiska data som statiska avbildningar, CSS-filer och JavaScript-filer.
På samma sätt används cachelagring av ett nätverk för innehållsleverans på gränsservrar nära användaren för att undvika begäranden som reser tillbaka till ursprunget och minskar slutanvändarens svarstid. Till skillnad från en webbläsarcache, som endast används för en enskild användare, har nätverket för innehållsleverans en delad cache. I en delad cache för innehållsleveransnätverk kan en filbegäran från en användare användas av en annan användare, vilket avsevärt minskar antalet begäranden till ursprungsservern.
Dynamiska resurser som ändras ofta eller är unika för en enskild användare kan inte cachelagras. Dessa typer av resurser kan dock dra nytta av DSA-optimering (dynamisk webbplatsacceleration) i Azure-nätverket för innehållsleverans för prestandaförbättringar.
Cachelagring kan ske på flera nivåer mellan ursprungsservern och slutanvändaren:
- Webbserver: Använder en delad cache (för flera användare).
- Nätverk för innehållsleverans: Använder en delad cache (för flera användare).
- Internetleverantör (ISP): Använder en delad cache (för flera användare).
- Webbläsare: Använder en privat cache (för en användare).
Varje cache hanterar vanligtvis sin egen resurs färskhet och utför validering när en fil är inaktuell. Det här beteendet definieras i HTTP-cachelagringsspecifikationen RFC 7234.
Resursens färskhet
Eftersom en cachelagrad resurs potentiellt kan vara inaktuell eller inaktuell (jämfört med motsvarande resurs på ursprungsservern) är det viktigt att alla cachelagringsmekanismer styr när innehållet får en uppdatering. För att spara tid och bandbreddsförbrukning jämförs inte en cachelagrad resurs med versionen på ursprungsservern varje gång den används. Så länge en cachelagrad resurs anses vara färsk antas den i stället vara den senaste versionen och skickas direkt till klienten. En cachelagrad resurs anses vara färsk när dess ålder är mindre än den ålder eller period som definieras av en cacheinställning. När en webbläsare till exempel läser in en webbsida igen verifierar den att varje cachelagrad resurs på hårddisken är färsk och läser in den. Om resursen inte är ny (inaktuell) läses en uppdaterad kopia in från servern.
Validering
Om en resurs anses vara inaktuell uppmanas ursprungsservern att verifiera den för att avgöra om data i cacheminnet fortfarande matchar det som finns på ursprungsservern. Om filen har ändrats på ursprungsservern uppdaterar cachen sin version av resursen. Annars, om resursen är färsk, levereras data direkt från cachen utan att verifiera den först.
Cachelagring av innehållsleveransnätverk
Cachelagring är en integrerad del av hur ett nätverk för innehållsleverans fungerar för att påskynda leveransen och minska ursprungsbelastningen för statiska tillgångar som bilder, teckensnitt och videor. I cachelagring av innehållsleveransnätverk lagras statiska resurser selektivt på strategiskt placerade servrar som är mer lokala för en användare och erbjuder följande fördelar:
Eftersom den mesta webbtrafiken är statisk (till exempel bilder, teckensnitt och videor) minskar cachelagringen av innehållsleveransnätverket nätverksfördröjningen genom att flytta innehåll närmare användaren, vilket minskar avståndet som data färdas till.
Genom att avlasta arbetet till ett nätverk för innehållsleverans kan cachelagring minska nätverkstrafiken och belastningen på ursprungsservern. Detta minskar kostnaderna och resurskraven för programmet, även om det finns ett stort antal användare.
På samma sätt som cachelagring implementeras i en webbläsare kan du styra hur cachelagring utförs i ett nätverk för innehållsleverans genom att skicka cachedirektivhuvuden. Cache-direktivrubriker är HTTP-huvuden, som vanligtvis läggs till av ursprungsservern. Även om de flesta av dessa huvuden ursprungligen utformades för att hantera cachelagring i klientwebbläsare, används de nu också av alla mellanliggande cacheminnen, till exempel nätverk för innehållsleverans.
Två huvuden kan användas för att definiera cache-färskhet: Cache-Control
och Expires
.
Cache-Control
är mer aktuell och har företräde framför Expires
, om båda finns. Det finns också två typer av huvuden som används för validering (kallas validatorer): ETag
och Last-Modified
.
ETag
är mer aktuell och har företräde framför Last-Modified
, om båda definieras.
Cache-direktivrubriker
Azure Content Delivery Network stöder följande HTTP-cachedirektivrubriker som definierar cachevaraktighet och cachedelning.
Cachekontroll:
- Introducerades i HTTP 1.1 för att ge webbutgivarna mer kontroll över sitt innehåll och för att åtgärda begränsningarna i
Expires
rubriken. - Åsidosätter
Expires
huvudet, om både det ochCache-Control
definieras. - När den används i en HTTP-begäran från klienten till innehållsleveransnätverkets POP
Cache-Control
ignoreras den som standard av alla Azure Content Delivery Network-profiler. - När det används i ett HTTP-svar från ursprungsservern till innehållsleveransnätverkets POP,
Cache-Control
respekteras som standard av alla Azure Content Delivery Network-profiler. Azure CDN respekterar även cachelagringsbeteenden för Cache-Control-direktiv i RFC 7234 – Hypertext Transfer Protocol (HTTP/1.1): Cachelagring (ietf.org).
Upphör:
- Äldre rubrik som introducerades i HTTP 1.0; stöds för bakåtkompatibilitet.
- Använder en datumbaserad förfallotid med andra precision.
-
Cache-Control: max-age
Liknar . - Används när
Cache-Control
finns inte.
Pragma:
- Stöds inte av Azure Content Delivery Network som standard.
- Äldre rubrik som introducerades i HTTP 1.0; stöds för bakåtkompatibilitet.
- Används som en klientbegäranshuvud med följande direktiv:
no-cache
. Det här direktivet instruerar servern att leverera en ny version av resursen. -
Pragma: no-cache
motsvararCache-Control: no-cache
.
Validerare
När cacheminnet är inaktuellt används HTTP-cacheverifierare för att jämföra den cachelagrade versionen av en fil med versionen på ursprungsservern.
Azure CDN Standard från Microsoft stöder endast Last-Modified
.
Kommentar
Azure CDN från Microsoft (klassisk) stöder ETag
inte .
Senast ändrad:
- Anger datum och tid då ursprungsservern har fastställt att resursen senast ändrades. Exempel:
Last-Modified: Thu, 19 Oct 2017 09:28:00 GMT
- För innehåll som är större än 8 MB bör ursprungsserverdelens servrar upprätthålla konsekventa
Last-Modified
tidsstämplar per tillgång. Om inkonsekventaLast-Modified
tider returneras från serverdelsservrar orsakas fel vid matchning av valideringsfel och orsaka HTTP 5XX-fel. Azure Storage kanske inte stöder konsekventaLast-Modified
tidsstämplar mellan repliker, vilket kan orsaka liknande fel vid matchning av validatorfel. - En cache verifierar en fil med hjälp
Last-Modified
av genom att skicka ettIf-Modified-Since
huvud med ett datum och en tid i begäran. Ursprungsservern jämför det datumet med rubriken förLast-Modified
den senaste resursen. Om resursen inte har ändrats sedan den angivna tiden returnerar servern statuskod 304 (inte ändrad) i sitt svar. Om resursen har ändrats returnerar servern statuskod 200 (OK) och den uppdaterade resursen.
Avgöra vilka filer som kan cachelagras
Alla resurser kan inte cachelagras. I följande tabell visas vilka resurser som kan cachelagras baserat på typen av HTTP-svar. Resurser som levereras med HTTP-svar som inte uppfyller alla dessa villkor kan inte cachelagras.
Villkor | Värde |
---|---|
HTTP-statuskoder | 200, 203, 206, 300, 301, 410, 416 |
HTTP-metoder | GET, HEAD |
Filstorleksgränser | 300 GB |
För att cachelagring ska fungera på en resurs måste ursprungsservern ha stöd för alla HEAD- och GET HTTP-begäranden och värdena för innehållslängd måste vara desamma för alla HEAD- och GET HTTP-svar för tillgången. För en HEAD-begäran måste ursprungsservern ha stöd för HEAD-begäran och svara med samma huvuden som om den tog emot en GET-begäran.
Kommentar
Begäranden som innehåller auktoriseringshuvud cachelagras inte.
Standardbeteende för cachelagring
Standardbeteendet för cachelagring för Azure CDN är att respektera ursprung och cacheinnehåll i två dagar.
Hederns ursprung: Den här inställningen anger om cache-direktivrubrikerna (Cache-Control
eller Expires
) ska respekteras om de finns i HTTP-svaret från ursprungsservern.
CDN-cachevaraktighet: Den här inställningen anger hur länge en resurs cachelagras på Azure CDN. Om Honor-ursprung är aktiverat och HTTP-svaret från ursprungsservern innehåller Cache-Control: max-age
rubriken eller Expires
använder Azure CDN den varaktighet som anges av dessa rubriker i stället för standardperioden på två dagar.
Kommentar
Azure CDN ger inga garantier om den minsta tid som objektet ska lagras i cacheminnet. Cachelagrat innehåll kan tas bort från nätverkscachen för innehållsleverans innan de upphör att gälla om innehållet inte begärs lika ofta för att göra plats för mer efterfrågat innehåll.
Nästa steg
- Information om hur du anpassar och åsidosätter standardbeteendet för cachelagring i nätverket för innehållsleverans via cachelagringsregler finns i Kontrollera cachelagringsbeteendet för Azure Content Delivery Network med cachelagringsregler.
- Information om hur du använder frågesträngar för att styra cachelagringsbeteendet finns i Kontrollera cachelagringsbeteendet för Azure Content Delivery Network med frågesträngar.