🥇[Non] utilizzare la CDN

Quasi in ogni articolo o strumento per l'ottimizzazione della velocità dei siti web c'è un discreto punto 'utilizza CDN'. In generale, CDN significa content delivery network o rete di distribuzione dei contenuti. Noi di 'Metodo Lab' ci imbattiamo spesso in domande dei clienti su questo argomento, alcuni attivano autonomamente il CDN. L'obiettivo di questo articolo è comprendere cosa può offrire il CDN in termini di velocità di caricamento del sito, quali problemi possono sorgere e in quali casi l'uso del CDN è giustificato.

I ritardi evidenziati nell'immagine sono causati dall'uso del CDN.

Un po' di storia

Come molte tecnologie, i CDN sono nati per bisogno. Con lo sviluppo dei canali Internet per gli utenti della rete, sono emersi i servizi di video online. È naturale che i contenuti video richiedano una capacità di banda significativamente maggiore rispetto ai normali contenuti delle pagine web (immagini, testo, e codice CSS o JS).

Nel tentativo di trasmettere in parallelo un flusso video a molti clienti da un unico server, il collo di bottiglia sarà probabilmente il canale Internet del server. In genere, bastano qualche migliaio di flussi per saturare un tipico canale server. Certamente, possono esserci altre limitazioni di risorse, ma in questo momento non sono rilevanti. È anche importante notare che ampliare il canale del server è troppo costoso (e talvolta impossibile), oltre che poco conveniente. Il carico sul canale durante le trasmissioni avrà un carattere ciclico.

Il problema della limitazione del canale di un singolo server è ottimamente risolto dal CDN. I clienti non si connettono direttamente al server, ma ai nodi della rete CDN. Nella situazione ideale, il server fornisce un flusso al nodo CDN e, da quel punto in poi, la rete utilizza le proprie risorse per fornire quel flusso a numerosi utenti. Dal punto di vista economico, paghiamo solo per le risorse effettivamente consumate (che possono essere larghezza di banda o traffico) e otteniamo un'eccellente scalabilità del nostro servizio. L'uso di CDN per la distribuzione di contenuti pesanti è completamente giustificato e logico. Va notato che i principali attori di questo settore (ad esempio, Netflix) costruiscono le proprie CDN piuttosto che utilizzare grandi CDN commerciali (Akamai, Cloudflare, Fastly, ecc.).

Con lo sviluppo del web, le applicazioni web stesse sono diventate più complesse e pesanti. Il problema principale è diventata la velocità di caricamento. Gli appassionati della velocità dei siti hanno rapidamente identificato alcuni problemi chiave che portano a un caricamento lento dei siti. Uno di questi era il ritardo nella rete (RTT — round trip time o tempo di ping). I ritardi influiscono su molti processi nel caricamento del sito: l'instaurazione di una connessione TCP, l'avvio di una sessione TLS, il caricamento di ogni singola risorsa (immagini, file JS, documenti HTML, ecc.)

Il problema era aggravato dal fatto che, utilizzando il protocollo HTTP/1.1 (fino all'arrivo di SPDY, QUIC e HTTP/2, questa era l'unica opzione), i browser aprono non più di 6 connessioni TCP a un host. Tutto ciò portava a un inattività della connessione e a un utilizzo inefficiente della larghezza di banda. Il problema veniva parzialmente risolto tramite lo sharding dei domini – creando host aggiuntivi per superare il limite sul numero di connessioni.

Qui emerge la seconda capacità del CDN: ridurre i ritardi (RTT) grazie al gran numero di punti e alla vicinanza dei nodi all'utente. La distanza gioca qui un ruolo cruciale: la velocità della luce è limitata (circa 200.000 km/sec nella fibra ottica). Ciò significa che ogni 1000 km percorsi aggiunge 5 ms di ritardo o 10 ms di RTT. Questi sono i costi minimi di tempo per la trasmissione, poiché ci sono anche ritardi nell'hardware intermedio. Poiché il CDN di solito può memorizzare nella cache oggetti sui propri server, possiamo trarre vantaggio dal caricamento di tali oggetti tramite il CDN. Le condizioni necessarie per questo sono: la presenza dell'oggetto nella cache e la vicinanza del punto CDN all'utente rispetto al server dell'applicazione web (origin server). È importante capire: la prossimità geografica del nodo CDN non garantisce ritardi bassi. La routing tra il cliente e il CDN può essere realizzato in modo tale che il cliente si connetta a un host in un altro paese, e forse anche su un altro continente. Qui entrano in gioco le relazioni tra gli operatori di telecomunicazioni e il servizio CDN (peering, presenza di punti di interscambio, partecipazione a IX, ecc.) e la politica di routing del traffico dello stesso CDN. Ad esempio, Cloudflare, utilizzando i due piani iniziali (quello gratuito e quello a basso costo), non garantisce la consegna dei contenuti dal nodo più vicino: la scelta dell'host sarà effettuata per raggiungere il minor costo.

Molte aziende leader nel settore di Internet attirano l'attenzione del pubblico (sviluppatori web e proprietari dei servizi) sul tema della velocità di caricamento e del funzionamento dei siti. Tra queste aziende ci sono Yahoo (strumento Yslow), AOL (WebPageTest) e Google (servizio Page Speed Insights), che sviluppano le loro raccomandazioni per accelerare i siti (in particolare riguardano l'ottimizzazione lato client). Successivamente, emergono nuovi strumenti di test della velocità dei siti, che offrono anche consigli per aumentare la velocità dei siti. In ciascuno di questi servizi o plugin è presente una raccomandazione invariabile: «Usa il CDN». Di solito, il motivo dell'effetto CDN viene spiegato con la riduzione delle latenze di rete. Sfortunatamente, non tutti sono disposti a capire come si raggiunge veramente l'effetto di accelerazione dal CDN e come può essere misurato, quindi la raccomandazione viene accettata per fede e utilizzata come postulato. In effetti, non tutti i CDN sono ugualmente utili.

Utilizzo del CDN oggi

Per valutare l'utilità dell'applicazione del CDN, è necessario classificarli. Cosa possiamo incontrare oggi nella pratica (gli esempi tra parentesi non sono ovviamente esaustivi):

CDN gratuiti per la distribuzione di librerie JS (MaxCDN, Google, Yandex).
CDN per l'ottimizzazione client (ad esempio Google Fonts per i caratteri, Cloudinary, Cloudimage per le immagini).
CDN per la statica e l'ottimizzazione delle risorse nei CMS (disponibili in Bitrix, WordPress e altri).
CDN di scopo generale (StackPath, CDNVideo, NGENIX, Megafon).
CDN per l'accelerazione dei siti (Cloudflare, Imperva, Airy).

La principale differenza tra questi tipi risiede nel seguente aspetto: quale parte del traffico passa attraverso il CDN. I tipi 1-3 si occupano solo della consegna di una parte del contenuto: da una richiesta a diverse decine (solitamente immagini). I tipi 4 e 5 comportano un'instradizzazione completa del traffico attraverso il CDN.

Nella pratica, questo significa il numero di connessioni utilizzate per caricare il sito. Con l'uso di HTTP/2, utilizziamo una sola connessione TCP all'host per gestire qualsiasi numero di richieste. Se separiamo le risorse tra l'host principale (origin) e il CDN, dobbiamo distribuire le richieste su più domini e creare diverse connessioni TCP. Nel peggiore dei casi si ha: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. In questa formula non sono considerati i ritardi nelle reti mobili per l'attivazione del canale radio del dispositivo (se non era già attivo) e i ritardi alla stazione radio.

Ecco come appare nella cascata di caricamento del sito (sono evidenziati i ritardi per la connessione al CDN con RTT di 150 ms):

Se il CDN copre tutto il traffico del sito (esclusi i servizi esterni), possiamo utilizzare una sola connessione TCP, risparmiando sui ritardi nella connessione a host aggiuntivi. Ovviamente, questo vale per le connessioni HTTP/2.

Ulteriori differenze sono determinate dalle funzionalità specifiche di ciascun CDN – per il primo tipo si tratta semplicemente di hosting di un file statico, per il quinto si parla di modifica di diversi tipi di contenuto del sito a scopo di ottimizzazione.

Capacità del CDN di accelerare il sito

Descriviamo l'intero ventaglio delle capacità del CDN di accelerare i siti, senza considerare le funzionalità dei singoli tipi di CDN, e poi vediamo cosa è stato implementato in ciascuno di essi.

1. Compressione delle risorse testuali

La funzionalità più basilare e comprensibile, tuttavia spesso implementata male. Tutti i CDN dichiarano la presenza della compressione come una delle loro caratteristiche di accelerazione. Ma se si guarda più da vicino, emergono le carenze:

possono essere utilizzati bassi gradi per la compressione dinamica – 5-6 (ad esempio, per gzip il massimo è 9);
nella compressione statica (file in cache) non sono sfruttate ulteriori potenzialità (ad esempio, zopfi o brotli con grado 11)
non c'è supporto per una compressione efficace tramite brotli (risparmio di circa il 20% rispetto a gzip).

Se utilizzi un CDN, è opportuno controllare alcuni di questi punti: prendi un file che è arrivato tramite il CDN, annota la sua dimensione in formato compresso e ricomprimi manualmente per il confronto (puoi utilizzare qualche servizio online che supporta brotli, ad esempio всёсжать.рф).

2. Impostazione delle intestazioni di caching client

Anche questa è una semplice funzionalità di accelerazione: impostare le intestazioni per la memorizzazione cache dei contenuti sul client (browser). L'intestazione più pertinente è cache-control, mentre expires è obsoleta. Può essere utilizzato Etag come opzione aggiuntiva. È fondamentale che max-age di cache-control sia abbastanza grande (da un mese e oltre), se desideri memorizzare il recurso in modo molto rigoroso, puoi aggiungere l'opzione immutable.

Le CDN possono ridurre il valore di max-age, costringendo l'utente a caricare la staticità più frequentemente. Non è chiaro se ciò sia legato al desiderio di aumentare il traffico in rete o a una maggiore compatibilità con siti web che non riescono a gestire la cache. Ad esempio, il valore predefinito del tempo di caching negli header di Cloudflare è di 1 ora, che è molto poco per la staticità immutabile.

3. Ottimizzazione delle immagini

Poiché i CDN assumono funzioni di caching e distribuzione delle immagini, è logico ottimizzarle sul lato CDN e consegnarle agli utenti in questo modo. Precisiamo subito che questa possibilità è disponibile solo per i CDN di tipi 2, 3 e 5.

Le immagini possono essere ottimizzate in vari modi: utilizzando formati di compressione avanzati (ad esempio, WebP), encoder più efficienti (MozJPEG) o semplicemente pulendo metadati superflui.

In generale, ci sono due tipi di ottimizzazioni: con perdita di qualità e senza perdita di qualità. I CDN tendono a utilizzare l'ottimizzazione senza perdita per evitare possibili lamentele da parte dei clienti riguardo al cambiamento della qualità delle immagini. In queste condizioni, il guadagno sarà minimo. Nella realtà, spesso il livello di qualità JPEG supera notevolmente il necessario e si può tranquillamente effettuare la ricompressione con un valore di qualità inferiore, senza compromettere la percezione degli utenti. D'altra parte, determinare il livello di qualità e le impostazioni universali per tutte le possibili applicazioni web è difficile, quindi i CDN utilizzano impostazioni più conservative rispetto a quelle che si potrebbero applicare tenendo conto del contesto (scopo delle immagini, tipo di applicazione web, ecc.)

4. Ottimizzazione della connessione TLS

La maggior parte del traffico oggi viene trasmesso tramite connessioni TLS, il che significa che perdiamo tempo aggiuntivo per la negoziazione TLS. Recentemente sono state sviluppate nuove tecnologie per accelerare questo processo. Ad esempio, ci sono la crittografia EC, TLS 1.3, il caching delle sessioni e i ticket (session tickets), l'accelerazione hardware della crittografia (AES-NI), ecc. Una configurazione corretta di TLS consente di ridurre il tempo di connessione a 0-1 RTT (escludendo DNS e TCP).

Con software moderno, implementare tali pratiche non è difficile nelle proprie infrastrutture.

Lontano da tutti i CDN implementano le migliori pratiche per TLS, è possibile verificarlo misurando il tempo della connessione TLS (ad esempio in Webpagetest). Ideale per una nuova connessione è 1RTT, 2RTT è un livello medio, 3RTT e oltre – è male.

Bisogna anche notare che, anche utilizzando TLS a livello CDN, il server con la nostra web app deve comunque gestire TLS, ma dal lato CDN, poiché il traffico tra il server e il CDN passa su una rete pubblica. Nel peggiore dei casi, otterremo ritardi doppi nella connessione TLS (primo al host CDN, secondo tra esso e il nostro server).

Per alcune applicazioni, è importante prestare attenzione alle questioni di sicurezza: normalmente il traffico viene decrittato sui nodi del CDN, il che rappresenta una potenziale opportunità per l'intercettazione del traffico. Una soluzione che non comporta la rivelazione del traffico è di solito proposta nei piani tariffari di fascia alta a pagamento separato.

5. Riduzione delle latenza di connessione

Il principale vantaggio del CDN, di cui tutti parlano: bassa latenza (distanza ridotta) tra l'host CDN e l'utente. Questo si ottiene creando un'architettura di rete geograficamente distribuita, in cui gli host si trovano nei punti di concentrazione degli utenti (città, punti di scambio di traffico, ecc.)

In pratica, le priorità per diverse reti possono essere in regioni specifiche. Ad esempio, i CDN russi avranno più punti di presenza in Russia. Gli americani svilupperanno principalmente la rete negli Stati Uniti. Ad esempio, uno dei più grandi CDN, Cloudflare, ha solo 2 punti in Russia: Mosca e San Pietroburgo. Dunque, possiamo risparmiare al massimo circa 10 ms di latenza rispetto a una collocazione diretta a Mosca.

La maggior parte dei CDN occidentali non ha affatto punti in Russia. Connettendoti a loro, puoi solo aumentare la latenza per il tuo pubblico russo.

6. Ottimizzazione dei contenuti (minificazione, cambiamenti strutturali)

Il punto più complesso e tecnico. Modificare i contenuti durante la consegna può essere molto rischioso. Anche limitandoci alla minificazione: ridurre il codice sorgente (eliminando spazi inutili, costrutti irrilevanti, ecc.) può influire sul suo funzionamento. Parlando di modifiche più serie – spostamento del codice JS alla fine dell'HTML, unione di file e simili – il rischio di compromettere la funzionalità del sito è ancora più elevato.

Pertanto, solo alcune CDN di tipo 5 si occupano di questo. Certo, non è possibile automatizzare tutte le modifiche necessarie per velocizzare – è necessaria un'analisi manuale e un'ottimizzazione. Ad esempio, la rimozione di codice non utilizzato o duplicato rientra proprio nelle attività manuali.

In generale, tutte queste ottimizzazioni sono gestite dalle impostazioni e le più pericolose sono disabilitate di default.

Supporto delle capacità di accelerazione per tipi di CDN

Dunque, diamo un'occhiata a quali potenziali capacità di accelerazione offrono i vari tipi di CDN.

Per comodità, ripetiamo la classificazione.

CDN gratuiti per la distribuzione di librerie JS (MaxCDN, Google, Yandex).
CDN per l'ottimizzazione client (ad esempio Google Fonts per i caratteri, Cloudinary, Cloudimage per le immagini).
CDN per la statica e l'ottimizzazione delle risorse nei CMS (disponibili in Bitrix, WordPress e altri).
CDN di scopo generale (StackPath, CDNVideo, NGENIX, Megafon).
CDN per l'accelerazione dei siti (Cloudflare, Imperva, Airy).

Ora confronteremo le funzionalità e i tipi di CDN.

Capacità
Tipo 1
Tipo 2
Tipo 3
Tipo 4
Tipo 5

Compressione del testo
+–
–
+–
+–
+

Intestazioni della cache
+
+
+
+
+

Immagini
–
+–
+–
–
+

TLS
–
–
–
+–
+

Ritardi
–
–
–
+
+

Contenuto
–
–
–
–
+

In questa tabella, il simbolo «+» indica il supporto completo, «–» l'assenza, e «+–» il supporto parziale. Certo, potrebbero esserci delle deviazioni rispetto a questa tabella nella realtà (ad esempio, qualche CDN di uso generale potrebbe implementare funzionalità per l'ottimizzazione delle immagini), ma è utile per avere un'idea generale.

Conclusioni

Spero che leggendo questo articolo avrete una visione più chiara riguardo alla raccomandazione «usate CDN» per accelerare i siti.

Come in qualsiasi settore, non si possono credere alle promesse di marketing di un qualsiasi servizio. Gli effetti devono essere misurati e verificati in condizioni reali. Se state già utilizzando qualche CDN, verificate la sua efficacia secondo i criteri descritti nell'articolo.

È possibile che utilizzare un CDN in questo momento stia rallentando il caricamento del vostro sito.

Come suggerimento generale, si può arrivare alla seguente conclusione: studiate il vostro pubblico, determinatene i confini geografici. Se il vostro pubblico principale è concentrato entro un raggio di 1-2 mila chilometri, non avrete bisogno di un CDN per il suo scopo principale – ridurre i ritardi. Invece, potete posizionare il vostro server più vicino agli utenti e configurarlo adeguatamente, ottenendo la maggior parte delle ottimizzazioni descritte nell'articolo (gratuitamente e permanentemente).

Nel caso in cui il vostro pubblico sia davvero distribuito geograficamente (raggio superiore ai 3000 chilometri), l'uso di una CDN di qualità sarà davvero utile. Tuttavia, è importante comprendere in anticipo cosa possa effettivamente accelerare la vostra CDN (vedi tabella delle possibilità e delle loro descrizioni). L'accelerazione del sito rimane comunque un compito complesso, che non può essere risolto semplicemente collegandosi a una CDN. Oltre alle ottimizzazioni indicate, fuori dalla CDN rimangono i mezzi più efficaci per l'accelerazione: ottimizzazione della parte server, modifiche avanzate della parte client (rimozione di codice non utilizzato, ottimizzazione del rendering, gestione dei contenuti, caratteri, adattabilità, ecc.)

Fonte: habr.com