Delen via

Hoe caching werkt

  • Artikel

Belangrijk

Azure CDN Standard van Microsoft (klassiek) wordt op 30 september 2027 buiten gebruik gesteld. Om serviceonderbrekingen te voorkomen, is het belangrijk dat u uw Azure CDN Standard migreert van Microsoft-profielen (klassiek) naar de Azure Front Door Standard- of Premium-laag op 30 september 2027. Zie Azure CDN Standard van Microsoft (klassiek) buiten gebruik stellen voor meer informatie.

Azure CDN van Edgio wordt op 4 november 2025 buiten gebruik gesteld. U moet uw workload vóór deze datum migreren naar Azure Front Door om serviceonderbreking te voorkomen. Zie Azure CDN van de veelgestelde vragen over buitengebruikstelling van Edgio voor meer informatie.

Dit artikel bevat een overzicht van algemene cacheconcepten en hoe Azure Content Delivery Network caching gebruikt om de prestaties te verbeteren. Als u meer wilt weten over het aanpassen van cachegedrag op het eindpunt van het netwerk voor contentlevering, raadpleegt u Het cachegedrag van Azure Content Delivery Network beheren met regels voor caching en het cachegedrag van Azure Content Delivery Network beheren met queryreeksen.

Inleiding tot opslaan in cache

Caching is het proces van het lokaal opslaan van gegevens, zodat toekomstige aanvragen voor die gegevens sneller kunnen worden geopend. In het meest voorkomende type caching slaat een webbrowser kopieën van statische gegevens lokaal op een lokale harde schijf op. Door caching te gebruiken, kan de webbrowser voorkomen dat er meerdere retouren naar de server worden gemaakt en in plaats daarvan lokaal toegang krijgen tot dezelfde gegevens, waardoor tijd en resources worden bespaard. Caching is geschikt voor lokaal beheer van kleine, statische gegevens, zoals statische afbeeldingen, CSS-bestanden en JavaScript-bestanden.

Op dezelfde manier wordt caching gebruikt door een netwerk voor contentlevering op randservers dicht bij de gebruiker om aanvragen die teruggaan naar de oorsprong te voorkomen en de latentie van eindgebruikers te verminderen. In tegenstelling tot een webbrowsercache, die alleen voor één gebruiker wordt gebruikt, heeft het netwerk voor contentlevering een gedeelde cache. In een gedeelde cache van een netwerk voor contentlevering kan een bestandsaanvraag door een gebruiker worden gebruikt door een andere gebruiker, waardoor het aantal aanvragen voor de oorspronkelijke server aanzienlijk afneemt.

Dynamische resources die regelmatig worden gewijzigd of uniek zijn voor een afzonderlijke gebruiker, kunnen niet in de cache worden opgeslagen. Deze typen resources kunnen echter profiteren van dynamische siteversnelling (DSA) optimalisatie op het Azure-netwerk voor contentlevering voor prestatieverbeteringen.

Caching kan zich voordoen op meerdere niveaus tussen de oorspronkelijke server en de eindgebruiker:

  • Webserver: maakt gebruik van een gedeelde cache (voor meerdere gebruikers).
  • Netwerk voor contentlevering: maakt gebruik van een gedeelde cache (voor meerdere gebruikers).
  • Internetprovider (ISP): Maakt gebruik van een gedeelde cache (voor meerdere gebruikers).
  • Webbrowser: maakt gebruik van een privécache (voor één gebruiker).

Elke cache beheert doorgaans zijn eigen resource-versheid en voert validatie uit wanneer een bestand verouderd is. Dit gedrag wordt gedefinieerd in de HTTP-cachespecificatie RFC 7234.

Nieuwheid van resources

Omdat een resource in de cache mogelijk verouderd of verouderd kan zijn (vergeleken met de bijbehorende resource op de oorspronkelijke server), is het belangrijk dat elk cachemechanisme bepaalt wanneer inhoud wordt vernieuwd. Om tijd en bandbreedteverbruik te besparen, wordt een resource in de cache niet vergeleken met de versie op de oorspronkelijke server wanneer deze wordt geopend. Zolang een resource in de cache als nieuw wordt beschouwd, wordt ervan uitgegaan dat deze de meest recente versie is en rechtstreeks naar de client wordt verzonden. Een resource in de cache wordt beschouwd als nieuw wanneer de leeftijd lager is dan de leeftijd of periode die is gedefinieerd door een cache-instelling. Wanneer een browser bijvoorbeeld een webpagina opnieuw laadt, wordt gecontroleerd of elke resource in de cache op uw harde schijf vers is en laadt. Als de resource niet vers (verouderd) is, wordt een up-to-date kopie van de server geladen.

Validatie

Als een resource als verouderd wordt beschouwd, wordt de oorspronkelijke server gevraagd deze te valideren om te bepalen of de gegevens in de cache nog steeds overeenkomen met wat zich op de oorspronkelijke server bevindt. Als het bestand is gewijzigd op de oorspronkelijke server, werkt de cache de versie van de resource bij. Als de resource anders vers is, worden de gegevens rechtstreeks vanuit de cache geleverd zonder deze eerst te valideren.

Netwerkcaching van inhoudslevering

Caching is een integraal onderdeel van de manier waarop een netwerk voor contentlevering werkt om de levering te versnellen en de belasting van oorsprong te verminderen voor statische assets, zoals afbeeldingen, lettertypen en video's. In cacheopslag van inhoudsleveringsnetwerk worden statische resources selectief opgeslagen op strategisch geplaatste servers die lokaaler zijn voor een gebruiker en bieden de volgende voordelen:

  • Omdat het meeste webverkeer statisch is (bijvoorbeeld afbeeldingen, lettertypen en video's), vermindert caching van het netwerk voor contentlevering de netwerklatentie door inhoud dichter bij de gebruiker te plaatsen, waardoor de afstand tussen gegevens wordt verminderd.

  • Door werk naar een netwerk voor contentlevering te offloaden, kan caching het netwerkverkeer en de belasting op de oorspronkelijke server verminderen. Als u dit doet, worden de kosten en resourcevereisten voor de toepassing verlaagd, zelfs wanneer er grote aantallen gebruikers zijn.

Net zoals caching wordt geïmplementeerd in een webbrowser, kunt u bepalen hoe caching wordt uitgevoerd in een netwerk voor contentlevering door headers van cache-instructies te verzenden. Headers van cache-instructies zijn HTTP-headers, die doorgaans worden toegevoegd door de oorspronkelijke server. Hoewel de meeste van deze headers oorspronkelijk zijn ontworpen om caching in clientbrowsers aan te pakken, worden ze nu ook gebruikt door alle tussenliggende caches, zoals netwerken voor contentlevering.

Er kunnen twee headers worden gebruikt om de versheid van de cache te definiëren: Cache-Control en Expires. Cache-Control is actueler en heeft voorrang op Expires, als beide bestaan. Er zijn ook twee typen headers die worden gebruikt voor validatie (validatieprogramma's genoemd): ETag en Last-Modified. ETag is actueler en heeft voorrang op Last-Modified, als beide zijn gedefinieerd.

Headers voor cache-instructie

Belangrijk

Standaard negeert een Azure Content Delivery Network-eindpunt dat is geoptimaliseerd voor DSA cache-instructieheaders en slaat caching over. Voor Azure CDN Standard van Edgio-profielen kunt u aanpassen hoe een Azure Content Delivery Network-eindpunt deze headers behandelt met behulp van regels voor netwerkcaching van contentlevering om caching mogelijk te maken. Alleen voor Azure CDN Premium van Edgio-profielen gebruikt u de regelengine om caching in te schakelen.

Azure Content Delivery Network ondersteunt de volgende headers van de HTTP-cacherichtlijn, waarmee de cacheduur en het delen van de cache worden gedefinieerd.

Cachebeheer:

  • Geïntroduceerd in HTTP 1.1 om webuitgevers meer controle te geven over hun inhoud en om de beperkingen van de Expires header aan te pakken.
  • Hiermee wordt de Expires header overschreven als deze zowel als Cache-Control zijn gedefinieerd.
  • Wanneer deze wordt gebruikt in een HTTP-aanvraag van de client naar het POP-netwerk voor contentlevering, Cache-Control wordt deze standaard genegeerd door alle Azure Content Delivery Network-profielen.
  • Wanneer deze wordt gebruikt in een HTTP-antwoord van de oorspronkelijke server naar de POP voor contentleveringsnetwerk:

Verloopt:

  • Verouderde header geïntroduceerd in HTTP 1.0; ondersteund voor compatibiliteit met eerdere versies.
  • Gebruikt een vervaldatum op basis van een datum met een tweede precisie.
  • Vergelijkbaar met Cache-Control: max-age.
  • Wordt gebruikt wanneer Cache-Control deze niet bestaat.

Pragma:

  • Niet gehonoreerd door Azure Content Delivery Network, standaard.
  • Verouderde header geïntroduceerd in HTTP 1.0; ondersteund voor compatibiliteit met eerdere versies.
  • Wordt gebruikt als clientaanvraagheader met de volgende instructie: no-cache. Deze instructie geeft de server de opdracht om een nieuwe versie van de resource te leveren.
  • Pragma: no-cache is equivalent aan Cache-Control: no-cache.

Validators

Wanneer de cache verouderd is, worden geldige HTTP-cachevalidators gebruikt om de versie van een bestand in de cache te vergelijken met de versie op de oorspronkelijke server. Azure CDN Standard/Premium van Edgio ondersteunt standaard zowel ETag Last-Modified als validators, terwijl Azure CDN Standard van Microsoft alleen Last-Modifiedondersteunt.

ETag:

  • Azure CDN Standard/Premium van Edgio biedt standaard ondersteuning ETag voor Azure CDN Standard van Microsoft .
  • ETag definieert een tekenreeks die uniek is voor elk bestand en elke versie van een bestand. Bijvoorbeeld: ETag: "17f0ddd99ed5bbe4edffdd6496d7131f".
  • Geïntroduceerd in HTTP 1.1 en is actueler dan Last-Modified. Handig wanneer de laatste wijzigingsdatum moeilijk te bepalen is.
  • Ondersteunt zowel sterke validatie als zwakke validatie; Azure Content Delivery Network ondersteunt echter alleen sterke validatie. Voor sterke validatie moeten de twee resourceweergaven byte-for-byte identiek zijn.
  • Een cache valideert een bestand dat wordt gebruikt ETag door een If-None-Match header te verzenden met een of meer ETag validators in de aanvraag. Bijvoorbeeld: If-None-Match: "17f0ddd99ed5bbe4edffdd6496d7131f". Als de versie van de server overeenkomt met een ETag validator in de lijst, wordt statuscode 304 (niet gewijzigd) verzonden in het antwoord. Als de versie anders is, reageert de server met statuscode 200 (OK) en de bijgewerkte resource.

Laatst gewijzigd:

  • Alleen voor Azure CDN Standard/Premium van Edgio Last-Modified wordt gebruikt als ETag dit geen deel uitmaakt van het HTTP-antwoord.
  • Hiermee geeft u de datum en tijd op waarop de oorspronkelijke server heeft vastgesteld dat de resource voor het laatst is gewijzigd. Bijvoorbeeld: Last-Modified: Thu, 19 Oct 2017 09:28:00 GMT.
  • Voor inhoud die groter is dan 8 MB, moeten de oorspronkelijke back-endservers consistente Last-Modified tijdstempels per asset onderhouden. Het retourneren van inconsistente Last-Modified tijden van back-endservers veroorzaakt fouten die niet overeenkomen met de validator en resulteert in HTTP 5XX-fouten. Azure Storage biedt mogelijk geen ondersteuning voor consistente Last-Modified tijdstempels voor replica's, waardoor vergelijkbare validatiefouten niet overeenkomen.
  • Een cache valideert een bestand met behulp van Last-Modified een If-Modified-Since header met een datum en tijd in de aanvraag. De oorspronkelijke server vergelijkt die datum met de Last-Modified header van de meest recente resource. Als de resource sinds de opgegeven tijd niet is gewijzigd, retourneert de server statuscode 304 (Niet gewijzigd) in het antwoord. Als de resource is gewijzigd, retourneert de server statuscode 200 (OK) en de bijgewerkte resource.

Bepalen welke bestanden in de cache kunnen worden opgeslagen

Niet alle resources kunnen in de cache worden opgeslagen. In de volgende tabel ziet u welke resources in de cache kunnen worden opgeslagen, op basis van het type HTTP-antwoord. Resources die worden geleverd met HTTP-antwoorden die niet aan al deze voorwaarden voldoen, kunnen niet in de cache worden opgeslagen. Voor Alleen Azure CDN Premium van Edgio kunt u de regelengine gebruiken om een aantal van deze voorwaarden aan te passen.

Azure Content Delivery Network van Microsoft Azure Content Delivery Network van Edgio
HTTP-statuscode 200, 203, 206, 300, 301, 410, 416 200
HTTP-methoden GET, HEAD GET
Limieten voor bestandsgrootte 300 GB 300 GB

Voor Azure CDN Standard van Microsoft-caching om te kunnen werken aan een resource, moet de oorspronkelijke server ONDERSTEUNING bieden voor HEAD- en GET HTTP-aanvragen en moeten de waarden voor inhoudslengte hetzelfde zijn voor HEAD- en GET HTTP-antwoorden voor de asset. Voor een HEAD-aanvraag moet de oorspronkelijke server de HEAD-aanvraag ondersteunen en met dezelfde headers reageren alsof deze een GET-aanvraag heeft ontvangen.

Notitie

Aanvragen met autorisatieheader worden niet in de cache opgeslagen.

Standaardgedrag voor opslaan in cache

In de volgende tabel wordt het standaardgedrag voor caching voor de Azure Content Delivery Network-producten en de bijbehorende optimalisaties beschreven.

Microsoft: Algemene weblevering Edgio: Algemene weblevering Edgio: DSA
Eer oorsprong Ja Ja Nr.
Duur van de netwerkcache voor contentlevering Twee dagen Zeven dagen Geen

Eer de oorsprong: geeft aan of de ondersteunde headers voor cache-instructie moeten worden uitgevoerd als deze bestaan in het HTTP-antwoord van de oorspronkelijke server.

Duur van cdn-cache: hiermee geeft u de hoeveelheid tijd op waarvoor een resource in de cache wordt opgeslagen in het Azure-netwerk voor contentlevering. Als honor-oorsprong echter Ja is en het HTTP-antwoord van de oorspronkelijke server de header cache-instructie Expires bevat of Cache-Control: max-age, gebruikt Azure Content Delivery Network in plaats daarvan de duurwaarde die is opgegeven door de header.

Notitie

Azure Content Delivery Network garandeert geen minimale tijdsduur die het object in de cache zal worden opgeslagen. Inhoud in de cache kan worden verwijderd uit de netwerkcache voor contentlevering voordat deze zijn verlopen als de inhoud niet zo vaak wordt aangevraagd om ruimte te maken voor meer gevraagde inhoud.

Volgende stappen