🥇[Gebruik niet] CDN

Bijna elk artikel of hulpmiddel voor het optimaliseren van de sitesnelheid heeft een bescheiden clausule ‘gebruik een CDN’. Over het algemeen is CDN een contentleveringsnetwerk of contentleveringsnetwerk. Bij Method Lab komen we vaak vragen tegen van klanten over dit onderwerp; sommigen schakelen hun eigen CDN in. Het doel van dit artikel is om te begrijpen wat een CDN kan bieden op het gebied van laadsnelheid van de site, welke problemen zich kunnen voordoen en in welke gevallen het gebruik van een CDN gerechtvaardigd is.

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

Een beetje geschiedenis

Zoals veel technologieën zijn CDN’s uit noodzaak ontstaan. Met de ontwikkeling van internetkanalen onder internetgebruikers verschenen online videodiensten. Uiteraard vereist video-inhoud een orde van grootte meer bandbreedte vergeleken met reguliere website-inhoud (afbeeldingen, tekst en CSS- of JS-code).

Wanneer u vanaf één server een videostream parallel naar veel clients probeert uit te zenden, zal het internetkanaal van de server hoogstwaarschijnlijk het knelpunt worden. In de regel zijn een paar duizend threads voldoende om een typisch serverkanaal te verstoppen. Natuurlijk kunnen er nog andere beperkingen van de middelen zijn, maar die zijn op dit moment niet belangrijk. Het is ook belangrijk dat het uitbreiden van het serverkanaal te duur (en soms onmogelijk) is, en ook onpraktisch. De belasting van het kanaal tijdens uitzendingen zal cyclisch zijn.

Het probleem van het beperken van het kanaal van een individuele server wordt perfect opgelost door CDN. Clients maken niet rechtstreeks verbinding met de server, maar met knooppunten in het CDN-netwerk. In een ideale situatie stuurt de server één stream naar het CDN-knooppunt, en vervolgens gebruikt het netwerk zijn eigen bronnen om deze stream aan veel gebruikers te leveren. Vanuit economisch oogpunt betalen we alleen voor de middelen die daadwerkelijk worden verbruikt (dit kan bandbreedte of verkeer zijn) en krijgen we een uitstekende schaalbaarheid van onze service. Het gebruik van een CDN om zware inhoud te leveren is volkomen gerechtvaardigd en logisch. Hoewel het de moeite waard is om op te merken dat de grootste spelers op dit gebied (bijvoorbeeld Netflix) hun eigen CDN’s bouwen in plaats van grote commerciële CDN’s te gebruiken (Akamai, Cloudflare, Fastly, etc.)

Naarmate het web zich heeft ontwikkeld, zijn webapplicaties zelf steeds complexer en complexer geworden. Het probleem van de laadsnelheid kwam naar voren. Liefhebbers van websitesnelheid ontdekten al snel een aantal grote problemen die ervoor zorgden dat websites langzaam laadden. Een daarvan was netwerkvertraging (RTT - round trip time of ping time). Vertragingen beïnvloeden veel processen bij het laden van websites: het tot stand brengen van een TCP-verbinding, het starten van een TLS-sessie, het laden van elke afzonderlijke bron (afbeelding, JS-bestand, HTML-document, enz.)

Het probleem werd verergerd door het feit dat browsers bij gebruik van het HTTP/1.1-protocol (vóór de komst van SPDY, QUIC en HTTP/2 de enige optie) niet meer dan zes TCP-verbindingen met één host openen. Dit alles leidde tot verbindingsuitval en inefficiënt gebruik van kanaalbandbreedte. Het probleem werd gedeeltelijk opgelost door domain sharding: het creëren van extra hosts om de limiet op het aantal verbindingen te overwinnen.

Dit is waar het tweede vermogen van CDN naar voren komt: het verminderen van de latentie (RTT) vanwege het grote aantal punten en de nabijheid van knooppunten tot de gebruiker. Afstand speelt hierbij een doorslaggevende rol: de snelheid van het licht is beperkt (ongeveer 200 km/sec in glasvezel). Dit betekent dat elke 000 km reizen 1000 ms vertraging of 5 ms aan RTT toevoegt. Dit is de minimale tijd die nodig is voor verzending, aangezien er ook vertragingen optreden op de tussenapparatuur. Omdat een CDN doorgaans weet hoe hij objecten op zijn servers moet cachen, kunnen we profiteren van het laden van dergelijke objecten via een CDN. Noodzakelijke voorwaarden hiervoor: de aanwezigheid van het object in de cache, de nabijheid van het CDN-punt naar de gebruiker in vergelijking met de webapplicatieserver (oorsprongserver). Het is belangrijk om te begrijpen dat de geografische nabijheid van een CDN-knooppunt geen lage latentie garandeert. Routing tussen de client en het CDN kan zo worden opgebouwd dat de client verbinding maakt met een host in een ander land, en mogelijk op een ander continent. Dit is waar de relatie tussen telecomoperatoren en de CDN-dienst (peering, verbindingen, deelname aan IX, etc.) en het verkeersrouteringsbeleid van het CDN zelf een rol spelen. Cloudflare garandeert bijvoorbeeld bij gebruik van twee initiële abonnementen (gratis en goedkoop) niet de levering van inhoud van de dichtstbijzijnde host - de host zal worden geselecteerd om de minimale kosten te realiseren.

Veel toonaangevende internetbedrijven trekken publieke belangstelling (webontwikkelaars en service-eigenaren) voor het onderwerp laadsnelheid en websiteprestaties. Onder deze bedrijven bevinden zich Yahoo (Yslow-tool), AOL (WebPageTest) en Google (Page Speed Insights-service), die hun eigen aanbevelingen ontwikkelen voor het versnellen van sites (vooral deze hebben betrekking op klantoptimalisatie). Later verschijnen er nieuwe tools voor het testen van de websitesnelheid, die ook tips geven over het verhogen van de websitesnelheid. Elk van deze services of plug-ins heeft een consistente aanbeveling: “Gebruik een CDN.” De vermindering van de netwerklatentie wordt meestal aangehaald als verklaring voor het effect van CDN. Helaas is niet iedereen bereid om precies te begrijpen hoe het versnellingseffect van CDN wordt bereikt en hoe het kan worden gemeten, dus wordt de aanbeveling op basis van vertrouwen aangenomen en als postulaat gebruikt. In feite zijn niet alle CDN’s gelijk gemaakt.

CDN vandaag gebruiken

Om het nut van het gebruik van CDN’s te beoordelen, moeten ze worden geclassificeerd. Wat kun je nu in de praktijk tegenkomen (de voorbeelden tussen haakjes zijn uiteraard niet uitputtend):

Gratis CDN voor het distribueren van JS-bibliotheken (MaxCDN, Google. Yandex).
CDN van services voor clientoptimalisatie (bijvoorbeeld Google Fonts voor lettertypen, Cloudinary, Cloudimage voor afbeeldingen).
CDN voor statische en resource-optimalisatie in CMS (beschikbaar in Bitrix, WordPress en andere).
CDN voor algemeen gebruik (StackPath, CDNVideo, NGENIX, Megafon).
CDN voor websiteversnelling (Cloudflare, Imperva, Airi).

Het belangrijkste verschil tussen deze typen is hoeveel van het verkeer via het CDN gaat. Typen 1-3 zijn de levering van slechts een deel van de inhoud: van één verzoek tot enkele tientallen (meestal afbeeldingen). Typen 4 en 5 zijn volledige proxy-verkeer via een CDN.

In de praktijk betekent dit het aantal verbindingen dat gebruikt wordt om de site te laden. Met HTTP/2 gebruiken we één enkele TCP-verbinding met de host om een willekeurig aantal verzoeken te verwerken. Als we bronnen verdelen in de hoofdhost (oorsprong) en CDN, dan is het noodzakelijk om verzoeken over verschillende domeinen te verdelen en verschillende TCP-verbindingen tot stand te brengen. Het ergste geval is: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Deze formule houdt geen rekening met vertragingen in mobiele netwerken voor de activering van het radiokanaal van het apparaat (als dit niet actief was) en vertragingen op de zendmast.

Hier ziet u hoe het eruit ziet in de laadwaterval van de site (latenties voor verbinding met het CDN worden gemarkeerd bij RTT 150 ms):

Als het CDN al het siteverkeer dekt (behalve voor services van derden), kunnen we één enkele TCP-verbinding gebruiken, waardoor vertragingen bij het verbinden met extra hosts worden bespaard. Dit geldt uiteraard voor HTTP/2-verbindingen.

Verdere verschillen worden bepaald door de functionaliteit van een bepaald CDN: bij het eerste type host het alleen maar een statisch bestand, bij het vijfde verandert het verschillende soorten site-inhoud met het oog op optimalisatie.

CDN-mogelijkheden voor websiteversnelling

Laten we het volledige scala aan CDN-mogelijkheden voor het versnellen van sites beschrijven, zonder rekening te houden met de functionaliteit van individuele typen CDN, en vervolgens kijken wat er in elk van deze is geïmplementeerd.

1. Compressie van tekstbronnen

De meest fundamentele en begrijpelijke functie, maar toch vaak slecht geïmplementeerd. Alle CDN's verklaren de aanwezigheid van compressie als hun versnellingsfunctie. Maar als je meer in detail kijkt, worden de tekortkomingen duidelijk:

lage graden voor dynamische compressie kunnen worden gebruikt - 5-6 (voor gzip is het maximum bijvoorbeeld 9);
statische compressie (bestanden in cache) maakt geen gebruik van extra functies (bijvoorbeeld zopfi of brotli met graad 11)
er is geen ondersteuning voor efficiënte brotli-compressie (een besparing van ongeveer 20% vergeleken met gzip).

Als je een CDN gebruikt, is het de moeite waard om deze paar punten te controleren: neem het bestand dat afkomstig is van het CDN, noteer de gecomprimeerde grootte ervan en comprimeer het handmatig ter vergelijking (je kunt bijvoorbeeld een online service gebruiken met brotli-ondersteuning vsszhat.rf).

2. Clientcaching-headers instellen

Ook een eenvoudige versnellingsfunctie: voeg headers toe voor het cachen van inhoud door de client (browser). De meest recente header is cache-control, de verouderde header is verlopen. Daarnaast kan Etag worden gebruikt. Het belangrijkste is dat de maximale leeftijd van cache-controle groot genoeg is (vanaf een maand of meer).Als u klaar bent om de bron zo hard mogelijk in de cache op te slaan, kunt u de onveranderlijke optie toevoegen.

CDN's kunnen de maximale leeftijdswaarde verlagen, waardoor de gebruiker gedwongen wordt statische inhoud vaker te herladen. Het is niet duidelijk waar dit mee te maken heeft: de wens om het verkeer op het netwerk te vergroten of de compatibiliteit te vergroten met sites die niet weten hoe ze de cache moeten resetten. De standaard cachetijd voor de Cloudflare-header is bijvoorbeeld 1 uur, wat erg laag is voor onveranderlijke statische gegevens.

3. Beeldoptimalisatie

Omdat het CDN de functies van het cachen en aanbieden van afbeeldingen op zich neemt, zou het logisch zijn om deze aan de CDN-kant te optimaliseren en in deze vorm aan gebruikers aan te bieden. Laten we meteen reserveren: deze functie is alleen beschikbaar voor CDN-types 2, 3 en 5.

U kunt afbeeldingen op verschillende manieren optimaliseren: met behulp van geavanceerde compressieformaten (zoals WebP), efficiëntere encoders (MozJPEG) of eenvoudigweg het opruimen van onnodige metagegevens.

Over het algemeen zijn er twee soorten van dergelijke optimalisaties: met kwaliteitsverlies en zonder kwaliteitsverlies. CDN's streven er doorgaans naar om verliesloze optimalisatie te gebruiken om mogelijke klachten van klanten over veranderingen in de beeldkwaliteit te voorkomen. In dergelijke omstandigheden zal de winst minimaal zijn. In werkelijkheid is het JPEG-kwaliteitsniveau vaak veel hoger dan nodig en kunt u veilig opnieuw comprimeren met een lager kwaliteitsniveau zonder de gebruikerservaring in gevaar te brengen. Aan de andere kant is het moeilijk om het kwaliteitsniveau en de instellingen universeel voor alle mogelijke webapplicaties te bepalen, dus gebruiken CDN's conservatievere instellingen vergeleken met de instellingen die kunnen worden toegepast rekening houdend met de context (doel van afbeeldingen, type webapplicatie , enz.)

4. Optimaliseren van de TLS-verbinding

Het meeste verkeer reist tegenwoordig via TLS-verbindingen, wat betekent dat we extra tijd besteden aan TLS-onderhandelingen. Onlangs zijn er nieuwe technologieën ontwikkeld om dit proces te versnellen. Dit is bijvoorbeeld EC-cryptografie, TLS 1.3, sessiecache en tickets, hardware-encryptieversnelling (AES-NI), etc. Het correct instellen van TLS kan de verbindingstijd terugbrengen tot 0-1 RTT (DNS en TCP niet meegerekend).

Met moderne software is het niet moeilijk om dergelijke praktijken zelf te implementeren.

Niet alle CDN's implementeren best practices van TLS; u kunt dit controleren door de TLS-verbindingstijd te meten (bijvoorbeeld in Webpagetest). Ideaal voor een nieuwe verbinding - 1RTT, 2RTT - gemiddeld niveau, 3RTT en meer - slecht.

Ook moet worden opgemerkt dat zelfs bij gebruik van TLS op CDN-niveau de server met onze webapplicatie ook TLS moet verwerken, maar dan vanaf de CDN-kant, omdat het verkeer tussen de server en het CDN over het publieke netwerk gaat. In het ergste geval krijgen we dubbele TLS-verbindingsvertragingen (de eerste naar de CDN-host, de tweede tussen deze en onze server).

Voor sommige toepassingen is het de moeite waard om aandacht te besteden aan beveiligingsproblemen: verkeer wordt meestal gedecodeerd op CDN-knooppunten, en dit is een potentiële mogelijkheid voor het onderscheppen van verkeer. De mogelijkheid om te werken zonder verkeersinformatie wordt in toptariefplannen doorgaans tegen meerprijs aangeboden.

5. Verminder verbindingsvertragingen

Het belangrijkste voordeel van CDN waar iedereen het over heeft: lage latentie (minder afstand) tussen de CDN-host en de gebruiker. Bereikt door het creëren van een geografisch gedistribueerde netwerkarchitectuur, waarin hosts zich bevinden in concentratiepunten van gebruikers (steden, verkeersuitwisselingspunten, enz.)

In de praktijk kunnen de prioriteiten voor verschillende netwerken in specifieke regio's liggen. Russische CDN’s zullen bijvoorbeeld meer aanwezigheidspunten in Rusland hebben. De Amerikanen zullen allereerst het netwerk in de VS ontwikkelen. Een van de grootste CDN Cloudflare heeft bijvoorbeeld slechts 2 punten in Rusland: Moskou en St. Petersburg. Dat wil zeggen dat we maximaal ongeveer 10 ms latentie kunnen besparen in vergelijking met directe plaatsing in Moskou.

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

6. Contentoptimalisatie (minificatie, structurele veranderingen)

Het meest complexe en technologisch geavanceerde punt. Het wijzigen van de inhoud tijdens de bezorging kan zeer riskant zijn. Zelfs als we minificatie toepassen: het verkleinen van de broncode (vanwege extra spaties, onbelangrijke structuren, enz.) kan de prestaties ervan beïnvloeden. Als we het hebben over serieuzere veranderingen - het verplaatsen van de JS-code naar het einde van de HTML, het samenvoegen van bestanden, enz. - is het risico dat de functionaliteit van de site wordt verstoord zelfs nog groter.

Daarom doen slechts enkele type 5 CDN’s dit. Natuurlijk zal het niet mogelijk zijn om alle veranderingen die nodig zijn om de zaken te versnellen te automatiseren; handmatige analyse en optimalisatie zijn vereist. Het verwijderen van ongebruikte of dubbele code is bijvoorbeeld een handmatige taak.

In de regel worden al dergelijke optimalisaties beheerd door instellingen en zijn de gevaarlijkste standaard uitgeschakeld.

Ondersteuning voor versnellingsmogelijkheden per CDN-type

Laten we dus eens kijken welke potentiële versnellingsmogelijkheden de verschillende soorten CDN's bieden.

Voor het gemak herhalen we de classificatie.

Gratis CDN voor het distribueren van JS-bibliotheken (MaxCDN, Google. Yandex).
CDN van services voor clientoptimalisatie (bijvoorbeeld Google Fonts voor lettertypen, Cloudinary, Cloudimage voor afbeeldingen).
CDN voor statische en resource-optimalisatie in CMS (beschikbaar in Bitrix, WordPress en andere).
CDN voor algemeen gebruik (StackPath, CDNVideo, NGENIX, Megafon).
CDN voor websiteversnelling (Cloudflare, Imperva, Airi).

Laten we nu de functies en typen CDN vergelijken.

Kans
Typ 1
Typ 2
Typ 3
Typ 4
Typ 5

Tekstcompressie
+–
-
+–
+–
+

Cache-headers
+
+
+
+
+

foto's
-
+–
+–
-
+

TLS
-
-
-
+–
+

vertragingen
-
-
-
+
+

Inhoud
-
-
-
-
+

In deze tabel wordt “+” gebruikt om volledige ondersteuning aan te geven, “–” is geen ondersteuning en “+–” is gedeeltelijke ondersteuning. Natuurlijk kunnen er in werkelijkheid afwijkingen van deze tabel voorkomen (sommige CDN's voor algemene doeleinden zullen bijvoorbeeld functies implementeren voor het optimaliseren van afbeeldingen), maar voor een algemeen idee is het nuttig.

Resultaten van

Hopelijk heeft u na het lezen van dit artikel een duidelijker beeld van de aanbeveling “gebruik een CDN” om uw sites te versnellen.

Zoals in elk bedrijf kunt u de marketingbeloften van welke dienst dan ook niet geloven. Het effect moet onder reële omstandigheden worden gemeten en getest. Als u al gebruik maakt van een CDN, controleer deze dan op effectiviteit aan de hand van de criteria die in het artikel worden beschreven.

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

Als algemene aanbeveling kunnen we ons op het volgende concentreren: bestudeer uw publiek, bepaal de geografische reikwijdte ervan. Als uw belangrijkste doelgroep zich binnen een straal van 1-2 kilometer bevindt, heeft u geen CDN nodig voor zijn hoofddoel: het verminderen van de latentie. In plaats daarvan kunt u uw server dichter bij uw gebruikers plaatsen en deze correct configureren, waarbij u de meeste optimalisaties krijgt die in het artikel worden beschreven (gratis en permanent).

Als uw publiek echt geografisch verspreid is (straal van meer dan 3000 kilometer), zal het gebruik van een kwalitatief CDN echt nuttig zijn. U moet echter van tevoren begrijpen wat uw CDN precies kan versnellen (zie de tabel met mogelijkheden en hun beschrijving). Websiteversnelling blijft echter nog steeds een complexe taak die niet kan worden opgelost door een CDN aan te sluiten. Naast de bovenstaande optimalisaties blijven achter het CDN de meest effectieve versnellingsmiddelen achter: optimalisatie van het servergedeelte, geavanceerde wijzigingen in het clientgedeelte (ongebruikte code verwijderen, het weergaveproces optimaliseren, werken met inhoud, lettertypen, aanpasbaarheid, enz. )

Bron: www.habr.com

Gebruik [geen] een CDN