ProHoster > Blog > Amministrazione > [Ùn] utilizate un CDN

[Ùn] utilizate un CDN

Quasi ogni articulu o strumentu per ottimisà a velocità di u situ hà una clause modesta "utilizate un CDN". In generale, CDN hè una rete di distribuzione di cuntenutu o rete di distribuzione di cuntenutu. Avemu à Method Lab spessu scontru dumande da i clienti nantu à questu tema, alcuni di elli attivanu u so propiu CDN. U scopu di questu articulu hè di capisce ciò chì un CDN pò furnisce in quantu à a velocità di carica di u situ, chì prublemi ponu esse, è in quali casi l'usu di un CDN hè ghjustificatu.

[Ùn] utilizate un CDN

I ritardi circundati in a stampa sò causati da l'usu di un CDN.

Un pocu di storia

Cum'è parechje tecnulugii, i CDN sò emersi da a necessità. Cù u sviluppu di i canali Internet trà l'utilizatori di Internet, i servizii di video in ligna apparsu. Naturalmente, u cuntenutu video richiede ordini di grandezza più larghezza di banda cumparatu cù u cuntenutu regulare di u situ web (foto, testu è codice CSS o JS).

Quandu pruvate di trasmette un flussu di video in parallelu à parechji clienti da un servitore, u canali Internet di u servitore diventerà probabilmente u collu di buttiglia. In regula, uni pochi di millai di fili sò abbastanza per obstruisce un canali tipicu di u servitore. Di sicuru, ci ponu esse altre limitazioni di risorse, ma ùn sò micca impurtanti avà. Hè ancu impurtante chì l'espansione di u canali di u servitore hè troppu caru (è qualchì volta impussibile), è ancu impracticable. A carica nantu à u canali durante i broadcasts serà ciclicu.

U prublema di limità u canali di un servitore individuale hè perfettamente risoltu da CDN. I clienti ùn sò micca cunnessi à u servitore direttamente, ma à i nodi in a reta CDN. In una situazione ideale, u servitore manda un flussu à u node CDN, è dopu a reta usa e so risorse per furnisce stu flussu à parechji utilizatori. Da un puntu di vista ecunomicu, paghemu solu per i risorse veramente cunsumati (questu puderia esse larghezza di banda o trafficu) è uttene una scalabilità eccellente di u nostru serviziu. Utilizà un CDN per furnisce un cuntenutu pesante hè cumplettamente ghjustificatu è logicu. Ancu s'ellu vale a pena nutà chì i più grandi attori in questu spaziu (per esempiu, Netflix) custruiscenu i so propri CDN invece di utilizà grandi CDN cummirciali (Akamai, Cloudflare, Fastly, etc.)

Quandu u web hà evolutu, l'applicazioni web sò diventate più cumplesse è cumplesse. U prublema di a velocità di carica hè vinutu à u primu. L'amatori di a velocità di u situ web identificanu rapidamente parechji prublemi maiò chì anu causatu i siti web per carica lentamente. Unu di elli era i ritardu di a rete (RTT - tempu di andata e ritorno o tempu di ping). I ritardi affettanu parechji prucessi in u caricamentu di u situ web: stabilisce una cunnessione TCP, inizià una sessione TLS, carica ogni risorsa individuale (imagine, file JS, document HTML, etc.)

U prublema hè stata aggravata da u fattu chì quandu si usa u protocolu HTTP / 1.1 (prima di l'avventu di SPDY, QUIC è HTTP / 2 era l'unica opzione), i navigatori ùn aprenu micca più di 6 cunnessione TCP à un host. Tuttu chistu hà purtatu à un downtime di cunnessione è un usu inefficace di a larghezza di banda di u canali. U prublema hè stata risolta parzialmente da u duminiu di u duminiu - a creazione di ospiti supplementari per superà u limitu di u numeru di cunnessione.

Hè quì chì a seconda capacità di CDN appare - riducendu a latenza (RTT) per u gran numaru di punti è a vicinanza di i nodi à l'utilizatori. A distanza ghjoca un rolu decisivu quì: a vitezza di a luce hè limitata (circa 200 000 km/sec in fibra ottica). Questu significa chì ogni 1000 km di viaghju aghjunghje 5 ms di ritardu o 10 ms à RTT. Questu hè u tempu minimu necessariu per a trasmissione, postu chì ci sò ancu ritardi in l'equipaggiu intermediu. Siccomu un CDN di solitu sapi cumu cache l'uggetti nantu à i so servitori, pudemu prufittà di carricà tali oggetti attraversu un CDN. Cundizioni necessarii per questu: a presenza di l'ughjettu in u cache, a vicinanza di u puntu CDN à l'utilizatore in paragunà cù u servitore di l'applicazioni web (servitore d'origine). Hè impurtante di capisce chì a vicinanza geografica di un node CDN ùn guarantisci micca una latenza bassa. U routing trà u cliente è u CDN pò esse custruitu in tale manera chì u cliente si cunnetta à un host in un altru paese, è possibbilmente in un altru cuntinente. Hè quì chì a relazione trà l'operatori di telecomunicazioni è u serviziu CDN (peering, cunnessione, participazione à IX, etc.) è a pulitica di routing di u trafficu di u CDN stessu entra in ghjocu. Per esempiu, Cloudflare, quandu si usa dui piani iniziali (gratis è prezzu), ùn guarantisci micca a consegna di cuntenutu da l'ospitu più vicinu - l'ospitu serà sceltu per ottene u costu minimu.

Parechje cumpagnie Internet di punta attrae l'interessu publicu (sviluppatori web è pruprietarii di servizii) à u tema di a velocità di carica è u performance di u situ web. Frà queste cumpagnie sò Yahoo (Yslow tool), AOL (WebPageTest) è Google (Page Speed ​​​​Insights service), chì sviluppanu e so propiu cunsiglii per accelerà i siti (principalmente sò in relazione à l'ottimisazione di u cliente). In seguitu, appariscenu novi strumenti di teste di velocità di u situ web, chì furnisce ancu cunsiglii per aumentà a velocità di u situ web. Ognunu di sti servizii o plugins hà una ricunniscenza coherente: "Usate un CDN". A riduzzione di a latenza di a rete hè generalmente citata cum'è una spiegazione per l'effettu di CDN. Sfurtunatamente, micca tutti sò pronti à capisce esattamente cumu l'effettu di l'accelerazione di CDN hè rializatu è cumu si pò esse misurata, cusì a ricunniscenza hè presa nantu à a fede è usata cum'è postulatu. In fatti, micca tutti i CDN sò creati uguali.

Utilizà CDN oghje

Per evaluà l'utilità di l'usu di CDN, anu da esse classificatu. Ciò chì si pò truvà avà in pratica (l'esempii in parentesi sò, sicuru, micca exhaustivi):

  1. CDN gratuitu per a distribuzione di biblioteche JS (MaxCDN, Google. Yandex).
  2. CDN di servizii per l'ottimisazione di u cliente (per esempiu, Google Fonts per i fonts, Cloudinary, Cloudimage per l'imaghjini).
  3. CDN per ottimisazione statica è risorse in CMS (disponibile in Bitrix, WordPress è altri).
  4. CDN generale (StackPath, CDNVideo, NGENIX, Megafon).
  5. CDN per l'accelerazione di u situ web (Cloudflare, Imperva, Airi).

A diferenza chjave trà questi tipi hè quantu di u trafficu passa per u CDN. Tipi 1-3 sò a consegna di solu una parte di u cuntenutu: da una dumanda à parechje decine (di solitu stampi). I tipi 4 è 5 sò proxy cumpletu di u trafficu via un CDN.

In pratica, questu significa u numeru di cunnessione chì sò usati per carricà u situ. Cù HTTP / 2, usemu una sola cunnessione TCP à l'ospitu per processà ogni quantità di richieste. Se dividimu risorse in l'ospite principale (origine) è CDN, allora hè necessariu di distribuisce e dumande in parechji domini è creanu parechje cunnessione TCP. U peghju casu hè: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Sta formula ùn piglia micca in contu i ritardi in e rete mobile per l'attivazione di u canali radio di u dispusitivu (se ùn era micca attivu) è i ritardi in a torre cellulare.

Eccu ciò chì pare nantu à a cascata di carica di u situ (latenza per a cunnessione à u CDN sò evidenziate à RTT 150 ms):

[Ùn] utilizate un CDN

Se u CDN copre tuttu u trafficu di u situ (eccettu per i servizii di terzu), allora pudemu usà una sola cunnessione TCP, salvendu i ritardi in a cunnessione à l'ospiti supplementari. Di sicuru, questu hè applicatu à e cunnessione HTTP/2.

Ulteriori differenze sò determinate da a funziunalità di un CDN particulari - per u primu tipu hè solu ospitu un schedariu staticu, per u quintu hè cambiatu parechji tipi di cuntenutu di u situ per u scopu di ottimisazione.

Capacità CDN per l'accelerazione di u situ web

Descrivemu a gamma completa di capacità CDN per accelerà i siti, senza riguardu à e funziunalità di i tipi individuali di CDN, è poi vede ciò chì hè implementatu in ognuna di elli.

1. Cumpressione di risorse di testu

A funzione più basica è comprensibile, ma spessu mal implementata. Tutti i CDN dichjaranu a presenza di cumpressione cum'è a so funzione di accelerazione. Ma s'è guardate in più detail, i difetti diventanu chjaru:

  • bassu gradi per a compressione dinamica pò esse usatu - 5-6 (per esempiu, per gzip u massimu hè 9);
  • A compressione statica (fichi in cache) ùn usa micca funzioni supplementari (per esempiu, zopfi o brotli cù u gradu 11)
  • ùn ci hè micca supportu per a compressione brotli efficiente (saving about 20% compared to gzip).

Se aduprate un CDN, vale a pena cuntrollà questi pochi punti: pigliate u schedariu chì vene da u CDN, arregistrate a so dimensione cumpressa è cumpressa manualmente per paragunà (pudete aduprà qualchì serviziu in linea cù supportu brotli, per esempiu. vsszhat.rf).

2. Stabbilimentu di l'intestazione di cache di u cliente

Ancu una funzione simplice di accelerazione: aghjunghje intestazioni per u caching di cuntenutu da u cliente (browser). L'intestazione più attuale hè u cuntrollu di cache, quella obsoleta hè scaduta. Inoltre, Etag pò esse usatu. A cosa principal hè chì l'età massima di cache-control hè abbastanza grande (da un mesi o più) Sè vo site prontu à cache u risorsu u più duru pussibule, pudete aghjunghje l'opzione immutable.

I CDN ponu abbassà u valore di l'età massima, furzendu l'utilizatori à ricaricà u cuntenutu staticu più spessu. Ùn hè micca chjaru ciò chì questu hè cunnessu: u desideriu di aumentà u trafficu in a reta o di aumentà a cumpatibilità cù i siti chì ùn sanu micca cumu resettate a cache. Per esempiu, u tempu predeterminatu di u cache di l'intestazione di Cloudflare hè 1 ora, chì hè assai bassu per dati statici immutabili.

3. Optimizazione di l'imaghjini

Siccomu u CDN assume e funzioni di caching è serve l'imaghjini, seria logicu per ottimisà à u latu CDN è serve à l'utilizatori in questa forma. Facemu una riservazione subitu chì sta funzione hè dispunibule solu per i tipi CDN 2, 3 è 5.

Pudete ottimisà l'imaghjini in una varietà di manere: utilizendu formati di cumpressione avanzati (cum'è WebP), codificatori più efficaci (MozJPEG), o simpricimenti pulizziari metadati inutili.

In generale, ci sò dui tipi di tali ottimisazioni: cù perdita di qualità è senza perdita di qualità. I CDN generalmente s'impegnanu à utilizà l'ottimisazione senza perdita per evità pussibuli lagnanze di i clienti nantu à i cambiamenti in a qualità di l'imaghjini. In tali cundizioni, u guadagnu serà minimu. In realità, spessu u nivellu di qualità JPEG hè assai più altu ch'è necessariu è pudete ricumpressà in modu sicuru cun un livellu di qualità più bassu senza compromette l'esperienza d'utilizatore. Per d 'altra banda, hè difficiule di determinà u livellu di qualità è paràmetri universalmente per tutte l'applicazioni web pussibuli, cusì i CDN utilizanu paràmetri più cunsirvatori in paragunà à quelli chì ponu esse appiicati tenendu in contu u cuntestu (scopu di l'imaghjini, tipu d'applicazione web). , etc.)

4. Optimizing a cunnessione TLS

A maiò parte di u trafficu oghje viaghja nantu à e cunnessione TLS, chì significa chì passemu tempu extra nantu à e negoziazioni TLS. Ricertamenti, novi tecnulugia sò state sviluppate per accelerà stu prucessu. Per esempiu, questu hè a criptografia EC, TLS 1.3, cache di sessione è biglietti, accelerazione di criptografia hardware (AES-NI), etc. L'impostazione curretta di TLS pò riduce u tempu di cunnessione à 0-1 RTT (senza cuntà DNS è TCP).

Cù u software mudernu, ùn hè micca difficiule di implementà tali pratiche nantu à u vostru propiu.

Micca tutti i CDN implementanu e pratiche megliu TLS, pudete cuntrollà questu misurà u tempu di cunnessione TLS (per esempiu, in Webpagetest). Ideale per una nova cunnessione - 1RTT, 2RTT - livellu mediu, 3RTT è più - male.

Hè ancu esse nutatu chì ancu quandu si usa TLS à u livellu CDN, u servitore cù a nostra applicazione web deve ancu processà TLS, ma da u latu CDN, perchè u trafficu trà u servitore è u CDN passa in a reta publica. In u peghju casu, averemu duppiu ritardu di cunnessione TLS (u primu à l'ospite CDN, u sicondu trà ellu è u nostru servitore).

Per alcune applicazioni, vale a pena attente à i prublemi di sicurità: u trafficu hè generalmente decriptatu nantu à i nodi CDN, è questu hè una opportunità potenziale per l'interceptazione di u trafficu. L'opzione di travaglià senza divulgazione di u trafficu hè generalmente offerta in i piani di tariffu superiore per una tarifa supplementaria.

5. Reduce ritardu di cunnessione

U benefiziu principalu di CDN chì tutti parlanu: bassa latenza (menu distanza) trà l'ospite CDN è l'utilizatore. Ottenutu da a creazione di una architettura di rete distribuita geograficamente, in quale l'ospiti sò situati in punti di cuncentrazione di l'utilizatori (città, punti di scambiu di trafficu, etc.)

In pratica, e priorità per e diverse rete ponu esse in regioni specifiche. Per esempiu, i CDN russi anu più punti di presenza in Russia. I americani prima di tuttu sviluppà a reta in i Stati Uniti. Per esempiu, unu di i più grandi CDN Cloudflare hà solu 2 punti in Russia - Mosca è San Petruburgu. Vale à dì, pudemu salvà un massimu di circa 10 ms di latenza cumparatu cù u piazzamentu direttu in Mosca.

A maiò parte di i CDN occidentali ùn anu micca punti in Russia. Cunnettendu cun elli, pudete solu aumentà i ritardi per u vostru audience russa.

6. Ottimisazione di u cuntenutu (minificazione, cambiamenti strutturali)

U puntu più cumplessu è tecnologicu avanzatu. Cambia u cuntenutu durante a consegna pò esse assai risicatu. Ancu s'è no pigghiamu minification: riducendu u codice fonte (per via di spazii extra, strutture senza impurtanza, etc.) pò affettà u so funziunamentu. Se parlemu di cambiamenti più serii - movendu u codice JS à a fine di l'HTML, unisce i schedari, etc. - u risicu di disturbà a funziunalità di u situ hè ancu più altu.

Dunque, solu alcuni CDN di u tipu 5 facenu questu. Di sicuru, ùn serà micca pussibule di automatizà tutti i cambiamenti necessarii per accelerà e cose - l'analisi manuale è l'ottimisazione sò necessarii. Per esempiu, sguassà u codice inutilizatu o duplicatu hè un compitu manuale.

In regula, tutti tali ottimisazioni sò cuntrullati da i paràmetri è i più periculosi sò disattivati ​​per automaticamente.

Supportu per e capacità di accelerazione per tipu CDN

Allora fighjemu un ochju à ciò chì potenziale opportunità di accelerazione furnisce i diversi tipi di CDN.

Per comodità, ripetemu a classificazione.

  1. CDN gratuitu per a distribuzione di biblioteche JS (MaxCDN, Google. Yandex).
  2. CDN di servizii per l'ottimisazione di u cliente (per esempiu, Google Fonts per i fonts, Cloudinary, Cloudimage per l'imaghjini).
  3. CDN per ottimisazione statica è risorse in CMS (disponibile in Bitrix, WordPress è altri).
  4. CDN generale (StackPath, CDNVideo, NGENIX, Megafon).
  5. CDN per l'accelerazione di u situ web (Cloudflare, Imperva, Airi).

Avà paragunemu e caratteristiche è i tipi di CDN.

uppurtunità
Type 1
Type 2
Type 3
Type 4
Type 5

Cumpressione di testu
+–
-
+–
+–
+

Intestazioni di cache
+
+
+
+
+

Pictures
-
+–
+–
-
+

TLS
-
-
-
+–
+

Ritardi
-
-
-
+
+

cuntenutu
-
-
-
-
+

In questa tabella, "+" hè utilizatu per indicà un sustegnu tutale, "-" ùn hè micca supportu, è "+-" hè un supportu parziale. Di sicuru, ci ponu esse deviazioni da sta tavula in a realità (per esempiu, alcuni CDN di u scopu generale implementanu funziunalità per ottimisà l'imaghjini), ma per una idea generale hè utile.

Risultati

Hopefully, dopu avè lettu stu articulu, avete una stampa più chjara in quantu à a ricunniscenza di "utilizate un CDN" per accelerà i vostri siti.

Cum'è in ogni attività, ùn pudete micca crede e prumesse di marketing di qualsiasi serviziu. L'effettu deve esse misuratu è pruvatu in cundizioni reali. Sè avete digià utilizatu un CDN, verificate l'efficacità utilizendu i criterii descritti in l'articulu.

Hè pussibule chì l'usu di un CDN avà rallenta u tempu di carica di u vostru situ.

Cum'è una raccomandazione generale, pudemu fucalizza nantu à i seguenti: studià u vostru audience, determina u so scopu geograficu. Se u vostru audience principale hè cuncentrata in un raghju di 1-2 mila chilometri, ùn avete micca bisognu di un CDN per u so scopu principale - riducendu a latenza. Invece, pudete mette u vostru servitore più vicinu à i vostri utilizatori è cunfigurà bè, ottenendu a maiò parte di l'ottimisazioni descritte in l'articulu (liberu è permanente).

In casu chì u vostru audience hè veramente distribuitu geograficamente (radiu di più di 3000 chilometri), utilizendu un CDN di qualità serà veramente utile. Tuttavia, avete bisognu di capisce in anticipu ciò chì esattamente u vostru CDN pò accelerà (vede a tavola di capacità è a so descrizzione). Tuttavia, l'accelerazione di u situ web resta sempre un compitu cumplessu chì ùn pò micca esse risoltu cunnessu un CDN. In più di l'ottimisazioni sopra, i mezi più efficaci di l'accelerazione restanu daretu à u CDN: ottimisazione di a parte di u servitore, cambiamenti avanzati à a parte di u cliente (eliminazione di codice inutilizatu, ottimisazione di u prucessu di rendering, travagliu cù cuntenutu, fonti, adattabilità, etc. )

Source: www.habr.com

Add a comment