Caching met Azure Front Door

  • Artikel

Belangrijk

Azure Front Door (klassiek) wordt op 31 maart 2027 buiten gebruik gesteld. Om serviceonderbrekingen te voorkomen, is het belangrijk dat u uw Azure Front Door-profielen (klassiek) tegen maart 2027 migreert naar de Azure Front Door Standard- of Premium-laag. Zie De buitengebruikstelling van Azure Front Door (klassiek) voor meer informatie.

Azure Front Door is een modern NETWERK voor contentlevering (CDN), met dynamische mogelijkheden voor siteversnelling en taakverdeling. Wanneer caching is geconfigureerd op uw route, controleert de edge-site die elke aanvraag ontvangt de cache voor een geldig antwoord. Caching helpt om de hoeveelheid verkeer dat naar uw oorspronkelijke server wordt verzonden, te verminderen. Als er geen reactie in de cache beschikbaar is, wordt de aanvraag doorgestuurd naar de oorsprong.

Elke Front Door Edge-site beheert zijn eigen cache en aanvragen worden mogelijk verwerkt door verschillende edge-sites. Als gevolg hiervan ziet u mogelijk nog steeds verkeer dat uw oorsprong bereikt, zelfs als u antwoorden in de cache hebt ontvangen.

Caching kan de latentie aanzienlijk verminderen en de belasting op oorspronkelijke servers verminderen. Niet alle typen verkeer kunnen echter profiteren van caching. Statische assets, zoals afbeeldingen, CSS en JavaScript-bestanden, zijn ideaal voor caching. Hoewel dynamische assets, zoals geverifieerde API-eindpunten, niet in de cache moeten worden opgeslagen om te voorkomen dat persoonlijke gegevens worden gelekt. Het is raadzaam om afzonderlijke routes voor statische en dynamische assets te hebben, waarbij caching is uitgeschakeld voor de laatste.

Waarschuwing

Voordat u caching inschakelt, moet u de openbare documentatie grondig bekijken en alle mogelijke scenario's testen voordat u caching inschakelt. Zoals eerder vermeld, kunt u met onjuiste configuratie per ongeluk gebruikersspecifieke gegevens in de cache opslaan die kunnen worden gedeeld door meerdere gebruikers die privacyincidenten tot gevolg hebben.

Aanvraagmethoden

Alleen aanvragen die gebruikmaken van de aanvraagmethode, kunnen in de GET cache worden opgeslagen. Alle andere aanvraagmethoden worden altijd via het netwerk geproxied.

Levering van grote bestanden

Azure Front Door levert grote bestanden zonder een limiet voor de bestandsgrootte. Als caching is ingeschakeld, gebruikt Front Door een techniek die objectsegmentering wordt genoemd. Wanneer een groot bestand wordt aangevraagd, haalt Front Door kleinere stukken van het bestand op uit de oorsprong. Nadat Front Door een volledige aanvraag of bytebereikbestandsaanvraag heeft ontvangen, vraagt de Front Door-omgeving het bestand aan bij de oorsprong in segmenten van 8 MB.

Nadat het segment binnenkomt in de Azure Front Door-omgeving, wordt het in de cache opgeslagen en onmiddellijk aan de gebruiker geleverd. Front Door prefetches the next chunk in parallel. Deze prefetch zorgt ervoor dat de inhoud één segment voor de gebruiker blijft, waardoor de latentie wordt verminderd. Dit proces wordt voortgezet totdat het hele bestand wordt gedownload (indien aangevraagd) of de client sluit de verbinding. Lees RFC 7233 voor meer informatie over de bytebereikaanvraag.

Front Door slaat segmenten in de cache op terwijl ze worden ontvangen, zodat het hele bestand niet hoeft te worden opgeslagen in de Front Door-cache. Volgende aanvragen voor het bestand of bytebereik worden vanuit de cache verwerkt. Als de segmenten niet allemaal in de cache zijn opgeslagen, wordt prefetching gebruikt om segmenten van de oorsprong aan te vragen.

Deze optimalisatie is afhankelijk van de mogelijkheid van de oorsprong om bytebereikaanvragen te ondersteunen. Als de oorsprong geen ondersteuning biedt voor bytebereikaanvragen of als deze bereikaanvragen niet correct verwerkt, is deze optimalisatie niet effectief.

Wanneer uw oorsprong reageert op een aanvraag met een Range header, moet deze op een van de volgende manieren reageren:

  • Retourneert een bereikantwoord. Het antwoord moet HTTP-statuscode 206 gebruiken. Content-Range De antwoordheader moet ook aanwezig zijn en moet overeenkomen met de werkelijke lengte van de inhoud die uw oorsprong retourneert. Als uw oorsprong niet de juiste antwoordheaders met geldige waarden verzendt, slaat Azure Front Door het antwoord niet in de cache op en ziet u mogelijk inconsistent gedrag.

    Tip

    Als uw oorsprong het antwoord comprimeert, moet u ervoor zorgen dat de Content-Range headerwaarde overeenkomt met de werkelijke lengte van het gecomprimeerde antwoord.

  • Retourneert een niet-bereikd antwoord. Als uw oorsprong bereikaanvragen niet kan verwerken, kan deze de Range header negeren en een niet-gerangschikt antwoord retourneren. Zorg ervoor dat de oorsprong een andere antwoordstatuscode dan 206 retourneert. De oorsprong kan bijvoorbeeld een 200 OK-antwoord retourneren.

Als de oorsprong gebruikmaakt van Chunked Transfer Encoding (CTE) om gegevens te verzenden naar de Azure Front Door POP, worden antwoordgrootten groter dan 8 MB niet ondersteund.

Bestandscompressie

Raadpleeg de prestaties verbeteren door bestanden in Azure Front Door te comprimeren.

Azure Front Door (klassiek) kan inhoud dynamisch comprimeren aan de rand, wat resulteert in een kleinere en snellere reactietijd voor uw clients. Als u wilt dat een bestand in aanmerking komt voor compressie, moet caching zijn ingeschakeld en moet het bestand van een MIME-type zijn om in aanmerking te komen voor compressie. Momenteel staat Front Door (klassiek) niet toe dat deze lijst wordt gewijzigd. De huidige lijst is:

  • "application/eot"
  • "toepassing/lettertype"
  • "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"
  • "tekst/csv"
  • "text/html"
  • "text/javascript"
  • "text/js", "text/plain"
  • "tekst/richtext"
  • "tekst/door tabs gescheiden waarden"
  • "text/xml"
  • "text/x-script"
  • "text/x-component"
  • "text/x-java-source"

Daarnaast moet het bestand ook tussen 1 kB en 8 MB groot zijn, inclusief.

Deze profielen ondersteunen de volgende compressiecoderingen:

Als een aanvraag ondersteuning biedt voor gzip- en Brotli-compressie, heeft Brotli-compressie voorrang.

Wanneer een aanvraag voor een asset compressie opgeeft en de aanvraag resulteert in een cachemisser, wordt de asset rechtstreeks op de POP-server gecomprimeerd door Azure Front Door (klassiek). Daarna wordt het gecomprimeerde bestand uit de cache geleverd. Het resulterende item wordt geretourneerd met een Transfer-Encoding: chunked antwoordheader.

Als de oorsprong gebruikmaakt van Chunked Transfer Encoding (CTE) om gegevens te verzenden naar de Azure Front Door POP, wordt compressie niet ondersteund.

Notitie

Bereikaanvragen kunnen worden gecomprimeerd in verschillende grootten. Voor Azure Front Door moeten de waarden voor inhoudslengte hetzelfde zijn voor elke GET HTTP-aanvraag. Als clients bytebereikaanvragen verzenden met de Accept-Encoding header die leidt tot de oorsprong die reageert met verschillende inhoudslengten, retourneert Azure Front Door een 503-fout. U kunt compressie op de oorsprong uitschakelen of een regel voor de regelengine maken om de Accept-Encoding header te verwijderen uit de aanvraag voor bytebereikaanvragen.

Gedrag van queryreeksen

Met Azure Front Door kunt u bepalen hoe bestanden in de cache worden opgeslagen voor een webaanvraag die een queryreeks bevat.

In een webaanvraag met een querytekenreeks is de querytekenreeks dat deel van de aanvraag dat plaatsvindt na een vraagteken (?). Een querytekenreeks kan een of meer sleutel-waardeparen bevatten, waarin de veldnaam en de bijbehorende waarde worden gescheiden door een gelijkteken (=). Elk sleutel-waardepaar wordt gescheiden door een en-teken (&).

De URL http://www.contoso.com/content.mov?field1=value1&field2=value2 bevat bijvoorbeeld twee queryreeksen:

  • field1, met een waarde van value1.
  • field2, met een waarde van value2.

Als er meer dan één sleutel-waardepaar in een queryreeks van een aanvraag staat, maakt de volgorde niet uit.

Wanneer u caching configureert, geeft u op hoe de cache queryreeksen moet verwerken. Het volgende gedrag wordt ondersteund:

  • Queryreeks negeren: In deze modus geeft Azure Front Door de queryreeksen van de client door aan de oorsprong van de eerste aanvraag en wordt de asset in de cache opgeslagen. Toekomstige aanvragen voor de asset die worden geleverd vanuit de Front Door-omgeving negeren de queryreeksen totdat de asset in de cache verloopt.

  • Queryreeks gebruiken: in deze modus wordt elke aanvraag met een unieke URL, inclusief de querytekenreeks, behandeld als een unieke asset met een eigen cache. Het antwoord van de oorsprong voor een aanvraag voor een aanvraag www.example.ashx?q=test1 wordt bijvoorbeeld in de cache opgeslagen in de Front Door-omgeving en geretourneerd voor het uitgeven van caches met dezelfde queryreeks. Een aanvraag voor www.example.ashx?q=test2 een aanvraag wordt in de cache opgeslagen als een afzonderlijke asset met een eigen time-to-live-instelling.

    De volgorde van de queryreeksparameters maakt niet uit. Als de Azure Front Door-omgeving bijvoorbeeld een antwoord in de cache voor de URL www.example.ashx?q=test1&r=test2bevat, wordt er ook een aanvraag www.example.ashx?r=test2&q=test1 vanuit de cache verwerkt.

  • Opgegeven queryreeksen negeren en opgegeven queryreeksen opnemen: in deze modus kunt u Azure Front Door configureren om opgegeven parameters op te nemen of uit te sluiten wanneer de cachesleutel wordt gegenereerd.

    Stel dat de standaardcachesleutel is /foo/image/asset.htmlen dat er een aanvraag wordt ingediend bij de URL https://contoso.com/foo/image/asset.html?language=EN&userid=100&sessionid=200. Als er een regel voor de regelengine is om de userid querytekenreeksparameter uit te sluiten, is /foo/image/asset.html?language=EN&sessionid=200de cachesleutel van de queryreeks.

Configureer het gedrag van de queryreeks op de Front Door-route.

Cache leegmaken

Zie Cache opschonen in Azure Front Door voor meer informatie over het configureren van caches opschonen.

Azure Front Door slaat assets in de cache op totdat de time-to-live (TTL) van de asset verloopt. Wanneer een client een asset aanvraagt met verlopen TTL, haalt de Front Door-omgeving een nieuwe bijgewerkte kopie van de asset op om de aanvraag te verwerken en slaat vervolgens de vernieuwde cache op.

De aanbevolen procedure om ervoor te zorgen dat uw gebruikers altijd de meest recente kopie van uw assets verkrijgen, is om uw assets voor elke update te versieren en deze als nieuwe URL's te publiceren. Front Door haalt onmiddellijk de nieuwe assets op voor de volgende clientaanvragen. Soms wilt u inhoud in de cache opschonen van alle edge-knooppunten en ze allemaal dwingen om nieuwe bijgewerkte assets op te halen. De reden kan zijn vanwege updates voor uw webtoepassing of om assets die onjuiste informatie bevatten, snel bij te werken.

Schermopname van de knop en pagina voor het opschonen van de cache.

Selecteer de assets die u wilt opschonen van de edge-knooppunten. Als u alle assets wilt wissen, selecteert u Alles leegmaken. Anders voert u in Pad het pad in van elke asset die u wilt opschonen.

Deze indelingen worden ondersteund in de lijsten met paden om te leegmaken:

  • Eén pad opschonen: afzonderlijke assets opschonen door het volledige pad van de asset op te geven (zonder het protocol en domein), met de bestandsextensie, bijvoorbeeld /pictures/strasbourg.png;
  • Jokertekens opschonen: Sterretje (*) kan worden gebruikt als jokerteken. Verwijder alle mappen, submappen en bestanden onder een eindpunt met /* in het pad of verwijder alle submappen en bestanden onder een specifieke map door de map op te geven gevolgd door /*, bijvoorbeeld /pictures/*.
  • Hoofddomein opschonen: verwijder de hoofdmap van het eindpunt met '/' in het pad.

Notitie

Domeinen met jokertekens opschonen: het opgeven van paden in de cache voor opschonen, zoals beschreven in deze sectie, is niet van toepassing op domeinen met jokertekens die zijn gekoppeld aan de Front Door. Momenteel bieden we geen ondersteuning voor het rechtstreeks opschonen van jokertekendomeinen. U kunt paden uit specifieke subdomeinen opschonen door dat specifieke subdomein en het pad voor opschonen op te geven. Als mijn Front Door bijvoorbeeld heeft *.contoso.com, kan ik assets van mijn subdomein foo.contoso.com leegmaken door te typen foo.contoso.com/path/*. Op dit moment is het opgeven van hostnamen in het inhoudspad voor opschonen beperkt tot subdomeinen van jokertekendomeinen, indien van toepassing.

Cache-opschoningen op de Front Door zijn hoofdlettergevoelig. Daarnaast zijn ze agnostisch voor queryreeksen, wat betekent dat door het opschonen van een URL alle queryreeksvariaties ervan worden opgeschoond.

Verlooptijd van cache

De volgende volgorde van kopteksten wordt gebruikt om te bepalen hoe lang een item wordt opgeslagen in onze cache:

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

Sommige Cache-Control antwoordheaderwaarden geven aan dat het antwoord niet in de cache kan worden opgeslagen. Deze waarden omvatten private, no-cacheen no-store. Front Door houdt rekening met deze headerwaarden en slaat de antwoorden niet in de cache op, zelfs als u het cachinggedrag overschrijft met behulp van de regelengine.

Als de Cache-Control header niet aanwezig is in het antwoord van de oorsprong, bepaalt Front Door standaard willekeurig een cacheduur tussen één en drie dagen.

Notitie

De verlooptijd van de cache mag niet langer zijn dan 366 dagen.

Mogelijk ziet REVALIDATED_HIT u in de Cache-Control antwoordheader. Dit geeft aan dat de inhoud in de cache in Azure Front Door opnieuw is gevalideerd met de oorspronkelijke server voordat deze aan de client wordt geleverd. Dit kan gebeuren wanneer de inhoud in de cache is verlopen, maar de oorspronkelijke server aangeeft dat de inhoud niet is gewijzigd. In dit geval wordt de inhoud in de cache aan de client geleverd en wordt de vervaldatum van de cache opnieuw ingesteld.

Aanvraagheaders

De volgende aanvraagheaders worden niet doorgestuurd naar de oorsprong wanneer caching is ingeschakeld:

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

Responsheaders

Als het oorspronkelijke antwoord in de cache kan worden opgeslagen, wordt de Set-Cookie header verwijderd voordat het antwoord naar de client wordt verzonden. Als een origin-antwoord niet in de cache kan worden opgeslagen, wordt de header niet verwijderd door Front Door. Als het oorspronkelijke antwoord bijvoorbeeld een Cache-Control header bevat met een max-age waarde die aan Front Door aangeeft dat het antwoord in de cache kan worden opgeslagen en de Set-Cookie header wordt verwijderd.

Bovendien voegt Front Door de X-Cache header toe aan alle antwoorden. De X-Cache antwoordheader bevat een van de volgende waarden:

  • TCP_HIT of TCP_REMOTE_HIT: Het eerste segment van 8 MB van het antwoord is een cachetreffer en de inhoud wordt geleverd vanuit de Front Door-cache.
  • TCP_MISS: Het eerste segment van 8 MB van het antwoord is een cachemisser en de inhoud wordt opgehaald uit de oorsprong.
  • PRIVATE_NOSTORE: De aanvraag kan niet in de cache worden opgeslagen omdat de antwoordheader Cache-Control is ingesteld op privé of geen archief.
  • CONFIG_NOCACHE: Aanvraag is geconfigureerd om de cache niet in het Front Door-profiel op te geven.

Logboeken en rapporten

Het toegangslogboek bevat de cachestatus voor elke aanvraag. Rapporten bevatten ook informatie over hoe de cache van Azure Front Door wordt gebruikt in uw toepassing.

Het toegangslogboek bevat de cachestatus voor elke aanvraag.

Cachegedrag en duur

Cachegedrag en -duur kunnen worden geconfigureerd in de regelengine. De configuratie van de cache van de regelengine overschrijft altijd de routeconfiguratie.

  • Wanneer caching is uitgeschakeld, slaat Azure Front Door de inhoud van het antwoord niet in de cache op, ongeacht de richtlijnen voor het oorspronkelijke antwoord.

  • Wanneer caching is ingeschakeld, verschilt het cachegedrag, afhankelijk van de cachegedragswaarde die wordt toegepast door de regelengine:

    • Eer aan de oorsprong: Azure Front Door respecteert altijd de richtlijn voor de header van het antwoord van oorsprong. Als de oorsprongsrichtlijn ontbreekt, slaat Azure Front Door de inhoud ergens van één tot drie dagen in de cache op.
    • Overschrijven altijd: Azure Front Door overschrijft altijd met de cacheduur, wat betekent dat de inhoud voor de cacheduur wordt opgeslagen, waarbij de waarden uit de oorspronkelijke antwoordrichtlijnen worden genegeerd. Dit gedrag is alleen van toepassing als het antwoord in de cache kan worden opgeslagen.
    • Overschrijven als de oorsprong ontbreekt: Als de oorsprong geen TTL-waarden in de cache retourneert, gebruikt Azure Front Door de opgegeven cacheduur. Dit gedrag is alleen van toepassing als het antwoord in de cache kan worden opgeslagen.

Notitie

  • Azure Front Door garandeert niet hoe lang de inhoud in de cache wordt opgeslagen. Inhoud in de cache kan worden verwijderd uit de edge-cache voordat de inhoud verloopt als de inhoud niet vaak wordt gebruikt. Front Door kan mogelijk gegevens uit de cache leveren, zelfs als de gegevens in de cache zijn verlopen. Dit gedrag kan uw site helpen gedeeltelijk beschikbaar te blijven wanneer uw origins offline zijn.
  • Origins kunnen opgeven dat specifieke antwoorden niet in de cache moeten worden opgeslagen met behulp van de header Cache-Control met een waarde van geen cache, privé of geen archief. Wanneer Azure Front Door wordt gebruikt in een HTTP-antwoord van de oorspronkelijke server naar de Azure Front Door-POPs, ondersteunt cachebeheerrichtlijnen en wordt cachegedrag toegepast voor cachebeheerrichtlijnen in RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching (ietf.org).

Cachegedrag en -duur kunnen worden geconfigureerd in zowel de routeringsregel van de Front Door-ontwerper als in de regelengine. De configuratie van de cache van de regelengine overschrijft altijd de configuratie van de routeringsregel voor Front Door Designer.

  • Wanneer caching is uitgeschakeld, slaat Azure Front Door (klassiek) de inhoud van het antwoord niet in de cache op, ongeacht de richtlijnen voor oorsprongsreacties.

  • Wanneer caching is ingeschakeld, verschilt het cachegedrag voor verschillende waarden van de standaardduur van de cache gebruiken.

    • Wanneer de standaardduur van het gebruik van de cache is ingesteld op Ja, wordt in Azure Front Door (klassiek) altijd de instructie voor de antwoordheader van oorsprong uitgevoerd. Als de oorsprongsrichtlijn ontbreekt, slaat Front Door inhoud van één tot drie dagen in de cache op.
    • Wanneer de standaardduur van de cache is ingesteld op Nee, overschrijft Azure Front Door (klassiek) altijd de cacheduur (vereiste velden), wat betekent dat de inhoud voor de cacheduur wordt opgeslagen, waarbij de waarden uit de oorspronkelijke antwoordrichtlijnen worden genegeerd.

Notitie

  • Azure Front Door (klassiek) garandeert niet hoe lang de inhoud in de cache wordt opgeslagen. Inhoud in de cache kan worden verwijderd uit de edge-cache voordat de inhoud verloopt als de inhoud niet vaak wordt gebruikt. Azure Front Door (klassiek) kan mogelijk gegevens uit de cache verwerken, zelfs als de gegevens in de cache zijn verlopen. Dit gedrag kan uw site helpen gedeeltelijk beschikbaar te blijven wanneer uw origins offline zijn.
  • De cacheduur die is ingesteld in de routeringsregel voor Front Door Designer, is de minimale cacheduur. Deze onderdrukking werkt niet als de header van het cachebeheer van de oorsprong een hogere TTL heeft dan de onderdrukkingswaarde.

Volgende stappen