Protocolli e architetture di instradamento/Content Delivery Network

Wikibooks, manuali e libri di testo liberi.
Indice del libro

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[1] di cache Web sparse in giro per il mondo ma cooperanti con l'obiettivo di offrire all'utente una migliore quality of experience[2]:

  • 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:
  • CDN basate sugli URL: il traffico è reindirizzato alla replica migliore in base agli URL completi:

CDN basate sui DNS[modifica]

Instradamento basato sui DNS[modifica]

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[modifica]

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[modifica]

Server load balancing[modifica]

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[modifica]

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.

Note[modifica]

  1. Una overlay network è una rete di calcolatori che è costruita al di sopra di un'altra rete.
  2. La quality of experience è una misura delle esperienze di un utente con un servizio (ad es. navigazione Web).