[Non] utilizzare il CDN

Praticamente in ogni articolo o strumento per l'ottimizzazione della velocità dei siti web c'è una nota discreta "usa un CDN". In generale, un CDN è una content delivery network, ovvero una rete di distribuzione dei contenuti. In azienda "Metodo Lab" ci troviamo spesso ad affrontare domande dei clienti su questo argomento, e alcuni attivano autonomamente il CDN. L'obiettivo di questo articolo è capire cosa può offrire un 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 necessità. Con lo sviluppo delle connessioni Internet da parte degli utenti, sono emersi servizi di video online. È evidente che i contenuti video richiedono una larghezza di banda significativamente maggiore rispetto ai contenuti standard dei siti (immagini, testi e codice CSS o JS).

Quando si tenta di trasmettere in parallelo un flusso video a molti clienti da un singolo server, il collo di bottiglia sarà molto probabilmente la banda internet del server. Di solito, bastano alcune migliaia di flussi per saturare una tipica connessione di rete del server. Naturalmente, possono esserci altre limitazioni delle risorse, ma al momento non sono rilevanti. È inoltre importante notare che espandere la banda del server è molto costoso (e a volte impossibile), oltre a non essere pratico. Il carico sulla rete durante la trasmissione avrà una natura ciclica.

Il problema della limitazione della banda di un singolo server è perfettamente risolto da un CDN. I clienti non si connettono direttamente al server, ma ai nodi della rete CDN. In una situazione ideale, il server invia un flusso al nodo CDN, e la rete utilizza le proprie risorse per distribuire quel flusso a molti utenti. Dal punto di vista economico, paghiamo solo per le risorse effettivamente utilizzate (che possono essere la larghezza di banda o il traffico) e otteniamo una scalabilità eccellente per il nostro servizio. L'uso di un CDN per la distribuzione di contenuti pesanti è totalmente giustificato e logico. Vale la pena notare, tuttavia, che i principali attori del settore (come Netflix) costruiscono i propri CDN anziché utilizzare grandi CDN commerciali (Akamai, Cloudflare, Fastly, ecc.).

Con l'evoluzione del web, le web app sono diventate più complesse e pesanti. La questione della velocità di caricamento è emersa come una priorità. Gli appassionati della velocità dei siti web hanno rapidamente identificato alcune delle principali problematiche che causavano caricamenti lenti. Tra queste vi erano i ritardi di rete (RTT – round trip time o tempo di ping). I ritardi influiscono su molti processi nel caricamento del sito: l'instaurazione della connessione TCP, l'avvio della sessione TLS, il caricamento di ciascuna risorsa separata (immagini, file JS, documenti HTML, ecc.).

Il problema era aggravato dal fatto che utilizzando il protocollo HTTP/1.1 (prima dell'arrivo di SPDY, QUIC e HTTP/2, questo era l'unico standard) i browser aprono non più di 6 connessioni TCP verso un singolo host. Tutto ciò portava a periodi di inattività della connessione e a un utilizzo inefficiente della larghezza di banda del canale. Una parte del problema veniva affrontata con il domain sharding, ovvero creando host aggiuntivi per superare il limite sul numero di connessioni.

Qui appare la seconda capacità del CDN: la riduzione dei ritardi (RTT) grazie al numero elevato di punti e alla vicinanza dei nodi all'utente. La distanza gioca un ruolo cruciale: la velocità della luce è limitata (circa 200.000 km/s nella fibra ottica). Ciò significa che ogni 1000 km di percorso aggiunge 5 ms di ritardo o 10 ms in RTT. Questi sono i costi minimi di tempo per il trasferimento, poiché ci sono anche ritardi nell'attrezzatura intermedia. Poiché il CDN di solito è in grado di memorizzare nella cache gli oggetti sui propri server, possiamo beneficiare del caricamento di tali oggetti tramite il CDN. Le condizioni necessarie per questo sono: la disponibilità dell'oggetto nella cache e la vicinanza del punto CDN all'utente rispetto al server dell'applicazione web (origin server). È importante comprendere che la vicinanza geografica di un nodo CDN non garantisce ritardi bassi. La routizzazione tra il cliente e il CDN può essere costruita in modo tale che il cliente si connetta a un host in un altro paese, o addirittura in un altro continente. Qui entrano in gioco le relazioni tra i fornitori di servizi di rete e il servizio CDN (peering, presenza di punti di scambio, partecipazione a IX, ecc.) e la politica di instradamento del traffico del CDN stesso. Ad esempio, Cloudflare, utilizzando i primi due piani (quello gratuito e quello economico), non garantisce la consegna dei contenuti dal nodo più vicino – la scelta dell'host sarà effettuata per raggiungere il costo minimo.

Molte delle principali aziende internet attirano l'attenzione del pubblico (sviluppatori web e proprietari di servizi) sul tema della velocità di caricamento e delle performance 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 si concentrano sull'ottimizzazione lato client). Successivamente, emergono nuovi strumenti di test della velocità dei siti, che offrono anche suggerimenti per migliorare le prestazioni. In ciascuno di questi servizi o plugin è presente la costante raccomandazione "Utilizza un CDN". Come spiegazione dell'effetto CDN si fa generalmente riferimento alla riduzione delle latenze di rete. Sfortunatamente, non tutti sono disposti a comprendere come venga realmente raggiunto l'effetto di accelerazione del CDN e come possa essere misurato, quindi la raccomandazione viene accettata per fede e usata come postulato. In realtà, non tutti i CDN sono ugualmente utili.

Utilizzo del CDN oggi

Per valutare l'utilità dell'implementazione dei CDN, è necessario classificarli. Cosa si può osservare attualmente nella pratica (gli esempi tra parentesi non sono ovviamente esaustivi):

1. CDN gratuiti per la distribuzione di librerie JS (MaxCDN, Google, Yandex).
2. Servizi CDN per l'ottimizzazione delle risorse client (ad esempio Google Fonts per i caratteri, Cloudinary, Cloudimage per le immagini).
3. CDN per file statici e ottimizzazione delle risorse nelle CMS (disponibile in Bitrix, WordPress e altri).
4. CDN di uso generale (StackPath, CDNVideo, NGENIX, MegaFon).
5. CDN per l'accelerazione dei siti web (Cloudflare, Imperva, Airy).

La principale differenza tra questi tipi è la seguente: quale parte del traffico passa attraverso il CDN. I tipi 1-3 si occupano della consegna solo di una parte del contenuto: da una a diverse decine di richieste (di solito immagini). I tipi 4 e 5 comportano il completo proxying del traffico attraverso il CDN.

Praticamente, questo riguarda il numero di connessioni utilizzate per il caricamento del sito. Utilizzando 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, è necessario distribuire le richieste su più domini e creare più connessioni TCP. Nella peggiore delle ipotesi, questo equivale a: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Questa formula non tiene conto dei ritardi nelle reti mobili per attivare il canale radio del dispositivo (se non è stato attivato) e dei ritardi sulla torre cellulare.

Ecco come appare nel waterfall di caricamento del sito (le latenze per la connessione al CDN sono evidenziate con RTT di 150 ms):

Se il CDN copre tutto il traffico del sito (eccetto i servizi di terze parti), possiamo utilizzare una sola connessione TCP, risparmiando le latenze per la connessione ad host aggiuntivi. Certamente, questo riguarda le connessioni HTTP/2.

Le ulteriori differenze sono determinate dalle funzionalità specifiche del CDN; per il primo tipo si tratta semplicemente di hosting un file statico, mentre per il quinto è la modifica di diversi tipi di contenuto del sito per ottimizzazione.

Le funzionalità del CDN per accelerare il sito

Descriviamo l'intera gamma di funzionalità che un CDN offre per velocizzare i siti, senza considerare le funzionalità dei singoli tipi di CDN, e poi vediamo quali di queste sono implementate in ciascuno di essi.

1. Compressione delle risorse testuali

Questa è la funzionalità più fondamentale e comprensibile, eppure spesso implementata male. Tutti i CDN dichiarano la compressione come una delle loro caratteristiche per l'accelerazione. Ma se si guarda più da vicino, emergono delle lacune:

• possono utilizzare gradi bassi per la compressione dinamica – 5-6 (ad esempio, per gzip il massimo è 9);
• nello static compression (file nella cache) non vengono utilizzate funzionalità aggiuntive (ad esempio, zopfi o brotli con livello 11)
• non c'è supporto per una compressione efficace di brotli (risparmio di circa il 20% rispetto a gzip).

Se utilizzi un CDN, vale la pena controllare questi punti: prendere un file che è arrivato dal CDN, registrarne la dimensione in formato compresso e ricomprimerlo manualmente per un confronto (puoi utilizzare qualche servizio online che supporta brotli, ad esempio vsi.comprimere.ru).

2. Impostazione delle intestazioni per la memorizzazione nella cache del client

Un'altra semplice funzionalità per accelerare: impostare le intestazioni per la memorizzazione nella cache dei contenuti da parte del client (browser). L'intestazione più rilevante è cache-control, quella obsoleta è expires. Può essere utilizzato anche Etag. L'importante è che il max-age in cache-control sia abbastanza lungo (da un mese in su); se sei pronto a memorizzare il risorsa in modo molto rigoroso, puoi aggiungere l'opzione immutable.

I CDN possono ridurre il valore di max-age, costringendo l'utente a dover ricaricare più frequentemente la statica. Non è chiaro se questo sia dovuto al desiderio di aumentare il traffico in rete o a una maggiore compatibilità con i siti che non possono eliminare la cache. Ad esempio, il valore di tempo di caching negli header di Cloudflare è di default di 1 ora, che è troppo poco per risorse statiche immutabili.

3. Ottimizzazione delle immagini

Poiché i CDN si occupano della cache e della consegna delle immagini, è logico ottimizzarle lato CDN e fornirle in questo formato agli utenti. Precisiamo subito che questa possibilità è disponibile solo per i CDN di tipo 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 rimuovendo i 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 perdite per evitare possibili reclami dei clienti riguardo ai cambiamenti nella qualità delle immagini. In tali condizioni, il guadagno sarà minimo. In realtà, spesso il livello di qualità JPEG supera notevolmente il necessario e si può tranquillamente effettuare una ricompressione con un indice di qualità inferiore, senza compromettere la percezione da parte degli utenti. D'altra parte, determinare un livello di qualità e impostazioni universali per tutte le possibili applicazioni web è difficile, quindi i CDN utilizzano impostazioni più conservative rispetto a quelle che potrebbero essere applicate 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 spendiamo 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, la cache delle sessioni e i ticket di sessione (session tickets), l'accelerazione hardware della crittografia (AES-NI), e così via. Una configurazione corretta di TLS può ridurre il tempo di connessione a 0-1 RTT (escludendo DNS e TCP).

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

Non tutti i CDN adottano le migliori pratiche in merito al TLS; ciò può essere verificato misurando il tempo di connessione TLS (ad esempio, in Webpagetest). Idealmente, per una nuova connessione, si punta a 1 RTT, 2 RTT è il livello medio, 3 RTT o più è considerato scarso.

Va anche notato che, anche utilizzando TLS a livello CDN, il server con la nostra applicazione web deve comunque gestire TLS, ma dalla parte del CDN, poiché il traffico tra il server e il CDN attraversa una rete pubblica. Nel peggiore dei casi, avremo ritardi doppi nella connessione TLS (il primo verso l'host CDN, il secondo tra questo e il nostro server).

Per alcune applicazioni, è importante tenere in considerazione le questioni di sicurezza: solitamente, il traffico viene decrittato nei nodi CDN, il che rappresenta una potenziale opportunità per l'intercettazione del traffico. L'opzione di operare senza rivelare il traffico è normalmente offerta nei piani tariffari più avanzati a pagamento separato.

5. Riduzione della latenza di connessione

Il principale vantaggio del CDN, di cui si parla tanto, è la bassa latenza (minore distanza) tra l'host CDN e l'utente. Questo viene raggiunto creando un'architettura di rete geograficamente distribuita, in cui gli host si trovano nei punti di concentrazione degli utenti (città, punti di scambio e così via).

Nella pratica, le priorità per diverse reti possono trovarsi 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. Ciò significa che possiamo risparmiare al massimo circa 10 ms di latenza rispetto a un posizionamento diretto a Mosca.

La maggior parte dei CDN occidentali non ha punti di accesso in Russia. Connetterti a loro può solo aumentare i tempi di latenza per il tuo pubblico russo.

6. Ottimizzazione dei contenuti (minificazione, modifiche strutturali)

Questo è il punto più complesso e tecnologico. Modificare i contenuti durante la consegna può essere molto rischioso. Anche la minificazione, che riduce il codice sorgente (eliminando spazi vuoti, costrutti poco significativi, ecc.), può influenzare la sua funzionalità. Se parliamo di modifiche più significative, come spostare il codice JS alla fine dell'HTML, unire file e simili, il rischio di compromettere la funzionalità del sito è ancora più elevato.

Per questo motivo, solo alcuni CDN di tipo 5 si occupano di questo. Certamente, non sarà possibile automatizzare tutte le necessarie modifiche per accelerare; è necessaria un'analisi manuale e un'ottimizzazione. Ad esempio, rimuovere codice non utilizzato o duplicato è un compito manuale.

In genere, tutte queste ottimizzazioni sono gestite dalle impostazioni e le più pericolose sono disabilitate per impostazione predefinita.

Supporto delle funzionalità di accelerazione per tipi di CDN

Quindi, vediamo quali opportunità potenziali di accelerazione offrono i diversi tipi di CDN.

Per comodità, ripetiamo la classificazione.

1. CDN gratuiti per la distribuzione di librerie JS (MaxCDN, Google, Yandex).
2. Servizi CDN per l'ottimizzazione delle risorse client (ad esempio Google Fonts per i caratteri, Cloudinary, Cloudimage per le immagini).
3. CDN per file statici e ottimizzazione delle risorse nelle CMS (disponibile in Bitrix, WordPress e altri).
4. CDN di uso generale (StackPath, CDNVideo, NGENIX, MegaFon).
5. CDN per l'accelerazione dei siti web (Cloudflare, Imperva, Airy).

Ora mettiamo in relazione le funzionalità e i tipi di CDN.

Possibilità
Tipo 1
Tipo 2
Tipo 3
Tipo 4
Tipo 5

Compressione del testo
+–
–
+–
+–
+

Intestazioni di cache
+
+
+
+
+

Immagini
–
+–
+–
–
+

TLS
–
–
–
+–
+

Ritardi
–
–
–
+
+

Contenuto
–
–
–
–
+

In questa tabella, il segno «+» indica un supporto completo, «–» indica l'assenza, e «+–» indica un supporto parziale. Naturalmente, potrebbero esserci delle eccezioni rispetto a questa tabella nella realtà (ad esempio, un CDN generico potrebbe implementare funzionalità di ottimizzazione delle immagini), ma è utile per avere una visione generale.

Risultati

Spero che, leggendo questo articolo, avrai un quadro più chiaro riguardo al consiglio «usa CDN» per velocizzare i siti web.

Come in qualsiasi cosa, non si possono credere alle promesse di marketing di un servizio. L'effetto deve essere misurato e verificato in condizioni reali. Se stai già utilizzando un CDN, verifica la sua efficacia secondo i criteri descritti nell'articolo.

Potrebbe essere che l'utilizzo del CDN stia attualmente rallentando il caricamento del tuo sito web.

Come regola generale, si può puntare su quanto segue: studiare il proprio pubblico e definire i suoi confini geografici. Se il vostro pubblico principale è concentrato entro un raggio di 1-2 mila chilometri, non è necessario un CDN per il suo scopo principale — ridurre la latenza. Invece, potete collocare il vostro server più vicino agli utenti e configurarlo adeguatamente, ottenendo la maggior parte delle ottimizzazioni descritte nell'articolo (gratuitamente e in modo permanente).

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

Fonte: habr.com