Daniela M. Prencipe
Matr. 3036718
Daniela M. Prencipe
Sommario
• Il Web caching;
• Il Caching cooperativo;
• Le varie architetture del caching cooperativo;
• Il protocollo ICP;
• La rete Garr-G;
• Configurazione del squid cache
server nella rete Garr.
Daniela M. Prencipe
WEB CACHING
• Il Web caching è una tecnica che può ridurre il ritardo nella ricerca dei documenti e diminuire la quantità di traffico
Web inviato su Internet.
• La cache nel Web è un’entità della rete,
detta anche proxy server che soddisfa le
richieste HTTP da parte di un client.
Daniela M. Prencipe
IL PROXY SERVER(1)
• Il proxy server ha un proprio disco
di archiviazione e conserva nella
sua memoria copie degli oggetti richiesti di recente.
• Gli utenti configurano i loro browser in modo tale che tutte le richieste HTTP siano dirette ai proxy
server.
Daniela M. Prencipe
IL PROXY SERVER (2)
• Quando un browser invia una richiesta
HTTP per un oggetto, il proxy server controlla se ha una copia dell'oggetto memorizzata. Se si invia un GET condizionato
all'URL dell'oggetto richiesto, altrimenti invia un GET semplice.
• Quindi il proxy server riceve, o mantiene, l'oggetto nella propria cache e invia
un messaggio di risposta HTTP al browser
con, in allegato, l'oggetto richiesto.
Daniela M. Prencipe
I VANTAGGGI
CON I PROXY SERVER (1)
I proxy server stanno avendo un grande successo in
Internet per almeno tre motivi:
1) Un proxy server può ridurre sostanzialmente
il tempo di risposta di una richiesta da
parte di un client. Se c'e una connessione
ad alta velocità fra il client e il proxy
server, come spesso succede, e se la cache
contiene gli oggetti richiesti, allora esso
e in grado di inviare rapidamente al client
gli oggetti richiesti.
2) I proxy server possono ridurre in modo drastico il traffico su un link di accesso di
un'organizzazione. Inoltre, possono ridurre
in modo consistente anche il traffico dell'intero Internet, migliorando quindi le
performance di tutte le applicazioni Internet.
Daniela M. Prencipe
I VANTAGGGI
CON I PROXY SERVER (2)
3) Un Internet fitto di proxy server fornisce
un'infrastruttura ideale per la rapida distribuzione di contenuti, anche per le informazioni disponibili su siti che funzionano su server lenti o con link di accesso a
bassa velocità. Se questi provider “poveri
di risorse" hanno contenuti di interesse generale, questi saranno copiati velocemente
nelle cache dei proxy server e l'alta richiesta degli utenti potrà essere soddisfatta.
Daniela M. Prencipe
IL CACHING COOPERATIVO
• I proxy server multipli, situati in locazioni
diverse su Internet, possono cooperare e migliorare le performance generali e possono
trarre beneficio dalla condivisione degli oggetti contenuti nella propria cache così come
un gruppo di client (browser). Il loro effetto positivo è amplificato dall'architettura
distribuita.
• Le cache gerarchiche sono un'estensione logica del concetto di cache, utilizzano i protocolli di intercache. Questo tipo di protocolli fornisce delle informazioni che possono
essere utilizzate da un apparato di webcache
per ridurre il tempo di ricerca di un oggetto.
Daniela M. Prencipe
VANTAGGI DEL CACHING
COOPERATIVO(1)
Un’efficiente cache nel client o nel proxy ha
dei significativi vantaggi:
1) riduce la latenza percepita dall'utente;
2) riduce il carico del Web server;
3) diminuisce il numero di pacchetti che transitano nella rete e quindi aumenta la banda
disponibile;
4) aumenta l'affidabilità perché gli oggetti
possono essere recuperati anche quando i
server d'origine non sono raggiungibili;
5) il minor costo, poiché si può utilizzare una
struttura distribuita più economica;
Daniela M. Prencipe
VANTAGGI DEL CACHING
COOPERATIVO(2)
6) un maggior numero di cache hits: in generale, ci si può aspettare che almeno il 10%
delle richieste ricevute da una cache si
traducano in cache hit (risposte positive)
in quelle adiacenti;
7) routing delle richieste: eseguendo un routing verso una certa cache adiacente, é possibile instradare il traffico HTTP su un determinato percorso. Per esempio, avendo due
link di connessione con la rete internet, é
possibile instradare il traffico HTTP su uno
dei due, lasciando il secondo collegamento a
disposizione per tutti gli altri utilizzi.
Daniela M. Prencipe
SVANTAGGI DEL CACHING
COOPERATIVO
Alcuni possibili svantaggi possono essere:
•
•
maggiore complessità della configurazione:
per ogni singola relazione di "parentela" é necessario coordinare gli interventi di configurazione di entrambi i nodi coinvolti ed al crescere del numero delle cache componenti la gerarchia, l'attività di configurazione tende a
divenire più impegnativa;
maggiore ritardo nella risoluzione di un cache
miss (risposta negativa):
il fatto che l'utilizzo od il mancato utilizzo
di una cache adiacente si traduca in un aumento
della velocità percepita dall'utente finale può
dipendere da svariati fattori: il ritardo tra i
nodi, la congestione dei link, l'utilizzo o il
mancato utilizzo di protocolli di comunicazione
intercache ed altro ancora.
Daniela M. Prencipe
ARCHITETTURA DEL
CACHING COOPERATIVO
Alcune soluzioni proposte:
• Architetture gerarchiche
• Architetture distribuite
• Architetture ibride
Daniela M. Prencipe
ESEMPIO (1)
di architettura gerarchica
Cache nazionale
HTTP
Memorizza
Nessuna copia
copia
dell’oggetto
Server di origine
Cache regionale
Nella risposta HTTP
viene inserita copia
dell’oggetto
Memorizza
Nessuna copia
copia
dell’oggetto
dell’oggetto
Cache dell’istituzione
Nessuna copia
Memorizza
copia
dell’oggetto
dell’oggetto
HTTP
ESEMPIO (2)
di architettura gerarchica
Cache dell’istituzione
HTTP
Contiene copia
dell’oggetto
HTTP
Richiesta copia
dello stesso
oggetto
ARCHITETTURA GERARCHICA
• Elevato tempo di latenza in caso di hit al livello più
alto.
• Non si utilizzano possibili hit sui cache server dello
stesso livello (sibling).
• I cache server di più alto livello possono diventare colli
di bottiglia.
Daniela M. Prencipe
SVANTAGGI DELLA
ARCHITETTURA GERARCHICA
• I server proxy della gerarchia devono
essere posizionati in punti strategici
della rete;
• Ogni livello della gerarchia può introdurre un ritardo aggiuntivo;
• Copie multiple della stessa risorsa
sono presenti in diversi livelli della
cache.
Daniela M. Prencipe
ARCHITETTURA
DISTRIBUITA
• Esiste un unico livello di server proxy;
• Ogni
server
proxy
mantiene delle metainformazioni sul contenuto
delle
cache
degli
altri
server
proxy.
• Tutte le cache sono
sorelle.
1
1
Daniela M. Prencipe
1
1
QUERY COOPERATION
• Quando viene inviata una richiesta ad un
proxy, se non ha l’oggetto nella sua cache,
lo chiede ai proxy dello stesso livello
(quelle cache sorelle) ;
• Non si appesantisce la rete con continui
scambi di informazioni fra le cache cooperanti.
Daniela M. Prencipe
VANTAGGI E SVANTAGGI DELLA
ARCHITETTURA DISTRIBUITA
• Vantaggi della architettura distribuita:
− gran parte del traffico è limitato ai livelli
locali della rete;
− permette una migliore condivisione del carico
ed una migliore tolleranza ai guasti;
• Svantaggi della architettura distribuita:
− numerosi problemi per sviluppare il caching distribuito su una vasta area geografica (elevati
tempi di connessione, maggiore uso della larghezza di banda, questioni amministrative, …);
− sovraccarico sulla rete;
− l’aumento del rischio di perdita di pacchetti
porta a tempi di risposta più alti.
Daniela M. Prencipe
INFORMED COOPERATION
• Continui scambi di informazioni fra le cache cooperanti circa il loro contenuto;
• Si scambiano poche informazioni, dunque non
si sovraccarica la rete.
Riassunt
o
Daniela M. Prencipe
PROTOCOLLI DI
COOPERAZIONE
Presenti in letteratura:
• ICP (Internet Caching Protocol)
• CD (Cache Digests)
• HTCP (HyperText Caching Protocol)
• CARP (Cache Array Routing Protocol)
•…
Daniela M. Prencipe
ICP (1)
1)
ICP è un protocollo intercache originario di livello applicativo (UDP come
lo strato del trasporto) che permette ad
un server proxy di chiedere ad un altro
proxy se possiede una copia valida di
una data risorsa;
2) ICP permette l’invio di richieste non
soltanto verso i nodi parent ma anche
tra nodi appartenenti allo stesso livello della gerarchia (nodi sibling);
3) Quando il proxy ha identificato tramite
ICP un altro proxy che possiede una copia valida della risorsa richiesta, per
ottenerla invia una normale richiesta
HTTP;
Daniela M. Prencipe
ICP (2)
4) Invio delle query ICP:
– per default, un proxy invia una query
ICP a tutti i proxy a cui è direttamente
collegato nella gerarchia;
5) Analisi delle risposte ICP:
– il proxy analizza le risposte ICP
finché riceve il primo ICP_HIT o finché
non ha ricevuto tutte le risposte con
ICP_MISS;
– timeout di 2 secondi. Se non si riceve
un messaggio di risposta significa che
la cache remota è fuori servizio oppure
la rete e/o la cache sono congestionate;e quindi si rinvia la query alla cache remota.
Daniela M. Prencipe
Esempio ICP :
si verifica un ICP_HIT
Consideriamo cosa avviene
nei proxy direttamente
collegati ad A
ICP_
MISS
S
2
ICP_
MISS
HTTP
1
HTTP
HTTP
ICP_
HIT
HTTP
A
ICP_
HIT
1
Esempio ICP :
tutti ICP_MISS
Consideriamo cosa avviene
in tutti i livelli
dell’architettura
HTTP
S
HTTP
ICP_
MISS
HTTP
2
ICP_
MISS
HTTP
1
HTTP
HTTP
HTTP
HTTP
A
ICP_
MISS
1
Esempio ICP :
si verifica un timeout
Consideriamo cosa avviene
nei proxy direttamente
collegati ad A
TIMEOUT
S
2
La cache è
fuori servizio
o/e
congestionata.
HTTP
2
1
HTTP
HTTP
HTTP
A
1
FORMATO DEL MESSAGGIO
ICP (1)
0
31
OPCODE
VERSION
REQUEST NUMBER
OPTIONS
PADDING
SENDER HOST ADDRESS
DATA
Daniela M. Prencipe
PACKET LENGTH
FORMATO DEL MESSAGGIO
ICP (2)
• OPCODE: tipo di messaggio (es. ICP_QUERY,
ICP_MISS, ICP_HIT)
– Messaggio di tipo ICP_QUERY: il payload
del pacchetto è l’URL della risorsa
richiesta;
• VERSION: versione del protocollo che è stato
usato;
• PACKET LENGTH: lunghezza totale del
pacchetto;
• REQUEST NUMBER: numero richiesta assegnata
dall’utente; è spesso usato come parte di una
chiave di cache;deve essere sempre lo stesso
nel msg di query e di reply;
• PADDING: autenticazione informazione;
• SENDER HOST ADDRESS: identificazione del
sender.
Daniela M. Prencipe
FORMATO DEL MESSAGGIO DI
QUERY
NOME
DIMENSIONE
DESCRIZIONE
Intestazione
16
La comune
intestazione
Richiedente
4
Id dell’host
richiedente
URL
variabile
URL al quale lo
stato è stato
controllato
Daniela M. Prencipe
FORMATO DEL MESSAGGIO DI
HIT O MISS
NOME
DIMENSIONE
DESCRIZIONE
Intestazione
16
La comune
intestazione
URL
Variabile
URL al quale lo
stato è stato
controllato
Daniela M. Prencipe
PROBLEMI DELL’ICP
1) Non supporta la validazione degli oggetti(header if-modified-since): questo può
portare a FALSE HIT;
2) I cache miss incorrono
addizionale (timeout);
in
un
ritardo
3) Overhead sulla rete nel cache hit (circa
160 byte per ogni richiesta/risposta ad
ogni cache cooperante).
4) Pericolo di cache poisoning se si usa
l’opzione ICP_HIT_OBJ
Daniela M. Prencipe
ICP_HIT_OBJ
Spesso un oggetto in cache come dimensioni entra in un pacchetto UDP, allora perché non
includere nella risposta direttamente anche
l’oggetto? Non dovendo effettuare la richiesta HTTP si risparmia tempo e banda.
• Primo problema: l’oggetto può essere scaduto,
mentre con una richiesta HTTP no.
• Secondo problema: Cache poisoning = contaminazione del contenuto di una cache con oggetti fasulli.
• In conclusione: lo stesso RFC che descrive
ICP sconsiglia caldamente l’uso dell’opzione
ICP_HIT_OBJ.
Daniela M. Prencipe
LA RETE GARR-G (1)
La fase di progettazione della nuova generazione della rete della ricerca italiana,
denominata
GARR-Giganet,
coincide con un periodo particolarmente ricco di innovazione nelle tecnologie di rete. Oggi sono infatti economicamente e tecnicamente realizzabili
la trasmissione a velocità di decine
di Gigabit per secondo su fibra ottica, l'utilizzo di router ad altissime
prestazioni, la creazione di una rete
ottica capillare e pervasiva e la molteplicità di fornitori di servizi e
connettività.
Daniela M. Prencipe
LA RETE GARR-G (2)
Daniela M. Prencipe
LA RETE GARR-G (3)
Lo scopo dell'attività di sperimentazione
chiamata GARR-G Pilot è di provare sul
campo tali avanzate tecnologie e possibilità per fornire dati ed esperienze alla
progettazione di GARR-Giganet.
Trasmissioni fotoniche, apparecchiature di
ultima generazione e l'attivazione di
funzionalità avanzate, come qualità di
servizio a livello di protocollo IP, sono
i pilastri su cui è costruita la rete Pilota della Ricerca Italiana.
Daniela M. Prencipe
LA RETE GARR
La Rete Italiana della Ricerca Scientifica
"GARR" si fonda su progetti di collaborazione scientifica ed accademica tra le Università e gli Enti di Ricerca pubblici
italiani. Di conseguenza il servizio di
rete GARR è destinato principalmente alla
comunità che afferisce al Ministero dell'Università e della Ricerca Scientifica
e Tecnologica (MURST). Esiste tuttavia la
possibilità di estensione del servizio
stesso anche ad altre realtà che svolgono
attività di ricerca in Italia, specialmente ma non esclusivamente in caso di
organismi "no-profit" impegnati in collaborazioni con la comunità afferente al
MURST.
Daniela M. Prencipe
Schemi dei PoP di GARR-G
Daniela M. Prencipe
Servizio Caching Nazionale
GARR (CNG) (1)
• Il servizio Caching Nazionale GARR (CNG) consente
di ridurre il traffico sulla rete, ed in particolar modo sulle tratte internazionali, mantenendo
copie in punti strategici della rete nazionale del
materiale più frequentemente richiesto dagli utenti.
• Il servizio Caching Nazionale è composto di due
parti: Web Caching e Mirroring. Il primo gestisce
delle cache per il WWW, mentre il secondo realizza
copie complete di siti di particolare interesse.
• Il Servizio Caching Nazionale si dovrà coordinare
od evolvere a partire dall'attuale servizio di Web
Caching svolto nell'ambito del GARR e dovrà partecipare alle iniziative in ambito europeo quali la
Cache Task Force di Terena.
Daniela M. Prencipe
Servizio Caching Nazionale
GARR (CNG) (2)
• Il servizio si occupa della pianificazione e coordinamento dei servizi di cache e mirroring; della
predisposizione di piani di utilizzo della banda
internazionale per il più efficace svolgimento del
servizio; della definizione di accordi di scambio
e peering con altri servizi analoghi su altre reti; della produzione di materiale tecnico (software, pagine Web, FAQ) per il supporto alla gestione del servizio; dell'organizzazione di un
gruppo di interesse e dell'organizzazione di incontri per diffondere raccomandazioni ed informazioni sullo sviluppo della tecnologia del caching.
• Oltre alla parte operativa del servizio, viene
svolta anche una parte di sperimentazione, seguendo gli sviluppi della tecnologia di caching e del
WWW, misurando e valutando i vantaggi di organizzazioni alternative, di prodotti e servizi.
Daniela M. Prencipe
Daniela M. Prencipe
Daniela M. Prencipe
Daniela M. Prencipe
Daniela M. Prencipe
Configurazione del
squid cache server(1)
Il protocollo ICP (Internet Caching Protocol), basato su UDP,
regola il colloquio tra due server cache in gerarchia.
Le relazioni che si possono stabilire tra le cache sono
fondamentalmente di tre tipi:
• essere "figli" di una cache ("parent")
• essere "fratelli" di una cache ("sibling")
• essere "padri" di una cache
In Squid, x configurare un “parent” o stabilire una
situazione di “sibling”, un cache_host direttivo è inserito
nel file di configurazione /etc/squid.conf, o un altro file
se viene usata l'opzione -f. Il formato è:
cache_peer hostname type http_port icp_port [options]
dove type può essere “parent” o “sibling”.
Nel caso specifico del nostro ateneo, diventerebbe:
cache_peer rm.cache.garr.it parent 3128 3130
La
riga cache_peer
rm.cache.garr.it.
definisce
il
Daniela M. Prencipe
parent
il
cui
nome
è
Squid
•Squid è il server proxy più usato (http://
www.squidcache.org)
– Progettato per sistemi Unix-like;
– Disponibilità del codice sorgente (progetto open-source);
– Efficienza;
– Stabilità ed affidabilità;
•Squid supporta diversi servizi tra cui:
– i protocolli applicativi HTTP, FTP, …;
– architettura gerarchica di proxy;
– i protocolli di cooperazione ICP (default), CARP, Cache Digest.
Daniela M. Prencipe
Configurazione del
squid cache server(2)
Per essere fratelli di un'altra cache occorrerà
configurare un "sibling", cioè un'analoga riga
cache_host con la clausola "sibling" anziché
"parent".
Configurare un sibling equivale quindi a tentare di
estendere la propria cache, per determinare la
presenza o meno dell'oggetto da parte dell'altra
cache.
Alle volte la relazione di sibling può risultare
inefficiente, soprattutto laddove le due comunità
di utenti sono troppo diverse (quindi poca
probabilità di HIT) o dove le due cache abbiano
dimensioni similari.
Non è obbligatorio che la relazione di sibling sia
simmetrica (come lo è nella vita): si può cioè
scegliere, e può avere senso, di essere fratelli
di uno che non ci configura come fratello (sibling
non reciproco).
Daniela M. Prencipe
Bibliografia
• rfc 2186 - Internet Cache
Protocol (ICP), version 2;
• www.cache.garr.it;
• www.garr.it.
Daniela M. Prencipe