Protocolli e architetture di instradamento/Content Delivery Network

Una cache Web è un dispositivo che archivia una copia locale dei contenuti (ad es. risorse HTTP) richiesti più di recente e reagisce come un server proxy alle richieste dei client:

• la cache Web è più vicina all'utente rispetto al server Web:
  • prestazioni: la risposta è più veloce quando la risorsa richiesta si trova già in cache;
  • banda: non vengono caricati costosi link a lunga distanza (ad es. link transoceanici);
• soluzione reattiva: se la risorsa richiesta non si trova in cache, l'utente deve attendere che la cache Web la acquisisca (pull) dal server Web;
• no trasparenza: il browser Web dell'utente deve essere configurato manualmente per contattare quella cache Web.

Una Content Delivery Network (CDN) è una overlay network di cache Web sparse in giro per il mondo ma cooperanti con l'obiettivo di offrire all'utente una migliore quality of experience:

• soluzione proattiva: il server Web copia (push) i contenuti (generalmente i più popolari) sulle cache Web prima che gli utenti li richiedano;
• trasparenza: l'utente si collega alla cache Web automaticamente, senza necessità di configurazione manuale sul suo client;
• prestazioni: l'utente, anche se si sposta, si collega sempre alla cache Web più vicina;
• bilanciamento del carico: l'utente si collega sempre alla cache Web meno carica;
• scalabilità: la distribuzione dei contenuti in più repliche permette un grande numero di richieste che un singolo server Web da solo non riuscirebbe a servire;
• accesso condizionato: è possibile personalizzare i contenuti restituiti in base all'utente (ad es. annunci pubblicitari mirati).

Le CDN sono l'ideale per contenuti che generano grandi quantità di traffico (ad es. risorse multimediali), ma non tutti i contenuti possono essere memorizzati in cache:

• pagine Web dinamiche (ad es. quotazioni di Borsa);
• pagine Web dal contenuto personalizzato (ad es. account utente).

Le CDN possono essere distribuite in vari modi:

• CDN basate sui DNS: il traffico è reindirizzato alla replica migliore in base agli host name:
  • instradamento basato sui DNS: l'hosting provider deve stipulare accordi con i gestori dei server DNS;
  • approccio di Akamai: non è necessario intervenire sui server DNS;
• CDN basate sugli URL: il traffico è reindirizzato alla replica migliore in base agli URL completi:
  • server load balancing: il punto di terminazione della connessione TCP è vicino al server;
  • content routing: il punto di terminazione della connessione TCP è vicino al client.

CDN basate sui DNS

Instradamento basato sui DNS

Navigazione tradizionale.

Navigazione CDN basata sui DNS.

La selezione della replica migliore ha luogo quando l'host name viene tradotto in un indirizzo IP. La risposta DNS a una query non dipende solo dall'host name, ma anche dalla sorgente: uno speciale server DNS calcola, in base a più metriche possibili (RTT, carico dei server, tempo di risposta, ecc.), una tabella di instradamento delle repliche contenente entry del tipo:

{host name, indirizzo IP client} → indirizzo IP replica

Il motore di instradamento nel server DNS "modificato" ha un'interfaccia standard per garantire la trasparenza: l'utente crede che l'indirizzo IP corrispondente all'host name sia l'indirizzo IP del server Web reale, mentre è l'indirizzo IP di una sua replica.

L'aggiunta di un nuovo attore, l'hosting provider, costituisce una nuova opportunità di business nel mondo delle reti:

• access provider: fornisce l'accesso alla rete agli utenti;
• backbone provider: fornisce la connettività a lungo raggio;
• hosting provider: fornisce il servizio di CDN ai content provider;
• content provider: fornisce i contenuti.

Problemi

• metriche: la misurazione delle metriche, soprattutto di quelle dinamiche, non è facile, e le metriche di livello 3 da sole non sono particolarmente significative;
• caching DNS: solo il server autoritativo conosce tutte le repliche e può selezionare la replica migliore in base alla posizione del client → i server DNS intermedi nella gerarchia non possono memorizzare in cache le risposte DNS;
• granularità: la granularità della redirezione è a livello di host name, non di singoli URL → il contenuto di grandi siti Web non può essere suddiviso in più cache, quindi due diverse pagine dello stesso sito Web saranno chieste alla stessa replica.

Approccio di Akamai

La CDN di Akamai sfrutta un algoritmo automatico proprietario per reindirizzare il traffico alle proprie repliche senza intervenire sui server DNS:

1. l'utente digita l'indirizzo di una pagina Web con il suo normale nome di dominio (ad es. http://cnn.com/index.html);
2. il server del content provider (ad es. CNN) restituisce una pagina Web in cui l'indirizzo di ogni risorsa multimediale (ad es. immagine) ha uno speciale nome di dominio corrispondente a una specifica replica su una cache di Akamai (ad es. http://a128.g.akamai.net/7/23/cnn.com/a.gif invece di http://cnn.com/a.gif);
3. il browser Web dell'utente durante il parsing della pagina effettua delle query DNS ai nuovi nomi di dominio e recupera le risorse multimediali dalle repliche più vicine.

CDN basate sugli URL

Server load balancing

SLB content-aware.

I server reali contenenti le repliche sono visti dai client come un unico server virtuale con lo stesso indirizzo IP.

Il carico di traffico destinato al server virtuale è bilanciato tra i diversi server reali da un Server Load Balancer (SLB):

• commutazione a livello 4: le connessioni TCP non sono terminate dal SLB (content-unaware):
  • uno dei server reali risponde al three-way handshake con il client;
  • tutte le query HTTP appartenenti alla stessa sessione TCP devono essere servite sempre dallo stesso server reale;
  • il bilanciamento del carico può essere basato sull'indirizzo IP sorgente, sulla porta TCP sorgente, ecc.;
• commutazione a livello 7: le connessioni TCP sono terminate dal SLB (content-aware), che agisce come un proxy:
  • il SLB risponde al three-way handshake con il client, per poter intercettare gli URL richiesti successivamente;
  • ogni query HTTP può essere servita dal server reale correntemente meno carico, in base alle decisioni del SLB;
  • il bilanciamento del carico è basato sull'URL completo.

Problemi

• connessioni cifrate (HTTPS): il SLB deve avere la chiave crittografica SSL privata del server, e deve sopportare il carico di elaborazione per criptare/decriptare i pacchetti in transito;
• connessioni sticky: alcune applicazioni richiedono che le connessioni TCP dallo stesso client siano reindirizzate allo stesso server (ad es. carrello della spesa) → occorre considerare anche i cookie;
• distribuzione geografica: tutte le repliche sono vicine tra loro e al SLB, che è lontano dal client.

Content routing

I content router sono dei router che instradano il traffico in base all'URL verso la replica migliore:

• TCP: i content router in sequenza terminino tutti delle connessioni TCP tra uno e l'altro → vengono introdotti troppo ritardi;
• content delivery control protocol: l'URL è estratto dal primo content router, ed è propagato da un protocollo specifico.

Problemi

• stateful: il primo content router deve terminare la connessione TCP per poter intercettare l'URL che l'utente richiederà;
• complessità degli apparati: il parsing dei pacchetti per recuperare l'URL è complicato → gli switch di livello 7 sono apparati complicati e costosi;
• complessità dei protocolli: i content delivery control protocol proposti sono veramente complicati;
• riservatezza: i content router leggono tutti gli URL richiesti dagli utenti.