I pagliaccioni delle CDN e delle reti Edge fai da te

Una volta per costruire una CDN serviva un’azienda: ingegneri di rete, accordi di peering, un ASN, blocchi di indirizzi IP, centinaia di punti di presenza, anni di lavoro. Oggi basta un abbonamento a un assistente di intelligenza artificiale, una manciata di VPS in giro per l’Europa e un pomeriggio libero.

È così che, negli ultimi tempi, anche i sistemisti e gli hosting provider più somari della scena internazionale hanno scoperto le CDN. Hanno chiesto all’AI come funziona una rete edge, hanno capito due o tre concetti di base, e hanno deciso di costruirsene una tutta loro. Qualche nodo su Hetzner, uno su OVH, uno su Scaleway, un paio su Linode e DigitalOcean, un reverse proxy con la cache attiva, un DNS che risponde in base alla posizione. Un bel logo, una pagina commerciale con il mappamondo pieno di puntini luminosi, e la CDN proprietaria è pronta per essere venduta come alternativa a Cloudflare, Imperva o Akamai.

Benvenuti nel circo dei pagliaccioni delle CDN fai da te.

Sia chiaro fin da subito: non c’è niente di male nel voler costruire una CDN self hosted. Anzi, è un ottimo esercizio di stile, un modo per dimostrare di saper fare le cose e di offrire qualcosa in più rispetto agli altri. Il problema non è fare le cose. Il problema è farle male, venderle come se fossero fatte bene e lasciare che a pagarne le conseguenze siano i clienti, che nella maggior parte dei casi non hanno nemmeno gli strumenti per accorgersene.

Che cos’è davvero una CDN

Una CDN, Content Delivery Network, è una rete di server distribuiti geograficamente che si mette tra i visitatori e il server su cui gira il sito, chiamato origin. Ogni server della rete, chiamato POP (Point of Presence) o nodo edge, conserva una copia dei contenuti e la consegna ai visitatori che si trovano più vicini a lui.

Il problema che risolve è fisico, prima ancora che informatico. La luce nella fibra ottica viaggia a circa due terzi della sua velocità nel vuoto, e i pacchetti non seguono mai la linea retta: attraversano router, scambi, cavi sottomarini. Un visitatore a Milano che si collega a un server a Francoforte paga una manciata di millisecondi di andata e ritorno. Uno a San Paolo o a Sydney ne paga centinaia.

E quei millisecondi non si pagano una volta sola. Per aprire una connessione HTTPS servono uno scambio TCP e uno scambio TLS prima ancora di chiedere la pagina: ogni viaggio di andata e ritorno si moltiplica. Il TTFB, il tempo che passa tra la richiesta e il primo byte della risposta, è fatto in buona parte proprio di questi viaggi, più il tempo che il server impiega a generare la risposta.

Una CDN interviene su entrambi i fronti. Il visitatore apre la connessione con un nodo vicino, quindi i viaggi di andata e ritorno sono brevi. E se quel nodo ha già la pagina in cache, la risposta parte subito, senza disturbare l’origin e senza aspettare PHP e il database. È questo il concetto di edge: spostare i contenuti, e possibilmente anche un po’ di logica, sul bordo della rete, il più vicino possibile a chi li chiede.

Come si porta un visitatore al nodo giusto

Esistono sostanzialmente due modi per indirizzare un visitatore verso il POP più vicino.

Il primo è il GeoDNS. Il server DNS che risponde per il dominio guarda da dove arriva la richiesta e restituisce l’indirizzo IP del nodo più vicino. È semplice e non richiede infrastrutture particolari, ma ha limiti noti: la posizione che il DNS vede è quella del resolver usato dal visitatore, non quella del visitatore stesso. Chi usa un resolver pubblico, una VPN o il DNS aziendale di una sede in un altro Paese può essere mandato nel posto sbagliato. E i record DNS restano in cache nei resolver: se un nodo cade, i visitatori continuano a essere mandati lì finché il TTL non scade.

Il secondo è l’IP Anycast, il metodo usato dalle grandi CDN come Cloudflare. Lo stesso indirizzo IP viene annunciato via BGP da tutti i punti di presenza contemporaneamente, ed è la rete Internet stessa a instradare ogni visitatore verso il nodo più vicino in termini di routing. Funziona molto bene, ma richiede un ASN assegnato, blocchi di indirizzi propri, sessioni BGP con i fornitori di connettività e una competenza di rete che non si improvvisa. Ne abbiamo parlato in modo approfondito spiegando perché il routing Anycast è la base di ogni CDN.

Il pagliaccione medio, naturalmente, usa il GeoDNS. Non perché sia una scelta ponderata, ma perché è l’unica che riesce a configurare. E fin qui, potremmo anche chiudere un occhio. Il disastro vero arriva dopo.

Prima domanda: vi serve davvero una CDN?

Prima di parlare di come si fa una CDN, bisognerebbe chiedersi se serve. E qui i pagliaccioni falliscono il primo esame, perché la propongono a tutti, di default, come se fosse sempre e comunque un miglioramento.

Prendiamo un e-commerce che vende solo in Italia, o al massimo in Europa, con il server in Germania. Un visitatore italiano ha qualche decina di millisecondi di latenza verso Francoforte. Se il sito è servito da una buona cache sull’origin, il TTFB resta abbondantemente sotto la soglia che Google considera buona, cioè 800 millisecondi: nella pratica, con una cache fatta bene, si parla di poche decine di millisecondi o di un centinaio al massimo.

Ecco il punto che nessun pagliaccione vi dirà mai: avere 30 millisecondi di TTFB o averne 60 non cambia nulla. Non cambia le conversioni, non cambia i Core Web Vitals, non cambia il posizionamento. Nessun cliente abbandona il carrello per trenta millisecondi. Una CDN, in questo scenario, porta un vantaggio marginale nel caso migliore. E come vedremo, porta un danno concreto nel caso peggiore, che con le CDN improvvisate è anche il caso più frequente.

Il vero problema: le cache fredde

Una CDN è veloce solo quando il contenuto richiesto è già nella cache del nodo a cui il visitatore si collega. È un HIT. Quando il contenuto non c’è, è un MISS, e il nodo deve fare quello che una CDN dovrebbe evitare: andare a chiedere la pagina all’origin, aspettare che venga generata, riceverla, memorizzarla e solo allora consegnarla al visitatore.

In una CDN fatta bene, il MISS è un’eccezione. In una CDN fatta dai pagliaccioni, il MISS è la regola. Perché?

Perché ogni nodo ha la sua cache, e i nodi non si parlano. La cache di Milano non sa niente della cache di Parigi, che non sa niente di quella di Madrid. Ogni pagina deve essere richiesta almeno una volta in ogni nodo prima di essere servita velocemente in quel nodo. Se avete dieci POP, avete dieci cache da scaldare. E le pagine che in Italia vengono viste centinaia di volte al giorno, a Varsavia o a Stoccolma vengono viste una volta ogni tanto: il tempo di scadenza della copia arriva prima della richiesta successiva, e quella cache non si scalda mai.

Il risultato è una rete che ha ottime prestazioni solo dove il traffico è già alto, cioè proprio dove c’era meno bisogno di lei, e prestazioni pessime ovunque altrove. Abbiamo spiegato perché in una cache non conta solo esserci, ma quanto spesso si trova quello che si cerca, in la Web Cache è bella ma l’HIT ratio è meglio. Con dieci cache separate, quel rapporto non si divide per dieci: crolla.

Il lettore italiano a Parigi

Facciamo un esempio concreto. Una testata giornalistica italiana usa una CDN fai da te con un nodo a Milano e uno a Parigi. Il nodo di Milano, con tutto il traffico italiano, ha praticamente ogni articolo in cache: è velocissimo. Il nodo di Parigi riceve pochissime visite: ha quasi niente in cache.

Un lettore italiano che si trova a Parigi apre un articolo. Il GeoDNS lo manda, correttamente dal suo punto di vista, al nodo di Parigi. Il nodo di Parigi non ha l’articolo. Deve aprire una connessione verso l’origin in Italia, chiedere la pagina, aspettare che venga generata o rivalidata, riceverla, memorizzarla, e solo allora iniziare a consegnarla al lettore. Il lettore paga la latenza verso Parigi, la latenza da Parigi all’origin, il tempo di generazione e quello di memorizzazione. Latenze doppie, più il lavoro del server.

Se lo stesso lettore si fosse collegato direttamente al server in Italia, avrebbe aggiunto qualche decina di millisecondi di latenza, diciamo una quarantina, ma avrebbe ricevuto una pagina già in cache, servita in un istante. Il pagliaccione ha speso soldi, tempo e marketing per rendere quel lettore più lento di quanto sarebbe stato senza la sua meravigliosa CDN.

E se l’origin non ha una sua cache, perché “tanto c’è la CDN”, ogni MISS diventa una generazione completa della pagina da parte di PHP e del database: centinaia di millisecondi, a volte secondi, per un visitatore che avrebbe dovuto essere servito in un attimo.

Un caso reale di CDN edge realizzata da pagliaccioni

Qualcuno potrebbe chiedere delle prove, per capire nella pratica di cosa stiamo parlando. Allora prendiamo due siti: il nostro, managedserver.it, che non usa alcuna CDN e si affida a Varnish sul server di origine, e quello di un noto hosting provider con la sua CDN proprietaria, che manterremo anonimo e chiameremo, per puro esempio, “PAGLIACCIONE SRL”.

Entrambi i siti sono stati misurati con il TTFB test di SpeedVitals, che misura il tempo di risposta di una singola risorsa da diverse località nel mondo. La risorsa può essere una pagina HTML, un’immagine, un font, un foglio di stile o un file JavaScript: per questo lo strumento è utile proprio per misurare il tempo di risposta di un server di origine o di una CDN a livello globale.

I numeri, località per località: nella colonna CDN il sito con la CDN proprietaria, nella colonna Varnish managedserver.it senza CDN.

Cosa dicono i numeri

Il server senza CDN vince in tutte e dieci le località. Non c’è una sola regione in cui la CDN abbia restituito un TTFB migliore. Nemmeno a Milano, dove la CDN impiega 79 millisecondi contro i 42 del server senza CDN.

Il TTFB medio scende di quasi la metà. Si passa da 209 a 112 millisecondi, circa 97 millisecondi in meno, una riduzione del 46%. Detto al contrario: con la CDN il TTFB medio è quasi dell’87% più alto.

Il vantaggio resta anche nelle località più lontane, quelle in cui una CDN dovrebbe dare il meglio di sé:

• Svezia: da 357 a 189 ms;
• Finlandia: da 372 a 224 ms;
• Varsavia: da 278 a 143 ms;
• Londra: da 239 a 112 ms.

In queste misure, la presenza della CDN non garantisce tempi di risposta migliori nemmeno dove la distanza dall’origin è maggiore.

Il dettaglio che dice più di tutto: la cache

Nel test di managedserver.it ogni riga riporta Served By: Varnish e Cache Status: HIT: tutte le richieste, da tutte le località, sono state servite dalla cache.

Nel test della CDN di PAGLIACCIONE SRL, invece, le colonne Served By, Served From e Cache Status sono vuote ovunque. Lo strumento non riesce a riconoscere né la CDN, né il nodo che ha risposto, né se la risposta arrivi dalla cache.

Per correttezza va detto che l’assenza dell’indicazione HIT non significa per forza che la cache non ci sia: potrebbe esserci senza essere dichiarata. Ma una CDN seria si fa riconoscere: dichiara il nodo che ha risposto e se la risposta è un HIT o un MISS, come fa Cloudflare con l’intestazione cf-cache-status. Una “CDN” che non permette nemmeno di verificare se sta usando la cache è già, di per sé, un campanello d’allarme.

Cosa si può concludere, con onestà

• Nel campione misurato, il server con Varnish e senza CDN consegna il primo byte più rapidamente da tutte e dieci le località europee.
• La differenza media è significativa: circa 97 millisecondi, il 46% in meno.
• Un’infrastruttura centralizzata, ottimizzata e con una cache HTTP efficiente può offrire prestazioni eccellenti in tutta Europa anche senza una CDN.
• Non è dimostrato che ogni CDN sia più lenta per sua natura: per isolare la causa bisognerebbe confrontare lo stesso contenuto, servito sicuramente dalla cache in entrambi i casi, e ripetere le misure più volte e in orari diversi.
• Il test riguarda solo il TTFB: non misura il caricamento completo, le risorse statiche, il Largest Contentful Paint o gli altri Core Web Vitals.

I dati smentiscono l’idea che basti mettere una CDN davanti a un sito per renderlo più veloce. Una CDN vera può dare vantaggi che vanno oltre il TTFB, come la mitigazione DDoS, la distribuzione dei file statici e lo scarico dell’origin. Ma quello che conta davvero è l’efficienza della cache e dell’infrastruttura, non la presenza di una CDN sulla pagina commerciale. E quando una CDN proprietaria è più lenta di un singolo server senza distribuzione geografica persino a Milano, il problema non è la CDN in sé: è chi l’ha costruita.

Come fanno le CDN vere

Le CDN serie questo problema lo conoscono da vent’anni, e lo hanno risolto con architetture che i pagliaccioni non sanno nemmeno che esistono.

• Cache a più livelli. I nodi periferici, in caso di MISS, non vanno all’origin: chiedono prima a un nodo di livello superiore, più grande e più vicino all’origin, che fa da cache condivisa per tutta una regione. Cloudflare la chiama Tiered Cache, altri la chiamano in modo diverso, ma il principio è lo stesso: una sola richiesta all’origin scalda la cache per molti POP.
• Scelta del percorso verso l’origin. Il nodo che deve andare all’origin non lo fa a caso, ma attraverso i nodi e i percorsi più rapidi in quel momento.
• Connessioni persistenti verso l’origin. I nodi tengono aperte connessioni già negoziate, così un MISS non paga ogni volta l’apertura di una nuova sessione TLS.
• Invalidazione globale rapida. Quando si svuota la cache, la richiesta arriva a tutti i nodi in pochi secondi, e non resta in giro una versione vecchia della pagina in qualche angolo del mondo.
• Capacità e protezione. Centinaia di punti di presenza, terabit di capacità, mitigazione DDoS integrata, monitoraggio continuo di ogni nodo con l’esclusione automatica di quelli che non rispondono.

Ora confrontate questo elenco con sei VPS noleggiati a pochi euro al mese, con vCPU condivise e dischi condivisi (ne abbiamo parlato a proposito dei VPS low cost), un NGINX con la cache attiva, un DNS geografico e una pagina commerciale con il mappamondo. Ecco la distanza tra una CDN e la sua caricatura.

Fare una CDN apparente è facile, farla funzionare no

Oggi mettere in piedi una CDN apparente, e reclamizzarla come tale, è facile. Con l’aiuto dell’intelligenza artificiale si configurano i reverse proxy, si generano i certificati, si scrive il file di zona del GeoDNS. In un paio di giorni si ha qualcosa che, a una prima occhiata, sembra funzionare.

Farla con le caratteristiche che contano davvero è un altro paio di maniche: la sincronizzazione o la condivisione delle cache tra i nodi, con il nodo più vicino che va a cercare il contenuto prima nel nodo vicino che ce l’ha e solo dopo all’origin; l’invalidazione coerente su tutta la rete; il controllo dello stato dei nodi con il ritiro automatico di quelli guasti; la gestione corretta delle chiavi di cache, dei cookie, delle pagine personalizzate. Su quest’ultimo punto un errore non costa solo millisecondi: può voler dire servire il carrello o l’area riservata di un cliente a un altro visitatore.

Il rischio, per il pagliaccione, è ottenere esattamente l’effetto opposto a quello per cui la CDN è stata costruita: un sito più lento, meno affidabile e più difficile da diagnosticare. E il rischio per il cliente è non accorgersene mai.

Il cliente non ha modo di accorgersene

Ed è qui che il circo diventa davvero pericoloso. Un cliente italiano che apre il proprio sito dall’ufficio di Bologna vedrà sempre un sito velocissimo: il nodo italiano è caldo, le pagine sono in cache, tutto risponde in un attimo. Il pagliaccione gli mostrerà un grafico, un test fatto dall’Italia, e il cliente sarà soddisfatto.

Ma quel cliente difficilmente avrà la competenza, gli strumenti o anche solo l’idea di verificare le prestazioni di un visitatore spagnolo, francese o tedesco. Non vedrà mai il cliente di Monaco che aspetta un secondo per una pagina che a Bologna arriva in trenta millisecondi. Non vedrà il bot di Google che scansiona il sito da un datacenter americano e trova TTFB pessimi. Non vedrà le statistiche del Chrome User Experience Report peggiorare lentamente, mentre tutti i test fatti dall’Italia continuano a dire che va tutto bene.

I pagliaccioni contano proprio su questo. Su un cliente che misura dal posto sbagliato e che si fida del grafico che gli viene mostrato.

Come smascherare un pagliaccione in cinque minuti

La buona notizia è che per smascherare una CDN improvvisata non servono competenze da sistemista. Servono due strumenti gratuiti e cinque minuti di tempo.

Ogni volta che leggete di CDN proprietarie, nodi edge, reti globali e performance garantite in tutto il mondo, usate il TTFB test di SpeedVitals, che misura il tempo di risposta del vostro sito da decine di località nel mondo, e il ping test di Uptrends, che misura la latenza dai vari Paesi.

• Fate il test due volte di seguito. Se il secondo giro è molto più veloce del primo in quasi tutte le località, ogni nodo ha la sua cache e la deve scaldare da solo: i vostri visitatori reali, che non fanno due giri, prenderanno quasi sempre il primo.
• Guardate le località vicine all’origin. Se Parigi, Madrid, Amsterdam o Varsavia hanno un TTFB più alto di oltre 100 millisecondi rispetto a quello che otterreste collegandovi direttamente al server, la CDN vi sta facendo perdere tempo invece di farvelo guadagnare.
• Provate pagine diverse dalla home. La home è sempre in cache ovunque. Provate un articolo di sei mesi fa o una scheda prodotto poco visitata: lì si vede la verità.
• Leggete le intestazioni della risposta. Le CDN serie dichiarano se la risposta arriva dalla cache, con intestazioni come cf-cache-status (ne abbiamo spiegato i codici di stato) o un header X-Cache con HIT o MISS. Se vedete MISS da quasi ovunque, sapete già tutto.

Se i numeri sono negativi e vedete differenze superiori ai 100 millisecondi, non c’è da pensarci molto: scappate verso CDN vere, come Cloudflare, e lasciate la robaccia improvvisata dai pagliaccioni di turno a chi ha voglia di fare da cavia.

E se una CDN non serve, cosa serve?

Per la grande maggioranza dei siti italiani ed europei, la risposta non è una rete edge, ma un origin fatto bene. Un server in una posizione centrale rispetto al pubblico, con risorse dedicate e misurate, e una web cache configurata seriamente, con un HIT ratio alto, invalidazioni corrette e la gestione dei contenuti personalizzati. Così il TTFB resta basso per tutti, senza dieci cache da scaldare, senza pagine vecchie dimenticate in qualche nodo e senza nessun pagliaccione in mezzo.

Quando invece il pubblico è davvero internazionale, o servono protezione DDoS, filtri contro i bot e capacità che un singolo server non può offrire, la scelta sensata è una CDN vera, configurata da chi sa cosa sta facendo. Non a caso offriamo anche consulenza su Cloudflare: la tecnologia c’è già, è matura ed è accessibile anche nei piani gratuiti. Reinventarla male non ha alcun senso.

Conclusioni

L’intelligenza artificiale ha reso accessibili a tutti le competenze di base. È una cosa splendida, e ha permesso a molti professionisti di imparare e di crescere. Ma ha anche dato a molti pagliaccioni l’illusione di poter costruire in un pomeriggio ciò che altri hanno costruito in vent’anni, con migliaia di ingegneri e investimenti enormi.

Una CDN non è un insieme di reverse proxy sparsi per l’Europa con un DNS che risponde in base alla posizione. È un sistema distribuito che funziona solo se le cache si scaldano, si condividono e si invalidano in modo coerente, se i nodi guasti escono dalla rete da soli e se qualcuno controlla ogni giorno che tutto questo accada davvero.

Se qualcuno vi propone la sua CDN proprietaria, non chiedetegli quanti punti ci sono sulla mappa. Chiedetegli come si condividono le cache tra i nodi, cosa succede in caso di MISS, come si invalida la cache su tutta la rete e quanto ci mette. Poi aprite SpeedVitals e misurate. Se le risposte sono vaghe e i numeri sono brutti, avete appena incontrato un altro pagliaccione. Ringraziate, sorridete, e andate altrove.