Så fungerar cachelagring

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 föråldrad eller inaktuell (jämfört med motsvarande resurs på ursprungsservern) är det viktigt att alla cachemekanismer 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.

Validation

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-directive headers

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-headern, om både Expires och är definierade.
• 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).

Utgår:

• Äldre rubrik som introducerades i HTTP 1.0; stöds för bakåtkompatibilitet.
• Använder en datumbaserad förfallotid med sekundprecision.
• Similar to Cache-Control: max-age.
• 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 huvud för klientbegäran 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 från Microsoft stöder endast Last-Modified.

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 inkonsekventa Last-Modified tider returneras från bakändeservrar orsakar det matchningsfel för valideraren och resulterar i HTTP 5XX-fel. Azure Storage kanske inte stöder konsekventa Last-Modified tidsstämplar över repliker, vilket kan orsaka liknande valideringsfel pga mismatch.
• En cache verifierar en fil med hjälp av Last-Modified genom att skicka en If-Modified-Since huvudrubrik med ett datum och 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.

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.

Standardbeteende för cachelagring

Standardbeteendet för cachelagring för Azure CDN är att respektera ursprung och cacheinnehåll i två dagar.

Respektera ursprung: Den här inställningen anger om cache-direktivrubriker 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.

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.