IL CACHING COOPERATIVO

1
IL CACHING
COOPERATIVO
Daniela M. Prencipe Matr. 3036718
2
Sommario

• Il Web caching
• Il Caching cooperativo
• Le varie architetture del ca-ching cooperativo
• Il protocollo ICP
• La rete Garr-G
• Configurazione del squid cache server nella rete
  Garr.

3
WEB CACHING

• Il Web caching è una tecnica che può ri-durre il
  ritardo nella ricerca dei docu-menti e diminuire
  la quantità di traffico Web inviato su Internet.
• La cache nel Web è unentità della rete, detta
  anche proxy server che soddisfa le richieste HTTP
  da parte di un client.

4
IL PROXY SERVER(1)

• Il proxy server ha un proprio disco di
  archiviazione e conserva nella sua memoria copie
  degli oggetti ri-chiesti di recente.
• Gli utenti configurano i loro brow-ser in modo
  tale che tutte le ri-chieste HTTP siano dirette
  ai proxy server.

5
IL PROXY SERVER (2)

• Quando un browser invia una richiesta HTTP per un
  oggetto, il proxy server con-trolla se ha una
  copia dell'oggetto memo-rizzata. Se si invia un
  GET condizionato all'URL dell'oggetto richiesto,
  altrimen-ti invia un GET semplice.
• Quindi il proxy server riceve, o mantie-ne,
  l'oggetto nella propria cache e invia un
  messaggio di risposta HTTP al browser con, in
  allegato, l'oggetto richiesto.

6
I VANTAGGGI CON I PROXY SERVER (1)

• I proxy server stanno avendo un grande successo
  in Internet per almeno tre motivi
• 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.
• I proxy server possono ridurre in modo dra-stico
  il traffico su un link di accesso di
  un'organizzazione. Inoltre, possono ridurre in
  modo consistente anche il traffico del-l'intero
  Internet, migliorando quindi le performance di
  tutte le applicazioni Inter-net.

7
I VANTAGGGI CON I PROXY SERVER (2)

• Un Internet fitto di proxy server fornisce
  un'infrastruttura ideale per la rapida
  di-stribuzione di contenuti, anche per le
  in-formazioni disponibili su siti che funziona-no
  su server lenti o con link di accesso a bassa
  velocità. Se questi provider poveri di risorse"
  hanno contenuti di interesse ge-nerale, questi
  saranno copiati velocemente nelle cache dei proxy
  server e l'alta ri-chiesta degli utenti potrà
  essere soddi-sfatta.

8
IL CACHING COOPERATIVO

• I proxy server multipli, situati in locazioni
  diverse su Internet, possono cooperare e
  mi-gliorare le performance generali e possono
  trarre beneficio dalla condivisione degli
  og-getti contenuti nella propria cache così come
  un gruppo di client (browser). Il loro effet-to
  positivo è amplificato dall'architettura
  distribuita.
• Le cache gerarchiche sono un'estensione logi-ca
  del concetto di cache, utilizzano i proto-colli
  di intercache. Questo tipo di protocol-li
  fornisce delle informazioni che possono essere
  utilizzate da un apparato di webcache per ridurre
  il tempo di ricerca di un ogget-to.

9
VANTAGGI DEL CACHING COOPERATIVO(1)

• Unefficiente cache nel client o nel proxy ha dei
  significativi vantaggi
• riduce la latenza percepita dall'utente
• riduce il carico del Web server
• diminuisce il numero di pacchetti che tran-sitano
  nella rete e quindi aumenta la banda disponibile
• aumenta l'affidabilità perché gli oggetti possono
  essere recuperati anche quando i server d'origine
  non sono raggiungibili
• il minor costo, poiché si può utilizzare una
  struttura distribuita più economica

10
VANTAGGI DEL CACHING COOPERATIVO(2)

• un maggior numero di cache hits in genera-le, ci
  si può aspettare che almeno il 10 delle
  richieste ricevute da una cache si traducano in
  cache hit (risposte positive) in quelle
  adiacenti
• routing delle richieste eseguendo un rou-ting
  verso una certa cache adiacente, é pos-sibile
  instradare il traffico HTTP su un de-terminato
  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.

11
SVANTAGGI DEL CACHING COOPERATIVO

• Alcuni possibili svantaggi possono essere
• maggiore complessità della configurazione
• per ogni singola relazione di "parentela" é
  ne-cessario coordinare gli interventi di
  configu-razione di entrambi i nodi coinvolti ed
  al cre-scere del numero delle cache componenti la
  ge-rarchia, 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.

12
ARCHITETTURA DEL CACHING COOPERATIVO

• Alcune soluzioni proposte
• Architetture gerarchiche
• Architetture distribuite
• Architetture ibride

13
ESEMPIO (1)di architettura gerarchica
Cache nazionale
HTTP
Server di origine
Nessuna copia delloggetto
Memorizza copia delloggetto
Cache regionale
Nella risposta HTTP viene inserita copia
delloggetto
Nessuna copia delloggetto
Memorizza copia delloggetto
Cache dellistituzione
Nessuna copia delloggetto
Memorizza copia delloggetto
HTTP
14
ESEMPIO (2)di architettura gerarchica
Cache dellistituzione
HTTP
Contiene copia delloggetto
Richiesta copia dello stesso oggetto
HTTP
15
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.

16
SVANTAGGI DELLA ARCHITETTURA GERARCHICA

• I server proxy della gerarchia devono essere
  posizionati in punti strategici della rete
• Ogni livello della gerarchia può in-trodurre un
  ritardo aggiuntivo
• Copie multiple della stessa risorsa sono
  presenti in diversi livelli della cache.

17
ARCHITETTURA DISTRIBUITA

• Esiste un unico li-vello di server pro-xy
• Ogni server proxy mantiene delle
  meta-informazioni sul con-tenuto delle cache
  degli altri server proxy.
• Tutte le cache sono sorelle.

1
1
1
1
18
QUERY COOPERATION

• Quando viene inviata una richiesta ad un proxy,
  se non ha loggetto 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 coope-ranti.

19
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
  di-stribuito su una vasta area geografica
  (elevati tempi di connessione, maggiore uso della
  lar-ghezza di banda, questioni amministrative,
  )
• sovraccarico sulla rete
• laumento del rischio di perdita di pacchetti
  porta a tempi di risposta più alti.

20
INFORMED COOPERATION

• Continui scambi di informazioni fra le ca-che
  cooperanti circa il loro contenuto
• Si scambiano poche informazioni, dunque non si
  sovraccarica la rete.

Rias-sunto
21
PROTOCOLLI DI COOPERAZIONE

• Presenti in letteratura
• ICP (Internet Caching Protocol)
• CD (Cache Digests)
• HTCP (HyperText Caching Protocol)
• CARP (Cache Array Routing Protocol)

22
ICP (1)

• ICP è un protocollo intercache origi-nario 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
• ICP permette linvio di richieste non soltanto
  verso i nodi parent ma anche tra nodi
  appartenenti allo stesso livel-lo della gerarchia
  (nodi sibling)
• Quando il proxy ha identificato tramite ICP un
  altro proxy che possiede una co-pia valida della
  risorsa richiesta, per ottenerla invia una
  normale richiesta HTTP

23
ICP (2)

• Invio delle query ICP
• per default, un proxy invia una query ICP a
  tutti i proxy a cui è direttamente collegato
  nella gerarchia
• 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 congestiona-tee quindi si rinvia la
  query alla ca-che remota.

24
Esempio ICP si verifica un ICP_HIT
Consideriamo cosa avviene nei proxy direttamente
collegati ad A
S
ICP_MISS
2
ICP_MISS
HTTP
1
HTTP
HTTP
ICP_HIT
HTTP
ICP_HIT
1
A
25
Esempio ICP tutti ICP_MISS
HTTP
Consideriamo cosa avviene in tutti i livelli
dellarchitettura
S
HTTP
ICP_MISS
HTTP
2
ICP_MISS
HTTP
1
HTTP
HTTP
ICP_MISS
HTTP
HTTP
1
A
26
Esempio ICP si verifica un timeout
Consideriamo cosa avviene nei proxy direttamente
collegati ad A
S
TIMEOUT
2
2
La cache è fuori servizio o/e congestionata.
HTTP
1
HTTP
HTTP
HTTP
1
A
27
FORMATO DEL MESSAGGIO ICP (1)
0
31
OPCODE VERSION PACKET LENGTH
REQUEST NUMBER REQUEST NUMBER REQUEST NUMBER
OPTIONS OPTIONS OPTIONS
PADDING PADDING PADDING
SENDER HOST ADDRESS SENDER HOST ADDRESS SENDER HOST ADDRESS
DATA DATA DATA
28
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 è lURL della risorsa richiesta
• VERSION versione del protocollo che è stato
  usato
• PACKET LENGTH lunghezza totale del pacchetto
• REQUEST NUMBER numero richiesta assegnata
  dallutente è spesso usato come parte di una
  chiave di cachedeve essere sempre lo stesso nel
  msg di query e di reply
• PADDING autenticazione informazione
• SENDER HOST ADDRESS identificazione del sender.

29
FORMATO DEL MESSAGGIO DI QUERY
NOME DIMENSIONE DESCRIZIONE
Intestazione 16 La comune intestazione
Richiedente 4 Id dellhost richiedente
URL variabile URL al quale lo stato è stato controllato
30
FORMATO DEL MESSAGGIO DI HIT O MISS
NOME DIMENSIONE DESCRIZIONE
Intestazione 16 La comune intestazione
URL Variabile URL al quale lo stato è stato controllato
31
PROBLEMI DELLICP

• Non supporta la validazione degli ogget-ti(header
  if-modified-since) questo può portare a FALSE
  HIT
• I cache miss incorrono in un ritardo addizionale
  (timeout)
• Overhead sulla rete nel cache hit (circa 160 byte
  per ogni richiesta/risposta ad ogni cache
  cooperante).
• Pericolo di cache poisoning se si usa lopzione
  ICP_HIT_OBJ

32
ICP_HIT_OBJ

• Spesso un oggetto in cache come dimensioni en-tra
  in un pacchetto UDP, allora perché non includere
  nella risposta direttamente anche loggetto? Non
  dovendo effettuare la richie-sta HTTP si
  risparmia tempo e banda.
• Primo problema loggetto può essere scaduto,
  mentre con una richiesta HTTP no.
• Secondo problema Cache poisoning
  contami-nazione del contenuto di una cache con
  ogget-ti fasulli.
• In conclusione lo stesso RFC che descrive ICP
  sconsiglia caldamente luso dellopzione
  ICP_HIT_OBJ.

33
LA RETE GARR-G (1)

• La fase di progettazione della nuova ge-nerazione
  della rete della ricerca i-taliana, denominata
  GARR-Giganet, coincide con un periodo
  particolarmen-te ricco di innovazione nelle
  tecnolo-gie di rete. Oggi sono infatti
  econo-micamente e tecnicamente realizzabili la
  trasmissione a velocità di decine di Gigabit per
  secondo su fibra otti-ca, l'utilizzo di router ad
  altissime prestazioni, la creazione di una rete
  ottica capillare e pervasiva e la mol-teplicità
  di fornitori di servizi e connettività.

34
LA RETE GARR-G (2)
35
LA RETE GARR-G (3)

• Lo scopo dell'attività di sperimentazione
  chiamata GARR-G Pilot è di provare sul campo tali
  avanzate tecnologie e possibi-lità 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 Pi-lota della Ricerca Italiana.

36
LA RETE GARR

• La Rete Italiana della Ricerca Scientifica "GARR"
  si fonda su progetti di collabora-zione
  scientifica ed accademica tra le U-niversità e
  gli Enti di Ricerca pubblici italiani. Di
  conseguenza il servizio di rete GARR è destinato
  principalmente alla comunità che afferisce al
  Ministero del-l'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,
  special-mente ma non esclusivamente in caso di
  organismi "no-profit" impegnati in
  colla-borazioni con la comunità afferente al
  MURST.

37
Schemi dei PoP di GARR-G
38
Servizio Caching Nazionale GARR (CNG) (1)

• Il servizio Caching Nazionale GARR (CNG) consente
  di ridurre il traffico sulla rete, ed in
  parti-colar modo sulle tratte internazionali,
  mantenendo copie in punti strategici della rete
  nazionale del materiale più frequentemente
  richiesto dagli uten-ti.
• 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à
  parte-cipare alle iniziative in ambito europeo
  quali la Cache Task Force di Terena.

39
Servizio Caching Nazionale GARR (CNG) (2)

• Il servizio si occupa della pianificazione e
  coor-dinamento 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 re-ti della produzione di
  materiale tecnico (soft-ware, pagine Web, FAQ)
  per il supporto alla ge-stione del servizio
  dell'organizzazione di un gruppo di interesse e
  dell'organizzazione di in-contri per diffondere
  raccomandazioni ed informa-zioni sullo sviluppo
  della tecnologia del caching.
• Oltre alla parte operativa del servizio, viene
  svolta anche una parte di sperimentazione,
  seguen-do gli sviluppi della tecnologia di
  caching e del WWW, misurando e valutando i
  vantaggi di organiz-zazioni alternative, di
  prodotti e servizi.

40
(No Transcript)
41
(No Transcript)
42
(No Transcript)
43
(No Transcript)
44
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 definisce il parent il cui
  nome è rm.cache.garr.it.

45
Squid

• Squid è il server proxy più usato (http//
  www.squidcache.org)
• Progettato per sistemi Unix-like
• Disponibilità del codice sorgente (pro-getto
  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 (de-fault),
  CARP, Cache Digest.

46
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).

47
Bibliografia

• rfc 2186 - Internet Cache Protocol (ICP), version
  2
• www.cache.garr.it
• www.garr.it.