Cachelagring med Azure Front Door

  • Artikel

Viktigt!

Azure Front Door (klassisk) dras tillbaka den 31 mars 2027. För att undvika avbrott i tjänsten är det viktigt att du migrerar dina Azure Front Door-profiler (klassiska) till Azure Front Door Standard- eller Premium-nivån senast i mars 2027. Mer information finns i Azure Front Door (klassisk) tillbakadragning.

Azure Front Door är ett modernt nätverk för innehållsleverans (CDN) med dynamisk platsacceleration och belastningsutjämning. När cachelagring har konfigurerats på din väg kontrollerar gränswebbplatsen som tar emot varje begäran dess cache för ett giltigt svar. Cachelagring hjälper till att minska mängden trafik som skickas till ursprungsservern. Om inget cachelagrat svar är tillgängligt vidarebefordras begäran till ursprunget.

Varje Front Door Edge-webbplats hanterar sin egen cache och begäranden kan hanteras av olika gränsplatser. Därför kan du fortfarande se att viss trafik når ditt ursprung, även om du har hanterat cachelagrade svar.

Cachelagring kan avsevärt minska svarstiden och minska belastningen på ursprungsservrar. Alla typer av trafik kan dock inte dra nytta av cachelagring. Statiska tillgångar som bilder, CSS- och JavaScript-filer är idealiska för cachelagring. Dynamiska tillgångar, till exempel autentiserade API-slutpunkter, bör inte cachelagras för att förhindra läckage av personlig information. Vi rekommenderar att du har separata vägar för statiska och dynamiska tillgångar, med cachelagring inaktiverad för den senare.

Varning

Innan du aktiverar cachelagring bör du noggrant granska den offentliga dokumentationen och testa alla möjliga scenarier innan du aktiverar cachelagring. Som tidigare nämnts kan du med felkonfiguration oavsiktligt cachelagrar användarspecifika data som kan delas av flera användare som resulterar i sekretessincidenter.

Metoder för begäran

Endast begäranden som använder GET begärandemetoden kan cachelagrats. Alla andra metoder för begäranden skickas alltid via nätverket.

Leverans av stora filer

Azure Front Door levererar stora filer utan ett tak för filstorleken. Om cachelagring är aktiverat använder Front Door en teknik som kallas objektsegmentering. När en stor fil begärs hämtar Front Door mindre delar av filen från ursprunget. När Front Door har fått en fullständig filbegäran eller byteintervallfilbegäran begär Front Door-miljön filen från ursprunget i segment på 8 MB.

När segmentet kommer till Azure Front Door-miljön cachelagras det och hanteras omedelbart av användaren. Front Door förinstallerar sedan nästa segment parallellt. Den här prefetchen säkerställer att innehållet ligger ett segment före användaren, vilket minskar svarstiden. Den här processen fortsätter tills hela filen laddas ned (om det begärs) eller tills klienten stänger anslutningen. Mer information om byteintervallbegäran finns i RFC 7233.

Front Door cachelagrar alla segment när de tas emot så att hela filen inte behöver cachelagras i Front Door-cachen. Efterföljande begäranden för filen eller byteintervallen hanteras från cacheminnet. Om segmenten inte alla cachelagras används prefetching för att begära segment från ursprunget.

Den här optimeringen bygger på ursprungets förmåga att stödja byteintervallbegäranden. Om ursprunget inte stöder byteintervallbegäranden, eller om det inte hanterar intervallbegäranden korrekt, är den här optimeringen inte effektiv.

När ditt ursprung svarar på en begäran med ett Range huvud måste det svara på något av följande sätt:

  • Returnera ett intervallsvar. Svaret måste använda HTTP-statuskod 206. Dessutom måste svarsrubriken Content-Range finnas och matcha den faktiska längden på innehållet som ditt ursprung returnerar. Om ditt ursprung inte skickar rätt svarshuvuden med giltiga värden cachelagrar Inte Azure Front Door svaret och du kan se inkonsekvent beteende.

    Dricks

    Om ditt ursprung komprimerar svaret kontrollerar du att Content-Range rubrikvärdet matchar den faktiska längden på det komprimerade svaret.

  • Returnera ett icke-intervallsvar. Om ditt ursprung inte kan hantera intervallbegäranden kan det Range ignorera huvudet och returnera ett icke-ordnat svar. Kontrollera att ursprunget returnerar en annan svarsstatuskod än 206. Till exempel kan ursprunget returnera ett 200 OK-svar.

Om ursprunget använder CTE (Chunked Transfer Encoding) för att skicka data till Azure Front Door POP stöds inte svarsstorlekar som är större än 8 MB.

Filkomprimering

Se Förbättra prestanda genom att komprimera filer i Azure Front Door.

Azure Front Door (klassisk) kan dynamiskt komprimera innehåll på gränsen, vilket resulterar i en mindre och snabbare svarstid till dina klienter. För att en fil ska vara berättigad till komprimering måste cachelagring aktiveras och filen måste vara av MIME-typ för att kunna komprimeras. För närvarande tillåter inte Front Door (klassisk) att den här listan ändras. Den aktuella listan är:

  • "application/eot"
  • "program/teckensnitt"
  • "application/font-sfnt"
  • "application/javascript"
  • "application/json"
  • "application/opentype"
  • "application/otf"
  • "application/pkcs7-mime"
  • "application/truetype"
  • "application/ttf",
  • "application/vnd.ms-fontobject"
  • "application/xhtml+xml"
  • "application/xml"
  • "application/xml+rss"
  • "application/x-font-opentype"
  • "application/x-font-truetype"
  • "application/x-font-ttf"
  • "application/x-httpd-cgi"
  • "application/x-mpegurl"
  • "application/x-opentype"
  • "application/x-otf"
  • "application/x-perl"
  • "application/x-ttf"
  • "application/x-javascript"
  • "font/eot"
  • "font/ttf"
  • "font/otf"
  • "font/opentype"
  • "image/svg+xml"
  • "text/css"
  • "text/csv"
  • "text/html"
  • "text/javascript"
  • "text/js", "text/oformaterad"
  • "text/rtftext"
  • "text/tab-separated-values"
  • "text/xml"
  • "text/x-script"
  • "text/x-komponent"
  • "text/x-java-source"

Dessutom måste filen också vara mellan 1 KB och 8 MB i storlek, inklusive.

Dessa profiler stöder följande komprimeringskodningar:

Om en begäran stöder gzip- och Brotli-komprimering har Brotli-komprimering företräde.

När en begäran om en tillgång anger komprimering och begäran resulterar i en cachemiss komprimerar Azure Front Door (klassisk) tillgången direkt på POP-servern. Därefter hanteras den komprimerade filen från cacheminnet. Det resulterande objektet returneras med ett Transfer-Encoding: chunked svarshuvud.

Om ursprunget använder CTE (Chunked Transfer Encoding) för att skicka data till Azure Front Door POP stöds inte komprimering.

Kommentar

Intervallbegäranden kan komprimeras till olika storlekar. Azure Front Door kräver att värdena för innehållslängd är desamma för alla GET HTTP-begäranden. Om klienter skickar byteintervallbegäranden med Accept-Encoding huvudet som leder till att Origin svarar med olika innehållslängder returnerar Azure Front Door ett 503-fel. Du kan antingen inaktivera komprimering av ursprunget eller skapa en regelmotorregel för att ta bort Accept-Encoding huvudet från begäran om byteintervallbegäranden.

Beteende för frågesträng

Med Azure Front Door kan du styra hur filer cachelagras för en webbbegäran som innehåller en frågesträng.

I en webbbegäran med en frågesträng är frågesträngen den del av begäran som inträffar efter ett frågetecken (?). En frågesträng kan innehålla ett eller flera nyckel/värde-par, där fältnamnet och dess värde avgränsas med ett likhetstecken (=). Varje nyckel/värde-par avgränsas med ett &ersand (&).

URL:en http://www.contoso.com/content.mov?field1=value1&field2=value2 innehåller till exempel två frågesträngar:

  • field1, med värdet value1.
  • field2, med värdet value2.

Om det finns fler än ett nyckel/värde-par i en frågesträng i en begäran spelar deras order ingen roll.

När du konfigurerar cachelagring anger du hur cachen ska hantera frågesträngar. Följande beteenden stöds:

  • Ignorera frågesträng: I det här läget skickar Azure Front Door frågesträngarna från klienten till ursprunget för den första begäran och cachelagrar tillgången. Framtida begäranden för tillgången som hanteras från Front Door-miljön ignorerar frågesträngarna tills den cachelagrade tillgången upphör att gälla.

  • Använd frågesträng: I det här läget behandlas varje begäran med en unik URL, inklusive frågesträngen, som en unik tillgång med sin egen cache. Svaret från ursprunget för en begäran om www.example.ashx?q=test1 cachelagras till exempel i Front Door-miljön och returneras för efterföljande cacheminnen med samma frågesträng. En begäran om www.example.ashx?q=test2 cachelagras som en separat tillgång med en egen time-to-live-inställning.

    Ordningen på frågesträngsparametrarna spelar ingen roll. Om Azure Front Door-miljön till exempel innehåller ett cachelagrat svar för URL:en www.example.ashx?q=test1&r=test2hanteras även en begäran från www.example.ashx?r=test2&q=test1 cachen.

  • Ignorera angivna frågesträngar och inkludera angivna frågesträngar: I det här läget kan du konfigurera Azure Front Door så att de inkluderar eller exkluderar angivna parametrar när cachenyckeln genereras.

    Anta till exempel att standardcachenyckeln är /foo/image/asset.htmloch att en begäran görs till URL:en https://contoso.com/foo/image/asset.html?language=EN&userid=100&sessionid=200. Om det finns en regelmotorregel som utesluter frågesträngsparametern userid blir /foo/image/asset.html?language=EN&sessionid=200cachenyckeln för frågesträngen .

Konfigurera frågesträngens beteende på Front Door-vägen.

Cacherensning

Mer information om hur du konfigurerar cacherensning finns i Cacherensning i Azure Front Door .

Azure Front Door cachelagrar tillgångar tills tillgångens time-to-live (TTL) upphör att gälla. När en klient begär en tillgång med förfallen TTL hämtar Front Door-miljön en ny uppdaterad kopia av tillgången för att hantera begäran och lagrar sedan den uppdaterade cachen.

Det bästa sättet att se till att användarna alltid får den senaste kopian av dina tillgångar är att versionshantera dina tillgångar för varje uppdatering och publicera dem som nya URL:er. Front Door hämtar omedelbart de nya tillgångarna för nästa klientbegäranden. Ibland kanske du vill rensa cachelagrat innehåll från alla gränsnoder och tvinga dem alla att hämta nya uppdaterade tillgångar. Orsaken kan bero på uppdateringar av webbprogrammet eller på att snabbt uppdatera tillgångar som innehåller felaktig information.

Skärmbild av cacherensningsknappen och sidan.

Välj de tillgångar som du vill rensa från kantnoderna. Om du vill rensa alla tillgångar väljer du Rensa alla. Annars anger du sökvägen för varje tillgång som du vill rensa i Sökväg.

Dessa format stöds i listan över sökvägar som ska rensas:

  • Rensning av enskild sökväg: Rensa enskilda tillgångar genom att ange den fullständiga sökvägen för tillgången (utan protokollet och domänen), med filnamnstillägget, till exempel /pictures/strasbourg.png;
  • Jokerteckenrensning: Asterisk (*) kan användas som jokertecken. Rensa alla mappar, undermappar och filer under en slutpunkt med /* i sökvägen eller rensa alla undermappar och filer under en specifik mapp genom att ange mappen följt av /*, till exempel /pictures/*.
  • Rensning av rotdomän: Rensa slutpunktens rot med "/" i sökvägen.

Kommentar

Rensa jokerteckendomäner: Att ange cachelagrade sökvägar för rensning enligt beskrivningen i det här avsnittet gäller inte för jokerteckendomäner som är associerade med Front Door. För närvarande stöder vi inte direkt rensning av jokerteckendomäner. Du kan rensa sökvägar från specifika underdomäner genom att ange den specifikationsunderdomänen och rensningssökvägen. Om min Front Door till exempel har *.contoso.comkan jag rensa tillgångar i min underdomän foo.contoso.com genom att foo.contoso.com/path/*skriva . För närvarande är det begränsat att ange värdnamn i sökvägen för rensningsinnehåll till underdomäner för jokerteckendomäner, om tillämpligt.

Cacherensningar på Front Door är skiftlägeskänsliga. Dessutom är de frågesträngsagnostiska, vilket innebär att rensning av en URL rensar alla frågesträngsvariationer av den.

Cache förfallodatum

Följande rubrikordning används för att avgöra hur länge ett objekt lagras i cacheminnet:

  1. Cache-Control: s-maxage=<seconds>
  2. Cache-Control: max-age=<seconds>
  3. Expires: <http-date>

Vissa Cache-Control svarshuvudvärden anger att svaret inte kan cachelagrats. Dessa värden inkluderar private, no-cacheoch no-store. Front Door respekterar dessa rubrikvärden och cachelagrar inte svaren, även om du åsidosätter cachelagringsbeteendet med hjälp av regelmotorn.

Cache-Control Om rubriken inte finns i svaret från ursprunget avgör Front Door som standard slumpmässigt en cachevaraktighet mellan en och tre dagar.

Kommentar

Cachens giltighetstid får inte vara längre än 366 dagar.

Du kan se REVALIDATED_HIT i svarshuvudet Cache-Control . Detta indikerar att det cachelagrade innehållet i Azure Front Door har omfördelades med ursprungsservern innan det serverades till klienten. Detta kan inträffa när det cachelagrade innehållet har upphört att gälla, men ursprungsservern anger att innehållet inte har ändrats. I det här fallet hanteras det cachelagrade innehållet till klienten och cachens förfallodatum återställs.

Begärandehuvuden

Följande begärandehuvuden vidarebefordras inte till ursprunget när cachelagring är aktiverat:

  • Content-Length
  • Transfer-Encoding
  • Accept
  • Accept-Charset
  • Accept-Language

Svarsrubriker

Om ursprungssvaret kan cachelagrats Set-Cookie tas huvudet bort innan svaret skickas till klienten. Om ett ursprungssvar inte kan cachelagrats tar Front Door inte bort rubriken. Om till exempel ursprungssvaret innehåller en Cache-Control rubrik med ett max-age värde anger för Front Door att svaret kan cachelagrats och Set-Cookie huvudet tas bort.

Dessutom bifogar X-Cache Front Door huvudet till alla svar. Svarshuvudet X-Cache innehåller något av följande värden:

  • TCP_HIT eller TCP_REMOTE_HIT: Det första 8 MB-segmentet i svaret är en cacheträff och innehållet hanteras från Front Door-cachen.
  • TCP_MISS: Det första 8 MB-segmentet i svaret är en cachemiss och innehållet hämtas från ursprunget.
  • PRIVATE_NOSTORE: Begäran kan inte cachelagras eftersom svarsrubriken Cache-Control är inställd på antingen privat eller ingen lagring.
  • CONFIG_NOCACHE: Begäran är konfigurerad att inte cachelagras i Front Door-profilen.

Loggar och rapporter

Åtkomstloggen innehåller cachestatus för varje begäran. Rapporter innehåller också information om hur Azure Front Door cache används i ditt program.

Åtkomstloggen innehåller cachestatus för varje begäran.

Cachebeteende och varaktighet

Cachebeteende och varaktighet kan konfigureras i regelmotorn. Cachelagringskonfigurationen för regelmotorn åsidosätter alltid routningskonfigurationen.

  • När cachelagring är inaktiverat cachelagrar inte Azure Front Door svarsinnehållet, oavsett ursprungssvarsdirektiven.

  • När cachelagring är aktiverat skiljer sig cachebeteendet beroende på det cachebeteendevärde som tillämpas av regelmotorn:

    • Hedersursprung: Azure Front Door respekterar alltid ursprungsdirektivet för svarshuvud. Om ursprungsdirektivet saknas cachelagrar Azure Front Door innehållet var som helst från en till tre dagar.
    • Åsidosätt alltid: Azure Front Door åsidosätter alltid med cachevaraktigheten, vilket innebär att innehållet cachelagrar under cachevaraktigheten och ignorerar värdena från ursprungssvarsdirektiven. Det här beteendet gäller bara om svaret kan cachelagras.
    • Åsidosätt om ursprunget saknas: Om ursprunget inte returnerar cachelagrings-TTL-värden använder Azure Front Door den angivna cachevaraktigheten. Det här beteendet gäller bara om svaret kan cachelagras.

Kommentar

  • Azure Front Door ger inga garantier om hur lång tid innehållet lagras i cacheminnet. Cachelagrat innehåll kan tas bort från gränsens cacheminne innan innehållet upphör att gälla om innehållet inte används ofta. Front Door kanske kan hantera data från cacheminnet även om cachelagrade data har upphört att gälla. Det här beteendet kan hjälpa webbplatsen att vara delvis tillgänglig när ditt ursprung är offline.
  • Ursprung kan ange att inte cachelagrar specifika svar med huvudet Cache-Control med värdet no-cache, private eller no-store. När det används i ett HTTP-svar från ursprungsservern till Azure Front Door-IP-adresser stöder Azure Front Door cachekontrolldirektiv och respekterar cachelagringsbeteenden för Cache-Control-direktiv i RFC 7234 – Hypertext Transfer Protocol (HTTP/1.1): Cachelagring (ietf.org).

Cachebeteende och varaktighet kan konfigureras i både Front Door-designerns routningsregel och i Regelmotor. Cachelagringskonfigurationen för Regelmotorn åsidosätter alltid konfigurationen av Front Door-designerns routningsregel.

  • När cachelagring är inaktiverat cachelagrar inte Azure Front Door (klassisk) svarsinnehållet, oavsett ursprungssvarsdirektiv.

  • När cachelagring är aktiverat skiljer sig cachebeteendet åt för olika värden i Använd cachens standardvaraktighet.

    • När Använd cachestandardvaraktighet har angetts till Ja, respekterar Azure Front Door (klassisk) alltid ursprungsdirektivet för svarshuvud. Om ursprungsdirektivet saknas cachelagrar Front Door innehållet var som helst från en till tre dagar.
    • När Använd cachens standardvaraktighet har angetts till Nej åsidosätter Azure Front Door (klassisk) alltid cachevaraktigheten (obligatoriska fält), vilket innebär att innehållet cachelagras under cachetiden och ignorerar värdena från ursprungssvarsdirektiven.

Kommentar

  • Azure Front Door (klassisk) ger inga garantier om hur lång tid innehållet lagras i cacheminnet. Cachelagrat innehåll kan tas bort från gränsens cacheminne innan innehållet upphör att gälla om innehållet inte används ofta. Azure Front Door (klassisk) kanske kan hantera data från cacheminnet även om cachelagrade data har upphört att gälla. Det här beteendet kan hjälpa webbplatsen att vara delvis tillgänglig när ditt ursprung är offline.
  • Cachevaraktigheten som anges i Front Door-designerns routningsregel är den minsta cachevaraktigheten. Den här åsidosättningen fungerar inte om cachekontrollhuvudet från ursprunget har en större TTL än åsidosättningsvärdet.

Nästa steg