Dela via

Så fungerar cachelagring

  • Artikel

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 din Azure CDN Standard 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 dras tillbaka den 4 november 2025. Du måste migrera din arbetsbelastning till Azure Front Door före det här datumet för att undvika avbrott i tjänsten. 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

Viktigt!

Som standard ignorerar en Azure Content Delivery Network-slutpunkt som är optimerad för DSA cachedirektivrubriker och kringgår cachelagring. För Azure CDN Standard från Edgio-profiler kan du justera hur en Azure Content Delivery Network-slutpunkt behandlar dessa rubriker med hjälp av cachelagringsregler för innehållsleveransnätverk för att aktivera cachelagring. Endast för Azure CDN Premium från Edgio-profiler använder du regelmotorn för att aktivera cachelagring.

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 och Cache-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ätverket POP:

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-ageLiknar .
  • 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 motsvarar Cache-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/Premium från Edgio har som standard stöd för både ETag och Last-Modified validatorer, medan Azure CDN Standard från Microsoft endast Last-Modifiedstöder .

ETag:

  • Azure CDN Standard/Premium från Edgio stöder ETag som standard, medan Azure CDN Standard från Microsoft inte gör det.
  • ETag definierar en sträng som är unik för varje fil och version av en fil. Exempel: ETag: "17f0ddd99ed5bbe4edffdd6496d7131f"
  • Introducerades i HTTP 1.1 och är mer aktuell än Last-Modified. Användbart när det senast ändrade datumet är svårt att avgöra.
  • Stöder både stark validering och svag validering. Azure Content Delivery Network stöder dock endast stark validering. För stark validering måste de två resursrepresentationerna vara byte-för-byte identiska.
  • En cache verifierar en fil som använder ETag genom att skicka ett If-None-Match huvud med en eller flera ETag validerare i begäran. Exempel: If-None-Match: "17f0ddd99ed5bbe4edffdd6496d7131f" Om serverns version matchar en ETag validerare i listan skickar den statuskod 304 (inte ändrad) i sitt svar. Om versionen är annorlunda svarar servern med statuskod 200 (OK) och den uppdaterade resursen.

Senast ändrad:

  • Endast för Azure CDN Standard/Premium från Edgio Last-Modified används om ETag det inte ingår i HTTP-svaret.
  • 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 inkonsekventa Last-Modified tider returneras från serverdelsservrar orsakas fel vid matchning av valideringsfel och orsaka HTTP 5XX-fel. Azure Storage kanske inte stöder konsekventa Last-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 ett If-Modified-Since huvud med ett datum och en tid i begäran. Ursprungsservern jämför det datumet med rubriken för Last-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. Endast för Azure CDN Premium från Edgio kan du använda regelmotorn för att anpassa vissa av dessa villkor.

Azure Content Delivery Network från Microsoft Azure Content Delivery Network från Edgio
HTTP-statuskoder 200, 203, 206, 300, 301, 410, 416 200
HTTP-metoder GET, HEAD GET
Filstorleksgränser 300 GB 300 GB

För att Azure CDN Standard från Microsoft-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

I följande tabell beskrivs standardbeteendet för cachelagring för Azure Content Delivery Network-produkter och deras optimeringar.

Microsoft: Allmän webbleverans Edgio: Allmän webbleverans Edgio: DSA
Heders ursprung Ja Ja Nej
varaktighet för nätverkscache för innehållsleverans Två dagar Sju dagar Ingen

Honor-ursprung: Anger om de cachedirektivrubriker som stöds ska respekteras om de finns i HTTP-svaret från ursprungsservern.

CDN-cachevaraktighet: Anger hur lång tid en resurs cachelagras i Azures innehållsleveransnätverk. Men om Honor-ursprunget är Ja och HTTP-svaret från ursprungsservern innehåller huvudet Expires cache-directive eller Cache-Control: max-ageanvänder Azure Content Delivery Network det varaktighetsvärde som anges av huvudet i stället.

Kommentar

Azure Content Delivery Network ger inga garantier om minsta tid för att 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