Megosztás a következőn keresztül:


A gyorsítótárazás működése

Fontos

A Microsofttól (klasszikus) származó Azure CDN Standard 2027. szeptember 30-án megszűnik. A szolgáltatáskimaradások elkerülése érdekében fontos, hogy az Azure CDN Standardot 2027. szeptember 30-ig migrálja a Microsoft (klasszikus) profiljaiból az Azure Front Door Standard vagy a Premium szintre. További információ: Azure CDN Standard a Microsoft (klasszikus) kivonásáról.

Az Edgio-ból származó Azure CDN 2025. november 4-én megszűnik. A szolgáltatáskimaradás elkerülése érdekében a számítási feladatot a dátum előtt át kell telepítenie az Azure Front Doorba. További információ: Azure CDN az Edgio kivonásáról – gyakori kérdések.

Ez a cikk áttekintést nyújt az általános gyorsítótárazási fogalmakról, valamint arról, hogy az Azure Content Delivery Network hogyan használja a gyorsítótárazást a teljesítmény javítása érdekében. Ha szeretné megtudni, hogyan szabhatja testre a gyorsítótárazási viselkedést a tartalomkézbesítési hálózati végponton, olvassa el az Azure Content Delivery Network gyorsítótárazási viselkedésének szabályozása gyorsítótárazási szabályokkal és az Azure Content Delivery Network gyorsítótárazási viselkedésének vezérlése lekérdezési sztringekkel.

Bevezetés a gyorsítótárazásba

A gyorsítótárazás az adatok helyi tárolásának folyamata, hogy az adatokra vonatkozó jövőbeli kérések gyorsabban elérhetők legyenek. A gyorsítótárazás leggyakoribb típusában, a webböngésző gyorsítótárazásával a webböngésző helyben tárolja a statikus adatok másolatát egy helyi merevlemezen. A gyorsítótárazás használatával a webböngésző elkerülheti a kiszolgálóra való több oda-vissza utazást, és ehelyett helyben érheti el ugyanazokat az adatokat, így időt és erőforrásokat takaríthat meg. A gyorsítótárazás kiválóan alkalmas kis méretű, statikus adatok, például statikus képek, CSS-fájlok és JavaScript-fájlok helyi kezelésére.

Hasonlóképpen, a gyorsítótárazást egy tartalomkézbesítési hálózat használja a felhasználóhoz közeli peremkiszolgálókon, hogy elkerülje a forráshoz visszafelé irányuló kéréseket, és csökkentse a végfelhasználói késést. A csak egyetlen felhasználó számára használt webböngésző-gyorsítótárral ellentétben a tartalomkézbesítési hálózat megosztott gyorsítótárral rendelkezik. A tartalomkézbesítési hálózat megosztott gyorsítótárában a felhasználó által küldött fájlkéréseket egy másik felhasználó használhatja, ami jelentősen csökkenti a forráskiszolgálóra irányuló kérések számát.

A gyakran változó vagy az egyes felhasználókra egyedi dinamikus erőforrások nem gyorsítótárazhatók. Az ilyen típusú erőforrások azonban kihasználhatják a dinamikus helygyorsítás (DSA) optimalizálását az Azure tartalomkézbesítési hálózatán a teljesítmény javítása érdekében.

A gyorsítótárazás több szinten is történhet a forráskiszolgáló és a végfelhasználó között:

  • Webkiszolgáló: Megosztott gyorsítótárat használ (több felhasználó számára).
  • Tartalomkézbesítési hálózat: Megosztott gyorsítótárat használ (több felhasználó számára).
  • Internetszolgáltató (ISP): Megosztott gyorsítótárat használ (több felhasználó számára).
  • Webböngésző: Privát gyorsítótárat használ (egy felhasználó számára).

Minden gyorsítótár általában a saját erőforrás-frissességét kezeli, és ellenőrzi, hogy egy fájl elavult-e. Ezt a viselkedést az RFC 7234 HTTP-gyorsítótárazási specifikációja határozza meg.

Erőforrás frissessége

Mivel a gyorsítótárazott erőforrások esetleg elavultak vagy elavultak lehetnek (a forráskiszolgálón lévő megfelelő erőforráshoz képest), fontos, hogy a gyorsítótárazási mechanizmus szabályozhassa, hogy a tartalom mikor kapjon frissítést. Az idő- és sávszélesség-felhasználás megtakarítása érdekében a gyorsítótárazott erőforrások nem lesznek összehasonlítva a forráskiszolgálón lévő verzióval minden alkalommal, amikor hozzáférnek. Ehelyett, amíg a gyorsítótárazott erőforrás frissnek minősül, feltételezzük, hogy ez a legújabb verzió, és közvetlenül az ügyfélnek küldi el. A gyorsítótárazott erőforrások akkor tekinthetők frissnek, ha az életkora kisebb, mint a gyorsítótár-beállítás által meghatározott kor vagy időszak. Ha például egy böngésző újra betölt egy weblapot, ellenőrzi, hogy a merevlemezen lévő összes gyorsítótárazott erőforrás friss-e, és betölti-e. Ha az erőforrás nem friss (elavult), a rendszer betölt egy naprakész másolatot a kiszolgálóról.

Érvényesítés

Ha egy erőforrás elavultnak minősül, a forráskiszolgálót megkéri annak ellenőrzésére, hogy a gyorsítótárban lévő adatok továbbra is megegyeznek-e a forráskiszolgálón található adatokkal. Ha a fájlt módosították a forráskiszolgálón, a gyorsítótár frissíti az erőforrás verzióját. Ellenkező esetben, ha az erőforrás friss, az adatok közvetlenül a gyorsítótárból lesznek kézbesítve anélkül, hogy először érvényesíteni volna azokat.

Tartalomkézbesítési hálózati gyorsítótárazás

A gyorsítótárazás szerves része a tartalomkézbesítési hálózat működésének, hogy felgyorsítsa a kézbesítést, és csökkentse a statikus objektumok, például képek, betűtípusok és videók forrásterhelését. A tartalomkézbesítési hálózati gyorsítótárazás során a statikus erőforrások szelektíven vannak tárolva a felhasználó számára helyibb, stratégiailag elhelyezett kiszolgálókon, és az alábbi előnyöket nyújtják:

  • Mivel a webes forgalom nagy része statikus (például képek, betűtípusok és videók), a tartalomkézbesítési hálózat gyorsítótárazása csökkenti a hálózati késést azáltal, hogy közelebb helyezi a tartalmat a felhasználóhoz, ezáltal csökkenti az adatforgalom távolságát.

  • A munka tartalomkézbesítési hálózatra való kiszervezésével a gyorsítótárazás csökkentheti a hálózati forgalmat és a forráskiszolgáló terhelését. Ez csökkenti az alkalmazás költségeit és erőforrás-követelményeit, még akkor is, ha nagy számú felhasználó van.

A gyorsítótárazás webböngészőben való implementálásához hasonlóan a gyorsítótárazási irányelv fejléceinek küldésével szabályozhatja a tartalomkézbesítési hálózaton történő gyorsítótárazást. A gyorsítótár-irányelv fejlécei HTTP-fejlécek, amelyeket általában a forráskiszolgáló ad hozzá. Bár a fejlécek többsége eredetileg az ügyfélböngészők gyorsítótárazásának kezelésére készült, most már az összes köztes gyorsítótár, például a tartalomkézbesítési hálózatok is használják őket.

A gyorsítótár frissességének meghatározásához két fejléc használható: Cache-Control és Expires. Cache-Control aktuálisabb, és elsőbbséget Expiresélvez, ha mindkettő létezik. Az ellenőrzéshez két fejléctípus (úgynevezett érvényesítő) is használható: ETag és Last-Modified. ETag aktuálisabb, és elsőbbséget Last-Modifiedélvez, ha mindkettő definiálva van.

Gyorsítótár-irányelv fejlécei

Fontos

Alapértelmezés szerint a DSA-hoz optimalizált Azure Content Delivery Network-végpont figyelmen kívül hagyja a gyorsítótár-irányelv fejléceit és a gyorsítótárazást. Az Edgio-profilokból származó Azure CDN Standard esetében módosíthatja, hogy egy Azure Content Delivery Network-végpont hogyan kezeli ezeket a fejléceket a tartalomkézbesítési hálózati gyorsítótárazási szabályok használatával a gyorsítótárazás engedélyezéséhez. Csak Edgio-profilokból származó Azure CDN Premium esetén a szabálymotor használatával engedélyezheti a gyorsítótárazást.

Az Azure Content Delivery Network az alábbi HTTP-gyorsítótár-irányelv fejléceket támogatja, amelyek meghatározzák a gyorsítótár időtartamát és a gyorsítótár megosztását.

Gyorsítótár-vezérlés:

  • A HTTP 1.1-ben bevezetésre került, hogy a webes közzétevők jobban szabályozhassák a tartalmakat, és kezelni tudják a fejléc korlátait Expires .
  • Felülbírálja a Expires fejlécet, ha mindkettő Cache-Control és definiálva van.
  • Ha az ügyféltől a pop tartalomkézbesítési hálózatra irányuló HTTP-kérésben használják, Cache-Control a rendszer alapértelmezés szerint figyelmen kívül hagyja az összes Azure Content Delivery Network-profilt.
  • Ha a forráskiszolgálóról a POP tartalomkézbesítési hálózatra küldött HTTP-válaszban használják:
    • Az Edgio Azure CDN Standard/Premium és a Microsoft Azure CDN Standard szolgáltatása minden Cache-Control irányelvet támogat.
    • Az Edgio Azure CDN Standard/Premium és a Microsoft Azure CDN Standardja az RFC 7234 – Hypertext Transfer Protocol (HTTP/1.1): Gyorsítótárazási (ietf.org) irányelvek gyorsítótárazási viselkedését tiszteletben tartja.

Lejár:

  • A HTTP 1.0-ban bevezetett örökölt fejléc; támogatja a visszamenőleges kompatibilitást.
  • Dátumalapú lejárati időt használ második pontossággal.
  • Hasonló a .Cache-Control: max-age
  • Akkor használatos, ha Cache-Control nem létezik.

Pragma:

  • Alapértelmezés szerint az Azure Content Delivery Network nem tartja tiszteletben.
  • A HTTP 1.0-ban bevezetett örökölt fejléc; támogatja a visszamenőleges kompatibilitást.
  • Ügyfélkérés fejléceként a következő irányelvvel használható: no-cache. Ez az irányelv arra utasítja a kiszolgálót, hogy adja meg az erőforrás új verzióját.
  • Pragma: no-cacheegyenértékű a .-nak.Cache-Control: no-cache

Érvényesítők

Ha a gyorsítótár elavult, a HTTP-gyorsítótár-érvényesítők a fájl gyorsítótárazott verzióját hasonlítják össze a forráskiszolgálón lévő verzióval. Az Edgio Azure CDN Standard/Premium alapértelmezés szerint támogatja a két ETag és Last-Modified az érvényesítőt, míg a Microsofttól származó Azure CDN Standard csak Last-Modified.

ETag:

  • Az Edgio Azure CDN Standard/Premium szolgáltatása alapértelmezés szerint támogatja ETag , míg a Microsofttól származó Azure CDN Standard nem.
  • ETag a fájl minden fájljára és verziójára egyedi sztringet határoz meg. Például: ETag: "17f0ddd99ed5bbe4edffdd6496d7131f".
  • A HTTP 1.1-ben bevezetett és aktuálisabb, mint Last-Modifieda . Akkor hasznos, ha az utolsó módosítás dátuma nehezen határozható meg.
  • Támogatja az erős és a gyenge ellenőrzést is; Az Azure Content Delivery Network azonban csak az erős ellenőrzést támogatja. Az erős ellenőrzéshez a két erőforrás-ábrázolásnak bájtonként azonosnak kell lennie.
  • A gyorsítótár egy olyan fájlt érvényesít, amely ETag egy fejléc elküldésével If-None-Match egy vagy több ETag érvényesítőt küld a kérelemben. Például: If-None-Match: "17f0ddd99ed5bbe4edffdd6496d7131f". Ha a kiszolgáló verziója megegyezik a ETag listán szereplő érvényesítővel, a válaszában a 304-es (nem módosított) állapotkódot küldi el. Ha a verzió eltér, a kiszolgáló a 200-es állapotkóddal (OK) és a frissített erőforrással válaszol.

Utolsó módosítás:

  • Csak az Edgio-ból származó Azure CDN Standard/Premium esetén használható, Last-Modified ha ETag nem része a HTTP-válasznak.
  • Azt a dátumot és időpontot adja meg, amikor a forráskiszolgáló megállapította, hogy az erőforrást utoljára módosították. Például: Last-Modified: Thu, 19 Oct 2017 09:28:00 GMT.
  • A 8 MB-nál nagyobb tartalom esetén a forrás háttérkiszolgálóinak konzisztens Last-Modified időbélyegeket kell fenntartaniuk eszközenként. Ha inkonzisztens Last-Modified időpontokat ad vissza a háttérkiszolgálóktól, akkor a validátorok nem egyeznek, és HTTP 5XX-hibákhoz vezetnek. Előfordulhat, hogy az Azure Storage nem támogatja a replikák konzisztens Last-Modified időbélyegeit, ami hasonló érvényesítési eltérési hibákat okozhat.
  • A gyorsítótár a kérésben szereplő dátummal és időponttal rendelkező fejléc küldésével If-Modified-Since ellenőrzi a fájlokatLast-Modified. A forráskiszolgáló összehasonlítja ezt a dátumot a Last-Modified legújabb erőforrás fejlécével. Ha az erőforrás a megadott idő óta nem lett módosítva, a kiszolgáló a válaszában a 304-as állapotkódot adja vissza (nem módosítva). Ha az erőforrás módosult, a kiszolgáló a 200-ás állapotkódot (OK) és a frissített erőforrást adja vissza.

A gyorsítótárazható fájlok meghatározása

Nem minden erőforrás gyorsítótárazható. Az alábbi táblázat azt mutatja be, hogy milyen erőforrások gyorsítótárazhatók a HTTP-válasz típusa alapján. A HTTP-válaszokkal szállított erőforrások, amelyek nem felelnek meg az összes feltételnek, nem gyorsítótárazhatók. Csak az Edgio-ból származó Azure CDN Premium esetében a szabálymotor használatával testre szabhat néhány feltételt.

Azure Content Delivery Network a Microsofttól Azure Content Delivery Network az Edgio-tól
HTTP-állapotkódok 200, 203, 206, 300, 301, 410, 416 200
HTTP-metódusok GET, HEAD KAP
Fájlméretkorlátok 300 GB 300 GB

Ahhoz , hogy a Microsoft gyorsítótárazással rendelkező Azure CDN Standard működjön egy erőforráson, a forráskiszolgálónak támogatnia kell a HEAD- és GET HTTP-kéréseket, és a tartalomhossz-értékeknek meg kell egyeznie az eszköz head és GET HTTP-válaszaival. HEAD-kérés esetén a forráskiszolgálónak támogatnia kell a HEAD-kérést, és ugyanolyan fejlécekkel kell válaszolnia, mintha GET kérést kapott volna.

Feljegyzés

Az engedélyezési fejlécet tartalmazó kérések nem lesznek gyorsítótárazva.

Alapértelmezett gyorsítótárazási viselkedés

Az alábbi táblázat az Azure Content Delivery Network-termékek alapértelmezett gyorsítótárazási viselkedését és azok optimalizálását ismerteti.

Microsoft: Általános webkézbesítés Edgio: Általános webkézbesítés Edgio: DSA
Becsület eredete Igen Igen Nem
tartalomkézbesítési hálózati gyorsítótár időtartama Két nap Hét nap Egyik sem

Becsület forrása: Meghatározza, hogy a támogatott gyorsítótár-direktíva fejléceket tiszteletben kell-e tartani, ha a forráskiszolgáló HTTP-válaszában léteznek.

CDN-gyorsítótár időtartama: Azt az időtartamot határozza meg, amely alatt az erőforrás gyorsítótárazva van az Azure tartalomkézbesítési hálózaton. Ha azonban a Honor eredete Igen, és a forráskiszolgáló HTTP-válasza tartalmazza a gyorsítótár-direktíva fejlécét Expires , vagy Cache-Control: max-ageaz Azure Content Delivery Network a fejléc által megadott időtartamértéket használja.

Feljegyzés

Az Azure Content Delivery Network nem garantálja az objektum gyorsítótárban való tárolásának minimális időtartamát. Előfordulhat, hogy a gyorsítótárazott tartalom ki lesz távolítva a tartalomkézbesítési hálózati gyorsítótárból a lejáratuk előtt, ha a tartalom nem kér olyan gyakran, hogy helyet biztosítsunk a gyakrabban kért tartalmaknak.

Következő lépések