[Nu] folosiți CDN

Practically every article or tool for optimizing website speed includes the humble point "use a CDN". In general, CDN stands for content delivery network. At "Metod Lab", we often receive questions from clients on this topic; some activate CDN on their own. The goal of this article is to understand what CDN can offer in terms of website loading speed, what problems may arise, and in which cases using a CDN is justified.

The delays highlighted in the picture are caused by the use of a CDN.

Puțin istorie

Like many technologies, CDNs emerged out of necessity. With the growth of internet channels for users, online video services appeared. Naturally, video content requires much greater bandwidth compared to standard website content (images, text, and CSS or JS code).

When attempting to stream a video feed to many clients from a single server, the internet channel of the server is likely to become a bottleneck. Typically, just a few thousand streams can saturate a typical server channel. Of course, there may be other resource constraints, but those are not important right now. It’s also crucial to note that expanding the server channel is often too expensive (and sometimes impossible) and impractical. The load on the channel during streams will have a cyclical nature.

The issue of limiting the channel of an individual server is effectively solved by a CDN. Clients connect not directly to the server, but to the nodes of the CDN network. In an ideal situation, the server sends one stream to the CDN node, and then the network uses its own resources to deliver this stream to multiple users. From an economic perspective, we only pay for the resources actually consumed (which could be bandwidth or traffic) and achieve excellent scalability for our service. Using a CDN to deliver heavy content is fully justified and logical. However, it's worth noting that the largest players in this field (such as Netflix) build their own CDNs rather than using large commercial CDNs (Akamai, Cloudflare, Fastly, etc.).

Pe măsură ce web-ul a evoluat, aplicațiile web au devenit mai complexe și mai grele. Problema vitezei de încărcare a ieșit în evidență. Entuziaștii vitezei site-urilor au identificat rapid câteva probleme de bază care duceau la încărcarea lentă a site-urilor. Una dintre acestea era întârzierile în rețea (RTT - round trip time sau timpul ping). Întârzierile afectează multe procese în încărcarea unui site: stabilirea conexiunii TCP, inițierea sesiunii TLS, încărcarea fiecărui resursă individuală (imagine, fișier JS, document HTML etc.)

Problema era agravată de faptul că la utilizarea protocolului HTTP/1.1 (până la apariția SPDY, QUIC și HTTP/2, acesta era singurul variant) browserele deschideau nu mai mult de 6 conexiuni TCP la un singur host. Totul ducea la inactivitate a conexiunii și utilizarea ineficientă a lățimii de bandă. Problema era parțial rezolvată prin sharding de domenii - crearea de hosturi suplimentare pentru a depăși limita de conexiuni.

Aici apare a doua capacitate a CDN-ului - reducerea întârzierilor (RTT) datorită numărului mare de puncte și apropierea nodurilor de utilizator. Distanța joacă un rol decisiv: viteza luminii este limitată (aproximativ 200.000 km/sec în fibră optică). Asta înseamnă că fiecare 1000 km parcurs adaugă 5 ms de întârzieri sau 10 ms în RTT. Acestea sunt cheltuielile minime de timp pentru transfer, deoarece există și întârzieri pe echipamentele intermediare. Deoarece CDN-urile pot în general să cacheze obiecte pe serverele lor, putem beneficia de încărcarea acestor obiecte prin intermediul CDN-ului. Condițiile necesare pentru aceasta sunt: existența obiectului în cache, apropierea punctului CDN față de utilizator în comparație cu serverul aplicației web (serverul de origine). Este important de înțeles: apropierea geografică a nodului CDN nu garantează întârzieri scăzute. Rutarea între client și CDN poate fi construită astfel încât clientul să se conecteze la un host din altă țară, eventual chiar de pe un alt continent. Aici intervin relațiile operatorilor de telecomunicații și ale serviciului CDN (peering, existența punctelor de interconectare, participarea la IX etc.) și politica de rutare a traficului a CDN-ului în sine. De exemplu, Cloudflare, atunci când se utilizează cele două planuri de bază (cel gratuit și cel ieftin), nu garantează livrarea conținutului de la cel mai apropiat nod - alegerea hostului se va face pentru a atinge costul minim.

Multe companii mari de internet atrag atenția publicului (dezvoltatori web și proprietari de servicii) asupra temei vitezei de încărcare și funcționare a site-urilor. Printre aceste companii se numără Yahoo (instrumentul Yslow), AOL (WebPageTest) și Google (serviciul Page Speed Insights), care dezvoltă propriile recomandări pentru accelerarea site-urilor (în principal, acestea se referă la optimizarea pentru client). Ulterior, apar noi instrumente de testare a vitezei site-urilor, care oferă și recomandări pentru creșterea vitezei. În fiecare dintre aceste servicii sau pluginuri există o recomandare constantă: „Folositi CDN”. De obicei, explicația efectului CDN este reducerea întârzierilor de rețea. Din păcate, nu toată lumea este pregătită să înțeleagă cum se obține efectul de accelerare oferit de CDN și cum poate fi măsurat, așa că recomandarea este acceptată pe încredere și folosită ca un postulat. De fapt, nu toate CDN-urile sunt la fel de utile.

Utilizarea CDN-ului astăzi

Pentru a evalua utilitatea aplicării CDN-urilor, acestea trebuie clasificate. Ce putem întâlni acum în practică (exemplele din paranteze, desigur, nu sunt exhaustive):

1. CDN-uri gratuite pentru livrarea bibliotecilor JS (MaxCDN, Google, Yandex).
2. CDN-uri pentru optimizarea clientului (de exemplu Google Fonts pentru fonturi, Cloudinary, Cloudimage pentru imagini).
3. CDN pentru statice și optimizarea resurselor în CMS (disponibile în Bitrix, WordPress și altele).
4. CDN-uri de uz general (StackPath, CDNVideo, NGENIX, MegaFon).
5. CDN-uri pentru accelerarea site-urilor (Cloudflare, Imperva, Airy).

Principala diferență între aceste tipuri constă în următorul aspect: ce parte din trafic trece prin CDN. Tipurile 1-3 se ocupă doar de livrarea unei părți din conținut: de la o cerere la câteva zeci (de obicei imagini). Tipurile 4 și 5 implică proxy complet al traficului prin CDN.

În practică, acest lucru înseamnă numărul de conexiuni utilizate pentru a încărca site-ul. Când folosim HTTP/2, folosim o singură conexiune TCP la gazdă pentru a procesa orice număr de cereri. Dacă împărțim resursele între gazda principală (origin) și CDN, trebuie să distribuim cererile pe mai multe domenii și să creăm mai multe conexiuni TCP. În cel mai rău caz, aceasta înseamnă: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. În această formulă nu sunt incluse întârzierile din rețelele mobile pentru activarea canalului radio al dispozitivului (dacă acesta nu a fost activat) și întârzierile pe turnul de telefonie mobilă.

Iată cum arată pe diagrama de încărcare a site-ului (sunt evidențiate întârzierile pentru conectarea la CDN cu RTT de 150 ms):

Dacă CDN-ul acoperă tot traficul site-ului (cu excepția serviciilor externe), atunci putem folosi o singură conexiune TCP, economisind întârzieri în conectarea la gazde suplimentare. Desigur, acest lucru se aplică conexiunilor HTTP/2.

Diferențele ulterioare sunt determinate de funcționalitatea specifică a fiecărui CDN – pentru primul tip este vorba doar despre hosting fișiere statice, iar pentru al cincilea este vorba despre modificarea mai multor tipuri de conținut al site-ului pentru a optimiza.

Capacitățile CDN-ului în accelerarea site-ului

Să descriem întreaga gamă de capacități ale CDN-ului în accelerarea site-urilor, fără a ne întoarce la funcționalitatea tipurilor specifice de CDN, și apoi să vedem ce din acestea este implementat în fiecare dintre ele.

1. Comprimarea resurselor textuale

Cea mai de bază și clară capacitate, totuși adesea implementată prost. Toate CDN-urile declară comprimarea ca o caracteristică de accelerare. Dar, dacă ne uităm mai atent, apar neajunsuri:

• se pot utiliza grade scăzute pentru compresia dinamică – 5-6 (de exemplu, pentru gzip maximul este 9);
• în compresia statică (fișierele din cache) nu se utilizează opțiuni suplimentare (de exemplu, zopfi sau brotli cu gradul 11);
• nu există suport pentru compresia eficientă brotli (economisind aproximativ 20% comparativ cu gzip).

Dacă folosiți un CDN, ar trebui să verificați aceste câteva puncte: luați un fișier care a venit de la CDN, fixați dimensiunea sa în formă comprimată și recompresați manual pentru comparație (puteți folosi un serviciu online care suportă brotli, de exemplu, toatesigurat.ro).

2. Setarea anteturilor de cache pentru client

De asemenea, o caracteristică simplă de accelerare: setarea anteturilor pentru cache-ul de conținut pe partea clientului (browser). Cel mai relevant antet este cache-control, iar cel învechit – expires. În plus, se poate folosi Etag. Principalul lucru este ca max-age din cache-control să fie suficient de mare (de la o lună în sus); dacă sunteți gata să conservați resursa într-un mod foarte strict, puteți adăuga opțiunea immutable.

CDN-urile pot subestima valoarea max-age, forțând utilizatorul să descarce din nou statica mai des. Motivul pentru aceasta poate fi dorința de a crește traficul pe rețea sau o mai bună compatibilitate cu site-urile care nu știu să reîmprospăteze cache-ul – nu este clar. De exemplu, valoarea timpului de caching în header-urile Cloudflare este, în mod implicit, de 1 oră, ceea ce este foarte puțin pentru statica nemodificată.

3. Optimizarea imaginilor

Având în vedere că CDN-ul îndeplinește funcțiile de caching și livrare a imaginilor, este logic să le optimizăm de partea CDN-ului și să le livrăm utilizatorilor în această formă. Menționăm că această opțiune este disponibilă doar pentru tipurile de CDN 2, 3 și 5.

Imaginile pot fi optimizate în diverse moduri: utilizând formate avansate de compresie (de exemplu, WebP), encoder-e mai eficiente (MozJPEG) sau pur și simplu curățând metadatele inutile.

În general, există două tipuri de astfel de optimizări: cu pierdere de calitate și fără pierdere de calitate. CDN-urile tind să folosească optimizări fără pierderi – pentru a evita posibilele plângeri ale clienților cu privire la modificarea calității imaginilor. În astfel de condiții, câștigul va fi minim. În realitate, nivelul de calitate JPEG depășește adesea necesarul și se poate proceda fără probleme la recompresie cu un indicator de calitate mai mic, fără a afecta percepția utilizatorilor. Pe de altă parte, a determina nivelul de calitate și setările universale pentru toate aplicațiile web posibile este dificil, așa că CDN-urile folosesc setări mai conservatoare în comparație cu cele care ar putea fi aplicate în funcție de context (destinația imaginilor, tipul de aplicație web etc.)

4. Optimizarea conexiunii TLS

Majoritatea traficului este transmis prin conexiuni TLS, ceea ce înseamnă că noi investim timp suplimentar în negocierea TLS. În ultima vreme, au fost dezvoltate noi tehnologii pentru accelerarea acestui proces. De exemplu, este vorba de criptografia EC, TLS 1.3, caching-ul sesiunilor și tichetelor (session tickets), accelerarea hardware a criptării (AES-NI) etc. O configurare corectă a TLS permite reducerea timpului de conectare la 0-1 RTT (fără a include DNS și TCP).

Atunci când există software modern, implementarea acestor practici nu este dificilă pe propriile resurse.

Nu toate CDN-uri implementează cele mai bune practici pentru TLS, iar acest lucru poate fi verificat măsurând timpul de conectare TLS (de exemplu, în Webpagetest). Ideal pentru o nouă conexiune este 1RTT, 2RTT este nivel mediu, iar 3RTT și mai mult – slab.

De asemenea, este important de menționat că, chiar și în cazul utilizării TLS la nivelul CDN, serverul cu aplicația noastră web trebuie să proceseze de asemenea TLS, însă din partea CDN, deoarece traficul dintre server și CDN circulă într-o rețea publică. În cel mai rău caz, putem obține întârzieri duble de conectare TLS (prima către gazda CDN, a doua între aceasta și serverul nostru).

Pentru unele aplicații, este important să ne concentrăm asupra problemelor de securitate: de obicei, traficul este decriptat pe nodurile CDN, ceea ce reprezintă o oportunitate potențială pentru interceptarea traficului. O opțiune de lucru fără divulgarea traficului este de obicei oferită în planurile de top, contra unei taxe suplimentare.

5. Reducerea întârzierilor de conectare

Cel mai important avantaj al CDN, despre care toată lumea vorbește: întârzieri reduse (o distanță mai mică) între gazda CDN și utilizator. Acest lucru se realizează prin crearea unei arhitecturi de rețea geografic distribuite, în care gazdele sunt situate în puncte de concentrație a utilizatorilor (orașe, puncte de schimb de trafic etc.).

În practică, prioritățile diferitelor rețele pot fi concentrate în regiuni specifice. De exemplu, CDN-urile din Rusia vor avea mai multe puncte de prezență în Rusia. Cele americane se vor dezvolta în primul rând în Statele Unite. De exemplu, unul dintre cele mai mari CDN-uri, Cloudflare, are doar 2 puncte în Rusia - Moscova și Sankt Petersburg. Asta înseamnă că, în cel mai bun caz, putem economisi aproximativ 10 ms de întârziere comparativ cu găzduirea directă în Moscova.

Majoritatea CDN-urilor occidentale nu au deloc puncte în Rusia. Conectându-vă la ele, puteți doar să creșteți întârzierile pentru publicul dvs. din Rusia.

6. Optimizarea conținutului (minimizarea, modificări structurale)

Cel mai complicat și tehnologic punct. Modificarea conținutului în timpul livrării poate fi foarte riscantă. Chiar și în cazul minimizării: reducerea codului sursă (prin eliminarea spațiilor inutile, construcțiilor nesemnificative etc.) poate afecta funcționarea acestuia. Dacă ne referim la modificări mai serioase - mutarea codului JS la sfârșitul HTML-ului, combinarea fișierelor și similare - riscul de a compromite funcționalitatea site-ului este și mai ridicat.

Prin urmare, doar câteva CDN din tipul 5 se ocupă de acest lucru. Desigur, automatizarea tuturor modificărilor necesare pentru accelerare nu va fi posibilă – este nevoie de analiză manuală și optimizare. De exemplu, eliminarea codului neutilizat sau duplicat este o sarcină manuală.

În general, toate aceste optimizări sunt gestionate prin setări și cele mai periculoase sunt dezactivate în mod implicit.

Suport pentru capabilitățile de accelerare pe tipuri de CDN

Așadar, să vedem care dintre capabilitățile potențiale de accelerare oferite de diferitele tipuri de CDN.

Pentru confort, să repetăm clasificarea.

1. CDN-uri gratuite pentru livrarea bibliotecilor JS (MaxCDN, Google, Yandex).
2. CDN-uri pentru optimizarea clientului (de exemplu Google Fonts pentru fonturi, Cloudinary, Cloudimage pentru imagini).
3. CDN pentru statice și optimizarea resurselor în CMS (disponibile în Bitrix, WordPress și altele).
4. CDN-uri de uz general (StackPath, CDNVideo, NGENIX, MegaFon).
5. CDN-uri pentru accelerarea site-urilor (Cloudflare, Imperva, Airy).

Acum să comparăm caracteristicile și tipurile de CDN.

Posibilitatea
Tip 1
Tip 2
Tip 3
Tip 4
Tip 5

Compresia textului
+–
–
+–
+–
+

Antetele cache-ului
+
+
+
+
+

Imagini
–
+–
+–
–
+

TLS
–
–
–
+–
+

Retrageri
–
–
–
+
+

Conținut
–
–
–
–
+

În acest tabel, „+” este folosit pentru a indica suportul complet, „–” pentru absență, iar „+–” pentru suport parțial. Desigur, pot exista abateri de la acest tabel în realitate (de exemplu, un CDN de utilizare generală poate implementa caracteristici pentru optimizarea imaginilor), dar pentru o imagine de ansamblu, este util.

Concluzii

Sper că, citind acest articol, veți avea o idee mai clară despre recomandarea „folosiți CDN” pentru accelerarea site-urilor.

Ca în orice domeniu, nu trebuie să credeți promisiunile de marketing ale vreunui serviciu. Efectul trebuie măsurat și verificat în condiții reale. Dacă deja folosiți un CDN, verificați-l pentru eficiență conform criteriilor descrise în articol.

Este posibil ca utilizarea CDN-ului în acest moment să încetinească încărcarea site-ului dvs.

Ca o recomandare generală, puteți considera următoarele: studiați-vă audiența, determinați-i limitele geografice. Dacă publicul vostru principal este concentrat într-un radius de 1-2 mii de kilometri, nu aveți nevoie de CDN în scopul său principal – reducerea întârzierilor. În schimb, puteți plasa serverul mai aproape de utilizatori și să-l configurați corespunzător, obținând cele mai multe optimizări descrise în articol (gratis și constant).

Dacă publicul vostru este într-adevăr distribuit geografic (cu un radius mai mare de 3000 kilometri), utilizarea unei CDN de calitate va fi cu adevărat utilă. Totuși, trebuie să înțelegeți din timp ce anume va accelera CDN-ul vostru (vezi tabelul cu funcționalitățile și descrierile acestora). Accelerarea site-ului rămâne o sarcină complexă care nu se rezolvă doar prin conectarea la o CDN. Pe lângă optimizările menționate, cele mai eficiente metode de accelerare rămân în afara CDN-ului: optimizarea părții serverului, modificări avansate ale părții clientului (eliminarea codului neutilizat, optimizarea procesului de redare, gestionarea conținutului, fonturilor, adaptabilității etc.)

Sursa: habr.com