Web caching e Web replication

Transcript

1 Politecnico di Milano Dip. Elettronica e Informazione Milano, Italy Introduzione La diffusione dell'accesso ad Internet e della banda larga porta ad un incremento generale del traffico Web caching e Web replication Giuliano Casale casale@elet.polimi.it 17/5/2004 Corso di Impianti Informatici prof. G. Serazzi A.A. 2003/2004 Aumentano le esigenze degli utenti: Download di un gran numero di oggetti Web: pagine HTML, pagine dinamiche, immagini, applet Java, oggetti Flash, filmati, suoni, file compressi, Maggiore disponibilità verso download di file di grandi dimensioni Maggior numero di pagine visitate Video streaming, file-sharing, giochi multiplayer, G.Casale - Web Caching e Web Replication 2 Introduzione (2) Web caching e Web replication Una possibile analogia Come affrontare l aumento del carico? Potenziare banda e memoria dei server Duplicare in modo intelligente le informazioni nella rete Conserva nel tempo le prestazioni (Web scalability) Web caching Sfrutta la ripetitività degli accessi agli oggetti Web I dati sono copiati sul client o su server dedicati Web prefetching Si tenta di anticipare la prossima richiesta dell utente Web replication Gli oggetti originali sono replicati su più server La duplicazione è controllata da chi gestisce il sito Content provider Oggetto Browser Download Replication Download Caching G.Casale - Web Caching e Web Replication 3 G.Casale - Web Caching e Web Replication 4

2 Browser cache L'utente A vuole scaricare un file da un sito Il browser controlla se l'oggetto è già stato scaricato e salvato su disco o in RAM (browser cache) Se non è possibile reperirlo (cache miss), l'oggetto viene scaricato e salvato nella browser cache Se l'oggetto è presente si hanno due casi: il browser rileva che è necessario un aggiornamento e scarica nuovamente l'oggetto la copia cacheata va bene e viene visualizzata correttamente senza alcun download (cache hit) Web caching proxies I proxy ospitano una cache condivisa da un ampio numero di utenti Un client può ottenere una cache hit su una pagina che non ha mai visitato, ma che è già stata vista da un altro utente del proxy Richieste Utente 1 A B C D A B C D Tempo Richieste Utente 2 Tempo L utente 2 scarica solo dal proxy G.Casale - Web Caching e Web Replication 5 G.Casale - Web Caching e Web Replication 6 Configurazione di base Per permettere un accesso efficiente, il proxy è spesso un server dedicato Rete aziendale con un unico proxy Internet Nella configurazione più semplice il proxy intercetta tutte le richieste uscenti dalla rete aziendale Soluzione poco realistica per reti geografiche di grandi dimensioni o per reti ad elevato traffico Oggetti scaricati di recente da A e B Proxy Cache miss In realtà esistono diversi proxy che possono servire la richiesta nel cammino end-to-end Ciò rende difficile stimare a priori il reale miglioramento di prestazioni! Cache hit Internal Network Browser A Browser B G.Casale - Web Caching e Web Replication 7 G.Casale - Web Caching e Web Replication 8

3 Proxy multipli sul cammino end-to-end Web replication Internet Soluzione server-side per garantire la Web scalability Tre principali tipologie di Web replication: Internet Service Provider Oggetti scaricati di recente da A, B, C, D Mirroring esplicito ISP Proxy Mirroring statico trasparente Replicazione dinamica trasparente ENTERPRISE NETWORK 1 ENTERPRISE NETWORK 2 Oggetti scaricati di recente da A e B Proxy Oggetti scaricati di recente da C e D Proxy Ciascuna tipologia fornisce un diverso trade-off tra flessibilità, complessità e costo Internal Network Internal Network A B C D G.Casale - Web Caching e Web Replication 9 G.Casale - Web Caching e Web Replication 10 Web replication Mirroring esplicito Esempio di mirroring La più semplice forma di replication,largamente usata, èilmirroring esplicito Il sito è interamente duplicato su altri server Esempi: Tucows, GNU, Sourceforge, Linux, Tuttavia questa soluzione presenta diversi svantaggi Gli utenti devono scegliere esplicitamente quale mirror usare Il bilanciamento del carico non è dunque controllabile a priori La decisionedi rimuovereun mirror èdifficile perchè può creare notevoli disagi agli utenti G.Casale - Web Caching e Web Replication 11 G.Casale - Web Caching e Web Replication 12

4 Web replication Mirroring statico trasparente Mirroring statico trasparente Le richieste sono automaticamente redirezionate ai mirror senza l intervento dell utente Soluzione adatta se il sito Web non rappresenta il core business aziendale In caso contrario diventano critici il capacity planning e le scelte di allocazione delle risorse ai mirror es. Hosting provider (Aruba, Register.it,...) Web replication Replicazione dinamica trasparente Replicazione dinamica trasparente La politica di allocazione delle risorse ai mirror è gestita in automatico da un software dedicato Esempio: un hosting provider può fare in modo che un sito per cui è imminente un picco di carico sia replicato temporaneamente su un maggior numero di mirror E la tecnologia alla base di architetture più complesse quali reverse proxies e content delivery networks G.Casale - Web Caching e Web Replication 13 G.Casale - Web Caching e Web Replication 14 Politecnico di Milano Dip. Elettronica e Informazione Milano, Italy Vantaggi del Web caching Web caching Per l'utente finale: migliorano i tempi di download degli oggetti Web Per le aziende: minor traffico in uscita: risparmio sui contratti a consumo e diminuzione del carico dei router Per gli ISP: riduzione del traffico scambiato verso altri ISP e minori costi se questo è soggetto a contratti di peering minor carico per i router BGP di frontiera (molto carichi) Per i server Web: diminuisce il traffico in ingresso migliore scalabilità delle architetture G.Casale - Web Caching e Web Replication 16

5 Svantaggi del caching Architettura di un ISP (1) Il content provider non può più garantire che l'utente veda la versione più aggiornata di un pagina E' possibile che materiale soggetto a copyright o riservato venga archiviato su proxy esterni Modem Modem Upstream ISP Il caching non è una soluzione definitiva perché il 40% degli oggetti non è cacheabile per diversi motivi: pagine dinamiche presenza di cookie nella richieste HTTP il Web server richiede esplicitamente la non cacheabilità direttive HTTP cache-control e no-cache Clienti business (aziende, ISP) Dial-up Concentrator Network Clienti business (aziende, ISP) Peer ISP G.Casale - Web Caching e Web Replication 17 G.Casale - Web Caching e Web Replication 18 Architettura di un ISP (2) Esempi tipici di collegamenti tra rete aziendale e ISP L'Internet Service Provider (ISP) fornisce servizi di connettività attraverso una propria dorsale di rete (ISP backbone network) Il collegamento di clienti business avviene attraverso macchine dedicate, gli access routers () Gli utenti modem e DSL condividono la banda di un dial-up concentrator In entrambi i casi l'instradamento delle richieste all'interno della backbone network è effettuato dai backbone routers () Il collegamento ISP-resto del mondo è gestito dai router di frontiera (gateway routers - ) G.Casale - Web Caching e Web Replication 19 ISP singolo collegamenti singoli Network Network G.Casale - Web Caching e Web Replication 20 Network Network ISP singolo collegamenti multipli ISP multipli collegamenti multipli

6 Intercettazione delle richieste Collegamenti multipli ad Internet permettono di mantenere la connettività anche in presenza di guasti In alcuni casi sono usati anche per bilanciare il traffico uscente Politiche di collocazione del proxy Collocazione non trasparente: i browser vengono configurati per usare il proxy + Semplicità - Onere di configurazione dei browser - Difficile da realizzare per un ISP Collegamenti multipli rendono difficile l'intercettazione delle richieste da parte del proxy aziendale La situazione è ancora più complicata per gli ISP che possiedono decine di punti di ingresso e uscita dalla loro rete G.Casale - Web Caching e Web Replication 21 Collocazione trasparente: l'esistenza del proxy è mascherata al browser + Efficacia - Configurazione complessa - Può richiedere hardware dedicato G.Casale - Web Caching e Web Replication 22 Tipologie di deployment Collocazione non trasparente Configurazione esplicita Non trasparente Politica di deployment Browser Autoconfiguration Router Trasparente Switch L4 Configurazione esplicita dei browser + Il proxy può essere collocato dovunque - L'utente può evitare il proxy riconfigurando il browser - Scarsa tolleranza ai guasti Browser Autoconfiguration Il browser scarica all'avvio un file PAC (proxy autoconfiguration file) con le informazioni sul proxy L amministratore di rete può escludere l'uso dei proxy + Tolleranza ai guasti + Flessibilità nella gestione delle politiche di caching Proxy Autodiscovery Switch L7 Intercepting Link Proxy Autodiscovery + La posizione del file PAC è indicata dal DNS - E' ferma allo stadio di proposta di standard da diversi anni G.Casale - Web Caching e Web Replication 23 G.Casale - Web Caching e Web Replication 24

7 Collocazione trasparente Router e interception proxy Router il router di frontiera redireziona il traffico uscente verso il proxy (interception proxy) usando l IP-in-IP encapsulation Interception proxy Browser A Server Web Connection hijacking: l interception proxy si identifica fingendosi il Web server remoto + Tolleranza ai guasti e possibilità di escludere il proxy + Nessuna configurazione software necessaria - Si viola il principio end-to-end 1 Multipath problem Network Cache hit Internet ISP Proxy 1) Principio end-to-end : an application can completely and correctely be implemented only with the knowledge and help of the application standing at the end points of the communication system (Saltzer, 1984) TCP/HTTP G.Casale - Web Caching e Web Replication 25 G.Casale - Web Caching e Web Replication 26 Interception proxy (2) Multipath problem Server Web ISP 2 SECONDA RICHIESTA A Browser A Internet Internet Browser A Internet Server Web Network Cache miss TCP/HTTP ISP Proxy G ISP 1 R PRIMA RICHIESTA A HTTP Cache hit TCP/ HTTP ISP Proxy G.Casale - Web Caching e Web Replication 27 G.Casale - Web Caching e Web Replication 28

8 Collocazione trasparente Soluzionialmultipathproblem Collocazione trasparente Soluzioni al multipath problem (2) Switch L4 (layer four) E' uno switch che legge gli header TCP e li smista verso l'isp corretto Può essere connesso ad una batteria di proxy come load balancer Switch L7 (layer seven) Può interpretare direttamente le richieste HTTP Non redireziona le richieste a oggetti non cacheabili Puo separare i proxy in base al contenuto cacheato (HTML, immagini, video,...) G.Casale - Web Caching e Web Replication 29 Intercepting link La stessa macchina è al contempo uno switch L7 e un proxy Soluzione economica efficiente perchè come gli altri switch non usa l IP-in-IP encapsulation Rispetto agli altri switch, è un approccio plug n play al Web caching (autoconfigurazione) Utente 1 Utente 2 switch proxy G.Casale - Web Caching e Web Replication 30 Proxy Caching: aspettative realistiche Shared hits La percentuale sulle richieste di cache hit dovuti all attivita degli altri utenti (shared hits) giustifica l uso di proxy Generalmente compreso tra il 45% e il 50% Il valore usato per le analisi è per prudenza del 45% Alcuni studi riportano valori prossimi all 85% Il byte hit rate per gli shared hit è attorno al 50% MISS HIT Richieste Utente 1 Richieste Utente 2 Richieste Utente 3 A B C D A B C D A B C D Riduzione del 66% Tempo Tempo Tempo G.Casale - Web Caching e Web Replication 31 Proxy Caching: aspettative realistiche Riduzione della latenza: caso ottimo Trascurando l overhead del proxy, il tempo di download può essere scomposto in due componenti: CLIENT internal latency PROXY external latency SERVER WEB L external latency impatta per il 77-88% del totale Assumendo un shared hit rate del 45%, il guadagno di banda massimo è del 45 % x 88% = 40% Purtroppo un analisi di questo tipo è scorretta perchè non tiene conto delle dimensioni dei file il guadagno è nel caso ottimo attorno al 22-26% i proxy riducono i trasferimenti (già brevi) di file piccoli G.Casale - Web Caching e Web Replication 32

9 Proxy Caching: aspettative realistiche Riduzione della latenza: caso pessimo Rimuoviamo alcune ipotesi semplificative E necessaria una fase di connessione tra proxy e server Web in caso di cache miss Il proxy introduce un suo overhead di gestione del TCP Il guadagno nel caso pessimo èsoltantodel 3%! In realtà questa stima è eccessivamente severa perchè non tiene conto della congestioni di rete che ostacolano i download senza proxy ALLA LUCE DI QUESTI DATI IL WEB CACHING CONVIENE DAVVERO? Altri vantaggi del Web caching TCP connection caching Il proxy permette anche il caching delle connessioni UTENTE 1 UTENTE 2 GET X GET Z GET Y PROXY GET Z GET X GET Y SERVER A SERVER B Vengono mantenute attive le connessioni aperte per i cache miss risparmiando agli utenti i tempi di connessione lo stesso canale non puòperòessereusato simultaneamente da più client (HTTP pipelining) La pipeline viene servita in ordine FIFO e gli utenti dovrebbero aspettarsi fra loro (head of line blocking) G.Casale - Web Caching e Web Replication 33 G.Casale - Web Caching e Web Replication 34 TCP Connection Caching Guadagno nel caso pessimo Altri vantaggi del Web caching TCP connection splitting Latenza Riduzione media Riduzione mediana Il RTT può limitare notevolmente il throughput del TCP Dipende dalle dimensioni della finestra Web Connection caching 21% 40% Web Connection caching + Web Data caching Ethernet Connection caching Ethernet Data caching 24% 2% 47% 48% 20% 40% IL CONNECTION CACHING RENDE CONVENIENTE IL WEB CACHING ANCHE NEL CASO PESSIMO! Il proxy spezza il viaggio dei pacchetti su due RTT più piccoli: L incremento massimo del throughput è di tre volte, quello reale è circa del doppio Il vantaggio maggiore è per gli oggetti di grandi dimensioni G.Casale - Web Caching e Web Replication 35 G.Casale - Web Caching e Web Replication 36

10 Altri vantaggi del Web caching Riduzione del traffico di rete La riduzione di utilizzo della rete consentita dai proxy è stimata al 25% Tuttavia senza alcune cautele il traffico può aumentare: In presenza di abort del client dopo un cache miss i proxy devono cessare immediatamente il download dell oggetto Studi in letteratura mostrano che continuare a scaricare l oggetto per salvarlo in cache è una politica sbagliata Si può mantenere sul proxy la porzione di oggetto scaricato usando all occorrenza una HTTP partial GET per concludere il download Dimensionare il proxy Attraverso i file di log si vanno ad esaminare dimensioni, tempi di download, popolarità e altre proprietà degli oggetti scaricati dai proxy Dimensioni dei files Popolarità degli oggetti Web Legge di Zipf Livelli di localita temporale Stack distance Altre metriche Informazioni utili per il dimensionamento dei proxy, per la replicazione dei dati di un sito Web e per la valutazione analitica dell utilità del proxy G.Casale - Web Caching e Web Replication 37 G.Casale - Web Caching e Web Replication 38 Dimensioni dei files Popolarita degli oggetti Statistica/Tipo Numero di oggetti Media μ (kb) Tutti i tipi HTML Immagini ZIP/R/ Il 90% dei downloads è diretto a immagini e pagine HTML Mediamente ogni pagina HTML contiene 10 immagini Le immagini sono gli oggetti più popolari di un sito Mediana Me (kb) Distribuzione fortemente asimmetrica Spesso oltre il 75% degli oggetti ha dimensioni minori della media Numero non trascurabile di oggetti di grandi dimensioni Requisiti contrastanti per caching e replicazione: Duplicare oggetti piccoli migliora l hit rate 38.1 La diminuzione del tempo di download (latenza) e maggiore per i file di grandi dimensioni Si accetta un compromesso rinunciando a massimizzare l hit rate in favore del miglioramente complessivo della latenza media 4.4 Statistiche sul numero di oggetti Web del sito della FIFA World cup Fonte: [1] Non possiamo considerare indipendenti gli accessi ai diversi oggetti La relazione tra le popolarità segue la legge di Zipf Legge di Zipf: la popolarità dell i-esimo oggetto più popolare è proporzionale a 1/i α, con α>0 Es. per α=1 l oggetto Web più popolare è scaricato il doppio r ispetto al secondo più popolare, il triplo rispetto al terzo, ecc Permette di condurre studi sulle performance asintotiche (i.e. a regime) del Web caching G.Casale - Web Caching e Web Replication 39 G.Casale - Web Caching e Web Replication 40

11 Legge di Zipf Localita Temporale Stack Distance (SD) Log 10 (Popolarita ) Log 10 (i - Posizione in classifica) E possibile stimare α usando un grafico in scala logaritmica: Popolarita ~ 1/i α <=> log 10 (Popolarita ) ~ - α log 10 (i) E -α è il coefficiente angolare della retta che meglio approssima la distribuzione rappresentata in scala log-log G.Casale - Web Caching e Web Replication 41 Fornisce un idea dell hit rate previsto per il proxy La principale metrica e la stack distance (SD) Si simula un replay del flusso di richieste nei file di log e si misura il numero di richieste che intercorrono tra due acessi alla stessa pagina I numeri ottenuti vengono poi trattati come una distribuzione statistica P4 P3 P3 P4 t 0 = 0 P1 P2 t 4 = 25s P3 P2 t 1 = 10s P2 t 2 = 15s P3 P1 P1 t 3 = 23s P4 Stack t<0 SD=0 SD=2 G.Casale - Web Caching e Web Replication 42 Localita Temporale Esempio di SD Localita Temporale Esempio di SD Probabilita Probabilita Cumulativa Stack distance - SD G.Casale - Web Caching e Web Replication 43 Stack distance - SD G.Casale - Web Caching e Web Replication 44

12 Localita Temporale Esempio di SD Localita Spaziale (SL) Non è chiaro come si possa definire la località spaziale degli oggetti Web Nel caching tradizione la distanza è tra celle di memoria Probabilita Cumulativa Con un buffer di 50 oggetti riesco a gestire il 90% delle richieste Stack distance - SD G.Casale - Web Caching e Web Replication 45 Solitamente si usa: Numero di path diversi presenti nei file di log SL= Numero di path possibili Il denominatore è dato da una permutazione elevatissima La SL è dominata dal denominatore Molto permutazioni non sono path effettivamente percorribili Questi problemi spiegano perchè la SL è poco usata G.Casale - Web Caching e Web Replication 46 Altre metriche Tasso di aggiornamento degli oggetti (change ratio) alcuni studi indicano che il 15% delle richieste è diretto a pagine modificate dopo l ultima visita dell utente Numero di richieste abortite Nel calcolo delle prestazioni dei proxy si deve tenere in conto che un numero tra il 5% e il10% delle richieste è abortito G.Casale - Web Caching e Web Replication 47 Altre informazioni utili sui proxy I meccanismi di consistenza della cache si basano sul pipelining HTTP La validazione asincrona è il miglior trade-off costi-prestazioni Piggybacking 1. un utente chiede una pagina che genera un cache miss 2. Il proxy inoltra la richiesta verso il server 3. un thread sul proxy aggancia in coda alla richiesta un treno di richieste di validazione degli oggetti in cache già scaricati da quel server soltanto se ne vale la pena un oggetto modificato è scaricato subito la richiesta di validazione è pertanto eseguita con il metodo HEAD di HTTP Le politiche di replacement in cache sono di scarsa importanza in ambito Web La scelta tra LRU, LFU, non apporta miglioramenti sensibili alle performance del proxy G.Casale - Web Caching e Web Replication 48

13 Bibliografia e link interessanti 1. M. Arlitt, T. Jin - Workload Characterization of the 1998 World Cup Web Site- HP TR M. Rabinovich, O. Spatscheck Web Caching e Web Repli cation - Addison Wesley / ?v=glance 3. NLANR: 4. SQUID: G.Casale - Web Caching e Web Replication 49