Szinte minden webhely sebességének optimalizálására szolgáló cikkben vagy eszközben található egy szerény „CDN használata” záradék. Általában a CDN egy tartalomszolgáltató hálózat vagy tartalomszolgáltató hálózat. Mi, a Method Lab munkatársai gyakran találkozunk ügyfelek kérdéseivel ebben a témában; néhányuk lehetővé teszi a saját CDN-t. Ennek a cikknek az a célja, hogy megértsük, mit tud nyújtani a CDN a webhely betöltési sebessége szempontjából, milyen problémák merülhetnek fel, és milyen esetekben indokolt a CDN használata.
![[Ne] használjon CDN-t](https://prohoster.info/wp-content/plugins/wp-fastest-cache-premium/pro/images/blank.gif)
A képen bekarikázott késéseket CDN használata okozza.
Egy kis történelem
Mint sok technológia, a CDN-ek is szükségből jöttek létre. Az internetezők körében az internetes csatornák fejlődésével megjelentek az online videószolgáltatások. A videotartalom természetesen nagyságrendekkel nagyobb sávszélességet igényel, mint a normál webhelytartalom (képek, szöveg, CSS vagy JS kód).
Ha egy videofolyamot párhuzamosan próbálunk sugározni több kliensnek egy szerverről, akkor valószínűleg a szerver internetes csatornája lesz a szűk keresztmetszet. Általában néhány ezer szál elegendő egy tipikus szervercsatorna eltömítéséhez. Természetesen lehetnek más erőforrás-korlátozások, de ezek jelenleg nem fontosak. Az is fontos, hogy a szervercsatorna bővítése túl drága (és néha lehetetlen), és nem is praktikus. Az adások alatt a csatorna terhelése ciklikus lesz.
Az egyes szerverek csatornájának korlátozásának problémáját a CDN tökéletesen megoldja. Az ügyfelek nem közvetlenül a szerverhez csatlakoznak, hanem a CDN-hálózat csomópontjaihoz. Ideális esetben a szerver egy adatfolyamot küld a CDN-csomópontnak, majd a hálózat saját erőforrásait használja, hogy ezt a folyamot sok felhasználóhoz eljuttassa. Gazdasági szempontból csak a ténylegesen felhasznált erőforrásokért fizetünk (ez lehet sávszélesség vagy forgalom), és szolgáltatásunk kiváló skálázhatóságát kapja. A CDN használata nehéz tartalom szállítására teljesen indokolt és logikus. Bár érdemes megjegyezni, hogy ezen a téren a legnagyobb szereplők (pl. Netflix) saját CDN-eket építenek a nagy kereskedelmi CDN-ek (Akamai, Cloudflare, Fastly stb.) helyett.
A web fejlődésével maguk a webalkalmazások is összetettebbé és összetettebbé váltak. A rakodási sebesség problémája került előtérbe. A webhelysebesség-rajongók gyorsan azonosítottak néhány olyan fő problémát, amelyek miatt a webhelyek lassan töltődtek be. Az egyik a hálózati késések (RTT - oda-vissza út vagy ping idő). A késések számos folyamatot érintenek a webhely betöltésénél: TCP-kapcsolat létrehozása, TLS-munkamenet indítása, minden egyes erőforrás (kép, JS-fájl, HTML-dokumentum stb.) betöltése.
A problémát súlyosbította, hogy a HTTP/1.1 protokoll használatakor (az SPDY, QUIC és HTTP/2 megjelenése előtt ez volt az egyetlen lehetőség) a böngészők legfeljebb 6 TCP-kapcsolatot nyitnak meg egy gazdagéphez. Mindez csatlakozási leálláshoz és a csatorna sávszélességének nem megfelelő kihasználásához vezetett. A problémát részben megoldotta a tartomány felosztása – további gazdagépek létrehozása a kapcsolatok számának korlátozása érdekében.
Itt jelenik meg a CDN második képessége - a késleltetés (RTT) csökkentése a nagy számú pont és a csomópontok felhasználóhoz való közelsége miatt. Itt a távolság döntő szerepet játszik: a fény sebessége korlátozott (optikai szálban kb. 200 000 km/s). Ez azt jelenti, hogy minden 1000 km-es utazás 5 ms késéssel vagy 10 ms-tal növeli az RTT-t. Ez az átvitelhez szükséges minimális idő, mivel a közbenső berendezéseken is vannak késések. Mivel a CDN általában tudja, hogyan kell az objektumokat gyorsítótárba helyezni a szerverein, előnyös lehet az ilyen objektumok CDN-en keresztüli betöltése. Ehhez szükséges feltételek: az objektum jelenléte a gyorsítótárban, a CDN-pont közelsége a felhasználóhoz a webalkalmazás-szerverhez (origin server) képest. Fontos megérteni, hogy a CDN-csomópont földrajzi közelsége nem garantálja az alacsony késleltetést. A kliens és a CDN közötti útválasztás úgy is megépíthető, hogy az ügyfél egy másik országban, esetleg egy másik kontinensen lévő gazdagéphez csatlakozzon. Itt jön képbe a távközlési szolgáltatók és a CDN szolgáltatás kapcsolata (peering, kapcsolatok, részvétel a IX-ben stb.), illetve magának a CDN-nek a forgalomirányítási politikája. Például a Cloudflare két kezdeti csomag (ingyenes és olcsó) használatakor nem garantálja a tartalom kézbesítését a legközelebbi gazdagéptől – a gazdagép kiválasztása a minimális költség elérése érdekében történik.
Számos vezető internetes cég vonzza a közvélemény érdeklődését (webfejlesztők és szolgáltatók) a betöltési sebesség és a weboldal teljesítménye iránt. Ezek közé tartozik a Yahoo (Yslow eszköz), az AOL (WebPageTest) és a Google (Page Speed Insights szolgáltatás), amelyek saját ajánlásokat dolgoznak ki az oldalak felgyorsítására (elsősorban az ügyfelek optimalizálására vonatkoznak). Később új weboldal-sebesség-tesztelő eszközök jelennek meg, amelyek a weboldal sebességének növeléséhez is adnak tippeket. Ezen szolgáltatások vagy beépülő modulok mindegyikének következetes ajánlása van: „Használjon CDN-t”. A hálózati késleltetés csökkenését általában a CDN hatásának magyarázataként említik. Sajnos nem mindenki áll készen arra, hogy pontosan megértse, hogyan érhető el a CDN gyorsító hatása, és hogyan mérhető, ezért az ajánlást hitre vesszük és posztulátumként használják. Valójában nem minden CDN jön létre egyenlően.
A CDN használata ma
A CDN-ek használatának hasznosságának felméréséhez osztályozni kell őket. Ami most a gyakorlatban megtalálható (a zárójelben lévő példák természetesen nem teljesek):
- Ingyenes CDN a JS-könyvtárak terjesztéséhez (MaxCDN, Google. Yandex).
- Az ügyfelek optimalizálására szolgáló szolgáltatások CDN-je (például Google Fonts a betűtípusokhoz, Cloudinary, Cloudimage a képekhez).
- CDN a statikus és erőforrás-optimalizáláshoz a CMS-ben (elérhető a Bitrixben, WordPressben és másokban).
- Általános célú CDN (StackPath, CDNVideo, NGENIX, Megafon).
- CDN weboldalgyorsításhoz (Cloudflare, Imperva, Airi).
A fő különbség ezek között a típusok között az, hogy a forgalom mekkora része megy keresztül a CDN-n. Az 1-3 típusok a tartalomnak csak egy részének kézbesítése: egy kéréstől több tucatig (általában képek). A 4-es és 5-ös típus a forgalom teljes proxyzása CDN-n keresztül.
A gyakorlatban ez az oldal betöltéséhez használt kapcsolatok számát jelenti. A HTTP/2 használatával egyetlen TCP-kapcsolatot használunk a gazdagéphez tetszőleges számú kérés feldolgozásához. Ha az erőforrásokat felosztjuk a fő gazdagépre (eredetre) és a CDN-re, akkor a kéréseket több tartomány között kell elosztani, és több TCP-kapcsolatot kell létrehozni. A legrosszabb eset: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Ez a képlet nem veszi figyelembe a mobilhálózatokban az eszköz rádiócsatornájának aktiválásakor jelentkező késéseket (ha az nem volt aktív) és a cellatorony késéseit.
Így néz ki a webhely betöltési vízesésén (a CDN-hez való csatlakozás késleltetése 150 ms RTT-nél kiemelve):
Ha a CDN lefedi a webhely teljes forgalmát (kivéve a harmadik féltől származó szolgáltatásokat), akkor egyetlen TCP-kapcsolatot használhatunk, így megtakaríthatjuk a további gazdagépekhez való kapcsolódási késéseket. Természetesen ez a HTTP/2 kapcsolatokra vonatkozik.
A további különbségeket egy adott CDN funkcionalitása határozza meg - az első típusnál csak egy statikus fájlt tárol, az ötödiknél pedig többféle webhelytartalmat változtat meg optimalizálás céljából.
CDN-képességek a webhelyek gyorsításához
Ismertesse meg a helyek gyorsítására szolgáló CDN-képességek teljes skáláját, figyelmen kívül hagyva az egyes CDN-típusok funkcionalitását, majd nézzük meg, mit valósítottak meg mindegyikben.
1. Szövegforrások tömörítése
A legalapvetőbb és legérthetőbb funkció, de gyakran rosszul van megvalósítva. Minden CDN a tömörítés jelenlétét deklarálja gyorsítási jellemzőként. De ha részletesebben megnézzük, nyilvánvalóvá válnak a hiányosságok:
- a dinamikus tömörítéshez alacsony fokozatok használhatók - 5-6 (például gzip esetén a maximum 9);
- a statikus tömörítés (a fájlok a gyorsítótárban) nem használ további szolgáltatásokat (például zopfi vagy brotli 11-es fokozattal)
- nincs támogatás a hatékony brotli tömörítéshez (kb. 20% megtakarítás a gziphez képest).
Ha CDN-t használ, érdemes ezt a néhány pontot ellenőrizni: vegye ki a CDN-ről származó fájlt, rögzítse a tömörített méretét, és az összehasonlítás kedvéért manuálisan tömörítse (használhat pl. ).
2. Az ügyfél gyorsítótárazási fejléceinek beállítása
Szintén egy egyszerű gyorsító funkció: fejlécek hozzáadása a kliens (böngésző) tartalom gyorsítótárazásához. A legfrissebb fejléc a cache-control, az elavult pedig lejár. Ezenkívül az Etag is használható. A lényeg az, hogy a gyorsítótár-vezérlés max-kora elég nagy legyen (egy hónaptól vagy még tovább).Ha készen áll arra, hogy az erőforrást a lehető legkeményebben tárolja, akkor hozzáadhatja a változtathatatlan opciót.
A CDN-ek csökkenthetik a max-age értéket, és arra kényszerítik a felhasználót, hogy gyakrabban töltsön be statikus tartalmat. Nem világos, hogy ez mihez kapcsolódik: a hálózat forgalmának növelése vagy az olyan webhelyekkel való kompatibilitás növelése, amelyek nem tudják, hogyan kell visszaállítani a gyorsítótárat. Például a Cloudflare fejléc alapértelmezett gyorsítótárának ideje 1 óra, ami nagyon alacsony a megváltoztathatatlan statikus adatokhoz.
3. Képoptimalizálás
Mivel a CDN átveszi a gyorsítótárazás és a képek kiszolgálásának funkcióit, logikus lenne ezeket a CDN oldalon optimalizálni, és ebben a formában kiszolgálni a felhasználóknak. Azonnal le kell foglalni, hogy ez a funkció csak a 2-es, 3-as és 5-ös CDN-típusoknál érhető el.
A képeket többféleképpen optimalizálhatja: fejlett tömörítési formátumok (például WebP), hatékonyabb kódolók (MozJPEG) használatával vagy egyszerűen a felesleges metaadatok eltávolításával.
Általánosságban elmondható, hogy az ilyen optimalizálásnak két típusa van: minőségvesztéssel és minőségromlás nélkül. A CDN-ek általában veszteségmentes optimalizálásra törekednek, hogy elkerüljék a képminőség változásaival kapcsolatos esetleges vásárlói panaszokat. Ilyen körülmények között a nyereség minimális lesz. A valóságban gyakran előfordul, hogy a JPEG minőségi szint sokkal magasabb a szükségesnél, és biztonságosan újratömörítheti alacsonyabb minőségi szinttel anélkül, hogy a felhasználói élményt veszélyeztetné. Másrészt nehéz minden lehetséges webalkalmazáshoz univerzálisan meghatározni a minőséget és a beállításokat, ezért a CDN-ek konzervatívabb beállításokat használnak, mint a kontextus (képek célja, webes alkalmazás típusa) figyelembevételével alkalmazhatók. stb.)
4. A TLS kapcsolat optimalizálása
A legtöbb forgalom manapság TLS-kapcsolatokon keresztül halad, ami azt jelenti, hogy több időt töltünk a TLS-egyeztetéssel. A közelmúltban új technológiákat fejlesztettek ki ennek a folyamatnak a felgyorsítására. Ez például az EC-kriptográfia, a TLS 1.3, a munkamenet-gyorsítótár és a jegyek, a hardveres titkosítási gyorsítás (AES-NI), stb. A TLS helyes beállítása 0-1 RTT-re csökkentheti a csatlakozási időt (a DNS-t és a TCP-t nem számítva).
A modern szoftverekkel nem nehéz önállóan megvalósítani az ilyen gyakorlatokat.
Nem minden CDN valósítja meg a TLS bevált gyakorlatait; ezt a TLS csatlakozási idejének mérésével ellenőrizheti (például a Weboldaltesztben). Ideális új csatlakozáshoz - 1RTT, 2RTT - átlagos szint, 3RTT és több - rossz.
Figyelembe kell venni azt is, hogy még CDN szintű TLS használatakor is a webes alkalmazásunkkal rendelkező szervernek kell TLS-t feldolgoznia, de CDN oldalról, mert a szerver és a CDN közötti forgalom a nyilvános hálózaton halad át. A legrosszabb esetben dupla TLS-kapcsolati késést kapunk (az elsőt a CDN gazdagéphez, a másodikat pedig közte és a szerverünkhöz).
Egyes alkalmazásoknál érdemes odafigyelni a biztonsági kérdésekre: a forgalom általában a CDN-csomópontokon dekódolódik, és ez potenciális lehetőség a forgalom elfogására. A forgalominformáció nélküli munkavégzés lehetőségét általában a felső díjcsomagokban kínálják felár ellenében.
5. Csökkentse a csatlakozási késéseket
A CDN fő előnye, amelyről mindenki beszél: alacsony késleltetés (kisebb távolság) a CDN gazdagép és a felhasználó között. Egy földrajzilag elosztott hálózati architektúra létrehozásával érhető el, amelyben a gazdagépek a felhasználók koncentrációs pontjain (városok, forgalomcsere-pontok stb.) helyezkednek el.
A gyakorlatban a különböző hálózatok prioritásai meghatározott régiókban lehetnek. Például az orosz CDN-eknek több jelenléti pontja lesz Oroszországban. Az amerikaiak elsősorban az USA-ban fejlesztik majd a hálózatot. Például az egyik legnagyobb CDN Cloudflare csak 2 ponttal rendelkezik Oroszországban - Moszkvában és Szentpéterváron. Azaz maximum körülbelül 10 ms késleltetést takaríthatunk meg a moszkvai közvetlen elhelyezéshez képest.
A legtöbb nyugati CDN-nek egyáltalán nincs pontja Oroszországban. Ha csatlakozik hozzájuk, az orosz közönség számára csak növelheti a késéseket.
6. Tartalom optimalizálás (kicsinyítés, szerkezeti változtatások)
A legösszetettebb és technológiailag legfejlettebb pont. A tartalom kézbesítés közbeni megváltoztatása nagyon kockázatos lehet. Még ha kicsinyítést is vesszük: a forráskód csökkentése (pl. szóközök, lényegtelen szerkezetek stb. miatt) befolyásolhatja a teljesítményét. Ha komolyabb változtatásokról beszélünk - a JS kód áthelyezése a HTML végére, fájlok összevonása stb. -, akkor még nagyobb az oldal működésének megzavarásának veszélye.
Ezért csak néhány 5-ös típusú CDN teszi ezt meg. Természetesen nem lehet automatizálni a felgyorsításhoz szükséges összes változtatást – manuális elemzésre és optimalizálásra van szükség. Például a nem használt vagy ismétlődő kód eltávolítása manuális feladat.
Általános szabály, hogy minden ilyen optimalizálást a beállítások vezérelnek, és a legveszélyesebbek alapértelmezés szerint le vannak tiltva.
Gyorsítási képességek támogatása CDN-típusonként
Tehát nézzük meg, milyen potenciális gyorsítási lehetőségeket kínálnak a különböző típusú CDN-ek.
A kényelem kedvéért megismételjük az osztályozást.
- Ingyenes CDN a JS-könyvtárak terjesztéséhez (MaxCDN, Google. Yandex).
- Az ügyfelek optimalizálására szolgáló szolgáltatások CDN-je (például Google Fonts a betűtípusokhoz, Cloudinary, Cloudimage a képekhez).
- CDN a statikus és erőforrás-optimalizáláshoz a CMS-ben (elérhető a Bitrixben, WordPressben és másokban).
- Általános célú CDN (StackPath, CDNVideo, NGENIX, Megafon).
- CDN weboldalgyorsításhoz (Cloudflare, Imperva, Airi).
Most pedig hasonlítsuk össze a CDN jellemzőit és típusait.
Alkalom
1-as típus
2-as típus
3-as típus
4-as típus
5-as típus
Szövegtömörítés
+–
-
+–
+–
+
Gyorsítótár fejlécek
+
+
+
+
+
képek
-
+–
+–
-
+
TLS
-
-
-
+–
+
Késések
-
-
-
+
+
Tartalom
-
-
-
-
+
Ebben a táblázatban a „+” a teljes támogatást jelzi, a „–” nem támogatja, a „+–” pedig a részleges támogatás. Természetesen a valóságban előfordulhatnak eltérések ettől a táblázattól (például egyes általános célú CDN funkciókat valósít meg a képek optimalizálására), de általános ötlethez hasznos.
Eredményei
Remélhetőleg a cikk elolvasása után tisztább képet fog kapni a „CDN használata” javaslatról webhelyei felgyorsításához.
Mint minden üzletben, itt sem hiheti el egyetlen szolgáltatás marketing ígéretét sem. A hatást valós körülmények között kell mérni és tesztelni. Ha már használ CDN-t, ellenőrizze annak hatékonyságát a cikkben leírt kritériumok alapján.
Lehetséges, hogy a CDN mostani használata lelassítja webhelye betöltési idejét.
Általános javaslatként a következőkre összpontosíthatunk: tanulmányozza a közönségét, határozza meg annak földrajzi kiterjedését. Ha a fő közönség 1-2 ezer kilométeres körzetben koncentrálódik, akkor nincs szüksége CDN-re a fő célhoz - a késleltetés csökkentéséhez. Ehelyett a kiszolgálót közelebb helyezheti a felhasználókhoz, és megfelelően konfigurálhatja, így megkaphatja a cikkben leírt optimalizálások többségét (ingyenes és állandó).
Abban az esetben, ha a közönség valóban földrajzilag megoszlott (több mint 3000 kilométeres sugár), a minőségi CDN használata valóban hasznos lesz. Azonban előre meg kell értenie, hogy a CDN pontosan mit gyorsíthat fel (lásd a képességek táblázatát és leírását). A webhelygyorsítás azonban továbbra is összetett feladat, amelyet nem lehet CDN csatlakoztatásával megoldani. A fenti optimalizálások mellett a gyorsítás leghatékonyabb eszközei maradnak a CDN mögött: a szerver rész optimalizálása, a kliens rész haladó módosításai (nem használt kód eltávolítása, a renderelési folyamat optimalizálása, tartalommal való munka, fontok, alkalmazkodóképesség stb.). )
Forrás: will.com