[Non] utilizzare un CDN

Quasi ogni articolo o strumento per ottimizzare la velocità del sito contiene una clausola modesta “usa una CDN”. In generale, CDN è una rete di distribuzione dei contenuti o una rete di distribuzione dei contenuti. Noi di Method Lab incontriamo spesso domande dei clienti su questo argomento; alcuni di loro abilitano la propria CDN. Lo scopo di questo articolo è capire cosa può fornire una CDN in termini di velocità di caricamento del sito, quali problemi possono sorgere e in quali casi è giustificato l’utilizzo di una CDN.

I ritardi cerchiati nell'immagine sono causati dall'utilizzo di una CDN.

Un po 'di storia

Come molte tecnologie, le CDN sono emerse per necessità. Con lo sviluppo dei canali Internet tra gli utenti Internet, sono comparsi i servizi video online. Naturalmente, i contenuti video richiedono una larghezza di banda molto maggiore rispetto ai normali contenuti del sito Web (immagini, testo e codice CSS o JS).

Quando si tenta di trasmettere un flusso video in parallelo a molti client da un server, molto probabilmente il canale Internet del server diventerà il collo di bottiglia. Di norma, sono sufficienti poche migliaia di thread per intasare un tipico canale del server. Naturalmente potrebbero esserci altre limitazioni in termini di risorse, ma al momento non sono importanti. È anche importante che espandere il canale del server sia troppo costoso (e talvolta impossibile) e anche poco pratico. Il carico sul canale durante le trasmissioni sarà ciclico.

Il problema della limitazione del canale di un singolo server è perfettamente risolto dalla CDN. I client non si collegano direttamente al server, ma ai nodi della rete CDN. In una situazione ideale, il server invia un flusso al nodo CDN e quindi la rete utilizza le proprie risorse per fornire questo flusso a molti utenti. Dal punto di vista economico paghiamo solo le risorse effettivamente consumate (potrebbe trattarsi di banda o traffico) e otteniamo un'ottima scalabilità del nostro servizio. Usare una CDN per fornire contenuti pesanti è completamente giustificato e logico. Anche se vale la pena notare che i più grandi attori in questo spazio (ad esempio Netflix) stanno costruendo i propri CDN invece di utilizzare grandi CDN commerciali (Akamai, Cloudflare, Fastly, ecc.)

Con l'evoluzione del web, le applicazioni web stesse sono diventate sempre più complesse e complesse. È emerso il problema della velocità di caricamento. Gli appassionati della velocità dei siti web hanno rapidamente identificato diversi problemi importanti che causavano il caricamento lento dei siti web. Uno di questi erano i ritardi di rete (RTT - tempo di andata e ritorno o tempo di ping). I ritardi influenzano molti processi nel caricamento del sito web: stabilire una connessione TCP, avviare una sessione TLS, caricare ogni singola risorsa (immagine, file JS, documento HTML, ecc.)

Il problema era aggravato dal fatto che quando si utilizzava il protocollo HTTP/1.1 (prima dell'avvento di SPDY, QUIC e HTTP/2 questa era l'unica opzione), i browser non aprivano più di 6 connessioni TCP verso un host. Tutto ciò ha comportato tempi di inattività della connessione e un utilizzo inefficiente della larghezza di banda del canale. Il problema è stato parzialmente risolto con lo sharding del dominio, ovvero la creazione di host aggiuntivi per superare il limite del numero di connessioni.

È qui che appare la seconda capacità della CDN: ridurre la latenza (RTT) a causa dell'elevato numero di punti e della vicinanza dei nodi all'utente. Qui la distanza gioca un ruolo decisivo: la velocità della luce è limitata (circa 200 km/sec nella fibra ottica). Ciò significa che ogni 000 km di viaggio aggiungono 1000 ms di ritardo o 5 ms all'RTT. Questo è il tempo minimo richiesto per la trasmissione, poiché ci sono ritardi anche sugli apparati intermedi. Poiché una CDN di solito sa come memorizzare nella cache gli oggetti sui suoi server, possiamo trarre vantaggio dal caricamento di tali oggetti tramite una CDN. Condizioni necessarie per questo: la presenza dell'oggetto nella cache, la vicinanza del punto CDN all'utente rispetto al server delle applicazioni web (server di origine). È importante comprendere che la vicinanza geografica di un nodo CDN non garantisce una bassa latenza. Il routing tra il client e la CDN può essere costruito in modo tale che il client si connetta a un host in un altro paese e possibilmente in un altro continente. Qui entrano in gioco il rapporto degli operatori di telecomunicazioni con il servizio CDN (peering, collegamenti, partecipazione a IX, ecc.) e la politica di instradamento del traffico della CDN stessa. Ad esempio, Cloudflare, quando si utilizzano due piani iniziali (gratuito ed economico), non garantisce la consegna dei contenuti dall'host più vicino: l'host verrà selezionato per ottenere il costo minimo.

Molte aziende Internet leader attirano l'interesse del pubblico (sviluppatori web e proprietari di servizi) sul tema della velocità di caricamento e delle prestazioni dei siti web. Tra queste aziende ci sono Yahoo (strumento Yslow), AOL (WebPageTest) e Google (servizio Page Speed ​​​​Insights), che stanno sviluppando i propri consigli per velocizzare i siti (principalmente si riferiscono all'ottimizzazione del client). Successivamente compaiono nuovi strumenti per testare la velocità del sito web, che forniscono anche suggerimenti su come aumentare la velocità del sito web. Ciascuno di questi servizi o plugin ha una raccomandazione coerente: “Utilizza una CDN”. La riduzione della latenza di rete viene solitamente citata come spiegazione dell’effetto della CDN. Purtroppo non tutti sono pronti a capire esattamente come si ottiene l’effetto di accelerazione della CDN e come può essere misurato, quindi la raccomandazione viene presa per fede e utilizzata come postulato. In effetti, non tutti i CDN sono uguali.

Usare la CDN oggi

Per valutare l’utilità dell’utilizzo dei CDN, è necessario classificarli. Cosa si può trovare ora nella pratica (gli esempi tra parentesi, ovviamente, non sono esaustivi):

1. CDN gratuito per la distribuzione delle librerie JS (MaxCDN, Google. Yandex).
2. CDN di servizi per l'ottimizzazione del cliente (ad esempio Google Fonts per i font, Cloudinary, Cloudimage per le immagini).
3. CDN per l'ottimizzazione statica e delle risorse nel CMS (disponibile in Bitrix, WordPress e altri).
4. CDN per scopi generici (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN per l'accelerazione dei siti web (Cloudflare, Imperva, Airi).

La differenza fondamentale tra questi tipi è la quantità di traffico che passa attraverso la CDN. I tipi 1-3 riguardano la consegna solo di una parte del contenuto: da una richiesta a diverse dozzine (di solito immagini). I tipi 4 e 5 sono proxy completi del traffico tramite una CDN.

In pratica, questo significa il numero di connessioni utilizzate per caricare il sito. Con HTTP/2 utilizziamo una singola connessione TCP all'host per elaborare un numero qualsiasi di richieste. Se dividiamo le risorse in host principale (origine) e CDN, è necessario distribuire le richieste su più domini e creare più connessioni TCP. Il caso peggiore è: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Questa formula non tiene conto dei ritardi sulle reti mobili per l'attivazione del canale radio del dispositivo (se non era attivo) e dei ritardi sulla torre cellulare.

Ecco come appare nella cascata di caricamento del sito (le latenze per la connessione al CDN sono evidenziate a RTT 150 ms):

Se la CDN copre tutto il traffico del sito (ad eccezione dei servizi di terze parti), allora possiamo utilizzare un'unica connessione TCP, risparmiando ritardi nella connessione a host aggiuntivi. Naturalmente, questo vale per le connessioni HTTP/2.

Ulteriori differenze sono determinate dalla funzionalità di un determinato CDN: nel primo tipo ospita solo un file statico, nel quinto modifica diversi tipi di contenuto del sito a scopo di ottimizzazione.

Funzionalità CDN per l'accelerazione del sito web

Descriviamo l'intera gamma di funzionalità CDN per accelerare i siti, indipendentemente dalla funzionalità dei singoli tipi di CDN, e poi vediamo cosa è implementato in ciascuno di essi.

1. Compressione delle risorse testuali

La funzionalità più elementare e comprensibile, ma spesso mal implementata. Tutti i CDN dichiarano la presenza della compressione come caratteristica di accelerazione. Ma se guardi più in dettaglio, le carenze diventano evidenti:

• è possibile utilizzare gradi bassi per la compressione dinamica - 5-6 (ad esempio, per gzip il massimo è 9);
• la compressione statica (file nella cache) non utilizza funzionalità aggiuntive (ad esempio zopfi o brotli con grado 11)
• non c'è supporto per una compressione efficiente di brotli (risparmio di circa il 20% rispetto a gzip).

Se utilizzi una CDN, vale la pena verificare questi pochi punti: prendi il file proveniente dalla CDN, registra la sua dimensione compressa e comprimilo manualmente per confrontarlo (puoi utilizzare qualche servizio online con supporto brotli, ad esempio vsszhat.rf).

2. Impostazione delle intestazioni della cache del client

Anche una semplice funzionalità di accelerazione: aggiungi intestazioni per la memorizzazione nella cache dei contenuti da parte del client (browser). L'intestazione più recente è cache-control, quella obsoleta scade. Inoltre, è possibile utilizzare Etag. La cosa principale è che l'età massima del controllo della cache sia sufficientemente grande (da un mese o più).Se sei pronto a memorizzare nella cache la risorsa il più intensamente possibile, puoi aggiungere l'opzione immutabile.

I CDN possono abbassare il valore di età massima, costringendo l'utente a ricaricare il contenuto statico più spesso. Non è chiaro a cosa sia collegato: il desiderio di aumentare il traffico sulla rete o aumentare la compatibilità con i siti che non sanno come resettare la cache. Ad esempio, il tempo predefinito della cache dell'intestazione di Cloudflare è 1 ora, che è molto basso per dati statici immutabili.

3. Ottimizzazione dell'immagine

Poiché la CDN assume le funzioni di caching e di distribuzione delle immagini, sarebbe logico ottimizzarle sul lato CDN e servirle agli utenti in questa forma. Prenotiamo subito che questa funzionalità sia disponibile solo per i tipi CDN 2, 3 e 5.

Puoi ottimizzare le immagini in vari modi: utilizzando formati di compressione avanzati (come WebP), codificatori più efficienti (MozJPEG) o semplicemente eliminando i metadati non necessari.

In generale, esistono due tipi di tali ottimizzazioni: con perdita di qualità e senza perdita di qualità. I CDN di solito si sforzano di utilizzare l'ottimizzazione senza perdite per evitare possibili reclami da parte dei clienti sui cambiamenti nella qualità dell'immagine. In tali condizioni, il guadagno sarà minimo. In realtà, spesso il livello di qualità JPEG è molto più alto del necessario ed è possibile ricomprimere tranquillamente con un livello di qualità inferiore senza compromettere l'esperienza dell'utente. D’altra parte, è difficile determinare il livello di qualità e le impostazioni universalmente per tutte le possibili applicazioni web, quindi le CDN utilizzano impostazioni più conservative rispetto a quelle che possono essere applicate tenendo conto del contesto (scopo delle immagini, tipo di applicazione web , eccetera.)

4. Ottimizzazione della connessione TLS

La maggior parte del traffico oggi viaggia su connessioni TLS, il che significa che dedichiamo più tempo alla negoziazione TLS. Recentemente sono state sviluppate nuove tecnologie per accelerare questo processo. Ad esempio, si tratta di crittografia EC, TLS 1.3, cache di sessione e ticket, accelerazione di crittografia hardware (AES-NI), ecc. L'impostazione corretta di TLS può ridurre il tempo di connessione a 0-1 RTT (senza contare DNS e TCP).

Con i software moderni non è difficile implementare tali pratiche da soli.

Non tutti i CDN implementano le migliori pratiche TLS; puoi verificarlo misurando il tempo di connessione TLS (ad esempio, in Webpagetest). Ideale per una nuova connessione - 1RTT, 2RTT - livello medio, 3RTT e altro - pessimo.

Va inoltre notato che anche quando si utilizza TLS a livello CDN, anche il server con la nostra applicazione web deve elaborare TLS, ma dal lato CDN, perché il traffico tra il server e la CDN passa sulla rete pubblica. Nel peggiore dei casi, otterremo doppi ritardi di connessione TLS (il primo verso l'host CDN, il secondo tra questo e il nostro server).

Per alcune applicazioni vale la pena prestare attenzione ai problemi di sicurezza: il traffico viene solitamente decrittografato sui nodi CDN e questa è una potenziale opportunità di intercettazione del traffico. La possibilità di lavorare senza indicazione del traffico è solitamente offerta nei piani tariffari più alti a un costo aggiuntivo.

5. Ridurre i ritardi di connessione

Il vantaggio principale della CDN di cui tutti parlano: bassa latenza (minore distanza) tra l'host CDN e l'utente. Ottenuto creando un'architettura di rete geograficamente distribuita, in cui gli host sono ubicati in punti di concentrazione degli utenti (città, punti di scambio di traffico, ecc.)

In pratica, le priorità per le diverse reti possono trovarsi in regioni specifiche. Ad esempio, i CDN russi avranno più punti di presenza in Russia. Quelli americani svilupperanno innanzitutto la rete negli USA. Ad esempio, uno dei più grandi CDN Cloudflare ha solo 2 punti in Russia: Mosca e San Pietroburgo. Cioè possiamo risparmiare un massimo di circa 10 ms di latenza rispetto al posizionamento diretto a Mosca.

La maggior parte dei CDN occidentali non ha alcun punto in Russia. Collegandoti a loro, puoi solo aumentare i ritardi per il tuo pubblico russo.

6. Ottimizzazione dei contenuti (minimizzazione, modifiche strutturali)

Il punto più complesso e tecnologicamente avanzato. Modificare il contenuto durante la consegna può essere molto rischioso. Anche se prendiamo la minimizzazione: ridurre il codice sorgente (a causa di spazi extra, strutture non importanti, ecc.) può influenzarne le prestazioni. Se parliamo di modifiche più gravi - spostamento del codice JS alla fine dell'HTML, unione di file, ecc. - il rischio di interrompere la funzionalità del sito è ancora maggiore.

Pertanto, solo alcuni CDN di tipo 5 lo fanno. Naturalmente, non sarà possibile automatizzare tutte le modifiche necessarie per accelerare le cose: sono necessarie analisi e ottimizzazioni manuali. Ad esempio, la rimozione del codice inutilizzato o duplicato è un'attività manuale.

Di norma, tutte queste ottimizzazioni sono controllate dalle impostazioni e quelle più pericolose sono disabilitate per impostazione predefinita.

Supporto per funzionalità di accelerazione per tipo di CDN

Diamo quindi un'occhiata alle potenziali opportunità di accelerazione offerte dai diversi tipi di CDN.

Per comodità ripetiamo la classificazione.

1. CDN gratuito per la distribuzione delle librerie JS (MaxCDN, Google. Yandex).
2. CDN di servizi per l'ottimizzazione del cliente (ad esempio Google Fonts per i font, Cloudinary, Cloudimage per le immagini).
3. CDN per l'ottimizzazione statica e delle risorse nel CMS (disponibile in Bitrix, WordPress e altri).
4. CDN per scopi generici (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN per l'accelerazione dei siti web (Cloudflare, Imperva, Airi).

Ora confrontiamo le caratteristiche e le tipologie di CDN.

Opportunità
Tipo 1
Tipo 2
Tipo 3
Tipo 4
Tipo 5

Compressione del testo
+–
-
+–
+–
+

Intestazioni della cache
+
+
+
+
+

immagini
-
+–
+–
-
+

TLS
-
-
-
+–
+

ritardo
-
-
-
+
+

Contenuto
-
-
-
-
+

In questa tabella, “+” viene utilizzato per indicare il supporto completo, “–” non indica alcun supporto e “+–” indica un supporto parziale. Naturalmente, nella realtà potrebbero esserci delle deviazioni da questa tabella (ad esempio, alcune CDN generiche implementeranno funzionalità per l'ottimizzazione delle immagini), ma per un'idea generale è utile.

Risultati di

Speriamo che dopo aver letto questo articolo avrai un quadro più chiaro riguardo al consiglio di “usare una CDN” per velocizzare i tuoi siti.

Come in ogni attività, non puoi credere alle promesse di marketing di qualsiasi servizio. L’effetto deve essere misurato e testato in condizioni reali. Se utilizzi già una CDN, verificane l'efficacia utilizzando i criteri descritti nell'articolo.

È possibile che l'utilizzo di una CDN in questo momento rallenti il ​​tempo di caricamento del tuo sito.

Come raccomandazione generale, possiamo concentrarci su quanto segue: studiare il tuo pubblico, determinarne l'ambito geografico. Se il tuo pubblico principale è concentrato in un raggio di 1-2 mila chilometri, non hai bisogno di una CDN per il suo scopo principale: ridurre la latenza. Puoi invece posizionare il tuo server più vicino ai tuoi utenti e configurarlo correttamente, ottenendo la maggior parte delle ottimizzazioni descritte nell'articolo (gratuite e permanenti).

Nel caso in cui il tuo pubblico sia realmente distribuito geograficamente (raggio superiore a 3000 chilometri), utilizzare una CDN di qualità sarà davvero utile. Tuttavia, è necessario capire in anticipo cosa può accelerare esattamente la tua CDN (vedi la tabella delle funzionalità e la loro descrizione). Tuttavia, l’accelerazione dei siti web rimane ancora un compito complesso che non può essere risolto collegando una CDN. Oltre alle ottimizzazioni di cui sopra, i mezzi di accelerazione più efficaci rimangono dietro la CDN: ottimizzazione della parte server, modifiche avanzate alla parte client (rimozione del codice inutilizzato, ottimizzazione del processo di rendering, lavoro con contenuti, caratteri, adattabilità, ecc. )

Fonte: habr.com