[Geen] gebruik CDN

Bijna elk artikel of hulpmiddel voor het optimaliseren van de laadsnelheid van websites bevat de bescheiden optie 'gebruik een CDN'. Een CDN is eigenlijk een content delivery network of een netwerk voor het leveren van content. Bij ons bedrijf, 'Métod Lab', krijgen we vaak vragen van klanten over dit onderwerp; sommige schakelen zelf een CDN in. Het doel van dit artikel is om te begrijpen wat een CDN kan bieden qua laadsnelheid van de website, welke problemen zich kunnen voordoen en in welke gevallen het gebruik van een CDN gerechtvaardigd is.

De in de afbeelding omlijnde vertragingen worden veroorzaakt door het gebruik van een CDN.

Een beetje geschiedenis

Net als veel technologieën zijn CDNs ontstaan uit noodzaak. Met de ontwikkeling van internetverbindingen van gebruikers, zijn online video-services ontstaan. Het is vanzelfsprekend dat video-content veel hogere bandbreedte vereist in vergelijking met reguliere website-inhoud (afbeeldingen, tekst en CSS of JS-code).

Bij het proberen om een videostream gelijktijdig naar meerdere klanten vanaf één server te verzenden, wordt de internetsnelheid van de server waarschijnlijk de bottleneck. Gewoonlijk is het voldoende om enkele duizenden streams te hebben om een typische serververbinding te verstoppen. Natuurlijk kunnen er ook andere beperkingen zijn wat betreft middelen, maar dat is nu niet belangrijk. Het is ook belangrijk dat het te duur is (en soms onmogelijk) om de serververbinding uit te breiden, en bovendien niet rendabel. De belasting op de verbinding zal ciclic karakter hebben tijdens de streaming.

Het probleem van de beperking van de verbinding van een afzonderlijke server wordt uitstekend opgelost door een CDN. Klanten verbinden zich niet rechtstreeks met de server, maar met de knooppunten van het CDN-netwerk. In een ideale situatie geeft de server één stream aan een CDN-knooppunt, en vervolgens gebruikt het netwerk zijn eigen middelen om deze stream aan meerdere gebruikers te leveren. Economisch gezien betalen we alleen voor de werkelijke verbruikte middelen (dit kan bandbreedte of verkeer zijn) en krijgen we uitstekende schaalbaarheid van onze service. Het gebruik van een CDN voor het leveren van zware content is volledig gerechtvaardigd en logisch. Het is echter vermeldenswaard dat de grootste spelers in dit gebied (zoals Netflix) hun eigen CDN's bouwen in plaats van gebruik te maken van grote commerciële CDN's (Akamai, Cloudflare, Fastly, enz.).

Naarmate het web zich ontwikkelde, werden webapplicaties complexer en zwaarder. Het probleem van laadsnelheid kwam naar voren. Snelheidenthousiastelingen identificeerden al snel een aantal belangrijke problemen die leidden tot trage laadtijden van websites. Een daarvan was netwerkvertraging (RTT - round trip time of ping-tijd). Vertragingen beïnvloeden veel processen bij het laden van een website: het tot stand brengen van een TCP-verbinding, het opstarten van een TLS-sessie en het laden van elk afzonderlijk bestand (afbeeldingen, JS-bestanden, HTML-documenten, enzovoort).

Het probleem werd verergerd door het feit dat, bij gebruik van het HTTP/1.1-protocol (tot de komst van SPDY, QUIC en HTTP/2 de enige optie), browsers niet meer dan 6 TCP-verbindingen naar één host openen. Dit leidde tot stilstand van de verbinding en een ineffectief gebruik van de bandbreedte. Het probleem werd deels opgelost door domeinsharding - het creëren van extra hosts om de limiet op het aantal verbindingen te omzeilen.

Hier komt de tweede functie van een CDN naar voren: het verminderen van vertragingen (RTT) door het grote aantal punten en de nabijheid van knooppunten tot de gebruiker. Afstand speelt hier een cruciale rol: de snelheid van licht is beperkt (ongeveer 200.000 km/s in glasvezel). Dit betekent dat elke 1000 km afstand 5 ms vertraging toevoegt of 10 ms aan de RTT. Dit zijn de minimale tijdskosten voor overdracht, aangezien er ook nog vertragingen op tussenliggende apparatuur zijn. Aangezien een CDN meestal in staat is om objecten op zijn servers te cachen, kunnen we profiteren van het laden van dergelijke objecten via een CDN. De noodzakelijke voorwaarden hiervoor zijn: het object moet in de cache staan en de nabijheid van het CDN-punt ten opzichte van de origin server. Het is belangrijk om te begrijpen: geografische nabijheid van een CDN-knooppunt garandeert geen lage vertragingen. De routing tussen de cliënt en de CDN kan zodanig zijn opgebouwd dat de cliënt verbinding maakt met een host in een ander land, of misschien zelfs op een ander continent. Hier komen de relaties tussen telecomproviders en de CDN-dienstverlener in het spel (peering, aanwezigheid van knooppunten, deelname aan IX, enzovoort) en het routeringsbeleid van de CDN zelf. Bijvoorbeeld, Cloudflare garandeert bij het gebruik van de twee basisplannen (gratis en goedkope) niet dat de inhoud wordt geleverd vanaf het dichtstbijzijnde knooppunt – de keuze van de host wordt gemaakt om de minimale kosten te bereiken.

Veel toonaangevende internetbedrijven trekken de aandacht van het publiek (webontwikkelaars en service-eigenaren) naar het onderwerp laadtijd en werking van websites. Onder deze bedrijven zijn Yahoo (tool Yslow), AOL (WebPageTest) en Google (dienst Page Speed Insights), die hun aanbevelingen voor het versnellen van websites ontwikkelen (voornamelijk gericht op clientoptimalisatie). Later verschijnen er nieuwe tools om de snelheid van websites te testen, die ook advies geven over het verhogen van de snelheid. In elk van deze diensten of plugins is er een onveranderlijk advies: 'Gebruik een CDN'. Als verklaring voor het effect van een CDN wordt meestal de vermindering van netwerklatentie genoemd. Helaas zijn niet iedereen bereid om te begrijpen hoe precies het versnellingseffect van een CDN wordt bereikt en hoe het kan worden gemeten, dus de aanbeveling wordt op geloof aangenomen en als een postulaat gebruikt. In werkelijkheid zijn lang niet alle CDN's even nuttig.

Het gebruik van CDN vandaag de dag

Om de nuttigheid van het gebruik van CDN's te beoordelen, moeten ze worden geclassificeerd. Wat we momenteel in de praktijk tegenkomen (de voorbeelden tussen haakjes zijn uiteraard niet uitputtend):

1. Gratis CDN's voor het leveren van JS-bibliotheken (MaxCDN, Google, Yandex).
2. CDN's voor clientoptimalisatie (bijvoorbeeld Google Fonts voor lettertypen, Cloudinary, Cloudimage voor afbeeldingen).
3. CDN's voor statische bestanden en optimalisatie van middelen in CMS (beschikbaar in Bitrix, WordPress en andere).
4. Algemene CDN's (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN's voor het versnellen van websites (Cloudflare, Imperva, Airi).

Het belangrijkste verschil tussen deze types is het volgende: welk deel van het verkeer via de CDN gaat. Type 1-3 is alleen levering van een deel van de inhoud: van één aanvraag tot enkele tientallen (meestal afbeeldingen). Types 4 en 5 betreft volledige proxying van verkeer via de CDN.

In de praktijk betekent dit het aantal verbindingen dat wordt gebruikt om de website te laden. Bij het gebruik van HTTP/2 gebruiken we één TCP-verbinding met de host voor het verwerken van een willekeurig aantal aanvragen. Als we de middelen verdelen over de primaire host (origin) en de CDN, moeten we aanvragen over meerdere domeinen spreiden en meerdere TCP-verbindingen tot stand brengen. In het slechtste geval is dit: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. In deze formule zijn vertragingen in mobiele netwerken voor de activatie van de radioverbinding van het apparaat (als deze niet actief was) en vertragingen bij de cellulaire toren niet meegerekend.

Zo ziet het eruit op de laadsnelheid van de website (de verbindingvertragingen naar de CDN zijn gemarkeerd bij een RTT van 150 ms):

Als de CDN al het verkeer van de website dekt (behalve externe diensten), kunnen we één enkele TCP-verbinding gebruiken, waardoor we vertragingen bij het verbinden met extra hosts besparen. Dit geldt natuurlijk voor HTTP/2-verbindingen.

Verdere verschillen worden bepaald door de functionaliteit van de specifieke CDN – voor het eerste type is dit slechts hosting een statisch bestand, voor het vijfde type gaat het om het wijzigen van meerdere soorten inhoud op de website met als doel optimalisatie.

De mogelijkheden van de CDN voor het versnellen van de website

Laten we het volledige scala aan mogelijkheden van de CDN voor het versnellen van websites beschrijven, zonder te kijken naar de functionaliteit van afzonderlijke typen CDN, en daarna bekijken wat hiervan in elk van hen is geïmplementeerd.

1. Comprimeren van tekstbronnen

De meest basale en duidelijke mogelijkheid, maar toch vaak slecht uitgevoerd. Alle CDN's verklaren compressie als hun kenmerk voor versnelling. Maar als we dieper kijken, komen er tekortkomingen aan het licht:

• er kunnen lage niveaus voor dynamische compressie worden gebruikt – 5-6 (bijvoorbeeld maximaal 9 voor gzip);
• in statische compressie (bestanden in de cache) worden geen extra mogelijkheden gebruikt (bijvoorbeeld zopfi of brotli met niveau 11)
• er is geen ondersteuning voor effectieve brotli-compressie (ongeveer 20% besparing ten opzichte van gzip).

Als je een CDN gebruikt, is het de moeite waard om deze punten te controleren: neem een bestand dat van de CDN is ontvangen, noteer de grootte ervan in gecomprimeerde vorm en recomprimeer deze handmatig voor vergelijking (je kunt een online service gebruiken die brotli ondersteunt, bijvoorbeeld allescomprimeren.ru).

2. Instellen van client cache-headers

Een ook eenvoudige feature voor versnelling: cache-headers instellen voor het cachen van inhoud door de client (browser). De meest relevante header is cache-control, de verouderde is expires. Daarnaast kan Etag worden gebruikt. Het belangrijkste is dat max-age bij cache-control groot genoeg is (vanaf een maand of meer), als je ervoor kiest om de resource zo strikt mogelijk te cachen, kun je de optie immutable toevoegen.

CDN kunnen de waarde van max-age verlagen, waardoor gebruikers statische bestanden vaker opnieuw moeten laden. Of dit nu komt door de wens om het verkeer te verhogen of om de compatibiliteit met websites die geen cache kunnen wissen te verbeteren, is niet duidelijk. Zo is de standaard cachetijd in de headers van Cloudflare 1 uur, wat erg kort is voor onveranderlijke statische bestanden.

3. Optimalisatie van beelden

Aangezien CDN's verantwoordelijk zijn voor de caching en levering van beelden, is het logisch om deze aan de CDN-kant te optimaliseren en op deze manier aan gebruikers te leveren. Laten we meteen opmerken dat deze mogelijkheid alleen beschikbaar is voor CDN-types 2, 3 en 5.

Beelden kunnen op verschillende manieren worden geoptimaliseerd: door gebruik te maken van geavanceerde compressieformaten (zoals WebP), effectievere encoders (zoals MozJPEG) of gewoon door overtollige metadata te verwijderen.

Over het algemeen zijn er twee soorten optimalisaties: met kwaliteitsverlies en zonder kwaliteitsverlies. CDN's proberen meestal gebruik te maken van optimalisatie zonder kwaliteitsverlies om eventuele klachten van klanten over veranderde beeldkwaliteit te vermijden. In zulke omstandigheden zal de winst minimaal zijn. In de praktijk is de JPEG-kwaliteit vaak veel hoger dan nodig is, en kan men gerust hercompressie uitvoeren met een lagere kwaliteitsinstelling, zonder dat dit ten koste gaat van de gebruikersperceptie. Aan de andere kant is het moeilijk om een kwaliteitsniveau en instellingen voor alle mogelijke webapplicaties universeel te bepalen, waardoor CDN's conservatievere instellingen hanteren dan diegene die rekening houden met de context (doel van de beelden, type webapplicatie, enzovoort).

4. Optimalisatie van TLS-verbindingen

De meeste verkeer wordt tegenwoordig verzonden via TLS-verbindingen, wat betekent dat we extra tijd besteden aan de TLS-handshake. Onlangs zijn er nieuwe technologieën ontwikkeld om dit proces te versnellen. Dit omvat bijvoorbeeld EC-cryptografie, TLS 1.3, sessiecaching en session tickets, hardwareversnelling van encryptie (AES-NI), enzovoort. Een goede configuratie van TLS kan de verbindingstijd reduceren tot 0-1 RTT (exclusief DNS en TCP).

Met moderne software is het eenvoudig om dergelijke praktijken op eigen infrastructuur te implementeren.

Lang niet alle CDN's implementeren de beste praktijken voor TLS; dit kan worden gecontroleerd door de tijd van de TLS-verbinding te meten (bijvoorbeeld met Webpagetest). Ideaal voor een nieuwe verbinding is 1RTT, 2RTT is gemiddeld, 3RTT of meer is slecht.

Het moet ook opgemerkt worden dat zelfs bij het gebruik van TLS op het niveau van de CDN, de server met onze webapplicatie ook TLS moet verwerken, maar aan de kant van de CDN, omdat het verkeer tussen de server en de CDN door een openbaar netwerk gaat. In het slechtste geval krijgen we dubbele vertragingen van de TLS-verbinding (de eerste naar de CDN-host, de tweede tussen deze en onze server).

Voor sommige toepassingen is het belangrijk om aandacht te besteden aan veiligheidskwesties: doorgaans wordt het verkeer ontsleuteld op de CDN-node, wat een potentiële mogelijkheid voor onderschepping van verkeer met zich meebrengt. Een manier om zonder het verkeer te onthullen te werken, wordt vaak aangeboden in de beste abonnementen tegen extra kosten.

5. Vermindering van verbindingsvertragingen

Het belangrijkste voordeel van een CDN waar iedereen over praat: lage vertragingen (minder afstand) tussen de CDN-host en de gebruiker. Dit wordt bereikt door een geografisch verspreide netwerkinfrastructuur te creëren, waarin hosts zijn geplaatst op plekken waar gebruikers zich concentreren (steden, datacenters, enz.).

In de praktijk kunnen de prioriteiten voor verschillende netwerken zich in specifieke regio's bevinden. Russische CDN's zullen bijvoorbeeld meer punten van aanwezigheid in Rusland hebben. Amerikaanse zullen zich vooral richten op het uitbreiden van hun netwerk in de VS. Bijvoorbeeld, een van de grootste CDN's, Cloudflare, heeft slechts 2 punten in Rusland - Moskou en Sint-Petersburg. Dit betekent dat we maximaal ongeveer 10 ms vertraging kunnen besparen vergeleken met directe hosting in Moskou.

De meeste westerse CDN's hebben helemaal geen punten in Rusland. Door verbinding te maken met hen kunt u de vertragingen voor uw Russische publiek alleen maar verhogen.

6. Optimalisatie van inhoud (minificatie, structurele wijzigingen)

Het moeilijkste en technologisch lastigste punt. Het wijzigen van inhoud tijdens bezorging kan zeer riskant zijn. Zelfs als we het hebben over minificatie: het verkorten van de broncode (door onnodige spaties, irrelevante constructies, enz.) kan invloed hebben op de werking ervan. Als we het hebben over ernstigere wijzigingen – zoals het verplaatsen van JS-code naar de onderkant van de HTML, het samenvoegen van bestanden en dergelijke – is het risico om de functionaliteit van de site te verstoren nog groter.

Daarom zijn slechts enkele CDN van type 5 hiermee bezig. Natuurlijk is het niet mogelijk om alle noodzakelijke wijzigingen voor versnelling te automatiseren – handmatige analyse en optimalisatie is vereist. Bijvoorbeeld, het verwijderen van ongebruikte of dubbele code valt onder de handmatige taken.

In het algemeen worden dergelijke optimalisaties beheerd via instellingen en zijn de meest risicovolle standaard uitgeschakeld.

Ondersteuning van versnelling mogelijkheden per type CDN

Laten we eens bekijken welke potentiële versnelling mogelijkheden de verschillende types CDN bieden.

Voor de duidelijkheid, laten we de classificatie herhalen.

1. Gratis CDN's voor het leveren van JS-bibliotheken (MaxCDN, Google, Yandex).
2. CDN's voor clientoptimalisatie (bijvoorbeeld Google Fonts voor lettertypen, Cloudinary, Cloudimage voor afbeeldingen).
3. CDN's voor statische bestanden en optimalisatie van middelen in CMS (beschikbaar in Bitrix, WordPress en andere).
4. Algemene CDN's (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN's voor het versnellen van websites (Cloudflare, Imperva, Airi).

Laten we nu de functies en types CDN vergelijken.

Mogelijkheid
Type 1
Type 2
Type 3
Type 4
Type 5

Tekstcompressie
+–
–
+–
+–
+

Cache headers
+
+
+
+
+

Afbeeldingen
–
+–
+–
–
+

TLS
–
–
–
+–
+

Vertragingen
–
–
–
+
+

Inhoud
–
–
–
–
+

In deze tabel wordt '+' gebruikt om volledige ondersteuning aan te geven, '-' voor afwezigheid, en '+-' voor gedeeltelijke ondersteuning. Natuurlijk zijn afwijkingen van deze tabel in de praktijk mogelijk (bijvoorbeeld, een algemene CDN kan functies voor afbeeldingsoptimalisatie implementeren), maar voor een algemeen beeld is het nuttig.

Conclusies

Ik hoop dat je na het lezen van dit artikel een duidelijker beeld hebt van de aanbeveling "gebruik een CDN" voor het versnellen van websites.

Zoals bij alles, is het belangrijk om niet blindelings de marketingbeloven van een dienst te geloven. Het effect moet gemeten en getest worden in de echte wereld. Als je al een CDN gebruikt, controleer dan de effectiviteit ervan op basis van de criteria die in het artikel zijn beschreven.

Het is mogelijk dat het gebruik van een CDN op dit moment de laadtijd van je website vertraagt.

Als algemene aanbeveling kun je het volgende in overweging nemen: bestudeer je publiek, bepaal de geografische grenzen. Als je belangrijkste publiek zich binnen een straal van 1000-2000 kilometer bevindt, heb je geen CDN nodig voor zijn primaire doel – het verminderen van vertragingen. In plaats daarvan kun je je server dichter bij de gebruikers plaatsen en deze goed configureren om de meeste optimalisaties die in het artikel zijn beschreven te verkrijgen (gratis en voortdurend).

Als uw publiek daadwerkelijk geografisch verspreid is (straal van meer dan 3000 kilometer), kan het gebruik van een kwalitatieve CDN echt nuttig zijn. Het is echter belangrijk om vooraf te begrijpen wat uw CDN daadwerkelijk kan versnellen (zie de tabel met mogelijkheden en hun beschrijvingen). Het versnellen van uw website blijft in ieder geval een complexe taak, die niet opgelost kan worden door alleen een CDN aan te sluiten. Naast de genoemde optimalisaties blijven de meest effectieve middelen voor versnelling buiten de CDN: serveroptimalisatie, geavanceerde wijzigingen aan de clientzijde (het verwijderen van ongebruikte code, optimalisatie van het renderproces, werken met inhoud, lettertypen, responsiviteit, enzovoort).

Bron: habr.com