Caratteristiche e Differenza tra Web Replication e Web Caching

Web Replication

La tecnologia di Web Replication implica la replicazione di dati e servizi su server dislocati in differenti aree geografiche. In questo paragrafo descriviamo brevemente i principi che ispirano le tecniche utilizzate per il collegamento dinamico di un utente alla replica “più conveniente”, cioè le tecniche e le politiche di distribuzione che possono essere utilizzate nel bilanciamento del carico. In letteratura si differenziano tra strategie di distribuzione Mirror-based, che indirizzano il browser verso la replica geograficamente più vicina, tecniche DNS-based che, nella configurazione più semplice, distribuiscono il carico utilizzando una politica round robin (basata su una rigida rotazione degli indirizzi IP) e tecniche più sofisticate QoS-based (basate sulla Qualità del Servizio), che mirano ad ottimizzare l’URT (User Response Time), il tempo di risposta per l’utente, inteso come l’intervallo temporale che intercorre tra l’istante in cui l’utente effettua una richiesta e il rendering completo della pagina da parte del browser.

Le strategie di distribuzione del carico, sono classificabili in statiche e dinamiche. Le tecniche statiche, solitamente, si basano su algoritmi deterministici o stocastici, utilizzando informazioni riguardanti il carico medio dei sistemi, piuttosto che quello corrente (current workload). Per questo, anche se la loro implementazione risulta di limitata complessità, spesso possono condurre a prestazioni non soddisfacenti. Le tecniche adattive implementano il bilanciamento del carico, reagendo dinamicamente ai cambiamenti dello stato del sistema. In generale, queste tecniche sono intrinsecamente più complesse di quelle statiche, poiché necessitano di mantenere informazioni a run-time, in modo da rispondere a possibili cambiamenti dello stato, ma sono sicuramente più efficaci. La distribuzione adattiva del carico dei server web, comunque, non è facile da ottenere, poiché la sua implementazione richiede un binding (collegamento) dinamico dei browser verso i server web. Il binding dinamico verso la replica “più conveniente” diviene difficile, a causa della tendenza ad utilizzare schemi di naming basati su locazione. Poiché le URL contengono l’hostname del server e la locazione della risorsa su uno specifico server, c’è un mapping intrinseco tra l’istanza di una risorsa e la sua locazione. Questo rende difficile la distribuzione del carico tra un certo numero di macchine, senza aumentare la “smartness” del software dal lato client. Da queste problematiche è, anche, nata l’esigenza di definire le URN.

In particolare, poiché i client accedono alle risorse specificando direttamente l’hostname del server, le tecniche che regolano il collegamento dinamico di un client ad un insieme di server (senza un qualsiasi aumento del traffico di messaggi in rete) devono gestire il binding dell’indirizzo IP corrispondente al nome di host e/o il routing del messaggio.
Per abilitare un certo numero di macchine a condividere indirizzi IP sono state sviluppate diverse soluzioni. Per esempio, per aumentare progressivamente la potenza di calcolo su un dato sito, l’implementazione di un servizio web può essere basata su un cluster di macchine cooperanti localmente distribuite, accedute tramite un singolo indirizzo IP, utilizzando una tecnica chiamata NAT (Network Address Translation).

In letteratura si descrivono una efficiente strategia per repliche residenti su cluster. Infatti, la distribuzione di carico avviene sulla base di due parametri: la dimensione del working set e l’access rate del sito. Questo tipo di strategia può essere implementata utilizzando la feature Dynamic Update (descritta nell’RFC 2136 e presente nelle ultime versioni di BIND) permette ad agenti autorizzati di aggiornare zone inviando speciali messaggi di update per aggiungere o cancellare record, senza dover riavviare il DNS server. È ovvio che una replicazione di contenuti a livello locale offre meno benefici rispetto ad una distribuzione di repliche a livello geografico.

Un approccio alternativo per la distribuzione del carico è fare uso della funzionalità di redirezione (redirect) del protocollo HTTP, che redirige le richieste dei client in arrivo verso un server, facente parte di un insieme di repliche. I client fanno una connessione iniziale al server principale (a cui punta la URL) ed esso risponde con un codice HTTP 302 (found: la risorsa richiesta risiede temporaneamente sotto una differente URL), indicando il server a cui fare riferimento. Quindi, il client invia la richiesta corrente (e le successive) al server specificato. Questo meccanismo ha, comunque, lo svantaggio di rendere visibili le URL di tutti i server disponibili, che potrebbero essere memorizzate in hot-list o indicizzate da motori di ricerca, rendendo quindi inefficiente il bilanciamento del carico.

Web Caching

Quando un browser richiede una pagina web, effettua una connessione HTTP verso l’origin server su cui risiede la risorsa.
L’idea alla base del funzionamento di un cache server è una estensione del concetto di “cache locale” utilizzato dai browser web oggi più diffusi, come Netscape Navigator e MS Internet Explorer. Il principio è semplice: quando viene richiesta una pagina web, essa è salvata su disco, in una cache locale. Se viene richiesta di nuovo, il browser, anziché inoltrare la richiesta al server, carica la copia precedentemente salvata su disco. Nei file di configurazione di un browser è possibile condizionare il comportamento del browser perché vada, ad esempio, a controllare la validità degli oggetti presenti nella cache, con quelli presenti in rete, ad ogni sessione oppure ad ogni richiesta o mai.

Spostando questo concetto a livello di rete locale, un cache server è un sistema attraverso cui passano le richieste HTTP generate dai client presenti nella rete locale. Le richieste originate dagli utenti e indirizzate al server web (porta 80) sono trasmesse al cache server, che verifica la disponibilità dell’oggetto, all’interno della propria cache memory o dei dischi (cache disk), e, se questo è presente, lo fornisce al client che lo aveva richiesto. In caso di richiesta relativa ad un oggetto non presente nella cache, il cache server provvede a contattare il sito web originario definito nella URI e a recuperare l’oggetto restituendolo al client, conservandone però una copia, in modo da poter soddisfare direttamente eventuali richieste future dello stesso oggetto. In questo modo, questa tecnica riduce l’utilizzo della banda e diminuisce la latenza nel servire le richieste. Come nel caso della web replication un altro vantaggio indiretto è che i server web con contenuti molto popolari vengono alleggeriti nel carico di richieste ricevute.

Infine, esiste però un problema di consistenza e validità degli oggetti serviti da cache. Per controllare dunque la consistenza degli oggetti, sono impiegati meccanismi di scadenza o di validazione dei dati, resi disponibili dal protocollo HTTP.