IL CACHING

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

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. Daniela M. Prencipe

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 è un’entità della rete, detta anche proxy server che soddisfa le richieste HTTP da parte di un client. Daniela M. Prencipe

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. Daniela M. Prencipe

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. Daniela M. Prencipe

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. Daniela M. Prencipe

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. Daniela M. Prencipe

8. IL CACHING COOPERATIVO • Iproxy 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. Daniela M. Prencipe

9. VANTAGGI DEL CACHING COOPERATIVO(1) Un’efficiente 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; Daniela M. Prencipe

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. Daniela M. Prencipe

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. Daniela M. Prencipe

12. ARCHITETTURA DEL CACHING COOPERATIVO Alcune soluzioni proposte: • Architetture gerarchiche • Architetture distribuite • Architetture ibride Daniela M. Prencipe

13. ESEMPIO (1)di architettura gerarchica Cache nazionale HTTP Server di origine Nessuna copia dell’oggetto Memorizza copia dell’oggetto Cache regionale Nella risposta HTTP viene inserita copia dell’oggetto Nessuna copia dell’oggetto Memorizza copia dell’oggetto Cache dell’istituzione Nessuna copia dell’oggetto Memorizza copia dell’oggetto HTTP

14. ESEMPIO (2)di architettura gerarchica Cache dell’istituzione HTTP Contiene copia dell’oggetto 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. Daniela M. Prencipe

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. Daniela M. Prencipe

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 Daniela M. Prencipe

18. 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 coope-ranti. Daniela M. Prencipe

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; • l’aumento del rischio di perdita di pacchetti porta a tempi di risposta più alti. Daniela M. Prencipe

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 Daniela M. Prencipe

21. 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

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 l’invio di richieste non soltanto verso i nodi parentma 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; Daniela M. Prencipe

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-te;e quindi si rinvia la query alla ca-che remota. Daniela M. Prencipe

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 ICP_HIT HTTP 1 A

25. Esempio ICP : tutti ICP_MISS HTTP Consideriamo cosa avviene in tutti i livelli dell’architettura 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 Daniela M. Prencipe

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 è 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

29. FORMATO DEL MESSAGGIO DI QUERY Daniela M. Prencipe

30. FORMATO DEL MESSAGGIO DI HIT O MISS Daniela M. Prencipe

31. PROBLEMI DELL’ICP • 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 l’opzione ICP_HIT_OBJ Daniela M. Prencipe

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 l’oggetto? Non dovendo effettuare la richie-sta HTTP si risparmia tempo e banda. • Primo problema: l’oggetto 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 l’uso dell’opzione ICP_HIT_OBJ. Daniela M. Prencipe

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à. Daniela M. Prencipe

34. LA RETE GARR-G (2) Daniela M. Prencipe

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. Daniela M. Prencipe

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. Daniela M. Prencipe

37. Schemi dei PoP di GARR-G Daniela M. Prencipe

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. Daniela M. Prencipe

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. Daniela M. Prencipe

40. Daniela M. Prencipe

41. Daniela M. Prencipe

42. Daniela M. Prencipe

43. Daniela M. Prencipe

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. Daniela M. Prencipe

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. Daniela M. Prencipe

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). Daniela M. Prencipe

47. Bibliografia • rfc 2186 - Internet Cache Protocol (ICP), version 2; • www.cache.garr.it; • www.garr.it. Daniela M. Prencipe