---
term: 'CDN (content delivery network)'
seoTitle: 'CDN (content delivery network): come funziona e quando serve'
headline: 'Che cos''è un CDN (content delivery network)?'
slug: cdn
category: cloud-architecture
shortDefinition: '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.'
relatedTerms:
  - edge-computing-edge-functions
  - ssr-vs-csr-vs-ssg
  - jamstack
  - api-payload-optimization
contrastsWith:
  - edge-computing-edge-functions
faq:
  - question: 'Che cos''è un CDN, in parole semplici?'
    answer: 'Una rete di server distribuiti geograficamente che conserva copie in cache dei contenuti vicino agli utenti. Invece che ogni richiesta viaggi fino al server di origine – a volte dall''altra parte di un oceano – la maggior parte riceve risposta in pochi millisecondi da un server edge vicino. La maggioranza del traffico web dei grandi siti viene servita così.'
  - question: 'Come funziona un CDN?'
    answer: 'Routing più caching. La richiesta di un utente viene indirizzata al point of presence più vicino; se quel server edge ha una copia fresca in cache (un cache hit), risponde immediatamente. Altrimenti (un miss), l''edge va a prendere il contenuto all''origine, ne conserva una copia per il TTL configurato e serve dalla cache tutti gli utenti vicini fino alla scadenza.'
  - question: 'Un CDN è la stessa cosa dell''hosting web?'
    answer: 'No – un CDN completa l''hosting, non lo sostituisce mai. L''host (l''origine) conserva il contenuto di riferimento; il CDN ne detiene copie temporanee all''edge. Se l''origine scompare, alla fine il CDN non ha più nulla da servire. La divisione dei compiti: l''origine è la fonte di verità, il CDN è il livello di distribuzione.'
  - question: 'Che cosa sono cache hit, cache miss e TTL?'
    answer: 'Un hit significa che l''edge ha servito la sua copia in cache – veloce, e l''origine non si è accorta di nulla. Un miss significa che l''edge non aveva una copia fresca ed è andato a prenderla all''origine – più lento, una volta sola, per il primo visitatore della zona. Il TTL (time to live) è quanto a lungo una copia in cache conta come fresca, impostato con gli header Cache-Control. Progettare una cache è soprattutto l''arte di massimizzare gli hit senza servire contenuto scaduto.'
  - question: 'Un CDN può servire contenuti dinamici?'
    answer: 'Non dalla cache nel senso classico – una risposta API personalizzata cambia da utente a utente. I CDN però accelerano comunque il traffico dinamico con rotte ottimizzate, connessioni persistenti e TLS terminato vicino all''utente; e le piattaforme moderne eseguono logica direttamente all''edge. La divisione pratica: mettere in cache in modo aggressivo gli asset statici, accelerare le risposte dinamiche e calcolare all''edge dove rende.'
  - question: 'Come protegge un CDN dagli attacchi DDoS?'
    answer: 'Essendo enorme e trovandosi sul percorso. Come reverse proxy, il CDN nasconde l''indirizzo dell''origine, e la sua capacità distribuita assorbe gli attacchi volumetrici su molti point of presence – traffico che schiaccerebbe un server singolo si dissipa su una rete globale, con il filtraggio applicato all''edge prima che qualcosa arrivi a destinazione.'
  - question: 'Quando NON serve un CDN?'
    answer: 'Quando il pubblico si trova nella stessa regione del server, un salto in più attraverso un edge lontano può addirittura aggiungere latenza; quando il traffico è così basso che le cache scadono tra un visitatore e l''altro (miss perpetui non servono a nulla); e quando una piccola app dinamica semplicemente non è limitata dalla distribuzione. Un CDN è una leva su distanza e volume – senza nessuna delle due, è configurazione senza beneficio.'
  - question: 'Qual è la differenza tra un CDN e l''edge computing?'
    answer: 'Un CDN avvicina i contenuti agli utenti; l''edge computing avvicina il calcolo. Distribuzione contro decisioni: un CDN risponde a "servire questo file in fretta ovunque", le funzioni edge rispondono a "eseguire questa logica vicino all''utente". In pratica i due convergono – le piattaforme CDN moderne eseguono codice nei loro point of presence – ma il modello mentale tiene.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'CDN — MDN Web Docs Glossary'
    url: 'https://developer.mozilla.org/en-US/docs/Glossary/CDN'
  - name: 'Content delivery network (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Content_delivery_network'
  - name: 'HTTP Cache-Control — MDN Web Docs'
    url: 'https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control'
  - name: 'Back4app file storage documentation'
    url: 'https://www.back4app.com/docs'
cta:
  title: 'File serviti veloci, dal primo giorno'
  text: 'Carica un file su Back4app e l''URL che ricevi è compatibile con i CDN per impostazione predefinita – distribuzione pronta per la cache per immagini, media e download, con database, autenticazione e API già gestiti accanto. Nessun livello di distribuzione da configurare.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-19'
translationKey: 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

| Domanda | Risposta |
| --- | --- |
| Che cos'è | Server edge distribuiti che custodiscono copie in cache dei contenuti |
| Il problema che risolve | La distanza – la latenza cresce con il round trip fino all'origine |
| Il meccanismo | Routing verso l'edge più vicino → un cache hit risponde subito; un miss va a prendere il contenuto all'origine una volta sola |
| Le leve | Header Cache-Control, TTL, purge o nomi di file versionati |
| Che cosa non è | Un hosting web, né edge computing – distribuzione, non archiviazione né logica |

## 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:

```text
# 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:**

```javascript
// 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
// Flutter / Dart — Back4app Flutter SDK
final file = ParseFile(File('hero.webp'));
await file.save();
print(file.url); // CDN-backed, cache-friendly URL
```

**Swift:**

```swift
// 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
  }
}
```

**Kotlin:**

```kotlin
// 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

```mermaid
flowchart LR
  accTitle: Come un CDN serve una richiesta
  accDescr: Un utente viene indirizzato al point of presence più vicino; un cache hit viene servito subito dall'edge, mentre un miss va a prendere la risposta sul server di origine, la mette in cache secondo il suo TTL e poi la serve localmente.
  U["Utente"] --> R["Routing<br/>(PoP più vicino)"]
  R --> E["Server edge"]
  E -->|"cache hit"| U2["Risposta in ms"]
  E -->|"cache miss"| O["Server di origine"]
  O -->|"risposta + TTL"| E
```

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

| Dimensione | Hosting web (origine) | CDN | Edge computing |
| --- | --- | --- | --- |
| Ruolo | Conserva il contenuto di riferimento | Distribuisce copie in cache | Esegue logica vicino agli utenti |
| Risponde a | "Dove vive il sito?" | "Perché è veloce a Tokyo?" | "Si può calcolare a Tokyo?" |
| Stato | Permanente | Temporaneo, legato al TTL | Di solito stateless |
| Senza di esso | Nessun sito | Sito lento, origine esposta | Un round trip a ogni decisione |
| Contenuto tipico | Tutto, una volta sola | Asset statici, media, pagine intere in cache | Personalizzazione, controlli di autenticazione, riscritture |

La [definizione di MDN](https://developer.mozilla.org/en-US/docs/Glossary/CDN) 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

| Un CDN rende quando… | Conviene farne a meno (o rinviarlo) quando… |
| --- | --- |
| Gli utenti sono lontani dall'origine | Il pubblico si trova nella regione del server |
| Asset e media dominano il traffico | L'app è piccola, dinamica e centrata sulle API |
| I picchi di traffico fanno parte del mestiere | Il traffico è troppo basso perché le cache restino calde |
| La banda dell'origine è un costo reale | Il pezzo mobile in più pesa più dei ms risparmiati |
| Serve assorbire i DDoS davanti all'origine | Si finirebbe per mettere in cache risposte personalizzate (impossibile) |

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](https://www.back4app.com/container-as-a-service) 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.