Peppe’s CDN, analisi tecnica e critiche al vetriolo della Iweblab CDN

Ogni tanto qualcuno decide di costruirsi la propria CDN. In teoria è un’ottima idea: nodi distribuiti, contenuti vicini agli utenti, tempi di risposta più bassi e nessuna dipendenza dai grandi provider. In pratica, una CDN è uno dei progetti infrastrutturali più difficili da fare bene, perché si gioca tutto su pochi millisecondi e basta un anello debole per perderli tutti, e poi qualcuno in più.

È il caso della CDN di Iweblab, la creatura di Peppe. L’idea di partenza è legittima, la realizzazione molto meno: abbiamo misurato, confrontato e scavato nel DNS, e il risultato è che il collo di bottiglia non è la rete, non è il server, è proprio il meccanismo con cui la CDN decide dove mandare i visitatori. Quello che doveva far risparmiare tempo è esattamente il punto in cui il tempo si perde.

Sappiamo bene che a Peppe articoli come questo non fanno piacere, perché mettono in discussione le sue scelte tecnologiche. Ma qui non ci sono opinioni da prendere sulla fiducia: ci sono misure, comandi e numeri che chiunque può rifare in cinque minuti. Ed è giusto così, perché quando una soluzione viene proposta ai clienti come più veloce, la velocità si misura.

Il test: stesso strumento, stessi punti di misura

Abbiamo usato un comune servizio di test HTTP multi-località, che interroga un sito da decine di città e scompone il tempo totale in tre parti:

• Resolve time: il tempo per risolvere il nome a dominio in un indirizzo IP, cioè la risposta DNS;
• Connection time: il tempo per aprire la connessione verso il server, che dipende soprattutto dalla distanza di rete;
• Download time: il tempo in cui il server elabora la richiesta e invia la risposta.

Da una parte managedserver.it, servito da un’unica origine in Italia, senza CDN davanti all’HTML. Dall’altra iweblab.sm, il sito di chi la CDN la vende, che passa ovviamente dalla propria CDN.

Il test di iweblab.sm è del 30 ottobre 2026 alle 08:31 GMT. Vale la pena fermarsi un attimo sulla colonna degli indirizzi IP, perché racconta già metà della storia: alcune città ricevono 95.110.225.107, altre 81.31.156.7. È il segno inequivocabile del GeoDNS: il DNS risponde con un indirizzo diverso a seconda di dove arriva la domanda. Su managedserver.it, invece, tutte le città ricevono lo stesso indirizzo, 80.211.123.191.

I numeri, città per città

Abbiamo messo a confronto le nove città presenti in entrambi i test (MS sta per managedserver.it).

Tre cose saltano all’occhio.

La prima: il DNS. Su managedserver.it la risoluzione non supera mai i 25 ms, con una media di 17. Sulla CDN di Iweblab la media è 75 ms, cinque città su nove stanno sopra i 75 ms e Haarlem tocca 155 ms. A Haarlem e a Roma la sola risposta DNS vale più della metà dell’intero tempo di caricamento della risposta. Il visitatore non ha ancora scambiato un byte con il server e ha già perso un sesto di secondo.

La seconda: i tempi di connessione sono identici. 18 ms di media contro 19. Ed è qui che la CDN si smentisce da sola. Se Londra, Haarlem, Lille e Praga, che ricevono l’indirizzo 81.31.156.7, fossero servite da un nodo vicino, la connessione da quelle città dovrebbe durare pochi millisecondi. Invece Londra impiega 28 ms per collegarsi alla “CDN” e 30 ms per collegarsi al nostro server in Lombardia: la distanza di rete è la stessa. Le banche dati di geolocalizzazione collocano infatti entrambi gli indirizzi della CDN in Italia, uno nella rete di Aruba e l’altro in una rete di Host SpA in Piemonte. Due nodi, entrambi in Italia, distanti tra loro poche centinaia di chilometri. Il GeoDNS sceglie quale dei due dare a un utente di Londra, ma l’utente di Londra resta comunque a oltre mille chilometri dal contenuto.

La terza: anche i tempi di download si equivalgono, 132 ms di media per noi e 134 per loro. Non è un confronto perfetto, perché le pagine sono diverse per peso ed elaborazione, ma conferma che la CDN non porta alcun vantaggio misurabile nella consegna del contenuto.

Riassumendo: la differenza di 62 ms tra le due medie totali coincide quasi al millisecondo con la differenza di 58 ms nella risoluzione DNS. Tutto quello che la CDN aggiunge è attesa davanti al DNS. Tutto quello che dovrebbe togliere, la distanza, non lo toglie.

Dentro il DNS della CDN: perché è così lento

Gli screenshot mostrano il sintomo; per trovare la causa basta un terminale e il comando dig. Il 1° novembre 2026 abbiamo interrogato i server DNS di Iweblab da una connessione in Italia.

Il dominio iweblab.sm è delegato ai nameserver di Cloudflare, che rispondono in 14-25 ms, esattamente come quelli di managedserver.it. Fin qui nessun problema. Il problema arriva un passo dopo: www.iweblab.sm è un CNAME verso edge.iweblab.net, il nome della CDN, e il dominio iweblab.net è gestito da quattro nameserver propri:

Sì, avete letto bene: uno dei quattro nameserver di una CDN pensata per l’Europa sta in California. Un resolver che non conosce ancora i tempi di risposta dei quattro server ne sceglie uno più o meno a caso, e una volta su quattro finisce dall’altra parte dell’oceano. Durante le nostre prove, inoltre, una query a ns1 è andata in timeout, costringendo il resolver a ripiegare su un altro server.

A peggiorare le cose c’è il TTL di 60 secondi sui record della CDN. Il TTL è il tempo per cui un resolver può tenere in cache una risposta: con 60 secondi, la risposta scade di continuo e la maggior parte dei visitatori non la trova pronta, quindi paga per intero la catena di risoluzione. Il GeoDNS ha bisogno di TTL brevi per poter spostare il traffico velocemente, ma è una scelta che si paga in ogni singola risoluzione, e qui la si paga con nameserver lenti e lontani.

Il conto, a questo punto, torna: una catena con un passaggio in più, un TTL che svuota le cache ogni minuto e un nameserver su quattro a più di 150 ms. I 93, 111, 125 e 155 ms misurati a Francoforte, Roma, Praga e Haarlem sono esattamente quello che ci si aspetta da un’architettura del genere.

GeoDNS e Anycast: la differenza che fa la differenza

Per capire perché la scelta del GeoDNS sia il tallone d’Achille di questa CDN, bisogna capire come lavorano le due tecniche con cui una CDN può mandare ogni utente al nodo più vicino.

GeoDNS

Con il GeoDNS ogni nodo ha un indirizzo IP diverso. Quando arriva una richiesta DNS, il nameserver guarda da dove proviene, consulta una banca dati di geolocalizzazione e risponde con l’IP del nodo che ritiene più vicino. Ha tre debolezze strutturali:

• Il DNS diventa parte del percorso critico: la decisione richiede una risposta DNS su misura, che non può restare a lungo in cache, quindi TTL brevi e più risoluzioni complete.
• Il nameserver vede il resolver, non l’utente. Chi usa i DNS di Google, Cloudflare o del proprio provider viene localizzato in base al resolver, che può stare in un altro paese. L’estensione EDNS Client Subnet attenua il problema, ma non tutti i resolver la inviano: 1.1.1.1 di Cloudflare, per esempio, per scelta non lo fa.
• Le banche dati di geolocalizzazione sbagliano, soprattutto sugli indirizzi aziendali, mobili e dei grandi cloud.

Anycast

Con l’Anycast lo stesso indirizzo IP viene annunciato via BGP da tutti i nodi contemporaneamente. Il DNS risponde sempre con lo stesso IP, con TTL lunghi e cache che funzionano, e a portare l’utente al nodo più vicino ci pensa il routing di Internet: i pacchetti seguono il percorso più breve verso l’annuncio più vicino. Nessuna geolocalizzazione da indovinare, nessuna risposta DNS su misura, e in caso di guasto di un nodo basta ritirare l’annuncio perché il traffico si sposti in pochi secondi. È il motivo per cui Cloudflare, Fastly, Google e tutte le CDN di primo livello usano Anycast, sia per i nodi sia per i DNS.

L’Anycast ha però un prezzo d’ingresso: serve un proprio Autonomous System, uno spazio di indirizzi IP proprio (almeno un /24 IPv4 e un /48 IPv6), connettività di transito e peering in ogni località e la capacità di gestire sessioni BGP su più punti di presenza. Ed è qui che arriviamo al punto vero.

Il problema di scala

Una CDN ha senso quando gli utenti sono lontani dall’origine e i nodi sono vicini agli utenti. La CDN di Iweblab ha due nodi, entrambi in Italia, al servizio di siti con un pubblico in larga parte italiano. Per un utente italiano un buon server in Italia è già il nodo più vicino possibile. Per un utente di Londra, due nodi italiani invece di uno non cambiano nulla, come dimostrano i tempi di connessione identici.

Il risultato è una CDN che ha tutti i costi delle CDN, cioè la complessità, la catena DNS, i TTL brevi e la cache distribuita da invalidare, senza il loro unico vero beneficio, la vicinanza. Una CDN a due nodi non è una CDN: è un’origine con un indirizzo in più e un DNS più lento.

Per costruire qualcosa di realmente utile servirebbe la scala: decine di punti di presenza in Europa e nel mondo, Anycast, accordi di peering, un DNS globale. È un investimento che ha senso per chi serve traffico enorme e distribuito, e non a caso il mercato delle CDN è dominato da pochi operatori con reti gigantesche. Per tutti gli altri esistono strade più efficaci e più economiche: un’origine ottimizzata in Italia con una buona cache HTML, che è quello che facciamo noi, oppure una CDN Anycast vera davanti all’origine quando il pubblico è davvero internazionale.

Cosa avremmo fatto noi

Visto che criticare è facile, ecco cosa cambieremmo, in ordine di costo:

1. Togliere il nameserver in California, o almeno portare i quattro nameserver in Europa: è l’intervento più semplice e da solo elimina i picchi peggiori.
2. Affidare la zona della CDN a un DNS Anycast: Iweblab usa già Cloudflare per iweblab.sm, quindi sa benissimo come si fa.
3. Alzare il TTL a qualche minuto: con due nodi entrambi in Italia, la flessibilità di 60 secondi non vale il prezzo pagato su ogni risoluzione.
4. Chiedersi se la CDN serva davvero. Con due nodi italiani e un pubblico italiano, la risposta onesta è no: meglio un’origine sola, ben ottimizzata, con una cache HTML ad alto hit ratio.

Buone intenzioni, cattive misure

La strada dell’inferno, si sa, è lastricata di buone intenzioni. Costruirsi una CDN è una sfida tecnica affascinante, e sia chiaro: presentata all’esame di Reti all’università, con GeoDNS, nodi multipli e nameserver ridondati su quattro provider, la CDN di Peppe avrebbe probabilmente preso trenta e lode.

Ma il mercato, quello vero, non dà voti sul progetto: misura i millisecondi. E i millisecondi dicono che un utente di Haarlem aspetta 155 ms solo per sapere a quale server rivolgersi, per poi collegarsi comunque in Italia. Noi, con un solo server e nessuna CDN davanti all’HTML, in quel test non superiamo mai i 25 ms di risoluzione DNS.

I comandi sono pubblici, gli strumenti di test sono gratuiti e i risultati sono riproducibili da chiunque. Se qualcuno ha misure diverse, le pubblichi: saremo i primi a leggerle con attenzione.

Se invece volete capire dove si perdono davvero i millisecondi del vostro sito, tra DNS, rete, server e cache, parliamone: è il nostro lavoro di tutti i giorni. Per approfondire, abbiamo scritto anche di perché il routing Anycast è la base di ogni CDN e di perché, in una cache, conta l’hit ratio.