[Ne] használjon CDN

Szinte minden cikkben vagy eszközben, amely a weboldalak sebességének optimalizálásáról szól, található egy szerény pont, amely azt mondja: „Használj CDN-t”. Általában a CDN a „content delivery network” vagyis tartalomterjesztő hálózat. A „Metod Lab” cégnél gyakran találkozunk ügyfelek kérdéseivel ebben a témában, és néhányan önállóan is beállítanak CDN-t. Ennek a cikknek a célja, hogy megértsük, mit nyújthat a CDN a weboldal betöltési sebessége szempontjából, milyen problémák merülhetnek fel, és mikor indokolt a CDN használata.

A képen látható késlekedések a CDN használatának következményei.

Egy kis történelem

Mint sok technológia, a CDN-ek is szükségből születtek. Az internetezési csatornák fejlődésével megjelentek az online videószolgáltatások. Természetesen a videótartalom sokkal nagyobb sávszélességet igényel, mint a hagyományos weboldalak tartalma (képek, szöveg, CSS vagy JS kód).

Ha egy videostreamet egyszerre több ügyfél számára próbálunk megosztani egyetlen szerverről, az internetkapcsolat valószínűleg szűk keresztmetszet lesz. Általában elegendő néhány ezer stream, hogy a szerver tipikus csatornáját túltöltsük. Persze más erőforrás-korlátozások is lehetnek, de most ezek nem lényegesek. Fontos megjegyezni, hogy a szervercsatorna bővítése túl költséges (vagy néha lehetetlen), és nem is célszerű. A terhelés a csatornán az adások során ciklikusan változik.

A különálló szerver csatornájának korlátait a CDN nagyszerűen megoldja. Az ügyfelek nem közvetlenül a szerverhez csatlakoznak, hanem a CDN hálózat csomópontjaihoz. Ideális esetben a szerver egy streamet küld a CDN csomópontjának, majd a hálózat saját erőforrásait használja a stream sok felhasználóhoz történő eljuttatására. Gazdasági szempontból csak a ténylegesen felhasznált erőforrásokért (ez lehet sávszélesség vagy adatforgalom) fizetünk, és kiváló skálázhatóságot kapunk a szolgáltatásunkhoz. A CDN használata nehéz tartalom terjesztésére teljes mértékben indokolt és logikus. Érdemes megjegyezni, hogy a legnagyobb szereplők ezen a területen (például a Netflix) saját CDN-jüket építik ki a nagy kereskedelmi CDN-ek (Akamai, Cloudflare, Fastly stb.) használata helyett.

Ahogy a web fejlődött, maguk a webalkalmazások is egyre bonyolultabbak és nehezebbek lettek. Előtérbe került a betöltési sebesség problémája. A weboldalak sebességével foglalkozó lelkesedők viszonylag gyorsan azonosította néhány alapvető problémát, amelyek lassú weboldalakat eredményeztek. Az egyik ilyen probléma a hálózati késlekedések voltak (RTT - round trip time vagy ping idő). A késlekedések számos folyamatra hatással vannak a weboldal betöltésében: a TCP kapcsolat létrehozása, a TLS munkamenet indítása, az egyes erőforrások betöltése (képek, JS fájlok, HTML dokumentum stb.)

A probléma súlyosbította azt is, hogy az HTTP/1.1 protokoll használata során (a SPDY, QUIC és HTTP/2 megjelenése előtt ez volt az egyetlen lehetőség) a böngészők nem nyitottak meg több mint 6 TCP kapcsolatot egyetlen hosthoz. Mindez a kapcsolatok inaktivitásához és a sávszélesség nem hatékony kihasználásához vezetett. A problémát részben a domain sharding oldotta meg - további hostok létrehozása a kapcsolatok számának korlátainak átlépésére.

Itt lép be a CDN második képessége - a késlekedések (RTT) csökkentése a sok pont és a felhasználóhoz közeli csomópontok révén. A távolság kulcsszerepet játszik: a fénysebesség korlátozott (kb. 200 000 km/s optikai szálban). Ezért minden 1000 km távolság 5 ms késlekedést vagy 10 ms RTT-t ad hozzá. Ezek a minimális időráfordítások az adatátvitelre, mivel még késlekedések is vannak a közbenső berendezéseken. Mivel a CDN rendszerint képes az objektumok cach-álására a szerverein, nyerhetünk a CDN-en keresztül történő betöltésből. A szükséges feltételek ehhez: az objektumnak a cache-ben kell lennie és a CDN pontjának a felhasználóhoz képesti közelsége az eredeti webalkalmazás szerverrel összehasonlítva. Fontos megérteni: a CDN csomópont földrajzi közelsége nem garancia a alacsony késlekedésekre. Az útvonalhoz kapcsolódó kapcsolatok és a CDN szolgáltatás (peering, kapcsolatok megléte, részvétel IX-en stb.) politikája azt is befolyásolja, ahogyan a forgalmat irányítják a CDN-en belül. Például a Cloudflare a két alapcsomag (ingyenes és olcsó) használata esetén nem garantálja a tartalom legközelebbi csomópontból történő kiszolgálását - a host kiválasztása a minimális költség elérésére fog történni.

Sok vezető internetes vállalat felhívja a figyelmet (webfejlesztők és szolgáltatók) a weboldalak betöltési sebességére és működésére. Ezek között a cégek között található a Yahoo (Yslow eszköz), az AOL (WebPageTest) és a Google (Page Speed Insights szolgáltatás), amelyek saját ajánlásaikat dolgozzák ki a weboldalak gyorsítására (főleg a kliensoptimalizálásra vonatkozóan). Később új sebességtesztelő eszközök is megjelennek, amelyek szintén tanácsokat adnak a weboldalak gyorsabbá tételéhez. Minden egyes szolgáltatásban vagy bővítményben egy állandó ajánlás található: „Használj CDN-t”. A CDN hatásának magyarázata általában a hálózati késleltetések csökkentésében rejlik. Sajnos nem mindenki hajlandó megérteni, hogy a CDN-ből származó gyorsulás hogyan érhető el és hogyan mérhető, ezért az ajánlás hitelesnek tekinthető és posztulátumként használják. Valójában nem minden CDN egyformán hasznos.

A CDN használata napjainkban

A CDN alkalmazásának hasznosságát a következőképpen kellene osztályozni. Amit ma a gyakorlatban találunk (a zárójelben szereplő példák természetesen nem kimerítőek):

1. Ingyenes CDN-ek JS könyvtárak terjesztésére (MaxCDN, Google, Yandex).
2. CDN szolgáltatások kliensoptimalizáláshoz (például Google Fonts a betűtípusokhoz, Cloudinary, Cloudimage a képekhez).
3. CDN statikus tartalomhoz és források optimalizálásához CMS-ekben (elérhető a Bitrix-ben, WordPress-ben és másokban).
4. Általános célú CDN-ek (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN-ek a weboldalak gyorsításához (Cloudflare, Imperva, Airi).

A fő különbség ezek között a típusok között abban rejlik, hogy a forgalom mely része halad át a CDN-en. Az 1-3 típus csak a tartalom egy részének kiszállítását jelenti: egy kéréstől több tucatig (általában képek). A 4. és 5. típus teljes körű forgalom proxizálást jelent a CDN-en keresztül.

A gyakorlatban ez a weboldal betöltéséhez használt kapcsolatok számát jelenti. HTTP/2 használatakor egy TCP kapcsolatot használunk a gazda számára az összes kérés kezeléséhez. Ha az erőforrásokat az alapgazda (origin) és a CDN között osztjuk meg, akkor a kéréseket több tartományra kell szétterítenünk, ami több TCP-kapcsolat létrehozását igényli. A legrosszabb esetben ez a következő: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Ebben a formulában nem szerepelnek a mobil hálózatokban a rádiócsatorna aktiválásával kapcsolatos késleltetések (ha az még nem volt aktív) és a késések a mobil toronynál.

Itt van, hogyan néz ki a weboldal betöltési vízesésén (a CDN-hez való csatlakozási késlekedéseket emeltük ki 150 ms RTT esetén):

Ha a CDN lefedi az oldal forgalmát (kivéve a külső szolgáltatásokat), akkor egyetlen TCP-kapcsolatot használhatunk, így elkerülve a késlekedést további hosztokhoz való csatlakozással. Természetesen ez a HTTP/2 kapcsolatokra is vonatkozik.

A további különbségek a konkrét CDN funkcióival vannak meghatározva – az első típusnál ez mindössze hosztolást statikus fájl, az ötödiknél pedig a weboldal többféle tartalmának optimalizálása.

A CDN lehetőségei a weboldal felgyorsítására

Írjuk le a CDN weboldalak felgyorsítására vonatkozó teljes lehetőségek spektrumát, anélkül, hogy figyelembe vennénk a különböző CDN-típusok funkcióit, majd nézzük meg, hogy ezek közül mi valósult meg mindegyikben.

1. Szöveges erőforrások tömörítése

Ez a legalapvetőbb és legegyszerűbb lehetőség, azonban gyakran rosszul valósítják meg. Minden CDN hirdeti a tömörítést, mint sebességnövelő funkciót. De ha alaposabban megvizsgáljuk, kiderülnek a hiányosságok:

• alacsony tömörítési fokok használhatók a dinamikus tömörítéshez – 5-6 (például a gzip esetében a maximum — 9);
• a statikus tömörítésnél (a cache-ben levő fájlok) nem használják az extra lehetőségeket (például zopfli vagy brotli 11-es fokozattal)
• nincs hatékony brotli tömörítés támogatása (körülbelül 20% megtakarítás a gzip-hez képest).

Ha CDN-t használ, érdemes ellenőrizni ezeket a pontokat: vegyen egy fájlt, amely a CDN-től érkezett, rögzítse a tömörített méretét és tömörítse újra manuálisan az összehasonlításhoz (használhat online szolgáltatást brotli támogatással, például mindencompress.hu).

2. Ügyféltárolási fejlécek beállítása

Szintén egyszerű sebességnövelő funkció: állítson be fejléceket a tartalom kliens (böngésző) általi gyorsítótárazásához. A legfontosabb fejlécek a cache-control, az elavult – expires. Kiegészítőként használható az Etag. A max-age a cache-control-nál legyen elég nagy (legalább egy hónap), ha maximálisan szeretné gyorsítótárazni az erőforrást, az immutable opciót is hozzáadhatja.

A CDN can reduce the max-age value, forcing users to reload static resources more frequently. It is unclear whether this is due to the desire to increase network traffic or improve compatibility with sites that cannot clear the cache. For example, the default caching time in the headers for Cloudflare is 1 hour, which is very short for unchanging static content.

3. Képek optimalizálása

Mivel a CDN átveszi a képek gyorsítótárazását és szolgáltatását, logikus, hogy optimalizálni kell őket a CDN oldalán, és így kell azokat a felhasználóknak átadni. Előre bocsátjuk, hogy ez a lehetőség csak a 2., 3. és 5. típusú CDN-ek esetében érhető el.

A képek optimalizálása különböző módokon történhet: haladó tömörítési formátumok használatával (például WebP), hatékonyabb kódolókkal (MozJPEG), vagy egyszerűen a felesleges metainformációk eltávolításával.

Alapvetően kétféle ilyen optimalizálás létezik: minőségromlással és anélkül. A CDN-ek általában az elvesztes nélkül alkalmazott optimalizálást próbálják meg észlelni, hogy elkerüljék az esetleges ügyfélpanaszokat a képek minőségében történt változás miatt. Ilyen körülmények között a nyereség minimális lesz. A valóságban gyakran a JPEG minősége jelentősen meghaladja a szükségest, így biztonsággal elvégezhető az újrakompresszió alacsonyabb minőségi szinten, anélkül, hogy a felhasználók észrevennék a romlást. Másrészt nehéz univerzálisan meghatározni a minőség és beállítások szintjét minden lehetséges webalkalmazáshoz, ezért a CDN-ek konzervatívabb beállításokat használnak, mint amit a kontextus figyelembevételével alkalmazni lehetne (a képek célja, a webalkalmazás típusa stb.).

4. TLS-kapcsolatok optimalizálása

A mai forgalom többsége TLS-kapcsolatokon keresztül történik, ami azt jelenti, hogy további időt pazarolunk a TLS-alku lebonyolítására. Az utóbbi időben új technológiák jelentek meg ennek a folyamatnak a felgyorsítására. Például, ez az EC-kripto, a TLS 1.3, a munkamenet-cache és a jegyek (session tickets), a titkosítás hardveres gyorsítása (AES-NI) stb. A TLS helyes beállítása lehetővé teszi a kapcsolódási idő csökkentését 0-1 RTT-re (nem számítva a DNS-t és TCP-t).

A modern szoftverek birtokában könnyen bevezethetők ezek a gyakorlatok saját erőforrásainkon.

Nem minden CDN alkalmazza a legjobb TLS gyakorlati irányelveket; ezt a TLS-kapcsolat idejének mérésével ellenőrizhetjük (például a Webpagetest-en). Az új kapcsolat esetén a 1RTT ideális, a 2RTT közepes szintű, a 3RTT és annál magasabb pedig rossz.

Meg kell említenünk, hogy még a CDN szintjén történő TLS használata esetén is, a webalkalmazást futtató szervernek is kezelnie kell a TLS-t, de a CDN oldaláról, mivel a szerver és a CDN közötti forgalom nyilvános hálózaton keresztül halad. Legrosszabb esetben dupla TLS-kapcsolati késleltetést tapasztalhatunk (az első a CDN hosztra, a második a CDN és a mi szerverünk között).

Bizonyos alkalmazások esetén érdemes figyelembe venni a biztonsági kérdéseket: általában a forgalmat a CDN csomópontjain dekódolják, ami potenciális lehetőséget ad a forgalom lehallgatására. Az adatok felfedése nélküli működés általában a legjobb tervcsomagokban külön díj ellenében érhető el.

5. Késleltetések csökkentése

A CDN fő előnye, amiről mindenki beszél: alacsony késleltetés (kisebb távolság) a CDN hoszt és a felhasználó között. Ezt geográfiailag elosztott hálózati architektúra létrehozásával érik el, ahol a hosztok a felhasználók koncentrációs pontjaiban (városokban, forgalomcserélő pontokon stb.) találhatók.

A gyakorlatban a különböző hálózatok prioritásai konkrét régiókban összpontosulhatnak. Például az orosz CDN-ek több jelenléti ponttal rendelkeznek Oroszországban. Az amerikaiak elsősorban az Egyesült Államokban fejlesztik a hálózatot. Például az egyik legnagyobb CDN, a Cloudflare, csak 2 ponttal rendelkezik Oroszországban — Moszkvában és Szentpéterváron. Tehát a közvetlen elhelyezéshez képest körülbelül 10 ms késleltetést spórolhatunk meg Moszkvában.

A legtöbb nyugati CDN-nek egyáltalán nincs jelenléti pontja Oroszországban. Ha csatlakozik hozzájuk, csak növelheti a késleltetést az orosz közönsége számára.

6. Tartalom optimalizálása (minifikálás, struktúrált változások)

A legnehezebb és legtechnológiaibb pont. A tartalom szállítás közbeni módosítása nagyon kockázatos lehet. Még ha a minifikálást is nézzük: az eredeti kód csökkentése (felesleges szóközök, lényegtelen konstrukciók stb. révén) befolyásolhatja annak funkcionalitását. Ha komolyabb változásokról van szó — például a JS-kód áthelyezése a HTML végére, fájlok egyesítése és hasonlók — a webhely funkcionalitásának megszakításának kockázata még magasabb.

Ezért csak néhány 5. típusú CDN foglalkozik ezzel. Természetesen az összes szükséges módosítást az optimalizáláshoz nem lehet automatizálni – kézi elemzés és optimalizálás szükséges. Például a kihasználatlan vagy duplikált kód eltávolítása kézi feladatok közé tartozik.

Általában az összes ilyen optimalizálást a beállítások irányítják, és a legveszélyesebbek alapértelmezés szerint ki vannak kapcsolva.

A CDN típusok által nyújtott gyorsító lehetőségek támogatása

Tehát nézzük meg, hogy a különböző típusú CDN-ek milyen potenciális gyorsítási lehetőségeket kínálnak.

A kényelem kedvéért, ismételjük meg a klasszifikációt.

1. Ingyenes CDN-ek JS könyvtárak terjesztésére (MaxCDN, Google, Yandex).
2. CDN szolgáltatások kliensoptimalizáláshoz (például Google Fonts a betűtípusokhoz, Cloudinary, Cloudimage a képekhez).
3. CDN statikus tartalomhoz és források optimalizálásához CMS-ekben (elérhető a Bitrix-ben, WordPress-ben és másokban).
4. Általános célú CDN-ek (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN-ek a weboldalak gyorsításához (Cloudflare, Imperva, Airi).

Most összehasonlítjuk a funkciókat és a CDN típusokat.

Lehetőség
1. típus
2. típus
3. típus
4. típus
5. típus

Szöveg tömörítés
+–
–
+–
+–
+

Cache fejlécek
+
+
+
+
+

Képek
–
+–
+–
–
+

TLS
–
–
–
+–
+

Késések
–
–
–
+
+

Tartalom
–
–
–
–
+

Ebben a táblázatban a „+” a teljes támogatást jelzi, a „–” a hiányt, a „+–” pedig a részleges támogatást. Természetesen a valóságban lehetnek eltérések ettől a táblázattól (például egy általános CDN bevezethet olyan funkciókat, amelyek a képek optimalizálására vonatkoznak), de a általános elképzelés szempontjából hasznos.

Összegzés

Remélem, hogy ennek a cikknek az elolvasása után világosabb képet kaptok arról, miért javasolt a „CDN használata” a weboldalak gyorsításához.

Mint minden esetben, nem szabad hinni egy szolgáltatás marketingígéreteinek. A hatást valós körülmények között kell mérni és ellenőrizni. Ha már használsz valamilyen CDN-t, ellenőrizd az annak hatékonyságát a cikkben leírt kritériumok alapján.

Lehetséges, hogy a CDN használata éppen most lassítja a weboldalad betöltését.

Általános ajánlásként a következőre érdemes figyelni: tanulmányozd a közönségedet, határozd meg a földrajzi kereteit. Ha a fő közönséged 1-2 ezer kilométeres távolságon belül összpontosul, nincs szükséged CDN-re alapvető céljára – a késlekedések csökkentésére. Ehelyett közelebb helyezheted el a szerveredet a felhasználókhoz, és megfelelően beállíthatod, hogy a cikkben leírt optimálási lehetőségekből a legtöbbet kihozd (ingyen és folyamatosan).

Ha a közönséged valóban földrajzilag szétszórt (távolság több mint 3000 kilométer), akkor a minőségi CDN használata valóban hasznos lesz. Azonban előre tudni kell, hogy pontosan mi fogja felgyorsítani a CDN-edet (lásd a lehetőségek táblázatát és azok leírását). A weboldal felgyorsítása így is komplex feladat marad, amelyet a CDN csatlakoztatása nem old meg. A CDN-n kívül a legjobb gyorsító eszközök még mindig a következők: a szerveroldali optimalizáció, fejlett változtatások a kliensoldalon (felesleges kód eltávolítása, a renderelési folyamat optimalizálása, a tartalom, betűtípusok, reszponzivitás stb. kezelése).

Forrás: habr.com