[Nu] utilizați un CDN

Aproape fiecare articol sau instrument pentru optimizarea vitezei site-ului are o clauză modestă „utilizați un CDN”. În general, CDN este o rețea de livrare de conținut sau o rețea de livrare de conținut. Noi, cei de la Method Lab, întâlnim adesea întrebări de la clienți pe această temă, unii dintre ei își activează propriul CDN. Scopul acestui articol este de a înțelege ce poate oferi un CDN în ceea ce privește viteza de încărcare a site-ului, ce probleme pot apărea și în ce cazuri este justificată utilizarea unui CDN.

Întârzierile încercuite în imagine sunt cauzate de utilizarea unui CDN.

Un pic de istorie

Ca multe tehnologii, CDN-urile au apărut din necesitate. Odată cu dezvoltarea canalelor de internet în rândul utilizatorilor de internet, au apărut serviciile video online. Desigur, conținutul video necesită ordine de mărime mai multă lățime de bandă în comparație cu conținutul obișnuit al site-ului web (imagini, text și cod CSS sau JS).

Când încercați să difuzați un flux video în paralel cu mai mulți clienți de pe un server, canalul de Internet al serverului va deveni cel mai probabil un blocaj. De regulă, câteva mii de fire sunt suficiente pentru a înfunda un canal tipic de server. Desigur, pot exista și alte limitări ale resurselor, dar acestea nu sunt importante în acest moment. De asemenea, este important că extinderea canalului de server este prea costisitoare (și uneori imposibilă) și, de asemenea, nepractică. Încărcarea pe canal în timpul transmisiilor va fi ciclică.

Problema limitării canalului unui server individual este rezolvată perfect de CDN. Clienții nu se conectează direct la server, ci la noduri din rețeaua CDN. Într-o situație ideală, serverul trimite un flux către nodul CDN, iar apoi rețeaua își folosește propriile resurse pentru a livra acest flux către mulți utilizatori. Din punct de vedere economic, plătim doar pentru resursele efectiv consumate (aceasta ar putea fi lățime de bandă sau trafic) și obținem o scalabilitate excelentă a serviciului nostru. Utilizarea unui CDN pentru a livra conținut greu este complet justificată și logică. Deși este de remarcat faptul că cei mai mari jucători din acest spațiu (de exemplu, Netflix) își construiesc propriile CDN-uri în loc să folosească CDN-uri comerciale mari (Akamai, Cloudflare, Fastly etc.)

Pe măsură ce web-ul a evoluat, aplicațiile web în sine au devenit mai complexe și mai complexe. Problema vitezei de încărcare a apărut în prim-plan. Pasionații de viteză a site-urilor web au identificat rapid câteva probleme majore care au făcut ca site-urile web să se încarce încet. Unul dintre ele a fost întârzierile de rețea (RTT - round trip time sau ping time). Întârzierile afectează multe procese în încărcarea site-ului web: stabilirea unei conexiuni TCP, pornirea unei sesiuni TLS, încărcarea fiecărei resurse individuale (imagine, fișier JS, document HTML etc.)

Problema a fost agravată de faptul că atunci când se folosește protocolul HTTP/1.1 (înainte de apariția SPDY, QUIC și HTTP/2 aceasta era singura opțiune), browserele nu deschid mai mult de 6 conexiuni TCP la o singură gazdă. Toate acestea au dus la oprirea conexiunii și la utilizarea ineficientă a lățimii de bandă a canalului. Problema a fost parțial rezolvată prin shardingul domeniului - crearea de gazde suplimentare pentru a depăși limita privind numărul de conexiuni.

Aici apare a doua abilitate a CDN - reducerea latenței (RTT) datorită numărului mare de puncte și a proximității nodurilor față de utilizator. Distanța joacă aici un rol decisiv: viteza luminii este limitată (aproximativ 200 km/sec în fibra optică). Aceasta înseamnă că fiecare 000 km de călătorie adaugă 1000 ms de întârziere sau 5 ms la RTT. Acesta este timpul minim necesar pentru transmisie, deoarece există și întârzieri la echipamentul intermediar. Deoarece un CDN știe de obicei cum să memoreze în cache obiectele de pe serverele sale, putem beneficia de încărcarea unor astfel de obiecte printr-un CDN. Condiții necesare pentru aceasta: prezența obiectului în cache, proximitatea punctului CDN față de utilizator în comparație cu serverul de aplicații web (server de origine). Este important să înțelegeți că proximitatea geografică a unui nod CDN nu garantează o latență scăzută. Rutarea între client și CDN poate fi construită în așa fel încât clientul să se conecteze la o gazdă din altă țară și, eventual, pe alt continent. Aici intervin relația dintre operatorii de telecomunicații și serviciul CDN (peering, conexiuni, participare la IX etc.) și politica de rutare a traficului a CDN-ului însuși. De exemplu, Cloudflare, atunci când folosește două planuri inițiale (gratuit și ieftin), nu garantează livrarea conținutului de la cea mai apropiată gazdă - gazda va fi selectată pentru a atinge costul minim.

Multe companii de internet de top atrag interesul publicului (dezvoltatori web și proprietari de servicii) asupra subiectului vitezei de încărcare și a performanței site-ului web. Printre aceste companii se numără Yahoo (instrumentul Yslow), AOL (WebPageTest) și Google (serviciul Page Speed ​​​​Insights), care își dezvoltă propriile recomandări pentru accelerarea site-urilor (acestea se referă în primul rând la optimizarea clienților). Mai târziu, apar noi instrumente de testare a vitezei site-ului, care oferă, de asemenea, sfaturi pentru creșterea vitezei site-ului. Fiecare dintre aceste servicii sau pluginuri are o recomandare consecventă: „Utilizați un CDN”. Reducerea latenței rețelei este de obicei citată ca o explicație pentru efectul CDN. Din păcate, nu toată lumea este pregătită să înțeleagă exact cum se realizează efectul de accelerare al CDN și cum poate fi măsurat, așa că recomandarea este luată pe baza credinței și folosită ca postulat. De fapt, nu toate CDN-urile sunt create egale.

Folosind un CDN astăzi

Pentru a evalua utilitatea utilizării CDN-urilor, acestea trebuie să fie clasificate. Ce se poate găsi acum în practică (exemplele dintre paranteze nu sunt, desigur, exhaustive):

1. CDN gratuit pentru distribuirea bibliotecilor JS (MaxCDN, Google. Yandex).
2. CDN de servicii pentru optimizarea clientului (de exemplu, Fonturi Google pentru fonturi, Cloudinary, Cloudimage pentru imagini).
3. CDN pentru optimizarea statică și a resurselor în CMS (disponibil în Bitrix, WordPress și altele).
4. CDN de uz general (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN pentru accelerarea site-ului web (Cloudflare, Imperva, Airi).

Diferența cheie între aceste tipuri este cât de mult din trafic trece prin CDN. Tipurile 1-3 sunt livrarea doar a unei părți a conținutului: de la o solicitare la câteva zeci (de obicei imagini). Tipurile 4 și 5 sunt proxy completă a traficului printr-un CDN.

În practică, aceasta înseamnă numărul de conexiuni care sunt folosite pentru a încărca site-ul. Cu HTTP/2, folosim o singură conexiune TCP la gazdă pentru a procesa orice număr de solicitări. Dacă împărțim resursele în gazda principală (origine) și CDN, atunci este necesar să distribuim cererile pe mai multe domenii și să creăm mai multe conexiuni TCP. Cel mai rău caz este: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Această formulă nu ia în considerare întârzierile din rețelele mobile pentru activarea canalului radio al dispozitivului (dacă nu a fost activ) și întârzierile pe turnul celular.

Iată cum arată pe cascada de încărcare a site-ului (latențele pentru conectarea la CDN sunt evidențiate la RTT 150 ms):

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

Alte diferențe sunt determinate de funcționalitatea unui anumit CDN - pentru primul tip este doar găzduiește un fișier static, pentru al cincilea schimbă mai multe tipuri de conținut de site în scopul optimizării.

Capabilități CDN pentru accelerarea site-ului web

Să descriem întreaga gamă de capabilități CDN pentru accelerarea site-urilor, fără a ține cont de funcționalitatea tipurilor individuale de CDN, apoi să vedem ce este implementat în fiecare dintre ele.

1. Comprimarea resurselor de text

Caracteristica cea mai de bază și de înțeles, dar adesea prost implementată. Toate CDN-urile declară prezența compresiei drept caracteristică de accelerare. Dar dacă te uiți mai în detaliu, deficiențele devin clare:

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

Dacă utilizați un CDN, merită să verificați aceste câteva puncte: luați fișierul care a venit din CDN, înregistrați dimensiunea comprimată a acestuia și comprimați-l manual pentru comparație (puteți folosi un serviciu online cu suport brotli, de exemplu vsszhat.rf).

2. Setarea antetelor de cache ale clientului

De asemenea, o funcție simplă de accelerare: adăugați anteturi pentru stocarea în cache a conținutului de către client (browser). Cel mai actual antet este cache-control, cel învechit este expiră. În plus, Etag poate fi utilizat. Principalul lucru este că vârsta maximă a controlului cache-ului este suficient de mare (de la o lună sau mai mult, dacă sunteți gata să stocați în cache resursa cât mai mult posibil, puteți adăuga opțiunea imuabilă).

CDN-urile pot scădea valoarea maximă a vârstei, forțând utilizatorul să reîncarce mai des conținutul static. Nu este clar cu ce se leagă acest lucru: dorința de a crește traficul în rețea sau de a crește compatibilitatea cu site-urile care nu știu să resetați memoria cache. De exemplu, timpul implicit de cache a antetului Cloudflare este de 1 oră, ceea ce este foarte scăzut pentru date statice imuabile.

3. Optimizarea imaginii

Deoarece CDN-ul preia funcțiile de stocare în cache și de servire a imaginilor, ar fi logic să le optimizăm pe partea CDN și să le oferim utilizatorilor în această formă. Să facem imediat o rezervare că această funcție este disponibilă numai pentru tipurile CDN 2, 3 și 5.

Puteți optimiza imaginile într-o varietate de moduri: folosind formate avansate de compresie (cum ar fi WebP), codificatoare 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 se străduiesc de obicei să utilizeze optimizarea fără pierderi pentru a evita posibilele plângeri ale clienților cu privire la modificările calității imaginii. În astfel de condiții, câștigul va fi minim. În realitate, de multe ori nivelul de calitate JPEG este mult mai mare decât este necesar și puteți recomprima în siguranță cu un nivel de calitate mai scăzut, fără a compromite experiența utilizatorului. Pe de altă parte, este dificil să se determine universal nivelul de calitate și setări pentru toate aplicațiile web posibile, astfel încât CDN-urile folosesc setări mai conservatoare în comparație cu cele care pot fi aplicate ținând cont de context (scopul imaginilor, tipul de aplicație web). , etc.)

4. Optimizarea conexiunii TLS

Majoritatea traficului de astăzi se deplasează prin conexiuni TLS, ceea ce înseamnă că petrecem timp suplimentar negocierilor TLS. Recent, au fost dezvoltate noi tehnologii pentru a accelera acest proces. De exemplu, aceasta este criptografia EC, TLS 1.3, memoria cache și biletele de sesiune, accelerarea criptării hardware (AES-NI), etc. Setarea corectă a TLS poate reduce timpul de conectare la 0-1 RTT (fără a lua în considerare DNS și TCP).

Cu software-ul modern, nu este dificil să implementați astfel de practici pe cont propriu.

Nu toate CDN-urile implementează cele mai bune practici TLS, puteți verifica acest lucru măsurând timpul de conectare TLS (de exemplu, în Webpagetest). Ideal pentru o nouă conexiune - 1RTT, 2RTT - nivel mediu, 3RTT și mai mult - rău.

De asemenea, trebuie remarcat faptul că și atunci când se utilizează TLS la nivel CDN, serverul cu aplicația noastră web trebuie să proceseze și TLS, dar din partea CDN, deoarece traficul dintre server și CDN trece pe rețeaua publică. În cel mai rău caz, vom obține întârzieri duble ale conexiunii TLS (prima la gazda CDN, a doua între aceasta și serverul nostru).

Pentru unele aplicații, merită să acordați atenție problemelor de securitate: traficul este, de obicei, decriptat pe nodurile CDN, iar aceasta este o oportunitate potențială pentru interceptarea traficului. Opțiunea de a lucra fără dezvăluirea traficului este de obicei oferită în planurile tarifare de top pentru o taxă suplimentară.

5. Reduceți întârzierile de conectare

Principalul beneficiu al CDN-ului despre care vorbește toată lumea: latența scăzută (distanță mai mică) între gazda CDN și utilizator. Realizat prin crearea unei arhitecturi de rețea distribuite geografic, în care gazdele sunt situate în puncte de concentrare a utilizatorilor (orașe, puncte de schimb de trafic etc.)

În practică, prioritățile pentru diferite rețele pot fi în anumite regiuni. De exemplu, CDN-urile rusești vor avea mai multe puncte de prezență în Rusia. Cei americani vor dezvolta in primul rand reteaua in SUA. De exemplu, unul dintre cele mai mari CDN Cloudflare are doar 2 puncte în Rusia - Moscova și Sankt Petersburg. Adică putem economisi maxim aproximativ 10 ms de latență față de plasarea directă la Moscova.

Majoritatea CDN-urilor occidentale nu au deloc puncte în Rusia. Conectându-te la ele, nu poți decât să mărești întârzierile pentru publicul tău rus.

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

Cel mai complex și mai avansat punct tehnologic. Modificarea conținutului în timpul livrării poate fi foarte riscantă. Chiar dacă luăm minimizarea: reducerea codului sursă (din cauza spațiilor suplimentare, structurilor neimportante etc.) poate afecta performanța acestuia. Dacă vorbim de modificări mai serioase - mutarea codului JS la sfârșitul HTML, fuzionarea fișierelor etc. - riscul de a perturba funcționalitatea site-ului este și mai mare.

Prin urmare, doar unele CDN-uri de tip 5 fac acest lucru. Desigur, nu va fi posibilă automatizarea tuturor modificărilor necesare pentru a accelera lucrurile – sunt necesare analize și optimizare manuale. De exemplu, eliminarea codului neutilizat sau duplicat este o sarcină manuală.

De regulă, toate astfel de optimizări sunt controlate de setări, iar cele mai periculoase sunt dezactivate implicit.

Suport pentru capabilități de accelerare în funcție de tipul CDN

Deci, să aruncăm o privire la ce oportunități potențiale de accelerare oferă diferitele tipuri de CDN-uri.

Pentru comoditate, repetăm ​​clasificarea.

1. CDN gratuit pentru distribuirea bibliotecilor JS (MaxCDN, Google. Yandex).
2. CDN de servicii pentru optimizarea clientului (de exemplu, Fonturi Google pentru fonturi, Cloudinary, Cloudimage pentru imagini).
3. CDN pentru optimizarea statică și a resurselor în CMS (disponibil în Bitrix, WordPress și altele).
4. CDN de uz general (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN pentru accelerarea site-ului web (Cloudflare, Imperva, Airi).

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

Oportunitate
Tastați 1
Tastați 2
Tastați 3
Tastați 4
Tastați 5

Comprimarea textului
+–
-
+–
+–
+

Antetele din cache
+
+
+
+
+

poze
-
+–
+–
-
+

TLS
-
-
-
+–
+

Întârzieri
-
-
-
+
+

Conținut
-
-
-
-
+

În acest tabel, „+” este folosit pentru a indica suport complet, „–” nu este suport și „+–” este suport parțial. Desigur, pot exista abateri de la acest tabel în realitate (de exemplu, unele CDN de uz general vor implementa caracteristici pentru optimizarea imaginilor), dar pentru o idee generală este util.

Rezultatele

Sperăm că, după ce ați citit acest articol, veți avea o imagine mai clară cu privire la recomandarea „utilizați un CDN” pentru a vă accelera site-urile.

Ca în orice afacere, nu poți să crezi promisiunile de marketing ale oricărui serviciu. Efectul trebuie măsurat și testat în condiții reale. Dacă utilizați deja un CDN, verificați eficacitatea acestuia folosind criteriile descrise în articol.

Este posibil ca utilizarea unui CDN chiar acum să încetinească timpul de încărcare a site-ului dvs.

Ca recomandare generală, ne putem concentra pe următoarele: studiați-vă publicul, determinați sfera sa geografică. Dacă publicul dvs. principal este concentrat pe o rază de 1-2 mii de kilometri, nu aveți nevoie de un CDN pentru scopul său principal - reducerea latenței. În schimb, vă puteți plasa serverul mai aproape de utilizatori și îl puteți configura corect, obținând majoritatea optimizărilor descrise în articol (gratuit și permanent).

În cazul în care audiența dvs. este cu adevărat distribuită geografic (rază de peste 3000 de kilometri), folosirea unui CDN de calitate va fi cu adevărat utilă. Cu toate acestea, trebuie să înțelegeți dinainte ce anume poate accelera CDN-ul dvs. (consultați tabelul de capabilități și descrierea acestora). Cu toate acestea, accelerarea site-ului rămâne o sarcină complexă care nu poate fi rezolvată prin conectarea unui CDN. Pe lângă optimizările de mai sus, în spatele CDN-ului rămân cele mai eficiente mijloace de accelerare: optimizarea părții server, modificări avansate ale părții client (eliminarea codului neutilizat, optimizarea procesului de randare, lucrul cu conținut, fonturi, adaptabilitate etc. )

Sursa: www.habr.com