Så här fungerar cachelagring

  • Artikel
  • 8 minuter för att läsa

Den här artikeln innehåller en översikt över allmänna cachelagringsbegrepp och hur Azure Content Delivery Network (CDN) använder cachelagring för att förbättra prestanda. Om du vill lära dig mer om hur du anpassar cachelagringsbeteendet på CDN-slutpunkten kan du läsa Kontrollera beteendet för Azure CDN-cachelagring med cachelagringsregler och Kontrollera beteendet för Azure CDN-cachelagring med frågesträngar.

Introduktion till cachelagring

Cachelagring är en process för att lagra data lokalt så att framtida begäranden om 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 bilder, 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 skickas tillbaka till ursprunget och minska slutanvändarens svarstid. Till skillnad från en webbläsares cacheminne, som endast används för en enskild användare, har CDN en delad cache. I en DELAD CDN-cache 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 som ä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 Content Delivery Network 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 aktualitet och utför validering när en fil är inaktuell. Det här beteendet definieras i HTTP-cachelagringsspecifikationen , RFC 7234.

Resursens aktualitet

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 ny 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.

CDN-cachelagring

Cachelagring är en viktig del av hur ett CDN fungerar för att påskynda leveransen och minska ursprungsbelastningen för statiska tillgångar som bilder, teckensnitt och videor. Vid CDN-cachelagring lagras statiska resurser selektivt på strategiskt placerade servrar som är mer lokala för en användare och ger följande fördelar:

  • Eftersom den mesta webbtrafiken är statisk (till exempel bilder, teckensnitt och videor) minskar CDN-cachelagringen 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 CDN 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 CDN genom att skicka cache-direktivhuvuden. 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 CDN.

Två rubriker kan användas för att definiera cache-aktualitet: 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 CDN-slutpunkt som är optimerad för DSA cachedirektivrubriker och kringgår cachelagring. För Azure CDN Standard från Verizon och Azure CDN Standard från Akamai-profiler kan du justera hur en Azure CDN-slutpunkt behandlar dessa huvuden med hjälp av CDN-cachelagringsregler för att aktivera cachelagring. Endast för Azure CDN Premium från Verizon-profiler använder du regelmotorn för att aktivera cachelagring.

Azure CDN stöder följande HTTP-cachedirektivrubriker, som definierar cachevaraktighet och cachedelning.

Cachekontroll:

  • Introducerades i HTTP 1.1 för att ge webbutgivare 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 har definierats.
  • När den används i en HTTP-begäran från klienten till CDN POP Cache-Control ignoreras som standard av alla Azure CDN-profiler.
  • När det används i ett HTTP-svar från ursprungsservern till CDN POP:
    • Azure CDN Standard/Premium från Verizon och Azure CDN Standard från Microsoft har stöd för alla Cache-Control direktiv.
    • Azure CDN Standard/Premium från Verizon och Azure CDN Standard från Microsoft respekterar cachelagringsbeteenden för Cache-Control-direktiv i RFC 7234 – Hypertext Transfer Protocol (HTTP/1.1): Cachelagring (ietf.org).
    • Azure CDN Standard från Akamai stöder endast följande Cache-Control direktiv. Alla andra ignoreras:
      • max-age: Ett cacheminne kan lagra innehållet under det angivna antalet sekunder. Till exempel Cache-Control: max-age=5. Det här direktivet anger den längsta tid som innehållet anses vara färskt.
      • no-cache: Cachelagrat innehållet, men verifiera innehållet varje gång innan det levereras från cachen. Cache-Control: max-age=0Motsvarar .
      • no-store: Cachelagrade aldrig innehållet. Ta bort innehåll om det har lagrats tidigare.

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 CDN 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 är ekvivalent med Cache-Control: no-cache.

Validators

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 Verizon har som standard stöd för både ETag och Last-Modified validerare, medan Azure CDN Standard från Microsoft och Azure CDN Standard från Akamai endast Last-Modified stöder som standard.

Etag:

  • Azure CDN Standard/Premium från Verizon stöder ETag som standard, medan Azure CDN Standard från Microsoft och Azure CDN Standard från Akamai inte gör det.
  • ETag definierar en sträng som är unik för varje fil och version av en fil. Till exempel ETag: "17f0ddd99ed5bbe4edffdd6496d7131f".
  • Introducerades i HTTP 1.1 och är mer aktuell än Last-Modified. Användbart när datumet för senaste ändring är svårt att avgöra.
  • Stöder både stark validering och svag validering; Azure CDN stöder dock endast stark validering. För stark validering måste de två resursrepresentationerna vara identiska med byte för byte.
  • 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. Till 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 VerizonLast-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. Till exempel Last-Modified: Thu, 19 Oct 2017 09:28:00 GMT.
  • En cache verifierar en fil med hjälp Last-Modified av genom att skicka ett If-Modified-Since sidhuvud med ett datum och en tid i begäran. Ursprungsservern jämför det datumet med rubriken för den senaste resursen Last-Modified . Om resursen inte har ändrats sedan den angivna tiden returnerar servern statuskoden 304 (ändras inte) i svaret. 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 Verizon kan du använda regelmotorn för att anpassa vissa av dessa villkor.

Azure CDN från Microsoft Azure CDN från Verizon Azure CDN från Akamai
HTTP-statuskoder 200, 203, 206, 300, 301, 410, 416 200 200, 203, 300, 301, 302, 401
HTTP-metoder GET, HEAD GET GET
Filstorleksgränser 300 GB 300 GB – Allmän webbleveransoptimering: 1,8 GB
– Optimering av medieströmning: 1,8 GB
– Optimering av stora filer: 150 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 måste svara med samma huvuden som om den tog emot en GET-begäran.

Standardbeteende för cachelagring

I följande tabell beskrivs standardbeteendet för cachelagring för Azure CDN-produkterna och deras optimeringar.

Microsoft: Allmän webbleverans Verizon: Allmän webbleverans Verizon: DSA Akamai: Allmän webbleverans Akamai: DSA Akamai: Nedladdning av stora filer Akamai: allmän eller VOD-medieströmning
Ära ursprung Ja Ja Nej Ja Nej Ja Ja
VARAKTIGHET för CDN-cache Två dagar Sju dagar Ingen Sju dagar Ingen En dag Ett år

Ursprung för heder: 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 på Azure CDN. 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 CDN det varaktighetsvärde som anges av rubriken i stället.

Anteckning

Azure CDN ger inga garantier om den minsta tid som objektet ska lagras i cacheminnet. Cachelagrat innehåll kan avlägsnas från CDN-cachen innan de upphör att gälla om innehållet inte begärs så ofta för att göra plats för mer frekvent begärt innehåll.

Nästa steg