🥇[Älä] käytä CDN

Melkein jokaisessa artikkelissa tai työkalussa sivuston nopeuden optimoimiseksi on vaatimaton lauseke "käytä CDN". Yleisesti ottaen CDN on sisällönjakeluverkko tai sisällönjakeluverkko. Me Metho Labissa kohtaamme usein asiakkailta kysymyksiä tästä aiheesta; osa heistä mahdollistaa oman CDN:n. Tämän artikkelin tarkoituksena on ymmärtää, mitä CDN voi tarjota sivuston latausnopeuden suhteen, mitä ongelmia voi ilmetä ja missä tapauksissa CDN:n käyttö on perusteltua.

Kuvassa ympyröidyt viiveet johtuvat CDN:n käytöstä.

Vähän historiaa

Kuten monet tekniikat, CDN:t syntyivät välttämättömyydestä. Internet-kanavien kehittyessä Internetin käyttäjien keskuudessa online-videopalvelut ilmestyivät. Luonnollisesti videosisältö vaatii suuruusluokkaa enemmän kaistanleveyttä verrattuna tavalliseen verkkosivuston sisältöön (kuvat, teksti ja CSS- tai JS-koodi).

Kun yritetään lähettää videovirtaa rinnakkain useille asiakkaille yhdeltä palvelimelta, pullonkaulaksi tulee todennäköisesti palvelimen Internet-kanava. Yleensä muutama tuhat säiettä riittää tukkimaan tyypillisen palvelinkanavan. Tietenkin voi olla muita resurssirajoituksia, mutta ne eivät ole tärkeitä juuri nyt. On myös tärkeää, että palvelinkanavan laajentaminen on liian kallista (ja joskus mahdotonta) ja myös epäkäytännöllistä. Kanavan kuormitus lähetysten aikana on syklistä.

CDN ratkaisee täydellisesti yksittäisen palvelimen kanavan rajoittamisen ongelman. Asiakkaat eivät muodosta yhteyttä suoraan palvelimeen, vaan CDN-verkon solmuihin. Ihanteellisessa tilanteessa palvelin lähettää yhden virran CDN-solmulle, jonka jälkeen verkko toimittaa tämän virran useille käyttäjille omilla resursseillaan. Taloudellisesta näkökulmasta katsottuna maksamme vain tosiasiallisesti kulutetuista resursseista (tämä voi olla kaistanleveyttä tai liikennettä) ja saamme palvelumme erinomaisen skaalautuvuuden. CDN:n käyttö raskaan sisällön toimittamiseen on täysin perusteltua ja loogista. Vaikka on syytä huomata, että tämän tilan suurimmat toimijat (esim. Netflix) rakentavat omia CDN-verkkojaan suurten kaupallisten CDN-verkkojen (Akamai, Cloudflare, Fastly jne.) sijaan.

Webin kehittyessä itse web-sovelluksista on tullut monimutkaisempia ja monimutkaisempia. Latausnopeuden ongelma nousi esiin. Verkkosivustojen nopeuden harrastajat havaitsivat nopeasti useita suuria ongelmia, jotka saivat verkkosivustot latautumaan hitaasti. Yksi niistä oli verkon viiveet (RTT - meno-paluuaika tai ping-aika). Viiveet vaikuttavat moniin verkkosivustojen latauksen prosesseihin: TCP-yhteyden muodostamiseen, TLS-istunnon aloittamiseen, kunkin yksittäisen resurssin lataamiseen (kuva, JS-tiedosto, HTML-dokumentti jne.)

Ongelmaa pahensi se, että HTTP/1.1-protokollaa käytettäessä (ennen SPDY:n, QUIC:n ja HTTP/2:n tuloa tämä oli ainoa vaihtoehto) selaimet avaavat enintään 6 TCP-yhteyttä yhteen isäntään. Kaikki tämä johti yhteyden katkeamiseen ja kanavan kaistanleveyden tehottomaan käyttöön. Ongelma ratkesi osittain verkkotunnuksen jakamisella - lisäisäntien luomisella yhteyksien lukumäärän rajoituksen ylittämiseksi.

Tässä näkyy CDN:n toinen kyky - latenssin (RTT) vähentäminen suuren pistemäärän ja solmujen läheisyyden vuoksi käyttäjään. Etäisyydellä on tässä ratkaiseva rooli: valon nopeus on rajoitettu (noin 200 000 km/s optisessa kuidussa). Tämä tarkoittaa, että jokainen 1000 ajokilometriä lisää RTT:tä 5 ms viivettä tai 10 ms. Tämä on lähetykseen vaadittava vähimmäisaika, koska myös välilaitteessa on viiveitä. Koska CDN yleensä osaa tallentaa objektit välimuistiin palvelimillaan, voimme hyötyä tällaisten objektien lataamisesta CDN:n kautta. Tämän välttämättömät ehdot: objektin läsnäolo välimuistissa, CDN-pisteen läheisyys käyttäjään verrattuna verkkosovelluspalvelimeen (alkuperäpalvelimeen). On tärkeää ymmärtää, että CDN-solmun maantieteellinen läheisyys ei takaa pientä latenssia. Reititys asiakkaan ja CDN:n välillä voidaan rakentaa siten, että asiakas muodostaa yhteyden toisessa maassa ja mahdollisesti toisella mantereella sijaitsevaan isäntään. Tässä tulee esiin teleoperaattoreiden ja CDN-palvelun välinen suhde (peering, yhteydet, osallistuminen IX:ään jne.) ja itse CDN:n liikenteen reitityspolitiikka. Esimerkiksi Cloudflare, kun käytetään kahta alkuperäistä suunnitelmaa (ilmainen ja halpa), ei takaa sisällön toimitusta lähimmältä isännältä - isäntä valitaan saavuttamaan vähimmäiskustannukset.

Monet johtavat Internet-yritykset herättävät yleistä kiinnostusta (web-kehittäjät ja palvelujen omistajat) latausnopeuden ja verkkosivuston suorituskyvyn aiheeseen. Näihin yrityksiin kuuluvat Yahoo (Yslow-työkalu), AOL (WebPageTest) ja Google (Page Speed Insights -palvelu), jotka kehittävät omia suosituksiaan sivustojen nopeuttamiseksi (pääasiassa ne liittyvät asiakkaan optimointiin). Myöhemmin ilmestyy uusia verkkosivuston nopeuden testaustyökaluja, jotka tarjoavat myös vinkkejä verkkosivuston nopeuden lisäämiseen. Jokaisella näistä palveluista tai laajennuksista on johdonmukainen suositus: "Käytä CDN:ää". Verkon latenssin pieneneminen mainitaan yleensä selityksenä CDN:n vaikutukselle. Valitettavasti kaikki eivät ole valmiita ymmärtämään tarkalleen, miten CDN:n kiihtyvyysvaikutus saavutetaan ja miten se voidaan mitata, joten suositus perustuu uskoon ja sitä käytetään oletuksena. Itse asiassa kaikkia CDN-verkkoja ei ole luotu samanarvoisiksi.

CDN:n käyttö tänään

CDN-verkkojen käytön hyödyllisyyden arvioimiseksi ne on luokiteltava. Mitä nyt käytännössä löytyy (suluissa olevat esimerkit eivät tietenkään ole tyhjentäviä):

Ilmainen CDN JS-kirjastojen jakeluun (MaxCDN, Google. Yandex).
Asiakasoptimointipalveluiden CDN (esimerkiksi Google Fonts fonteille, Cloudinary, Cloudimage kuville).
CDN staattiseen ja resurssien optimointiin CMS:ssä (saatavilla Bitrixissä, WordPressissä ja muissa).
Yleiskäyttöinen CDN (StackPath, CDNVideo, NGENIX, Megafon).
CDN verkkosivujen kiihdyttämiseen (Cloudflare, Imperva, Airi).

Tärkein ero näiden tyyppien välillä on se, kuinka suuri osa liikenteestä kulkee CDN:n kautta. Tyypit 1-3 ovat vain osan sisällöstä toimittamista: yhdestä pyynnöstä useisiin kymmeniin (yleensä kuvia). Tyypit 4 ja 5 ovat liikenteen täydellistä välityspalvelinta CDN:n kautta.

Käytännössä tämä tarkoittaa sivuston lataamiseen käytettyjen yhteyksien määrää. HTTP/2:lla käytämme yhtä TCP-yhteyttä isäntään käsitelläksemme minkä tahansa määrän pyyntöjä. Jos jaamme resurssit pääisäntään (alkuperä) ja CDN:ään, on tarpeen jakaa pyynnöt useille toimialueille ja luoda useita TCP-yhteyksiä. Pahin tapaus on: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Tämä kaava ei ota huomioon matkapuhelinverkkojen viiveitä laitteen radiokanavan aktivoinnissa (jos se ei ollut aktiivinen) eikä solutornin viiveitä.

Tältä se näyttää sivuston latausvesiputouksella (CDN-yhteyden viiveet on korostettu RTT:ssä 150 ms):

Jos CDN kattaa koko sivuston liikenteen (paitsi kolmannen osapuolen palvelut), voimme käyttää yhtä TCP-yhteyttä, mikä säästää viiveitä yhteyden muodostamisessa muihin isäntiin. Tämä koskee tietysti HTTP/2-yhteyksiä.

Muut erot määräytyvät tietyn CDN:n toimivuuden mukaan - ensimmäisellä tyypillä se vain isännöi staattista tiedostoa, viidennessä se muuttaa useita sivuston sisältötyyppejä optimointia varten.

CDN-ominaisuudet verkkosivustojen kiihdyttämiseen

Kuvataan koko valikoima CDN-ominaisuuksia sivustojen kiihdyttämiseen, ottamatta huomioon yksittäisten CDN-tyyppien toimivuutta, ja katsotaan sitten, mitä kussakin niistä on toteutettu.

1. Tekstiresurssien pakkaus

Yksinkertaisin ja ymmärrettävin ominaisuus, mutta usein huonosti toteutettu. Kaikki CDN:t ilmoittavat pakkauksen olemassaolon kiihtyvyysominaisuutensa. Mutta jos tarkastellaan tarkemmin, puutteet käyvät selväksi:

dynaamiseen pakkaamiseen voidaan käyttää alhaisia asteita - 5-6 (esimerkiksi gzipille maksimi on 9);
staattinen pakkaus (välimuistissa olevat tiedostot) ei käytä lisäominaisuuksia (esim. zopfi tai brotli asteella 11)
ei ole tukea tehokkaalle brotli-pakkaukselle (säästö noin 20 % gzipiin verrattuna).

Jos käytät CDN:ää, kannattaa tarkistaa nämä muutamat kohdat: ota CDN:stä tullut tiedosto, tallenna sen pakattu koko ja pakkaa se manuaalisesti vertailua varten (voit käyttää jotain brotli-tuella varustettua verkkopalvelua, esim. vsszhat.rf).

2. Asiakkaan välimuistiotsikoiden asettaminen

Myös yksinkertainen nopeuttava ominaisuus: lisää otsikot asiakkaan (selaimen) sisällön välimuistiin. Uusin otsikko on cache-control, vanhentunut on vanhentunut. Lisäksi Etagia voidaan käyttää. Pääasia, että välimuistin hallinnan max-ikä on riittävän suuri (kuukaudesta tai enemmän) Jos olet valmis tallentamaan resurssin välimuistiin mahdollisimman lujasti, voit lisätä muuttumattoman vaihtoehdon.

CDN:t voivat alentaa enimmäisiän arvoa ja pakottaa käyttäjän lataamaan staattista sisältöä useammin. Ei ole selvää, mihin tämä liittyy: halu lisätä liikennettä verkossa tai lisätä yhteensopivuutta sivustojen kanssa, jotka eivät osaa nollata välimuistia. Esimerkiksi Cloudflaren otsikon oletusvälimuistin aika on 1 tunti, mikä on erittäin lyhyt muuttumattomille staattisille tiedoille.

3. Kuvan optimointi

Koska CDN ottaa välimuistin ja kuvien palvelemisen toiminnot, olisi loogista optimoida ne CDN-puolella ja palvella niitä käyttäjille tässä muodossa. Tehdään heti varaus, että tämä ominaisuus on saatavilla vain CDN-tyypeille 2, 3 ja 5.

Voit optimoida kuvia useilla tavoilla: käyttämällä edistyneitä pakkausmuotoja (kuten WebP), tehokkaampia koodereita (MozJPEG) tai yksinkertaisesti puhdistamalla tarpeettomat metatiedot.

Yleensä tällaisia optimointeja on kahdenlaisia: laadun heikkenemisen kanssa ja ilman laadun heikkenemistä. CDN:t pyrkivät yleensä käyttämään häviötöntä optimointia välttääkseen mahdolliset asiakkaiden valitukset kuvanlaadun muutoksista. Tällaisissa olosuhteissa voitto on minimaalinen. Todellisuudessa JPEG-laatutaso on usein paljon korkeampi kuin on tarpeen, ja voit turvallisesti pakata uudelleen alemmalla laatutasolla käyttäjäkokemuksesta tinkimättä. Toisaalta laatutasoa ja asetuksia on vaikea määrittää yleisesti kaikille mahdollisille verkkosovelluksille, joten CDN:t käyttävät konservatiivisempia asetuksia verrattuna niihin, joita voidaan soveltaa konteksti huomioon ottaen (kuvien tarkoitus, verkkosovelluksen tyyppi). , jne.)

4. TLS-yhteyden optimointi

Suurin osa liikenteestä kulkee nykyään TLS-yhteyksien kautta, mikä tarkoittaa, että käytämme ylimääräistä aikaa TLS-neuvotteluihin. Viime aikoina on kehitetty uusia tekniikoita tämän prosessin nopeuttamiseksi. Tämä on esimerkiksi EC-salaus, TLS 1.3, istuntovälimuisti ja liput, laitteiston salauskiihdytys (AES-NI) jne. TLS:n oikea asetus voi lyhentää yhteysaikaa 0-1 RTT:hen (DNS:tä ja TCP:tä lukuun ottamatta).

Nykyaikaisilla ohjelmistoilla tällaisten käytäntöjen toteuttaminen yksin ei ole vaikeaa.

Kaikki CDN:t eivät käytä TLS:n parhaita käytäntöjä; voit tarkistaa tämän mittaamalla TLS-yhteysajan (esimerkiksi Webpagetestissä). Ihanteellinen uudelle yhteydelle - 1RTT, 2RTT - keskitaso, 3RTT ja enemmän - huono.

On myös huomioitava, että myös käytettäessä TLS:ää CDN-tasolla web-sovelluksemme palvelimen täytyy myös käsitellä TLS:ää, mutta CDN-puolelta, koska palvelimen ja CDN:n välinen liikenne kulkee julkisessa verkossa. Pahimmassa tapauksessa saamme kaksinkertaisen TLS-yhteysviiveen (ensimmäinen CDN-isäntään, toinen sen ja palvelimemme välillä).

Joissakin sovelluksissa kannattaa kiinnittää huomiota tietoturvaongelmiin: liikenteen salaus puretaan yleensä CDN-solmuissa, mikä on mahdollinen mahdollisuus liikenteen sieppaamiseen. Mahdollisuus työskennellä ilman liikennetiedottamista tarjotaan yleensä huipputariffisuunnitelmissa lisämaksusta.

5. Vähennä yhteysviiveitä

CDN:n tärkein etu, josta kaikki puhuvat: alhainen latenssi (pienempi etäisyys) CDN-isännän ja käyttäjän välillä. Saavutetaan luomalla maantieteellisesti hajautettu verkkoarkkitehtuuri, jossa isännät sijaitsevat käyttäjien keskittymispisteissä (kaupungit, liikenteen vaihtopisteet jne.)

Käytännössä eri verkostojen prioriteetit voivat olla tietyillä alueilla. Esimerkiksi venäläisillä CDN-verkoilla on enemmän toimipisteitä Venäjällä. Amerikkalaiset kehittävät verkkoa ennen kaikkea Yhdysvalloissa. Esimerkiksi yhdellä suurimmista CDN Cloudflaresta on vain 2 pistettä Venäjällä - Moskova ja Pietari. Toisin sanoen voimme säästää korkeintaan noin 10 ms latenssia verrattuna Moskovassa suoritettuun sijoitukseen.

Useimmilla läntisillä CDN-verkoilla ei ole pisteitä Venäjällä ollenkaan. Yhdistämällä niihin voit vain lisätä venäläisen yleisösi viiveitä.

6. Sisällön optimointi (pienentäminen, rakenteelliset muutokset)

Monimutkaisin ja teknisesti edistynein kohta. Sisällön muuttaminen toimituksen aikana voi olla erittäin riskialtista. Vaikka otamme pienentämisen: lähdekoodin vähentäminen (ylimääräisten välilyöntien, merkityksettömien rakenteiden jne. takia) voi vaikuttaa sen suorituskykyyn. Jos puhumme vakavammista muutoksista - JS-koodin siirtämisestä HTML:n loppuun, tiedostojen yhdistämisestä jne. - sivuston toiminnan häiriintymisen riski on vielä suurempi.

Siksi vain jotkut tyypin 5 CDN:t tekevät tämän. Kaikkia asioiden nopeuttamiseen tarvittavia muutoksia ei tietenkään voida automatisoida – tarvitaan manuaalinen analyysi ja optimointi. Esimerkiksi käyttämättömän tai päällekkäisen koodin poistaminen on manuaalinen tehtävä.

Yleensä kaikkia tällaisia optimointeja ohjataan asetuksilla ja vaarallisimmat on oletuksena poistettu käytöstä.

Tuki kiihdytysominaisuuksille CDN-tyypin mukaan

Katsotaanpa, mitä mahdollisia kiihtyvyysmahdollisuuksia erityyppiset CDN:t tarjoavat.

Mukavuuden vuoksi toistamme luokituksen.

Ilmainen CDN JS-kirjastojen jakeluun (MaxCDN, Google. Yandex).
Asiakasoptimointipalveluiden CDN (esimerkiksi Google Fonts fonteille, Cloudinary, Cloudimage kuville).
CDN staattiseen ja resurssien optimointiin CMS:ssä (saatavilla Bitrixissä, WordPressissä ja muissa).
Yleiskäyttöinen CDN (StackPath, CDNVideo, NGENIX, Megafon).
CDN verkkosivujen kiihdyttämiseen (Cloudflare, Imperva, Airi).

Verrataan nyt CDN:n ominaisuuksia ja tyyppejä.

Tilaisuus
Tyyppi 1
Tyyppi 2
Tyyppi 3
Tyyppi 4
Tyyppi 5

Tekstin pakkaus
+ -
-
+ -
+ -
+

Välimuistin otsikot
+
+
+
+
+

kuvat
-
+ -
+ -
-
+

TLS
-
-
-
+ -
+

Viiveet
-
-
-
+
+

Pitoisuus
-
-
-
-
+

Tässä taulukossa "+" tarkoittaa täydellistä tukea, "-" ei ole tukea ja "+-" on osittainen tuki. Tietysti tästä taulukosta voi todellisuudessa olla poikkeamia (esimerkiksi jotkin yleiskäyttöiset CDN-verkot toteuttavat ominaisuuksia kuvien optimointiin), mutta yleisen idean kannalta se on hyödyllinen.

Tulokset

Toivottavasti tämän artikkelin lukemisen jälkeen sinulla on selkeämpi kuva "käytä CDN" -suositusta sivustojesi nopeuttamiseksi.

Kuten missä tahansa liiketoiminnassa, et voi uskoa minkään palvelun markkinointilupauksia. Vaikutus on mitattava ja testattava todellisissa olosuhteissa. Jos käytät jo CDN:ää, tarkista sen tehokkuus artikkelissa kuvattujen kriteerien avulla.

On mahdollista, että CDN:n käyttö juuri nyt hidastaa sivustosi latausaikaa.

Yleisenä suosituksena voimme keskittyä seuraaviin: tutki yleisöäsi, määritä sen maantieteellinen laajuus. Jos pääyleisösi on keskittynyt 1-2 tuhannen kilometrin säteelle, et tarvitse CDN:ää sen päätarkoitukseen - latenssin vähentämiseen. Sen sijaan voit sijoittaa palvelimesi lähemmäs käyttäjiäsi ja määrittää sen oikein, jolloin saat suurimman osan artikkelissa kuvatuista optimoinneista (ilmainen ja pysyvä).

Jos yleisösi on todella maantieteellisesti hajallaan (säde yli 3000 kilometriä), laadukkaan CDN:n käyttäminen on todella hyödyllistä. Sinun on kuitenkin ymmärrettävä etukäteen, mitä CDN-verkkosi voi nopeuttaa (katso ominaisuustaulukko ja niiden kuvaus). Verkkosivustojen kiihdytys on kuitenkin edelleen monimutkainen tehtävä, jota ei voida ratkaista yhdistämällä CDN. Yllä olevien optimointien lisäksi CDN:n taakse jää tehokkaimmat kiihdytyskeinot: palvelinosan optimointi, edistyneet muutokset asiakasosaan (käyttämättömän koodin poistaminen, renderöintiprosessin optimointi, työskentely sisällön kanssa, fontit, mukautuvuus jne. )

Lähde: will.com

[Älä] käytä CDN:ää