Protocolli e architetture di routing/B8/alt

Da WikiAppunti.
Jump to navigation Jump to search

Motivazioni[modifica | modifica sorgente]

In questo argomento ci si concentra unicamente sulle richieste HTTP. In questo contesto, una richiesta HTTP può essere diretta ad un server remoto potenzialmente in qualunque parte del Globo. Questo pone i seguenti problemi:

  • Il trasporto ha un costo non trascurabile, considerando che solitamente le backbone delle WAN hanno tariffazione a consumo.
  • La latenza, su distanze geografiche non è trascurabile il tempo impiegato dal segnale per spostarsi.
  • Il TCP, che in caso ci siano RTT grandi ha un transitorio di ingresso lungo.
  • I contenuti, difficilmente personalizzabili.
  • La scarsa scalabilità, considerando che un server (es. Youtube) dovrebbe gestire il traffico generato a livello mondiale.

Definizione[modifica | modifica sorgente]

Le content Delivery Networks sono reti logiche per gestire i contenuti su server distinti e geograficamente distribuiti, mantenendo l'allineamento con il server originale, al fine di offrirli all'utente finale. Questo meccanismo deve essere trasparente all'utente e dunque al browser. A questo proposito è particolarmente interessante notare la differenza con meccanismi di web-caching, che invece richiedono esplicita collaborazione con il browser.

DNS-Based CDN[modifica | modifica sorgente]

Le DNS-Based Content Delivery Networks sono CDN basate sulla modifica dell'algoritmo di risoluzione del DNS. A grandi linee, si richiede che il DNS non computi a partire da un nome simbolico un indirizzo IP, ma che il risultato sia prodotto partendo dal nome simbolico e dalla posizione data dall'indirizzo IP sorgente.

Browsing tradizionale[modifica | modifica sorgente]

Il browsing tradizionale, inteso come richiesta-risposta di una pagina HTML su HTTP, può essere delineato con il seguente scenario (a livello applicativo):

  1. Il browser interroga il DNS locale
  2. Il DNS locale interroga il DNS autoritativo del server
  3. Il DNS autoritativo risponde al DNS locale
  4. Il DNS locale fornisce il risultato al browser
  5. Il browser interroga il server chiedendo lo "scheletro" della pagina, senza oggetti all'interno.
  6. Per oggi oggetto contenuto nella pagina, uno scambio del tipo richiesta - risposta avviene con il server.

Browsing con DNS-Based CDN[modifica | modifica sorgente]

Usando la tecnica del DNS-Based CDN, gli step 1-4 rimangono invariati. La differenza inizia dal punto 5, in cui la pagina restituita non contiene i link alle risorse nel server, ma link che direzionano a server dei provider di CDN. Questi link verranno risolti dal browser, e nella risoluzione il DNS autoritativo sarà in possesso del provider di CDN, che restituirà gli IP in base ad algoritmi proprietari basati anche sulla posizione dedotta dall'IP sorgente. Tutti gli oggetti all'interno della pagina verranno quindi richiesti a server esterni e possibilmente locali, non al server principale remoto. Questo meccanismo risolve tutti i problemi esposti in precedenza, ma pone un problema nuovo dato dal contenuto dinamico, che rimane di competenza del server principale per non diffondere gli algoritmi di computazione del server (come ad esempio l'algoritmo di scelta delle pubblicità mirate). Le repliche sui server dislocati dei provider di CDN sono più o meno mantenute allineate in base ad algoritmi proprietari, basati ad esempio sul tipo di contratto, sulla personalizzazione dei contenuti, sul tipo di richieste.

URL-Based CDN[modifica | modifica sorgente]

La tecnica dell'URL-Based CDN è basata sull'infrastruttura dell'operatore, che attraverso una serie di meccanismi simili al NAT ridirige le richieste. Questo espone i contenuti all'operatore, che ha quindi anche la possibilità di cambiarli (i.e. cambiare le pubblicità nelle pagine), ed inoltre è incompatibile con SSL, che non fa passare il payload in chiaro.

Cenni sulle Server Farms[modifica | modifica sorgente]

Definizione[modifica | modifica sorgente]

Insieme di server che lavorano in parallelo e che all'esterno vengono visti come un unico server al quale corrisponde un singolo IP.

Load Balancing[modifica | modifica sorgente]

La gestione dei server richiede un dispositivo che "arbitri" il traffico decidendo a quale server verrà inoltrata ciascuna richiesta. Ci si concentra unicamente sul traffico HTTP.

L4-Switch[modifica | modifica sorgente]

L'L4-Switch, chiamato anche Content unaware switch, limita l'interpretazione del pacchetto al livello 4. Garantisce uno switching rapido e semplice, inoltrando tutti i pacchetti di una stessa sessione TCP al server con cui è in corso la sessione. Questo viene fatto attraverso una hash function o una session table. La prima tecnica è molto semplice e veloce, ma non fornisce alcun reale bilanciamento, la seconda soluzione è più complessa ma può gestire quale server servirà una certa richiesta in base al numero di sessioni che il server sta già gestendo, con i relativi problemi di aging delle entry per mantenere la tabella aggiornata. A prescindere dalla tecnica adottata, questo load balancing è fortemente imperfetto perché non si tiene conto dell'effettiva quantità di traffico scambiata, ma solo del numero di sessioni, che è un indice poco indicativo. Un ulteriore problema sorge dalle sticky connections, ovvero da quel set di iterazioni TCP con il server che mantengono attraverso i cookie una sessione, risultando all'utente come un'unica connessione. Questo caso non è gestito, infatti il load balancer si limita alla singola sessione TCP, ed i cookie sono a livello applicativo.

L7-Load Balancer[modifica | modifica sorgente]

L'L7-Load Balancer o Content aware sceglie dove indirizzare le richieste valutando il pacchetto anche a livello applicativo. Un possibile approccio è distribuire i contenuti tra i server e reindirizzare ciascuna richiesta in base all'URL sul server che detiene il contenuto corrispondente. Un approccio più sofisticato prevede di valutare i cookie, al fine di non richiedere ai server di dover condividere lo stato. Questo approccio è però molto complesso, peggiora il load balancing e riduce l'affidabilità del servizio in quanto un solo server deterrà lo stato. Inoltre il Load Balancer deve diventare terminatore delle sessioni TCP, e trasferire ai server creando un'altra connessione. Questa computazione è piuttosto pesante, ed è facile che il load balancer diventi esso stesso il collo di bottiglia. Un problema comune ad entrambi gli approcci è SSL, sarà infatti il load balancer a detenere le chiavi, e questo risulta scomodo in caso i server siano affittati e ci siano problemi di ruolo su chi debba detenere le chiavi.