Che cos'è un CDN (content delivery network)?

Un CDN è una rete di server distribuiti che mette in cache i contenuti vicino agli utenti, così pagine e file si caricano in fretta ovunque. Il problema che risolve è di fisica: una richiesta che parte da São Paulo verso un server a Francoforte paga il round trip in latenza, ogni volta. Un CDN risponde da São Paulo – e una precisazione evita confusioni senza fine: completa l’hosting, non lo sostituisce mai.

Punti chiave

Le leve che lo fanno funzionare

Tutto il contratto di caching sta in un unico header HTTP – ed è il pezzo meno spiegato di ogni presentazione di un CDN:

# L'istruzione dell'origine a ogni cache tra sé e l'utente:
Cache-Control: public, max-age=300, s-maxage=86400, stale-while-revalidate=3600

  public                  → qualsiasi cache può conservarlo
  max-age=300             → browser: fresco per 5 minuti
  s-maxage=86400          → edge del CDN: freschi per 24 ore
  stale-while-revalidate  → servire subito lo scaduto, aggiornare in background

# L'altra strategia: non scadere mai, non purgare mai – versionare il nome del file
/_assets/app.3f9c1b.css   → in cache "per sempre"; una nuova build, un nuovo URL

Conta anche la provenienza dei file in un’app: su un backend gestito, il caricamento di un file restituisce un URL pronto per la distribuzione, con una politica di cache già sensata:

// JavaScript / Node.js — Back4app JS SDK
// Upload once; the returned URL serves from edge cache worldwide
const file = new Parse.File('hero.webp', { base64: imageData });
await file.save();
console.log(file.url()); // CDN-backed, cache-friendly URL

// Flutter / Dart — Back4app Flutter SDK
final file = ParseFile(File('hero.webp'));
await file.save();
print(file.url); // CDN-backed, cache-friendly URL

// iOS / Swift — Back4app Swift SDK
let file = ParseFile(name: "hero.webp", data: imageData)
file.save { result in
  if case .success(let saved) = result {
    print(saved.url ?? "") // CDN-backed, cache-friendly URL
  }
}

// Android / Kotlin — Back4app Android SDK
val file = ParseFile("hero.webp", imageBytes)
file.saveInBackground { e ->
  if (e == null) Log.d("CDN", file.url) // CDN-backed, cache-friendly URL
}

Anatomia di una richiesta

Il vocabolario in un colpo solo: l’origine è il server reale – la fonte di verità. Un PoP (point of presence) è una sede di data center del CDN; i server edge sono le macchine di cache che ospita. Il cache-hit ratio – la quota di richieste servite senza toccare l’origine – è la metrica che tutto l’esercizio ottimizza, e le leve sono gli header visti sopra. Per gli utenti migliora il TTFB (time to first byte) e, quando pagine intere sono in cache all’edge, le metriche di caricamento che ne derivano.

CDN vs. hosting web vs. edge computing

La definizione di MDN aggiunge l’avvertenza che le pagine dei fornitori saltano: gli script serviti da un CDN di terze parti sono una dipendenza nella catena di fornitura (gli attributi di integrità esistono per un motivo), e una risoluzione DNS in più verso un CDN può addirittura costare tempo alla prima visita – una leva, non magia.

Casi d’uso comuni

• Asset statici su larga scala. CSS, JavaScript, font, immagini – nomi di file con hash e TTL lunghi trasformano le visite ripetute in puro traffico edge.
• Media e download. Segmenti video e file di grandi dimensioni, dove la banda dell’origine sarebbe sia la fattura sia il collo di bottiglia.
• Pubblico globale. La stessa pagina servita sotto i 100 ms su quattro continenti, senza far girare server su quattro continenti.
• Picchi di traffico e lanci. L’edge assorbe l’onda; l’origine ne vede una frazione.
• Postura di sicurezza. Origine nascosta dietro un reverse proxy, TLS terminato all’edge, attacchi volumetrici dissipati su tutta la rete.

Serve un CDN? Matrice decisionale

La riga onesta che nessuno stampa: su un sito a basso traffico le copie in cache scadono tra un visitatore e l’altro, ogni richiesta è un miss e il CDN aggiunge un salto per niente. Distanza e volume sono i dati di ingresso; senza nessuno dei due, conviene sistemare prima qualcos’altro.

Limiti e trade-off

• Il contenuto scaduto è il guasto predefinito. TTL lunghi significano che il file di ieri viene servito oggi con sicurezza; il rimedio è la purge (lenta, diversa per ogni CDN) o i nomi di file versionati (meglio).
• L’invalidazione della cache è davvero difficile. Non per niente figura tra i due famosi problemi difficili dell’informatica – conviene progettare gli URL per averne bisogno raramente.
• Il contenuto dinamico resiste al caching. Le risposte specifiche per utente non si condividono; accelerazione e logica edge aiutano, ma il lavoro lo fa sempre l’origine.
• Una dipendenza sul percorso critico. I guasti di un CDN sono eventi meteorologici di internet; quando cade l’edge, il sito risulta giù, per quanto l’origine stia benissimo.
• Il debug guadagna un livello. Quale cache ha servito questa risposta? Con quali header? Gli header di stato della cache e il comportamento di ogni singolo edge diventano parte della superficie di osservabilità.

I CDN su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. La distribuzione via CDN è integrata nel livello dei file: basta caricare un file con qualunque SDK (le schede qui sopra) e l’URL restituito è pronto per la distribuzione – stabile, memorizzabile in cache e indipendente dal traffico dinamico delle API, il che tiene separate in modo netto la metà memorizzabile e quella non memorizzabile dell’app. I frontend web ospitati su Back4app Containers si collocano naturalmente dietro qualsiasi CDN, con il pattern classico – asset con hash a vita lunga, HTML a vita breve – configurato in un solo header.