UNIVERSITA' DEGLI STUDI DI ROMA TOR VERGATA - TECA ELIS

UNIVERSITA’ DEGLI STUDI DI ROMA 

TOR VERGATA 

FACOLTA’ DI INGEGNERIA 

Corso di Laurea Specialistica in Ingegneria Informatica 

Tesi di Laurea 

“SATSQUID: UN SISTEMA DI PROXY CACHING 

SATELLITARE” 

Relatore: 

Chiar.mo Prof. 

Salvatore Tucci 

Correlatore: 

Ing. 

Valeria Cardellini 

Laureando: 

ANNO ACCADEMICO 2004/2005 

Marco Crucianelli

Alla mia famiglia, che più di tutti mi ha aiutato e sostenuto 

nei momenti difficili, ma soprattutto ha sempre creduto in me. 

Alla mia Giorgia, grazie di avermi fatto sentire che c’eri. 

“La teoria è quando si sa tutto e niente funziona. La pratica è 

quando tutto funziona e nessuno sa il perchè. In questo 

caso abbiamo messo insieme la teoria e la pratica: non c'è 

niente che funziona...e nessuno sa il perchè!” 

Albert Einstein

Sommario 

Sommario 

Indice delle figure...........................................................................................................4 

Indice delle tabelle..........................................................................................................8 

Introduzione....................................................................................................................9 

1 Caching.................................................................................................................12 

1.1 Localizzazione di un proxy server..................................................................13 

1.1.1 Reverse proxy........................................................................................13 

1.1.2 Interception proxy..................................................................................14 

1.2 Politiche di rimpiazzamento...........................................................................15 

1.2.1 Algoritmi di rimpiazzamento deterministici...........................................16 

1.2.2 Algoritmi di rimpiazzamento casuali......................................................20 

1.3 Caching di contenuti multimediali.................................................................20 

1.3.1 Segmentazione e prefix caching.............................................................21 

1.3.2 Caching dinamico..................................................................................22 

1.3.3 Codifica a livelli....................................................................................23 

1.4 Caching cooperativo......................................................................................24 

1.4.1 Internet Cache Protocol (ICP)................................................................24 

1.4.2 Cache Array Resolution Protocol (CARP)..............................................25 

1.4.3 Cache Digest Protocol (Digest)..............................................................26 

1.4.4 Web Cache Coordination Protocol (WCCP)...........................................26 

2 Connessioni satellitari...........................................................................................27 

2.1 Problematiche di una connessione satellitare..................................................27 

2.2 Soluzioni possibili.........................................................................................28 

2.2.1 AI3 Network: Adaptive WWW Caching................................................28 

2.2.2 Hughes Network Systems: Cumulative Caching.....................................31 

2.2.3 INTELSAT Internet Delivery System (IDS)...........................................33 

2.2.4 SatCAST: multicast via satellite per applicazioni web............................36 

2.3 Considerazioni sulle soluzioni proposte.........................................................40 

3 Progettazione e architettura del sistema SatSquid..................................................42 

1

Sommario 

3.1 Le scelte progettuali.......................................................................................42 

3.1.1 La scelta del proxy: Squid......................................................................44 

3.1.2 Due livelli di caching.............................................................................45 

3.1.3 Due istanze di Squid..............................................................................46 

3.1.4 Pushing vs. prefetching..........................................................................48 

3.1.5 Gestione del prefetching ........................................................................50 

3.1.6 Indirizzamento delle richieste.................................................................50 

3.1.7 Dimensionamento hardware...................................................................52 

3.2 Le possibili architetture.................................................................................54 

3.2.1 Pushing vs. prefetching..........................................................................55 

3.2.2 Indirizzamento delle richieste.................................................................59 

3.2.3 Mirroring separato.................................................................................65 

3.3 Architettura scelta: vantaggi e limiti..............................................................66 

4 Strumenti per la realizzazione di SatSquid.............................................................69 

4.1 Squid.............................................................................................................69 

4.1.1 Configurazione iniziale..........................................................................69 

4.1.2 ACL.......................................................................................................71 

4.1.3 File di log..............................................................................................74 

4.1.4 Configurazioni varie..............................................................................78 

4.2 SNMP...........................................................................................................80 

4.3 MRTG e RRDTOOL.....................................................................................83 

4.4 Calamaris......................................................................................................87 

5 Progettazione e implementazione dei moduli software di SatSquid........................89 

5.1 Architettura software di SatSquid..................................................................89 

5.2 SPD (Satelitte Prefetching Daemon)..............................................................92 

5.2.1 Funzionamento......................................................................................93 

5.2.2 Implementazione....................................................................................96 

5.3 MMI (Mirroring Management Interface) .....................................................103 

5.3.1 Funzionamento....................................................................................103 

5.3.2 Implementazione..................................................................................105 

6 Testing e analisi dei risultati................................................................................130 

6.1 Architettura di testing..................................................................................130 

2

Sommario 

6.1.1 IRCache e Web log..............................................................................132 

6.1.2 Log_stripper, log_player e log_cleaner................................................132 

6.1.3 Netem..................................................................................................134 

6.2 Test e risultati..............................................................................................135 

6.2.1 Dimensione della cache pari a 4GB......................................................135 

6.2.2 Dimensione della cache pari a 300MB.................................................138 

6.3 Analisi dei risultati......................................................................................140 

Conclusioni.................................................................................................................146 

Appendice A...............................................................................................................149 

Squid.conf (Calamaro)............................................................................................149 

Squid.conf (Andromeda).........................................................................................154 

Appendice B...............................................................................................................158 

Configurazione MRTG ...........................................................................................158 

Appendice C...............................................................................................................169 

calamaris.conf.........................................................................................................169 

Appendice D...............................................................................................................196 

Spd.cfg....................................................................................................................196 

Glossario.....................................................................................................................198 

Bibliografia.................................................................................................................204 

3

Indice delle figure 


Fig. 1-1 - Classificazione delle politiche di rimpiazzamento a seconda delle informazioni 

considerate.................................................................................................................16 

Fig. 1-2 - Esempio di segmentazione e prefix caching......................................................22 

Fig. 1-3 - Funzionamento del caching dinamico...............................................................23 

Fig. 2-1 - AI3 Testbed Network.......................................................................................29 

Fig. 2-2 - Architettura della soluzione AI3 per il web caching..........................................31 

Fig. 2-3 - Hughes Network Systems SPACEWAY...........................................................32 

Fig. 2-4 - Architettura INTELSAT IDS...........................................................................35 

Fig. 2-5 - Uso del pushing in una catena di proxy.............................................................36 

Fig. 2-6 - Topologia dei core-link della rete Mercure........................................................37 

Fig. 2-7 - Archietettura della SatCAST con Squid e agenti MCast....................................39 

Fig. 3-1 - Sistema di proxy/caching su due livelli.............................................................46 

Fig. 3-2 - Doppia istanza di Squid per ogni livello di caching...........................................46 

Fig. 3-3 - Istanza di Squid dedicata ai file multimediali: basso traffico e hit rate...............48 

Fig. 3-4 - Layer 7 switching dedicato...............................................................................51 

Fig. 3-5 - Layer 7 Switching tramite Squid e ACL...........................................................51 

Fig. 3-6 - Grafico della tipologia di traffico della rete Elis................................................54 

Fig. 3-7 - Sottoscrizione di un contenuto da parte agente esterno......................................56 

Fig. 3-8 - Memorizzazione della richiesta di sottoscrizione e risposta alla GET................57 

Fig. 3-9 - Aggiornamento del contenuto da parte di un agente di PUSHING....................57 

Fig. 3-10 - Aggiornamento del contenuto di L2 tramite PUT HTTP.................................58 

Fig. 3-11 - Architettura Virtual Server tramite IP Tunneling.............................................62 

Fig. 3-12 - Flusso di incapsulamento/decapsulamento tra il forntend (LinuxDirector) e il 

backend (Real Server)................................................................................................63 

Fig. 3-13 - Comandi per disabilitare le risposte ARP per una interfaccia di loopback.......64 

Fig. 3-14 - Architettura del sistema di caching satellitare SatSquid...................................66 

Fig. 3-15 - Architettura finale "alternativa": mirroring dedicato........................................67 

4


Fig. 4-1 - Script di configurazione di Squid......................................................................71 

Fig. 4-2 - Esempi di elementi di ACL...............................................................................72 

Fig. 4-3 - Esempi di elementi ACL con valori multipli.....................................................73 

Fig. 4-4 - Esempi di regole di ACL..................................................................................73 

Fig. 4-5 - Esempi di regole ACL con valori multipli.........................................................73 

Fig. 4-6 - Insieme di ACL usate per effettuare l’indirizzamento delle richieste.................74 

Fig. 4-7 - Esempio di file cache.log..................................................................................75 

Fig. 4-8 - Esempio di file store.log...................................................................................76 

Fig. 4-9 - Esempio di access.log nel formato nativo di Squid............................................76 

Fig. 4-10 - Formato del file di logging access.log proprietario di Squid............................78 

Fig. 4-11 - Esempio di impostazione cache_peer usata per i test.......................................79 

Fig. 4-12 - Esempio di impostazioni del parametro refresh_pattern..................................80 

Fig. 4-13 - Pseudocodice per il controllo della freschezza di un oggetto di Squid.............80 

Fig. 4-14 - Albero gerarchico degli OID nel MIB.............................................................82 

Fig. 4-15 - Esempio di ACL per l'accesso SNMP su Squid...............................................83 

Fig. 4-16 - Impostazioni per l'utilizzo di RRDTOOL all'interno di un .cfg di MRTG........85 

Fig. 4-17 - Dimensione della cache in un giorno di utilizzo..............................................86 

Fig. 4-18 - Numero di oggetti in cache in un giorno di utilizzo.........................................86 

Fig. 4-19 - Distribuzione della dimensione e del numero dei file richiesti.........................88 

Fig. 5-1 - Funzionamento dell'architettura software nel caso di richiesta di tipo WD.........90 

Fig. 5-2 - Funzionamento dell'architettura software nel caso di richiesta di tipo MM........91 

Fig. 5-3 - Funzionamento dell'architettura software alternativa.........................................92 

Fig. 5-4 - Esempio di istruzioni all'interno del crontab......................................................93 

Fig. 5-5 - Diagramma di flusso del funzionamento del demone SPD................................95 

Fig. 5-6 - Funzionamento delle varie istanze di SPD in una architettura base....................96 

Fig. 5-7 - Funzionamento delle varie istanze di SPD in una architettura alternativa..........97 

Fig. 5-8 - Una sezione del file di configurazione spd.cfg ..................................................98 

Fig. 5-9 - Parsing di valori del file spd.cfg........................................................................98 

Fig. 5-10 - Inizializzazione del logging su file di testo per il demone SPD......................100 

Fig. 5-11 - Codice per l'invio di una mail di notifica in caso di errore.............................101 

Fig. 5-12 - Codice necessario al matching delle richieste nel file di log di Squid............103 

5


Fig. 5-13 - Funzionamento della MMI nell’architettura base..........................................104 

Fig. 5-14 - Funzionamento MMI nell’architettura alternativa.........................................105 

Fig. 5-15 - Relazioni tra le tabelle del database di MMI in configurazione base..............107 

Fig. 5-16 - Relazione tra le tabelle del database di MMI in configurazione alternativa....108 

Fig. 5-17 - Interfaccia di autenticazione..........................................................................109 

Fig. 5-18 - Codice per il controllo dei diritti di accesso...................................................110 

Fig. 5-19 - Diagramma di flusso del funzionamento di MMI..........................................111 

Fig. 5-20 - Interfaccia di inserimento utente...................................................................112 

Fig. 5-21 - Interfaccia di inserimento utente in configurazione alternativa......................113 

Fig. 5-22 - Diagramma di flusso dell'inserimento utente.................................................114 

Fig. 5-23 - Codice relativo all'inserimento utenti............................................................115 

Fig. 5-24 - Interfaccia di modifica utente........................................................................116 

Fig. 5-25 - Diagramma di flusso della modifica utenti....................................................117 

Fig. 5-26 - Codice per la modifica di un amministratore in un utente..............................117 

Fig. 5-27 - Codice per la modifica di un amministratore.................................................118 

Fig. 5-28 - Codice per la modifica di un utente in amministratore...................................118 

Fig. 5-29 - Codice per la modifica di un utente...............................................................118 

Fig. 5-30 - Codice per la rimozione di un amministratore...............................................119 

Fig. 5-31 - Codice per la rimozione di un utente.............................................................119 

Fig. 5-32 - Interfaccia per l'inserimento di un sito mirror................................................120 

Fig. 5-33 - Interfaccia per l'inserimento di un sito mirror in configurazione alternativa...121 

Fig. 5-34 - Diagramma di flusso dell'inserimento di un sito mirror.................................122 

Fig. 5-35 - Codice per l'inserimento di una URL non presente nel database....................123 

Fig. 5-36 - Codice per l'inserimento delle ACL in squid.conf nel caso di architettura 

alternativa................................................................................................................123 

Fig. 5-37 - Diagramma di flusso della modifica di un sito mirror....................................124 

Fig. 5-38 - Codice per la modifica di una URL associata a più L2 con campi identici.....125 

Fig. 5-39 - Codice per la modifica di una URL con una unica associazione, ma associazioni 

multiple a seguito della modifica..............................................................................125 

Fig. 5-40 - Codice per la modifica di una URL associata a più L2 con campi diversi......126 

Fig. 5-41 - Codice per la modifica di una URL con una unica associazione....................126 

6


Fig. 5-42 - Diagramma di flusso della rimozione di un sito mirror..................................127 

Fig. 5-43 - Codice per la rimozione di un sito in mirroring.............................................128 

Fig. 5-44 - Codice per la rimozione delle operazioni nel crontab....................................128 

Fig. 5-45 - Codice per la rimozione di un sito in mirroring nel caso di configurazione 

alternativa................................................................................................................129 

Fig. 6-1 - Architettura di testing.....................................................................................131 

Fig. 6-2 - Comando per impostare un ritardo fisso di 500msec con Netem.....................135 

Fig. 6-3 - Valori di HIT, MISS ed ERROR per cache a 4GB senza SPD.........................136 

Fig. 6-4 - Valori di HIT, MISS ed ERROR per cache a 4GB con SPD............................137 

Fig. 6-5 - Valori di HIT, MISS ed ERROR per cache a 300MB senza SPD....................138 

Fig. 6-6 - Valori di HIT, MISS ed ERROR per cache a 300MB con SPD.......................139 

Fig. 6-7 - Hit rate al variare della dimensione della cache e della presenza di SPD.........141 

Fig. 6-8 - Byte/hit rate al variare della dimensione della cache e della presenza di SPD..142 

Fig. 6-9 - Distribuzione dei tempi di risposta nel caso di connessione LAN....................144 

Fig. 6-10 - Distribuzione dei tempi di risposta nel caso di connessione satellitare...........145 

7

Indice delle tabelle 

Indice delle tabelle 

Tab. 3-1 - Tabella per il dimensionamento di un proxy server Squid................................53 

Tab. 6-1 - Valori di HIT, MISS ed ERROR per cache a 4GB senza SPD........................136 

Tab. 6-2 - Valori di HIT, MISS ed ERROR per cache a 4GB con SPD...........................137 

Tab. 6-3 - Valori di HIT, MISS ed ERROR per cache a 300MB senza SPD...................138 

Tab. 6-4 - Valori di HIT, MISS ed ERROR per cache a 300MB con SPD......................139 

8

Introduzione 

Introduzione 

Il lavoro di tesi qui presentato nasce come progetto aziendale, svolto presso la 

società di consulenza Junior Consulting e con committente Telespazio. 

Telespazio, una delle realtà più importanti in Italia in ambito satellitare, ha nella 

propria offerta di servizi anche la connettività dati attraverso connessione satellitare. In 

particolare, la propria offerta è sia di tipo Business-to-Consumer, rivolta direttamente 

all’utente finale, sia di tipo Business-to-Business, rivolta quindi ad altri fornitori di servizi. 

Proprio queste realtà sono quelle di maggiore interesse, poiché, coinvolgono direttamente 

quegli ISP (Internet Service Provider) che, per motivi legati ad un posizionamento 

geografico “poco fortunato” (quindi impossibilitati all’utilizzo di connessioni terrestri) o per 

ragioni riguardanti la sicurezza (necessità di utilizzare dei link di back-up), necessitano di 

una connessione dati satellitare. A tali realtà vanno ad aggiungersene altre più recenti, frutto 

degli ultimi sviluppi nel campo delle connessioni senza fili, che vedono l’impiego 

contemporaneo di connessioni satellitari e di connessioni con tecnologia Wi-Max al fine di 

coprire rapidamente un vasto territorio. E’ questo il caso di aziende in forte espansione, con 

una vasta presenza sul territorio e che necessitano di collegare tra loro le sedi periferiche con 

la sede centrale, evitando così di transitare sulla rete pubblica, sia per questioni di sicurezza 

dei dati in transito, sia per ridurre la possibilità di ritardi o difficoltà di connettività non 

direttamente controllabili. 

Attualmente, tuttavia, le connessioni satellitari soffrono di un problema che le rende 

poco “appetibili” e che è insito nella natura stessa di queste connessioni, la latenza. I satelliti 

impiegati in questa tipologia di connessioni sono, nel caso di Telespazio, geostazionari, 

viaggiano quindi ad una distanza dalla terra di circa 36 mila kilometri. Questa distanza ha 

come conseguenza un ritardo dovuto alla propagazione stessa del segnale, quantificabile 

nell’ordine dei 500msec, divisi in 250msec nella tratta di uplink e 250msec nella tratta di 

downlink. E’ evidente come un siffatto ritardo determini una latenza riscontrabile durante la 

navigazione assai “fastidiosa”, soprattutto se si considerano le numerose interazioni 

normalmente necessarie per la visualizzazione di una semplice pagina Web: dalla risoluzione 

del nome del sito contenuto nella URL, fino alle richieste per i singoli oggetti “embedded” 

nella pagina stessa. Ogni richiesta subisce così un ritardo di 500msec, che sommato a quello 

9

Introduzione 

delle altre porta a diversi secondi di attesa per la visualizzazione di una semplice pagina Web, 

nonostante l’utilizzo di una connessione satellitare veloce (nell’ordine dei megabit/sec). 

A questo problema della latenza va ad aggiungersi una necessità del committente: la 

possibilità di utilizzare un meccanismo di mirroring dei contenuti. Il motivo di tale bisogno è 

da ricondursi ai vantaggi offerti dal mirroring, sia dal punto di vista tecnologico (riduzione 

dei tempi di caricamento dei contenuti), sia dal punto di vista commerciale (possibilità di 

stipulare accordi mirati per il mirroring selettivo di contenuti). 

Questo lavoro di tesi è stato quindi svolto tenendo sempre ben in mente il problema 

della latenza insita nella natura del canale e la necessità di un meccanismo di mirroring e 

traducendo tali problematiche nei due obiettivi principali: il mascheramento della latenza del 

canale satellitare e il mirroring di contenuti Web. A tal proposito è stato così studiato, 

progettato e realizzato un sistema di proxy caching e mirroring di contenuti fruibili 

attraverso una connessione satellitare, con il fine di rendere la navigazione una esperienza 

“piacevole” per l’utente finale e quanto più vicina possibile a quella riscontrabile nel caso di 

utilizzo di una connessione cablata. 

Per il conseguimento di questi due obiettivi, durante tutto il corso del lavoro, sono 

state attentamente prese in considerazione e, dove possibile, sfruttate due ipotesi di partenza, 

direttamente fornite da Telespazio: il basso costo delle capacità di storage e la disponibilità 

di una banda satellitare pressoché infinita. Allo stato attuale, infatti, è abbastanza economico 

costruire macchine con capacità di storage elevata, nell’ordine dei terabyte (considerando 

che attualmente un disco S-ATA da 200GB costa all’incirca 90€), analogamente, la velocità 

delle connessione satellitari supera ormai facilmente i 30 megabit/sec (a tal proposito 

Telespazio ha espresso la volontà di creare eventualmente un satellite dedicato con 

connessione nell’ordine dei 50 megabit/sec). 

Il risultato finale è stato quindi SatSquid, un sistema di proxy caching satellitare 

basato su Squid, uno dei più noti e affermati programmi proxy server. SatSquid, tramite 

l’ausilio di due moduli di supporto opportunamente creati, SPD (Squid Prefetching Daemon) 

e MMI (Mirroring Management Interface), consente di raggiungere gli obiettivi sopra 

accennati: attraverso l’utilizzo di tecniche di prefetching che prevedono l’analisi del traffico 

e il prelevamento anticipato del contenuto (prima ancora che venga richiesto), unitamente ad 

un meccanismo di mirroring di siti web, è possibile sia ridurre la latenza percepita 

10

Introduzione 

dall’utente finale durante la navigazione, sia effettuare il mirroring selettivo di contenuti 

Web, specificandone una frequenza di refresh e un livello di profondità. 

Lo sviluppo del lavoro di tesi è così articolato: inizialmente vengono presentati 

alcuni studi effettuati sugli algoritmi di caching più diffusi (Cap.1), elementi fondamentali di 

un buon sistema di caching e base di partenza per valutazioni relative all’architettura del 

sistema. Successivamente, vengono analizzate alcune architetture di proxy caching satellitari 

e soluzioni già presenti sul mercato (Cap.2), sottolineandone di volta in volta le 

caratteristiche salienti e gli elementi distintivi. A seguito di questa analisi, viene presentata 

una fase di studio e progettazione del sistema SatSquid (Cap.3), evidenziando in dettaglio i 

passaggi, le scelte e le motivazioni che hanno guidato tale fase, risultante nella presentazione 

dell’architettura finale e dei propri pregi e difetti. Vengono quindi descritti gli strumenti 

necessari all’implementazione di tale architettura (Cap.4), così come di quelli che sono stati 

utilizzati nella fase di progettazione al fine di effettuare determinate scelte architetturali. 

Segue poi una accurata presentazione delle caratteristiche dei moduli di supporto SPD e 

MMI (Cap.5) e delle rispettive implementazioni. Il lavoro si conclude con la presentazione 

della fase di sperimentazione condotta sul prototipo realizzato, dell’architettura e degli 

strumenti utilizzati durante il testing e dell’analisi dei risultati raccolti durante tale fase 

(Cap.6). Alla fine del testo, sono riportate in appendice le configurazioni di alcuni degli 

strumenti utilizzati durante tutto il lavoro di tesi, nonché un glossario dei termini tecnici e 

degli acronimi utilizzati in questo testo. 

11

1 Caching 

1. Caching 

Il caching assume particolare rilevanza nell’ambito delle reti. E’ indubbio che, con la 

continua crescita di Internet, sempre più documenti e contenuti di varia natura vengono 

scambiati ogni giorno in ogni parte del globo. Alcuni di questi documenti hanno maggiore 

rilevanza rispetto ad altri e per questo sono maggiormente acceduti. Di conseguenza, diventa 

evidente la necessità di velocizzare l’accesso a tali risorse altamente utilizzate, tramite 

l’ausilio del caching. 

Il caching di contenuti web, quindi, ha lo scopo principale di rendere più rapido 

l’accesso ai documenti maggiormente acceduti, riducendo la latenza percepita dagli utenti. 

Per raggiungere tale risultato è possibile agire sia lato server (chi fornisce i documenti) sia 

lato utente (chi fruisce di tali documenti). 

Lo strumento maggiormente utilizzato in tal senso è il proxy server: una macchina, 

spesso posizionata in prossimità di un Internet gateway, che fornisce una cache condivisa per 

un insieme di client. Le richieste effettuate da tali client pervengono al proxy 

indipendentemente dal server web che ospita i documenti richiesti. Il proxy può così 

rispondere a tali richieste con una copia di questi documenti conservata nella propria cache, 

oppure prelevarli direttamente dall’origin server ed effettuarne una copia in cache prima di 

restituirli al client. 

Un proxy quindi ha un triplice scopo: 

• ridurre la latenza d’accesso ad un documento; 

• limitare il traffico Internet, favorendo la circolazione di documenti all’interno 

della rete di appartenenza del client richiedente; 

• ridurre il carico sugli origin server. 

In questo primo capitolo verranno trattati quegli elementi del caching che saranno 

fondamentali nello sviluppo del lavoro di tesi. Il primo di tali elementi fondamentali è 

rappresentato dalla strategia di posizionamento di un server di proxying/caching e quindi 

dalle caratteristiche che ne derivano (1.1), rappresentabili attraverso due tipologie di proxy 

server: reverse proxy (1.1.1) e interception proxy (1.1.2). In seguito vengono trattate le 

politiche di rimpiazzamento di un elemento all’interno della cache (1.2). Sono quindi 

12

1. Caching 

evidenziati gli accorgimenti necessari al caching di contenuti di tipo multimediale (1.3). 

Infine viene fatto un breve accenno al caching cooperativo (1.4). 

1.1 Localizzazione di un proxy server 

I proxy server vedono il loro massimo sviluppo e notorietà nella metà degli anni 

novanta, allorquando, con il continuo crescere dei collegamenti ad Internet, era necessario 

sfruttare al meglio le connessioni disponibili, vista la loro banda ridotta e il costo elevato. 

Per tale motivo, inizialmente, il posizionamento dei proxy server è stato pensato in 

prossimità degli utenti finali, proprio al fine di risparmiare banda e ridurre la latenza 

percepita durante la navigazione. Con il passare del tempo però e l’aumentare della 

popolarità di alcuni siti Web, il traffico generato verso tali siti assumeva dimensioni 

considerevoli. Si è quindi pensato di spostare il proxy e di posizionarlo vicino all’origin 

server, al fine di alleggerirne il carico. 

1.1.1 Reverse proxy 

Parlando di un proxy server quindi il suo posizionamento costituisce un elemento 

distintivo, in quanto, proprio in base ad esso è possibile distinguere tra un semplice proxy 

server e un reverse proxy server [Rab01]. Il termine reverse proxy server viene appunto 

usato in contrapposizione al semplice proxy server, proprio per evidenziarne la particolare 

posizione assunta all’interno della catena richiesta-risposta, in cui normalmente il proxy è 

posizionato in prossimità del client. I motivi di un posizionamento siffatto sono 

principalmente da ricondurre, come precedentemente accennato, alla volontà di ridurre il 

carico di quei server molto popolari, soggetti quindi ad un traffico intenso. Un reverse proxy 

infatti viene visto dai client come un origin server che provvede a rispondere alle richieste di 

quest’ultimi, eventualmente reindirizzando tali richieste al proprio origin server, nel caso 

non in sia grado di soddisfarle (richiesta non presente in cache o scaduta). Inoltre, il ruolo di 

un reverse proxy è anche quello di fornire un primo livello di protezione per l’origin server. 

Grazie al proprio posizionamento, esso costituisce una protezione per l’origin server, in 

quanto assicura a quest’ultimo di non essere direttamente visibile ai client e ne impedisce 

13

1. Caching 

così l’esposizione ad attacchi diretti dall’esterno. Attualmente, proprio per la funzionalità di 

snellire il traffico per l’origin server, tali proxy vengono anche chiamati accelerator proxy, 

in quanto contribuiscono a accelerare lo snellimento del traffico e quindi la velocità di 

risposta di un orgin server. 

1.1.2 Interception proxy 

Un altro elemento determinante nella definizione di un proxy server è la propria 

“visibilità” rispetto ai client. Generalmente un proxy posizionato in prossimità dei client si 

prende carico di gestire tutte le richieste e le risposte generate e dirette verso questi ultimi. A 

volte, specialmente nel caso di grandi compagnie, per un amministratore di rete risulta 

difficoltoso impostare un numero elevato di client al fine di utilizzare un proxy. In tal caso 

l’utilizzo di un interception proxy diventa la soluzione ottimale. Come indica il termine 

stesso, una tale tipologia di proxy, tramite l’ausilio di apparecchiature che lavorano ad un 

livello generalmente più basso della pila ISO/OSI (switch e router), è in grado di intercettare 

il traffico generato dai client, senza che questi ne siano al corrente. Non è richiesta infatti 

alcuna configurazione lato client. Inoltre tale soluzione viene sempre più spesso adottata 

dagli Internet Service Provider (ISP), poiché, oltre a non richiedere configurazione per i 

client, risulta di facile gestione in caso di guasti o problemi al sistema: è sufficiente 

“spegnere” l’apparato di rete che intercetta il traffico per direzionarlo al proxy server, per 

eliminare il problema. 

L’intercettazione del traffico può avvenire a differenti livelli, di seguito ne vengono 

elencate le caratteristiche salienti. 

• livello 2: il traffico viene indirizzato dall’apparato di rete (generalmente 

switch) che si occupa dell’intercettazione direttamente alla macchina proxy 

server, utilizzando l’indirizzo MAC di quest’ultima. L’unico inconveniente in 

una tale soluzione è dovuto alla necessità per l’apparato intercettore e il proxy 

server di risiedere nello stesso segmento di rete. 

• Livello 3: in questo caso il traffico di rete viene, tramite la tecnica di IP- 

tunnelling indirizzato al proxy server. Il meccanismo di IP-tunnelling prevede 

l’incapsulamento di un pacchetto IP in un altro pacchetto IP, in cui quello più 

14

1. Caching 

esterno contiene l’indirizzo IP del proxy server. In tal modo, l’elemento 

intercettore e il proxy server possono risiedere in reti differenti. 

• Livello 4: utilizzando uno switching di livello 4 è possibile indirizzare il 

traffico di rete in base alle porte utilizzate verso il proxy server. Infatti, 

generalmente il traffico web transita sulla porta 80, di conseguenza, 

indirizzando il traffico diretto verso tale porta al proxy server è possibile 

intercettare tutto o quasi il traffico web. 

• Livello 7: uno switching di livello 7, lavorando al livello applicazione, 

intercetta anch’esso le richieste di connessione verso un web server 

(generalmente attraverso i pacchetti SYN diretti verso la porta 80), ma, al 

contrario di uno switch di livello 4, non si limita ad indirizzare direttamente i 

pacchetti verso il proxy, piuttosto esegue un handshake TCP (meccanismo 

utilizzato nel protocollo TCP per stabilire una connessione tra un client ed un 

server) con il client, impersonando l’origin server. Solo in seguito, dopo 

l’analisi della richiesta, indirizza il pacchetto verso il proxy, potendo basare la 

propria scelta su una serie di informazioni recuperabili solamente al livello 7, 

quali, per esempio, l’estensione del file richiesto. 

Spesso una tale tipologia di proxy viene indicata erroneamente con il termine di 

transparent proxy, con l’intenzione di riferirsi al fatto che questi proxy risultano 

completamente trasparenti all’utente finale. Tuttavia, in letteratura, la trasparenza di un 

proxy è riferita alle modifiche e all’adattamento del contenuto effettuate, non alla propria 

visibilità verso l’utente finale. 

1.2 Politiche di rimpiazzamento 

L’elemento caratterizzante ogni algoritmo di caching è la politica di rimpiazzamento 

dei documenti in cache, utilizzata per individuare il (o i) documento(i) che deve essere 

eliminato dalla cache quando questa è piena ed occorre inserire un nuovo documento. 

I tre parametri decisionali maggiormente presi in considerazione nelle diverse policy 

sono informazioni di: 

• recency, quanto recentemente un documento è stato acceduto; 

15

• frequency, quanto frequentemente un documento è stato ecceduto; 

• size, quanto “pesa” un documento in termini di dimensione. 

1. Caching 

Alcune politiche di rimpiazzamento (Fig.1-1) prendono in considerazione l’una o 

l’altra informazione, altre ancora tutte e tre le informazioni, insieme ad altri parametri come 

il costo associato ad ogni documento, al fine di prendere le proprie decisioni. 

Fig. 1-1 - Classificazione delle politiche di rimpiazzamento a seconda delle informazioni considerate 

Una classificazione possibile di tali algoritmi di rimpiazzamento, oltre che per queste 

tre informazioni prese in considerazione, è quella che li divide in algoritmi deterministici e 

casuali, in base alla casualità adottata nei criteri di selezione, al fine di ridurre la complessità 

di calcolo [Bal04]. Tale casualità è spesso basata su parametri quali il tempo dall’ultimo 

accesso, il numero di referenze di un documento o la dimensione del documento stesso. 

1.2.1 Algoritmi di rimpiazzamento deterministici 

A partire dalla metà degli anni novanta, vista la sempre maggiore espansione di 

Internet, il caching è stato uno dei maggiori temi di ricerca da parte della comunità 

scientifica che si occupa di sistemi Web, da qui il fiorire di numerose proposte. 

16

1. Caching 

Di seguito sono descritti alcuni degli algoritmi di rimpiazzamento [Bal04] di tipo 

deterministico più comuni. 

LRU (Least Recently Used): algoritmo, insieme l’LFU, tra i più utilizzati. Elimina 

per primi i documenti acceduti meno di recente, sulla base del presupposto che il traffico 

web è soggetto a località temporale. Di conseguenza più tempo è trascorso da quando il 

documento è stato richiesto l’ultima volta e meno probabilmente verrà richiesto nel prossimo 

futuro. 

LFU (Least Frequently Used): algoritmo molto diffuso che elimina per primi i 

documenti acceduti meno frequentemente, sulla base del presupposto che i documenti più 

frequentemente acceduti hanno un profilo di popolarità a lungo termine. Tale algoritmo, 

insieme l’LRU precedentemente descritto, è anche un algoritmo di rimpiazzamento per la 

gestione della cache in un calcolatore. Tuttavia, mentre nel caso di un calcolatore la 

dimensione dell’oggetto da rimpiazzare è fissa, nel caso dei documenti Web vi è una elevata 

variabilità delle dimensioni. 

SIZE: algoritmo che prevede l’eliminazione prima di tutto dei documenti di 

dimensioni maggiori, presupponendo che, proprio a causa delle loro dimensioni, tali 

documenti abbiano scarsa probabilità di essere acceduti di nuovo, visto l’elevato ritardo di 

accesso. 

LOG2-SIZE: analogo al precedente, tuttavia non utilizza solo le dimensioni del 

documento, ma anche la data dell’ultimo accesso come elemento decisionale. Da notare 

inoltre che tale algoritmo risulta meno sensibile del precedente ai piccoli cambiamenti di 

dimensioni, in quanto prende in considerazione log2 (SIZE). 

LRU Threshold: lavora in maniera analoga all’algoritmo LRU, introducendo però un 

limite massimo oltre il quale i documenti non vengono memorizzati in cache. Tale approccio 

cerca di prevenire il rimpiazzamento di numerosi file di piccole dimensioni con uno solo di 

grandi dimensioni . Quindi tende ad assumere implicitamente che un utente non sia portato a 

richiedere nuovamente file con dimensioni maggiori di un certo limite. 

LRU-Min: questa politica lavora in maniera analoga alla precedente, cercando 

tuttavia di essere meno discriminante nei confronti dei documenti di grandi dimensioni. Ogni 

volta che un documento di dimensione S deve essere memorizzato, vengono rimossi 

documenti che hanno dimensione maggiore di S. Se tali documenti non sono presenti, 

17

1. Caching 

l’algoritmo viene ripetuto con S/2, quindi S/4 e così via. In questa maniera LRU-Min tende a 

rimuovere documenti di grandi dimensioni meno frequentemente di LOG2-SIZE. 

Hyper-G: combina LFU, LRU e SIZE. Il suo funzionamento si basa sul rimuovere 

prima il documento usato meno di frequente, nel caso di indecisione tra più di un documento 

viene quindi preso in considerazione quello acceduto meno di recente e come ultima risorsa 

viene considerata la dimensione. 

Pitkow/Recker: è una politica LRU che opera su cicli di un giorno, documenti 

acceduti nello stesso giorno sono assunti avere la stessa informazione di recency. Per gli 

accessi di uno stesso giorno il documento più grande viene rimosso. Questa politica sembra 

implicitamente assumere che gli interessi di un client cambino da un giorno all’altro e che 

questo tenda a concentrare le proprie richieste su un insieme stabilito di documenti. 

All’interno degli algoritmi deterministici, un ruolo particolare lo svolgono le 

function-based policy (politiche basate su una funzione di costo). Queste infatti sono 

anch’esse basate su parametri decisionali. Tuttavia, tali parametri non sono applicati in 

maniera sequenziale, ma sono combinati tra loro e considerati con diversi pesi in una 

funzione di costo. Questi algoritmi quindi mirano a tenere in cache i documenti di “maggior 

valore”, ma possono differire a seconda della definizione della funzione di costo. Di seguito 

vengono elencate alcune politiche di rimpiazzamento tra le più significative appartenenti a 

questa categoria. 

GD-LRU (Greedy-Dual LRU): questa politica assegna per ogni documento p un 

valore H(p) pari al costo necessario per memorizzare tale documento in cache. Ogni volta 

che un documento viene acceduto, il suo valore H viene assegnato pari al costo necessario 

per portare tale documento in cache. Qualora ci sia necessità di memorizzare un nuovo 

documento, viene rimosso dalla cache quello che ha il valore di Hmin minimo, quindi il 

valore H di tutti gli altri documenti viene diminuito di Hmin. 

GDS: questa politica estende la precedente, aggiungendo una informazione relativa 

alla dimensione del documento nel valore H(p) e anche una informazione relativa al tempo. 

In questo modo, tale algoritmo consente sia di favorire la presenza di file di piccole 

dimensioni in cache, sia, tramite l’ausilio della informazione temporale, di evitare di 

mantenere in cache documenti delle “giuste” dimensioni ma poco acceduti. 

18

1. Caching 

LRV (Least Relative Value): tale algoritmo, frutto di studi e analisi statistiche su 

numerose tracce di traffico web, prende in considerazione per la propria funzione di costo 

informazioni quali la probabilità che un documento venga nuovamente richiesto a partire 

dall’ora in cui verrà rimpiazzato e un valore che riflette il guadagno ottenuto dal rimuovere 

tale documento dalla cache. 

LNC-R-W3-U (Least Normalized Cost Replacement for the Web with Update): questa 

politica considera i file come costituiti di tante piccole parti, ognuna di una dimensione 

fissata ed ognuna con un costo assegnato pari al costo del documento diviso per la sua 

dimensione. Partendo da questo principio viene definito quindi un valore di profitto per ogni 

documento e si procede quindi alla sostituzione del documento con il valore di profitto 

minore. 

SLRU (Size-Adjusted LRU): tale algoritmo di rimpiazzamento estende LRU 

attraverso informazioni relative alle dimensioni dei documenti. Il “semplice” LRU 

considerava tutti i documenti come delle stesse dimensioni, limitandosi a rimuove quello 

acceduto meno di recente. SLRU invece, tramite la propria funzione di costo calcola ad ogni 

passo e per ogni documento un valore dipendente sia dall’ora dell’ultimo accesso sia dalle 

dimensioni del documento stesso, rimuovendo il file con il valore più basso. 

Hybrid: politica di rimpiazzamento che prende in considerazione nella propria 

funzione di costo informazioni quali il round trip time dell’origin server e la larghezza di 

banda tra il proxy e il server. 

Inoltre, tiene in considerazione anche il numero di volte che un documento è stato 

richiesto nonché, le sue dimensioni. 

LR (Logistic Regression): algoritmo che usa un modello di regressione logistica per 

acquisire informazioni sui documenti web in una determinata traccia al fine di predire la 

distanza del prossimo accesso per ogni documento in cache. Questo algoritmo “predice” la 

distanza attesa per il prossimo accesso, pesandola con la dimensione del documento stesso, 

quindi, al momento opportuno, rimpiazza il documento la cui distanza attesa e pesata è 

maggiore degli altri. 

Static[Rou97]: politica di rimpiazzamento che basa il proprio funzionamento sul 

presupposto che il traffico che ci si aspetta in un determinato giorno è lo stesso del giorno 

precedente. Di conseguenza ogni giorno, tramite l’analisi dei log del traffico del giorno 

19

1. Caching 

prima, considera i documenti maggiormente visitati e li assume come unici candidati ad 

essere mantenuti in cache per la giornata in corso. 

1.2.2 Algoritmi di rimpiazzamento casuali 

Generalmente, le politiche di rimpiazzamento deterministiche basate su funzioni di 

costo richiedono complesse strutture dati e sono soggette ad un alto carico computazionale, 

che ne limita quindi la scalabilità. L’alternativa è quella di utilizzare un approccio che si basi 

su algoritmici di tipo casuali. 

SLRU- Random: variante casuale dell’algoritmo SLRU, attraverso l’introduzione di 

un indice di “randomicita”, calcolato in base al costo e alle dimensioni del file che determina 

la probabilità con la quale un documento appena acceduto viene messo “in testa” alla cache. 

Di conseguenza, al momento della selezione del candidato alla rimozione, dal momento che 

il documento rimosso è sempre quello in fondo allo stack della cache, può anche capitare che 

il documento nuovo venga direttamente rimosso e quindi non inserito in cache del tutto. 

RANDOM: un algoritmo che cerca di approssimare un qualsiasi algoritmo esistente 

implementandone la casualità. Per raggiungere lo scopo lavora selezionando 

randomicamente un insieme di N documenti e selezionando tra questi il candidato alla 

rimozione in base alla politica di rimpiazzamento utilizzata. 

1.3 Caching di contenuti multimediali 

Gli algoritmi di rimpiazzamento finora considerati vengono utilizzati soprattutto nel 

caso di caching di tipo tradizionale, ovvero di contenuti web statici. Ormai, è però sempre 

più frequente trovare contenuti multimediali che vengono veicolati sulla rete, siano essi 

musica, video o streaming degli stessi. Questa tipologia di informazioni necessita tuttavia di 

trattamenti particolari, che i semplici algoritmi di caching con le proprie politiche di 

rimpiazzamento non prendono minimamente in considerazione. 

Per tali motivi sono possibili una serie di “aggiunte” ai sistemi di caching tradizionali, 

atte a facilitare il trattamento di contenuti multimediali, con particolare attenzione ai 

contenuti veicolati in streaming [Hof99]. 

20

1. Caching 

I sistemi di caching “tradizionale” non considerano due informazioni molto 

importanti nel caso di contenuti multimediali in streaming: 

• la dimensione di un file in streaming (che può raggiungere notevoli 

dimensioni, basti pensare che un film in MPEG-2 di due ore può raggiungere 

senza troppi sforzi i 6GB); 

• il numero di stream contemporanei possibili. 

Per questi motivi, tali sistemi di caching tenderebbero, per esempio, a non 

memorizzare affatto in cache un file multimediale di grandi dimensioni e a saturare la rete, 

rispondendo alle varie richieste di stream in unicast invece che in multicast. 

Al fine di risolvere questi ed altri problemi si possono utilizzare tecniche quali: 

segmentazione, prefix caching, caching dinamico e la codifica a livelli. 

1.3.1 Segmentazione e prefix caching 

La tecnica della segmentazione ed il prefix caching sono strettamente legate. La 

prima consente di suddividere uno stream multimediale di grandi dimensioni in più parti: 

immaginando di avere l’unità minima di allocazione su un disco pari a S, allora ogni stream 

può essere visto con una dimensione pari ad un multiplo di S. Questo consente di salvare in 

cache in maniera indipendente i segmenti più popolari di uno stream, diminuendo anche la 

contesa per lo spazio necessario al caching su disco. La seconda risolve un problema 

introdotto dalla prima, consentendo di memorizzare in cache solo determinati segmenti di 

uno stream multimediale. Il problema infatti che si viene a creare con la segmentazione è 

dovuto al fatto che, a seguito di una richiesta di uno stream, il risultato può essere solo un 

hit parziale, dal momento che soltanto alcuni segmenti dei dati richiesti sono presenti in 

cache. Quindi, sarà necessario reperire altrove i segmenti mancanti, con il rischio di avere 

perdite di sincronizzazione nel flusso multimediale. 

A tal fine, si è pensato ad una unità logica di segmentazione dello stream, il chunck. 

Esso scompone uno stream in una serie consecutiva di chunk, dove ognuno è composto da 

un numero prefissato di segmenti (Fig. 1-2). In tal modo, variando la dimensione del chunk e 

tramite l’ausilio del prefix caching, vengono memorizzati preventivamente un certo numero 

21

1. Caching 

di segmenti per ogni chunk, in modo da consentire il recupero dei segmenti mancanti senza 

incorrere nel rischio di ritardi o perdite di sincronia. 

Fig. 1-2 - Esempio di segmentazione e prefix caching 

1.3.2 Caching dinamico 

La tecnica del caching dinamico consente invece lo sfruttamento ottimale di una 

trasmissione di dati in streaming multicast. Tale accorgimento inoltre risulta particolarmente 

efficace nel caso di video on demand e consiste nel mascherare la distanza temporale 

presente tra due richieste successive di uno stesso streaming. Come mostrato in Fig.1-3, il 

richiedente R1 ha richiesto un determinato stream al server S al tempo t1. In seguito, al tempo 

t2, il richiedente R2 richiede lo stesso oggetto. Al tempo t2 quindi i primi ∆=t2-t1 secondi 

dello stream saranno già stati ricevuti da R1. A questo punto, tramite l’ausilio di un buffer 

circolare che memorizza una finestra temporale mobile di ∆ secondi a partire dal tempo t2, i 

dati inviati ad R1 potranno servire anche per soddisfare la richiesta di R2 ∆ secondi più tardi. 

Il buffer circolare quindi nasconde la distanza temporale tra le due richieste, di conseguenza 

R2 dovrà solamente limitarsi a richiedere il ∆ di stream mancante tramite una operazione 

detta di patching. 

22

1.3.3 Codifica a livelli 

Fig. 1-3 - Funzionamento del caching dinamico 

1. Caching 

Parlando del caching di contenuti multimediali non è da sottovalutare l’impatto della 

rete sulla trasmissione dei contenuti medesimi. Sono molte infatti le variabili che 

influenzano la qualità di un collegamento e che ne provocano un andamento altalenante. 

Possono esserci picchi improvvisi di traffico sia sul server fornitore di contenuti che sulla 

rete stessa tali da provocare una perdita di sincronia o addirittura una interruzione. Tali 

problematiche risultano ancora più evidenti in quelle tipologie di collegamento soggette per 

natura a fenomeni di disturbo, come i collegamenti wireless. Per ovviare a tali inconvenienti, 

è necessario quindi tenere in considerazione la qualità del collegamento ed eventualmente 

adattare dinamicamente la comunicazione. 

Una tecnica possibile è quella di codificare a livelli di differente qualità lo stream che 

si intende trasmettere, così da potersi adattare dinamicamente ad un cambio di qualità del 

collegamento riducendo la qualità dello stream inviato, ovvero trasmettendolo ad un livello 

di qualità inferiore. Questo consente di evitare perdite di sincronia o addirittura interruzioni 

delle stream, sebbene a scapito della qualità percepita. Inoltre, per non incorrere in ritardi 

dovuti al sovraccarico introdotto dalla codifica multilivello dello stream, si può pensare di 

adoperarsi [Zha04] al fine di tenere in cache preventivamente lo stream codificato nei vari 

livelli di qualità, così da essere pronti a rispondere alle esigenze trasmissive del momento. 

23

1.4 Caching cooperativo 

1. Caching 

Quando i proxy furono introdotti generalmente veniva utilizzato un solo proxy nel 

percorso tra il client e l’origin server. Con il passare del tempo e con la crescita della rete il 

numero di proxy che si possono attraversare in tale percorso è andato aumentando sempre di 

più; non è infrequente trovare in una azienda più di un proxy, a seconda del dipartimento. 

Ipotizzando poi di avere un proxy anche dal lato ISP che fornisce la connessione e magari 

anche uno davanti all’origin server, il quadro d’insieme diventa più chiaro. Un discorso 

analogo può essere anche esteso al caso di connessioni ad Internet: per risparmiare sul costo 

della connessione si possono trovare diverse strutture composte da proxy a livello regionale, 

facenti capo ad un proxy centralizzato a livello nazionale. Queste gerarchie di cache hanno 

lo scopo di limitare il più possibile il traffico all’interno dei confini nazionali di una rete, al 

fine sia di limitare la latenza ma anche di mantenere bassi, appunto, i costi di 

interconnessione con l’esterno. 

Tali gerarchi di cache utilizzano solitamente dei protocolli “leggeri” al fine di 

scambiarsi e eventualmente mantenere informazioni sulle risorse disponibili tra i partecipanti 

alla gerarchia stessa. Tutti questi protocolli [Kri01] si basano sul principio che il 

sovraccarico dovuto al reperimento delle informazioni necessarie e dell’eventuale risorsa 

dalle altre cache della gerarchia è comunque minore al tempo necessario per prelevare tale 

risorsa direttamente dall’origin server. I protocolli maggiormente utilizzati sono: Internet 

Cache Protocol (ICP), Cache Array Resolution Protocol (CARP), Cache Digest Protocol 

(Digest) e Web Cache Coordination Protocol (WCCP). 

1.4.1 Internet Cache Protocol (ICP) 

ICP è un protocollo utilizzato per fare interrogazioni, tramite ICP infatti una cache 

client interroga una cache server (tipicamente tramite un messaggio UDP) per sapere se 

possiede o meno una copia in cache di un determinato documento. Quindi, in base alla 

positività o meno della risposta ed alla sua tempestività la cache client deciderà se prelevare 

o meno il documento dalla cache server. Tale modalità di funzionamento ben si adatta al 

caso delle gerarchie di cache, dove più cache (a livello regionale per esempio) fanno capo ad 

una cache centrale (a livello nazionale). Il funzionamento in tale modalità prevede 

24

1. Caching 

l’interrogazione di tutte le cache di pari livello (regionali), nel caso non si abbia nessuna 

risposta positiva la cache centrale (nazionale) provvede a ripetere la procedura al proprio 

livello di appartenenza interrogando le altre cache regionali ed, eventualmente, estendendo a 

sua volta l’interrogazione a livelli di cache ad essa superiori. In caso di mancata risposta 

positiva o comunque di timeout, la cache scatenante l’interrogazione utilizza come ultima 

risorsa l’origin server. Infine, per ottimizzare ulteriormente l’architettura, è previsto che una 

cache nel tragitto tra cache client e cache server memorizzi nella propria cache la risorsa 

eventualmente trasferita per usi futuri. 

Lo svantaggio derivante dall’utilizzo di ICP è dovuto ai ritardi via via crescenti che 

vanno a sommarsi ogni volta che la query ICP sale di livello nella gerarchia di cache, dovuti 

sia alla latenza introdotta dall’attesa della risposta all’interrogazione ma anche dall’eventuale 

percorso a ritroso che deve fare la risorsa una volta individuata. 

1.4.2 Cache Array Resolution Protocol (CARP) 

CARP definisce un meccanismo attraverso il quale un insieme di cache può 

effettivamente funzionare come una unica grande cache a livello logico. Per effettuare il 

partizionamento delle url viene utilizzata una funzione di hash che dovrà essere utilizzata 

quando il client interrogherà una cache per sapere dove indirizzare la propria richiesta 

relativamente ad una determinata risorsa. Tale funzione utilizza l’url della risorsa richiesta e 

l’identificativo della cache appartenente alla grande “cache logica” per costruire un percorso 

univoco che porta alla risorsa di interesse. Di conseguenza, diversamente dall’ICP, il CARP 

utilizza un percorso deterministici per arrivare alla risorsa, eliminando quindi la necessità di 

qualsiasi messaggio di interrogazione. Per consentire la comunicazione tra cache CARP 

utilizza sia l’http che interfacce di chiamata a procedura remota. 

Gli svantaggi derivanti dall’uso di tale architettura sono da ricercarsi 

nell’impossibilità di effettuare del load balancing tra le cache, dal momento che non è 

possibile trovare la stessa url in due proxy. Sempre per tale motivo, l’uso del CARP può 

portare al sovraccarico sistematico di determinati proxy “colpevoli” di contenere le url 

maggiormente richieste. 

25

1.4.3 Cache Digest Protocol (Digest) 

1. Caching 

Digest è una estensione dell’ICP. L’idea che ne è alla base è quella di consentire lo 

scambio di una sorta di “sommario” (digest appunto) del contenuto di una cache tra le cache 

stesse. Un digest quindi altro non è che una sorta di descrizione “stringata” del contenuto di 

una cache, un indicatore degli oggetti in essa contenuti. Una volta ottenuti i vari digest 

quindi una cache può analizzarli per capire chi è in possesso o meno della risorsa che 

necessità, decidendo anche a chi eventualmente indirizzare la richiesta tra tutti quelli che 

possiedono tale risorsa. In questo modo una cache può risparmiarsi di contattare le cache che, 

secondo i propri digest, non risultano avere disponibile la risorsa in questione. 

Il problema che questa architettura viene tuttavia a creare è derivante dai falsi contatti 

positivi che possono verificarsi a seguito di un digest non aggiornato. Così come non è da 

sottovalutare il sovraccarico della rete dovuto allo scambio continuo di tali informazioni, dal 

momento che queste informazioni possono essere diffuse sia su UDP, che tramite semplice 

http su TCP quindi. 

1.4.4 Web Cache Coordination Protocol (WCCP) 

Differentemente da protocolli di alto livello come ICP e CARP, WCCP lavora a 

stretto contatto con i protocolli di livello rete: lo scopo del WCCP infatti è quello di 

intercettare le richieste http e di ridirezionarle ad un motore di cache, con lo scopo di 

bilanciare il carico tra le varie cache presenti. Inoltre, per evitare di inviare richieste ad una 

cache non più disponibile, provvede a tenere traccia delle cache attive tramite interrogazioni 

periodiche. 

Questo meccanismo è implementato come parte del Cisco Cache Engine all’interno 

dei router. Tali dispositivi infatti, qualora abilitati all’uso del WCCP, sono capaci di 

analizzare l’header IP e di ridirezionare quindi un pacchetto TCP destinato alla porta 80 al 

motore di cache che si occuperà poi di indirizzarlo alla cache più adatta. 

26

2 Connessioni satellitari 

2. Connessioni satellitari 

Il progetto su cui verte il lavoro di tesi prevede come scenario di applicazione il caso 

di una fornitura di servizi Business To Business: un ISP che rivolge la propria offerta di 

connessione ad Internet, tramite canali satellitari su satelliti geostazionari, ad altri ISP che si 

trovano in condizioni tali da non poter usufruire di una connessione terrestre a banda larga. 

In tali condizioni, spesso dovute ad un posizionamento geografico poco “fortunato”, una 

connessione satellitare risulta essere la via più rapida e “indolore” per ottenere un 

collegamento ad Internet veloce. 

In questo capitolo verranno inizialmente evidenziati i problemi che normalmente 

caratterizzano una connessione ad alta latenza come quella satellitare (2.1) e in seguito 

analizzate (2.2) alcune tra le soluzioni proposte per il superamento di tali problemi: quali la 

soluzione del consorzio AI3 (2.2.1), quella di Hughes Network System (2.2.2), la soluzione 

di INTELSAT (2.2.3) e infine quella di SatCAST (2.2.4). Il fine è quello di mostrare 

l’evoluzione del mercato e gli sviluppi che ci sono stati nel corso degli anni relativamente 

alle architetture di proxying/caching per canali di trasmissione satellitari, ma anche quello di 

trarre spunto e insegnamento dalle esperienze passate, evidenziando gli elementi più 

interessanti emersi nel corso dell’analisi (2.3). 

2.1 Problematiche di una connessione satellitare 

La natura del canale satellitare (broadband), attraverso l’utilizzo di satelliti 

geostazionari, consente di creare facilmente delle connessioni con una ampia copertura, 

nonché di trasmettere simultaneamente molteplici informazioni. 

Tuttavia, l’utilizzo del canale satellitare non è privo di problematiche, prima fra tutte 

la latenza insita nel canale stesso [Bha04]. L’utilizzo di satelliti geostazionari e la loro 

distanza dalla terra provoca dei ritardi nella propagazione delle onde tra il satellite e una 

stazione terrestre (e viceversa), quantificabili nell’ordine di un ottavo di secondo. E’ quindi 

facile calcolare che il RTT di una connessione satellitare si attesta nell’ordine del mezzo 

secondo (che corrispondono a circa un ottavo di secondo sia per la tratta di uplink sia per la 

tratta di downlink e quindi, un totale di mezzo secondo per andare e tornare). Questa latenza 

27


viene poi ulteriormente amplificata, soprattutto nel caso di utilizzo del protocollo HTTP, da 

altri fattori quali: 

• Three-Way-Handshaking del TCP (sul quale poggia l’HTTP), necessario per 

effettuare una connessione client-server; 

• Maximum Segment Size (MSS) del TCP che tipicamente ammonta a 536 byte, 

costringendo alla divisione di una singola richiesta HTTP in più segmenti; 

• Slow Start Algorithm del TCP che, per le nuove connessioni o anche in caso 

di timeout, rallenta la trasmissione iniziale; 

• Controllo del flusso proprio del TCP che impedisce l’invio di nuovi dati se 

non si è ricevuto un ACK dei precedenti. 

Tutto ciò evidenzia come una richiesta HTTP possa aver bisogno di numerosi RTT 

prima di essere soddisfatta, soprattutto nel caso di pagine Web composte da diversi oggetti, 

rendendo quindi la navigazione web una esperienza poco “piacevole”. 

2.2 Soluzioni possibili 

Considerati i problemi precedentemente descritti, la strada che si è cercato di 

intraprendere porta al mascheramento della latenza insita nel canale satellitare, al fine di 

rendere la navigazione attraverso questa tipologia di connessioni quanto più vicina possibile 

ad una navigazione tramite connessioni terrestri. A tal fine, risulta evidente come l’utilizzo 

di un proxy possa essere di grande aiuto nella soluzione del problema: opportunamente 

posizionato (a valle di una connessione satellitare) esso può fornire direttamente i contenuti 

richiesti, eliminando la necessità di transitare per il canale satellitare. 

Diverse sono state le architetture proposte e sviluppate in tal senso, di seguito ne 

vengono descritte alcune tra le più significative. 

2.2.1 AI3 Network: Adaptive WWW Caching 

La Asian Internet Interconnection Initiatives (AI3) è una testbed network 

[Ino96],[Ino97] costituita da un consorzio di diversi istituti di ricerca della regione asiatica, 

tra i quali il NAIST (Nara Institute of Science and Technology, Giappone), l’AIT (Asian 

28


Institute of Technology, Thailandia), l’ITB (Institut Teknologi Bandung, Indonesia) e 

HKUST (Hong Kong University of Science and Technology, Hong Kong). L’installazione 

della rete è iniziata nel 1996 e in Fig.2-1 è possibile notare lo stato attuale della stessa e la 

sua topologia. Attualmente, la stazione di terra, così come l’hub principale, è localizzata 

presso il NAIST in Giappone; da qui si diramano diversi link a 1.5Mbps verso l’Indonesia, 

Honk Kong, la Thailandia ed altri paesi partner. Il protocollo implementato è l’IPv4, ma, 

vista la proprio natura (testbed network), saranno implementati anche IPv6 e altre tecnologie 

quali RSVP e M-Bone. Tra le varie ricerche portate avanti ci sono, appunto, quelle 

riguardanti il caching di contenuti web. 

In questa testbed network è presente una struttura di caching articolata in due livelli. 

Il primo livello (Hub Cache) è rappresentato da un centro di trasmissione in Giappone, 

direttamente connesso ad Internet tramite una connessione T3 e collegato via satellite con le 

varie cache di secondo livello (Rim Cache), sparse per il continente asiatico, tramite una 

connessione satellitare bidirezionale asimmetrica, che prevede una velocità in downstream di 

1.5Mbps e in upstream di 512Kbps. 

Fig. 2-1 - AI3 Testbed Network 

29


L’architettura utilizzata (Fig.2-2) prevede l’utilizzo del prefetching sia lato Hub 

cache sia lato Rim cache, tramite un meccanismo di caching adattativo. Questo perché, per 

quanto il prefetching costituisca una valida soluzione al problema della latenza del canale 

satellitare, non si può non considerare l’aumento di traffico apportato dall’utilizzo di una tale 

soluzione. Da notare infatti come un server situato al NAIST, attraverso l’utilizzo del 

prefetching abbia incrementato del 20% l’Hit Rate, aumentando tuttavia anche il traffico 

Web del 200%. A tale scopo, l’AI3 ha proposto dei meccanismi di “smart caching” o 

caching adattativo allo scopo di migliorare la latenza dei link satellitari più lenti, tramite 

l’utilizzo del prefetching basato su pattern di accesso precedenti, accesso ritardato, 

aggiornamento automatico notturno (momento di minor carico) e compressione dei file. 

Tale meccanismo di caching analizza i log di accesso per decidere le risorse sulle 

quali effettuare il prefetching. Mentre sulla Hub cache il prefetching è effettuato solamente 

nei momenti di minor carico, sulle Rim cache, invece, è attivo un agente che attua il 

prefetching in maniera più sofisticata. 

I compiti dell’agente infatti prevedono: 

• analisi dei log per la determinazione degli oggetti sui quali effettuare il 

prefetching, costruendo degli schemi di accesso che legano gli oggetti 

strutturati (per esempio le pagine Web che contengono al loro interno link ad 

altre pagine e/o oggetti) a quelli che essi stessi referenziano direttamente, 

associando anche la frequenza delle referenze medesime; 

• tenere traccia delle dimensioni di un file e del tempo necessario al suo 

reperimento, in modo da decidere dinamicamente l’eventuale convenienza 

nell’effettuare il prefetching dello stesso (per esempio, se il tempo per 

scaricare un file risulta comunque molto superiore al RTT della connessione 

satellitare, non ne viene eseguito il prefetching); 

• analisi del traffico e della congestione del canale satellitare, al fine di decidere 

l’eventuale posticipazione delle operazioni di prefetching in un momento in 

cui il canale sia meno congestionato; 

• monitoraggio della cache ad esso associata in modo da rilevare eventuali 

rallentamenti dovuti alla congestione della stessa e tali da richiedere quindi 

una operazione di manutenzione, portando all’eliminazione dei file più vecchi. 

30

Fig. 2-2 - Architettura della soluzione AI3 per il web caching 

2.2.2 Hughes Network Systems: Cumulative Caching 


Gli studi condotti dalla Hughes Network Systems insieme alla NASA hanno lo scopo 

di ridurre, tramite un meccanismo di Cumulative Caching, la latenza percepita da un gruppo 

di utenti che utilizzino un sistema di navigazione satellitare fornito dalla Hughes Network 

Systems stessa, avente come target una utenza di tipo SO-HO [Bha04] (Small Office-Home 

Office, utenza costituita da piccoli uffici, spesso abitazioni private). 

I presupposti alla base di tale meccanismo di caching sono forniti da alcuni studi 

[Mog97], che hanno portato in evidenza che: 

• utenti appartenenti ad una stessa area geografica sono portati a visitare gli 

stessi siti web, a causa spesso di ragioni relative al mirroring dei siti stessi; 

• utenti appartenenti ad uno stesso ambito lavorativo tendono a visitare una 

stessa tipologia di siti web. 

L’algoritmo di cumulative caching quindi è stato pensato sulla base di tali 

considerazioni e sugli studi relativi all’applicabilità alla navigazione web del principio di 

Pareto (anche noto come regola dell’80/20), in base al quale l’80% circa delle richieste 

HTTP sono dirette verso il 20% delle risorse disponibili, mentre il rimanente 20% delle 

31


richieste è diretto verso il rimanente 80% delle risorse. Lo scopo del caching cumulativo 

quindi è stato quello di riuscire a salvare in cache almeno quel 20% delle risorse online, che 

però consente all’80% degli utenti di non percepire la latenza del canale. 

Il sistema di navigazione satellitare considerato come target dagli ideatori di questo 

algoritmo è lo Spaceway della Hughes Network Systems (Fig.2-3), costituito da un sistema 

di connessione ad Internet tramite link satellitari (satelliti geostazionari) bidirezionali a larga 

banda. In prospettiva di utilizzo SO-HO, è stata prevista la possibilità di integrare le 

funzionalità di caching cumulativo direttamente all’interno del set-top box che lavora a 

livello network ed è direttamente collegato al ricevitore satellitare. Fornendo infatti tale 

apparecchiatura di una memoria addizionale e consentendogli di lavorare a livello 

applicativo, sarebbe possibile realizzare quanto richiesto. Tuttavia, tale soluzione, potrebbe 

risultare economicamente svantaggiosa per il fornitore di servizi, poiché il costo del set-top 

box aumenterebbe in maniera proporzionale allo spazio di cui viene dotato. Opzionalmente, 

quindi, è stata prevista la possibilità di implementare la soluzione di caching cumulativo 

direttamente all’interno del computer di un utente, dove parte della memoria, attraverso un 

processo demone, potrebbe essere assegnata a tale scopo. 

Il principio che è alla base dell’algoritmo di caching cumulativo è alquanto 

semplice: memorizzare in cache tutto quello che viene richiesto. Il suo funzionamento 

prevede lo svuotamento della cache ogni 24 ore, nel momento di minor utilizzo del sistema, 

e il successivo riempimento con tutto quello che è stato visitato dagli utenti. 

Fig. 2-3 - Hughes Network Systems SPACEWAY 

32


Il funzionamento dell’architettura è il seguente: quando lo stesso client o un altro 

client richiedono una stessa pagina, viene restituita la versione memorizzata nella cache 

locale. Allo stesso tempo, viene inviato il timestamp della pagina richiesta attraverso il 

canale satellitare fino al Network Operation Center (NOC). Qualora questo abbia una 

versione più recente di tale pagina in cache, provvede ad inviarla al client attraverso il canale 

satellitare, quest’ultimo genera la nuova pagina e provoca un auto-refresh del browser. 

Simultaneamente, il NOC controlla se esiste online una versione più aggiornata della 

suddetta pagina e, in caso affermativo, si occupa di inviarla ancora una volta al client che a 

sua volta la aggiornerà al browser. Infine, il NOC aggiorna e controlla le pagine che ha 

salvato in cache, indipendentemente dalle richieste del client. 

Questo algoritmo di caching cumulativo è differente dal prefetching, in quanto molto 

più semplice. Non è presente infatti nessun algoritmo di fetching, semplicemente le pagine 

che non sono mai state richieste prima vengono prelevate direttamente online. 

E’ tuttavia interessante notare come, nonostante la sua apparente semplicità, i risultati 

ottenibili da tale architettura possono portare benefici consistenti, in termini di riduzione 

della latenza percepita, oscillanti tra il 40% e il 70%. 

2.2.3 INTELSAT Internet Delivery System (IDS) 

L’Internet Delivery System della INTELSAT (che possiede il più grande sistema 

commerciale di comunicazioni satellitari) è una implementazione prototipale del concetto di 

wormhole caching. Iniziato come un progetto di ricerca e sviluppo volto ad evidenziare la 

natura broadcast del canale satellitare, si è evoluto in una piattaforma di web caching 

multicast. In questa piattaforma, i contenuti web sono inviati in pushing o in prefetching in 

grossi repository (Warehouse) localizzati vicino ai fornitori di servizi. Tale contenuto Web 

viene quindi inviato in pushing attraverso IP multicast su link satellitari ai Kiosk, distribuiti 

in tutto il mondo, che ne avevano fatto sottoscrizione. Un canale di ritorno dal Kiosk alla 

Warehouse è utilizzato per costruire dinamicamente canali di push. 

Le motivazioni che hanno condotto gli studi della INTELSAT [Mat99] si basano 

sull’idea che, attualmente, non c’è una distribuzione uniforme del traffico in Internet: client 

di ogni paese del mondo accedono a contenuti che vengono prodotti in pochi regioni dello 

33


stesso. Lo scopo dell’architettura proposta è quindi quello di creare dei veri e proprio canali 

preferenziali multicast nello spazio (wormhole caching), al fine di “saltare” i lenti e 

imprevedibili percorsi internazionali che si diramano attraverso numerosi router, bridge e 

switch. 

L’IDS della INTELSAT [Che99] quindi, come precedentemente accennato, è basato 

su un paradigma di caching a due livelli (Warehouse-Kiosk), e fornisce accesso globale e 

canali preferenziali attraverso la flotta di satelliti della INTELSAT stessa. Contenuti come 

oggetti Web, FTP o streaming vengono scaricati o “spinti” (pushing), sia attivamente che 

reattivamente, in un repository centrale attraverso degli agenti web intelligenti. Oggetti 

“freschi” vengono costantemente inviati attraverso IP Multicast a cache Kiosk registrate. 

Il sistema IDS della INTELSAT si compone di quattro elementi principali: 

1. Content Management Subsystem: una interfaccia web che fornisce 

funzionalità per configurare, controllare il sistema e gestire i contenuti web, 

quali la registrazione, la categorizzazione e la creazioni di canali di contenuti, 

nonché l’analisi statica dell’utilizzo degli oggetti web nel sistema. 

2. Persistent Storage Subsystem: un database relazionale orientato al caching 

che immagazzina i metadati degli oggetti web, i log di utilizzo e altre 

informazioni come i contenuti delle categorie e i canali sottoscritti. 

3. Multicast Transmission Subsystem: un sistema di trasmissione multicast 

affidabile con capacità di scheduling, accorpamento dei contenuti e 

compressione/decompressione degli stessi. 

4. Web Caching Subsystem: un sistema di caching a due livelli (Fig.2-4), basato 

su Squid [Squ05a] che implementa agenti intelligenti e un nuovo metodo di 

pushing insieme al tradizionale meccanismo di caching. Lato warehouse è 

presente una cache centrale che si interfaccia con i content provider, mentre 

lato Kiosk sono utilizzate delle web cache che accettano sia richieste push sia 

le più tradizionali richieste pull. 

34

Fig. 2-4 - Architettura INTELSAT IDS 


Gli elementi di maggior interesse, nonché i più caratterizzanti l’architettura della 

INTELSAT sono il reactive caching ed il metodo HTTP PUSH. 

Il primo consiste in una serie di processi distribuiti atti a raccogliere ed analizzare i 

comportamenti degli utenti registrati ai Kiosk, in modo da adattarsi dinamicamente al 

comportamento degli stessi. Periodicamente, ogni Kiosk invia le proprie statistiche locali di 

accesso web alla Warehouse. Questa possiede l’intelligenza necessaria a reagire a nuove 

attività o a picchi improvvisi, secondo un algoritmo apposito che prende in considerazione il 

numero di Kiosk e il numero di utenti al fine di decidere quando un nuovo documento può 

essere ritenuto popolare. A questo punto, tale documento viene aggiunto dinamicamente ad 

un canale di push, che verrà in seguito aggiornato in multicast ai Kiosk. Qualora la pagina 

non fosse più ritenuta popolare, tale documento viene rimosso da qualsiasi canale di push al 

quale era stato precedentemente aggiunto. 

Il metodo HTTP PUSH, proposto come aggiunta agli altri già presenti nel protocollo 

HTTP, consente l’inserimento diretto di oggetti nella cache Warehouse e in quella dei Kiosk, 

aumentando le semplici funzionalità “pull” offerte dalle cache tradizionali. Al fine di 

35


effettuare l’operazione, è necessario un client-push abilitato che invia alla cache una 

richiesta PUSH. Questa, similmente ad una normale PUT HTTP, contiene un header e un 

body con l’oggetto da inviare. La cache, al momento della ricezione di una PUSH, controlla 

in una Push Control List (PCL) se il client è autorizzato, prima di processare la richiesta 

stessa. Verificata l’autorizzazione, se l’oggetto è già presente in cache, ne viene verificata la 

“freschezza” e quindi eventualmente viene sostituito quello già presente (caso di risposta 

HTTP con un codice 207, PUSH created). Nel caso l’oggetto non fosse invece presente in 

cache, viene in essa memorizzato (caso di risposta HTTP con un codice 200, OK). Quindi 

questo metodo, come mostrato in Fig.2-5, consente di inserire un oggetto HTTP, ricevuto 

tramite un canale multicast o una altra sorgente, direttamente all’interno di una catena di 

proxy in modo rapido ed efficiente, senza richiedere l’intervento diretto dell’utente. 

Fig. 2-5 - Uso del pushing in una catena di proxy 

2.2.4 SatCAST: multicast via satellite per applicazioni web 

Il sistema SatCAST [Lin01] è stato sviluppato dalla West Consulting B.V. e 

dall’Università di Salisburgo, nell’ambito del programma Advanced Satellite Technology 

(ASTE) dell’Agenzia Spaziale Europea (ESA). 

L’idea alla base di tale progetto risiede nella considerazione che, attualmente, una 

parte sostanziale del traffico Internet viene da applicazioni dove dei client richiedono oggetti 

che risiedono su server. Quindi, il caching di tali oggetti vicino a tali client è una tecnica 

importante per ridurre sia il traffico di rete che il tempo di risposta di questo tipo di 

applicazioni. Tuttavia, l’utilizzo di tecniche normalmente applicate alle reti terrestri, non 

consente di trarre grandi benefici, vista la sostanziale differenza nella distribuzione del 

tempo nei canali satellitari. Di conseguenza, i canali satellitari, grazie alla propria natura 

broadcast, devono essere trattati differentemente dalle reti terrestri, sfruttando, appunto, le 

36


caratteristiche proprie di questo mezzo di trasmissione e tenendo però in debita 

considerazione le peculiarità relative ai tempi di risposta. 

Per portare avanti questo progetto è stata utilizzata nell’ambito dell’UNEP (United 

Nation Enviroment Programme) la rete di telecomunicazioni Mercure, composta da un serie 

di stazioni terrestri comunicanti attraverso canali satellitari bidirezionali su satelliti 

INTELSAT. Attualmente, sono state costruite 16 stazioni presso le seguenti località: 

Antwerpen, Vienna, La Paz, Havana, San Jose, Geneva/Leuk, Nairobi, Arendal, Beijing, 

Bangkok, Hanoi, Kathmandu, Maputo, Manama e Almaty. Infine, è presente una struttura di 

controllo posizionata in Svizzera per assicurare un livello di servizio uniforme a prescindere 

dalle differenti reti pubbliche. In Fig.2-6 è mostrata la parte centrale della topologia di rete, 

costituita da siti interconnessi permanentemente tramite dei link satellitari a 128Kbps o 

384Kbps 

Fig. 2-6 - Topologia dei core-link della rete Mercure 

La rete implementa IPv4 e la propria filosofia di funzionamento è quella di “servizio 

locale per utenti locali”. Con questo si intende che le informazioni create e aggiornate nei 

diversi siti della rete (pagine Web o database dai quali vengono create le pagine Web stesse) 

vengono aggiornate regolarmente in maniera automatica, inviandole agli altri nodi della rete. 

Questo permette a chi ricerca informazioni un accesso facilitato e rapido attraverso qualsiasi 

37


nodo della rete. Fino alle modifiche apportate dalla SatCAST, gli aggiornamenti dei database 

venivano effettuati in modalità punto-punto, tramite l’utilizzo del protocollo TCP. Al fine di 

ottimizzare l’utilizzo dei link satellitari, quest’ultima ha sviluppato un sistema di proxying 

basato su un meccanismo di pushing multicast, rimpiazzando il TCP tramite un protocollo di 

multicast affidabile. 

Infatti, un modo efficace per effettuare operazioni di replicazione di dati è quello di 

utilizzare un protocollo di multicast come protocollo di livello transport tra i proxy, fermo 

restando la possibilità per la rete sottostante di utilizzare il multicast su protocollo IP. In tal 

modo, è possibile effettuare un’unica trasmissione dei dati, mentre con un più tradizionale 

protocollo unicast il numero di trasmissioni dipende direttamente dal numero di riceventi e 

può portare quindi rapidamente a problemi di scalabilità. Tuttavia, il multicast è stato finora 

sempre utilizzato per applicazioni quali lo streaming audio e video, che quindi non 

necessitavano di una particolare affidabilità implementandola a livello applicativo. Nel caso 

di replicazione di dati (del quale la cache costituisce una particolare specializzazione) è 

sicuramente conveniente avere la possibilità di utilizzare un protocollo di multicast affidabile 

a livello transport. Proprio in questo ambito ha operato la SatCAST attraverso 

l’implementazione del RRMP, Restricted Reliable Multicast Protocol. 

L’architettura sviluppata prevede l’utilizzo del proxy server Squid, coadiuvato da 

agenti di multicast MCast che agiscono come peer-cache per Squid e comunicano tra di loro 

attraverso il protocollo RRMP. Questo protocollo utilizza un trasferimento dati senza prima 

effettuare alcuna connessione di rete, questo al fine di evitare i problemi derivanti 

dall’utilizzo di una procedura di handshake, ovvero l’introduzione di un ritardo significativo, 

soprattutto nei casi di brevi trasmissioni di dati su link ad alta latenza, come quelli satellitari. 

Inoltre, la SatCAST ha provveduto a rendere affidabile tale protocollo di multicast attraverso 

l’utilizzo di differenti schemi di controllo di errore, per adattarsi alle necessità delle varie 

applicazioni: 

• multicast semi-affidabile, attraverso l’uso della tecnica di Forward Error 

Correction (FEC); 

• multicast completamente affidabile, attraverso l’utilizzo del FEC, 

congiuntamente ad un meccanismo di un ARQ (Automatic Request- 

Response) basato su Negative Aknowledgement (NAK). Il funzionamento 

38


prevede, nel caso del rilevamento di una errore (perdita di dati) da parte del 

ricevente, l’invio di un NAK al mittente. Questo risponderà con dei pacchetti 

FEC al fine di permettere al ricevente di ricostruire quanto perso; 

• multicast affidabile e proattivo, combinazione dei due precedenti. In questa 

modalità, i dati FEC sono sempre inviati insieme ai dati originali. 

Fig. 2-7 - Archietettura della SatCAST con Squid e agenti MCast 

In Fig.2-7 è mostrato un esempio di funzionamento dell’architettura della SatCAST. 

Procedendo per ordine: 

1. Un client invia una richiesta HTTP per una URL. 

2. Squid (supponendo di non avere a disposizione il file in cache) ricerca 

all’interno del proprio file di configurazione il cache-peer al quale inoltrare la 

richiesta (il proprio agente MCast). 

3. Squid inoltra la richiesta al proprio agente MCast. 

39


4. L’agente MCast inoltra la richiesta in multicast attraverso la rete satellitare. 

5. Gli agenti MCast agli altri capi dei link ricevono le richieste e le inoltrano ai 

propri Squid. 

6. Squid ricerca all’interno del proprio file di configurazione se la richiesta è 

indirizzata localmente: 

a. in caso affermativo, invia la richiesta HTTP al server WWW locale 

che possiede i dati; 

b. altrimenti, invia la richiesta HTTP al proprio agente MCast locale. [il 

prossimo passo è il passo 10] 

7. Il server WWW locale invia la risposta HTTP a Squid. 

8. Squid invia la risposta HTTP al proprio agente locale MCast. 

9. L’agente MCast invia la risposta in multicast alla rete satellitare. 

10. Gli agenti MCast agli altri capi dei link ricevono le risposte e le inviano ai 

propri Squid. 

11. Squid memorizza la risposta nella cache locale. 

12. Squid invia le risposte HTTP: 

a. al client (se il client ha effettuato la richiesta HTTP); 

b. all’agente MCast (se l’agente MCast ha effettuato la richiesta HTTP). 

2.3 Considerazioni sulle soluzioni proposte 

Nella sezione precedente sono state descritte alcune tra le soluzioni più significative 

nell’ambito dei sistemi di proxying/caching per contenuti fruibili attraverso connessioni 

satellitari. Da una prima analisi risultano evidenti diversi elementi caratterizzanti le soluzioni 

mostrate, dai quali è stato possibile trarre spunto per una successiva fase di progettazione: 

• un sistema di proxying/caching su doppio livello, un primo livello a monte 

del satellite e un secondo livello a valle del satellite; 

• sfruttamento massimo di un’architettura su due livelli, spesso utilizzando un 

unico livello superiore (a monte del satellite) per numerosi livelli inferiori (a 

valle del satellite); 

40


• utilizzo di Squid [Squ95a] come software proxy server, uno tra i più diffusi e 

riconosciuti (nonché open source); 

• uso di tecniche di pushing o prefetching al fine di mascherare la latenza insita 

nella natura stessa del canale satellitare; 

• utilizzazione del multicast come complemento ideale alle tecniche di pushing, 

allo scopo di ottimizzare al massimo lo sfruttamento della banda; 

• tecniche di analisi del traffico in modo da consentire una selezione mirata 

delle informazioni necessarie, prelevate in seguito attraverso pushing o 

prefetching. 

E’ infine interessante notare come la maggior parte delle soluzioni analizzate sono 

state sviluppate in un periodo di tempo relativamente breve, tra il 1996 e il 2001. Segno 

evidente di come, con il passare del tempo, sia sempre più diffusa la connessione a larga 

banda, tale da rendere economicamente poco “appetibile” l’utilizzo di una connessione 

satellitare in ambito trasmissione dati. 

41

3. Progettazione e architettura del sistema SatSquid 

3 Progettazione e architettura del sistema 

SatSquid 

Tutta la fase di definizione e progettazione dell’architettura di caching satellitare 

SatSquid è stata guidata principalmente dai problemi derivanti dalla natura del canale 

trasmissivo utilizzato: la connessione satellitare. Il problema più grande da affrontare, nel 

caso di utilizzo di tale mezzo di comunicazione, è infatti la latenza insita nel canale stesso, 

ben 500msec di ritardo per ogni richiesta, che si vanno a sommare al ritardo normalmente 

necessario ad esaudire la richiesta stessa. Se consideriamo tutte le interazioni necessarie 

anche solo per scaricare una semplice pagina web, ci rendiamo conto che tale ritardo diventa 

“insopportabile” per un utente che si accinge ad utilizzare tale mezzo per navigare su 

Internet. Lo scopo principale che si è cercato di raggiungere è stato quindi il mascheramento 

di tale latenza. A tal proposito in questo capitolo saranno inizialmente mostrati quelle che 

sono state le ipotesi e le problematiche di partenza (3.1), quindi le scelte di progetto fatte per 

risolvere tali problematiche, quali la scelta del software di proxy server da utilizzare (3.1.1), 

l’utilizzo di un doppio livello di caching (3.1.2) e di una doppia istanza di Squid (3.1.3), la 

scelta del meccanismo atto a mascherare la latenza del canale (3.1.4), l’uso di una tecnica di 

content switching per smistare le richieste (3.1.5), la logica di controllo alla base del 

funzionamento dell’architettura (3.1.6) e infine un attento dimensionamento hardware 

dell’impianto (3.1.7). Verranno quindi presentate le possibili architetture derivanti dalle 

scelte effettuate in fase di progetto (3.2), pushing vs. prefetching (3.2.1), la tecnologia 

impiegata per effettuare l’indirizzamento delle richieste (3.2.2) e la possibilità di un sistema 

dedicato per il mirroring dei siti (3.2.3). Infine sarà presentata l’architettura scelta (3.3). 

3.1 Le scelte progettuali 

Prima di iniziare a discutere la progettazione del sistema di caching satellitare 

SatSquid, è necessario inquadrare meglio il contesto di utilizzo di tale sistema, quello 

dell’Internet Service Providing. L’azienda committente vuole infatti proporsi come fornitrice 

di connettività attraverso canali satellitari a tutti quegli Internet Service Provider che per 

motivi vari non possono utilizzare connettività terrestre a larga banda. L’interesse di tale 

42


iniziativa è anche rivolto verso quelle aziende in forte espansione, con una vasta presenza sul 

territorio e che hanno quindi la necessità di collegare tra loro le sedi periferiche con la sede 

centrale, eliminando la necessità di transitare sulla rete pubblica, sia per questioni di 

sicurezza dei dati in transito, sia per ridurre la possibilità di ritardi o difficoltà di connettività 

non direttamente controllabili. 

Lo scopo principale è quindi quello di rendere “appetibile” l’offerta del servizio di 

caching satellitare, cercando di avvicinare quanto più possibile la qualità del servizio offerta, 

percepita dall’utente finale, da una connessione satellitare ad una normalmente offerta da reti 

cablate. 

A questo punto, è necessario sottolineare quelli che sono stati i presupposti alla base 

del progetto, direttamente forniti dal committente: 

• basso costo delle capacità di storage: attualmente è diventato abbastanza 

economico assemblare sistemi con capacità disco nell’ordine dei terabyte; 

• larga banda satellitare a disposizione: l’intenzione dietro questa ipotesi è 

quella di costruire un satellite espressamente dedicato alla trasmissione dati, 

quindi appositamente bilanciato sulla base delle necessità operative. 

Come sarà meglio evidenziato in seguito, nonostante queste due ipotesi siano state 

tenute in grande considerazione durante tutta la fase di progettazione, non è stato possibile 

avvantaggiarsi da entrambe, ma solamente dalla prima. Infatti, la possibilità di avere a 

disposizione uno spazio disco di grande dimensioni, non necessariamente porta benefici al 

caching. 

Le problematiche da affrontare sono state principalmente due: 

• ritardo insito nella natura stessa del canale satellitare; 

• necessità di avere funzionalità di mirroring di siti web (richiesta esplicita del 

committente). 

Sulla base delle ipotesi e delle problematiche di partenza, sono state effettuate tutte le scelte 

progettuali, che vengono descritte nelle sezioni successive. 

43

3.1.1 La scelta del proxy: Squid 


Come evidenziato precedentemente, il problema principale da risolvere era relativo 

alla latenza del canale satellitare. In tal senso, l’utilizzo di un sistema di proxy sicuramente 

consente di trarre beneficio dall’uso della cache, al fine di ridurre il numero di richieste 

instradate attraverso la connessione satellitare. 

Diverse erano le possibilità di scelta del software da usare per la realizzazione del 

sistema: sicuramente si è cercato di dare maggiore preferenza alle soluzioni open source, in 

quanto più facilmente accessibili e anche eventualmente modificabili, grazie alla 

disponibilità del codice sorgente, in tal senso, le scelte si sono subito ristrette all’uso di 

quello che viene oggigiorno considerato uno dei migliori proxy server sul mercato: Squid 

[Squ05a]. 

Squid è il più conosciuto, nonché il più utilizzato tra i proxy server attualmente in 

commercio, il suo codice sorgente è libero e fornisce funzionalità di caching e proxing per il 

traffico HTTP, FTP e Gopher. Squid può anche essere utilizzato come motore HTTP/HTTPS 

per eseguire avanzate tecniche di reverse proxy. Il progetto nasce come evoluzione di CERN 

HTTP Server, che già nel 1994 includeva un modulo per la gestione della cache. Questo 

modulo, implementato nel progetto Harvest, fu realizzato nel 1994 al fine di migliorare i 

sistemi di gestione della cache. Tuttavia ebbe vita breve, visto che venne sciolto l'anno 

successivo. In seguito, venne ripreso sia per scopi commerciali (Network Appliance) sia per 

scopi scientifici, determinando la nascità di Squid. Duane Wessels è l'autore di Squid. 

Durante il lavoro svolto presso il National Laboratory of Applied Network Research 

(NLANR), all'interno del gruppo Information Resource Caching (IRcache) fondato dalla 

National Science Foundation, Wessels riprese in mano il progetto originario Harvest e lo 

rinominò in Squid, rilasciandolo secondo l'accordo di licenza GPL (General Pubblic 

License). Attualmente, Squid viene sviluppato da una vasta schiera di sviluppatori, tra questi 

i più importanti sono Henrik Nordstrom, Robert Collins, Adrian Chadd e Joe Cooper. 

Sicuramente peculiare è stata la scelta del nome per tale proxy server: per distinguere questo 

nuovo prodotto da quello realizzato dalla Harvest, Duane Wessels decise di chiamarlo con il 

nome del progetto iniziale: Squid ovvero "il calamaro". Henrik Nordstrom, uno dei migliori 

hacker del progetto Squid, a tale proposito afferma: "il nome Squid non è una abbreviazione, 

il calamaro è un animale marino che in qualche modo si comporta proprio come il nostro 

44


proxy. Le cache gerarchiche ed il protocollo Internet Cache Protocol (ICP) possono essere 

paragonati ai tentacoli utilizzati da un calamaro per fare suo tutto quello che lo interessa". 

3.1.2 Due livelli di caching 

L’uso di un semplice proxy non consente tuttavia di ottenere il risparmio desiderato 

in termini di latenza percepita. Infatti, nonostante sia possibile ottenere dei valori di hit 

prossimi anche al 40%, gran parte delle richieste transiterebbero ancora su sul canale 

satellitare e quindi, al normale ritardo necessario al soddisfacimento della richiesta, si 

sommerebbe il ritardo del canale stesso. Per ovviare alla limitazione sull’hit rate, si è pensato 

di adottare un sistema di caching su due livelli (Fig.3-1), uno lato Content Broker 

(distributore di contenuti, nel caso in esame Telespazio) e uno lato Service Provider 

(fornitore di connettività agli utenti finali). L’utilizzo di una tale soluzione è stato valutato 

anche sulla base delle esperienze positive raccolte durante la fase di analisi delle soluzioni 

offerte dal mercato (Capitolo 2). 

L’architettura su due livelli consente di raggiungere un duplice scopo: 

• limitare al massimo il ritardo, eliminando la parte relativa al normale 

adempimento della richiesta. In tal modo infatti, essendo i dati già presenti 

nella cache di livello superiore, qualora anche la richiesta di tali dati, non 

soddisfatta dalla cache di livello inferiore, debba transitare sul canale 

satellitare, può comunque essere risolta dalla cache di livello superiore, senza 

dover sopportare il ritardo necessario all’indirizzamento della stessa all’origin 

server a cui era destinata; 

• consentire lo sfruttamento di un livello superiore di caching (L1), al fine di 

soddisfare le richieste di numerosi livelli inferiori (L2). La presenza di una 

cache di livello superiore, facente capo a numerose cache di livello inferiore, 

consente di sfruttare al meglio la banda a disposizione, attraverso meccanismi 

quali il pushing e il multicast. Uno stesso dato, per esempio, memorizzato 

nella cache L1 potrebbe essere inviato in pushing a diverse cache di livello L2 

che ne avessero fatto preventivamente richiesta. 

45


Fig. 3-1 - Sistema di proxy/caching su due livelli 

3.1.3 Due istanze di Squid 

Parallelamente all’utilizzo di una soluzione con due livelli di caching, si è pensato di 

suddividere ognuno dei due livelli in due istanze di Squid separate: 

• la prima per la gestione dei normali documenti web, quindi di dimensione 

generalmente contenute (WD Squid); 

• la seconda per la gestione di contenuti multimediali, generalmente di 

dimensioni medio-grandi (MM Squid). 

Ognuna delle due istanze di Squid in un determinato livello comunica con la 

rispettiva controparte nell’altro livello, come mostrato in Fig.3-2. 

Fig. 3-2 - Doppia istanza di Squid per ogni livello di caching 

46


Tale scelta è stata pensata in funzione delle politiche di rimpiazzamento utilizzabili 

in Squid: LRU, GDSF e LFUDA. Infatti, le ultime due risultano particolarmente adatte per 

la gestione, rispettivamente, di file di piccola dimensione e di file di medio-grande 

dimensione. 

La politica GDSF (Greedy Dual Size Frequency) [Arl99] ottimizza l’hit rate, 

cercando di mantenere in cache gli oggetti più piccoli tra quelli maggiormente popolari, sulla 

base del presupposto che tale strategia porta ad avere una probabilità maggiore di hit in 

cache. Così facendo, si ottimizza l’hit rate a discapito del byte hit rate, poiché vengono 

eliminati prima i file di grandi dimensioni. 

La politica LFUDA (Least Frequently Used Dynamic Age) [Dil99] opera invece in 

maniera opposta alla GDSF: essa infatti cerca di tenere in cache gli oggetti più popolari, 

favorendo quelli di dimensioni maggiori. In tal modo, usando per esempio un unico grande 

oggetto, si ha sicuramente una minor probabilità di avere hit rispetto a tanti piccoli oggetti 

con una dimensione complessiva analoga, tuttavia si aumenta, viste le dimensioni del file, il 

byte hit rate. 

Quindi, l’adozione di due istanze separate di Squid consente l’utilizzo, altrimenti non 

possibile (per ogni istanza di Squid è possibile usare solamente una politica di 

rimpiazzamento) di differenti replacement policy, garantendo lo sfruttamento ottimale dello 

spazio a disposizione. Per validare una tale soluzione oltre le considerazioni teoriche, sono 

stati condotti dei test attraverso l’ausilio di strumenti (che verranno adeguatamente descritti 

nel capitolo successivo) quali Calamaris (analizzatore di log), MRTG (interrogazione remota 

di apparecchiature tramite SNMP) e RRDTool (database round robin, usato per migliorare le 

caratteristiche di MRTG). I dati emersi dai test condotti evidenziano come, in un ambito 

business (Elis, circa 25 IP), la percentuale di traffico “multimediale” sia effettivamente poco 

rilevante, in quanto rappresentativa di circa lo 0.5% del traffico totale e caratterizzato 

comunque da percentuali di hit molto basse, inferiori al 3% circa, come evidenziato dal 

grafico in Fig.3-3. 

47


Fig. 3-3 - Istanza di Squid dedicata ai file multimediali: basso traffico e hit rate 

Pur ipotizzando il basso sfruttamento della istanza dedicata ai file multimediali, una 

configurazione a due istanze, come verrà evidenziato meglio in seguito, può comunque 

costituire una valida soluzione per la gestione del mirroring di siti web. 

3.1.4 Pushing vs. prefetching 

Un sistema di proxying/caching disposto su due livelli, come precedentemente 

illustrato, consente di avere diversi vantaggi quali la massima limitazione del ritardo e la 

possibilità di fare content broadcasting sfruttando la posizione privilegiata del livello 

superiore. Tuttavia, il vantaggio maggiore lo si ottiene se si utilizzano contestualmente due 

tecniche per il reperimento delle informazioni, quali il prefetching e il pushing. La prima 

tecnica consente di prelevare delle informazioni in maniera “preventiva”, ancor prima, 

quindi, che ne sia fatta richiesta. La seconda invece consiste nell’inviare informazioni a chi 

si sia precedentemente sottoscritto per la ricezione delle stesse, senza però che quest’ultimo 

ne abbia fatto esplicita richiesta. La ricezione di tali informazioni avviene ogni qual volta 

queste siano state aggiornate e per il solo fatto di essere sottoscritti. Come si è potuto notare 

48


dall’analisi delle differenti soluzioni proposte dal mercato (Cap.2), queste due tecniche 

vengono largamente utilizzate al fine di mascherare la latenza del canale satellitare, pur 

necessitando di una implementazione e di una gestione completamente differente. 

Sicuramente l’utilizzo del pushing, congiuntamente all’uso di una trasmissione multicast, 

consente di ottenere una serie di vantaggi rispetto al prefetching: 

• non è richiesta interazione da parte dei client, se non la sottoscrizione del 

contenuto; 

• grazie all’utilizzo del multicast, si può inviare in pushing, con una sola 

trasmissione, lo stesso dato ad una serie di client che si siano 

precedentemente sottoscritti per lo stesso, minimizzando così l’utilizzazione 

della banda a disposizione e limitando al contempo il traffico sul canale. 

Tuttavia, tale soluzione non è esente da difetti: 

• necessità di implementare un protocollo di pushing proprietario o tramite 

modifica diretta del protocollo HTTP; 

• necessità di implementare un protocollo di trasmissione multicast affidabile; 

• necessità di modificare o di creare un proxy server che sia in grado di 

supportare entrambi i protocolli di pushing e multicast. 

Allo stesso modo, l’utilizzo del prefetching presenta pregi e difetti. Andando con 

ordine, sicuramente sono da evidenziare in positivo: 

• la facilità di implementazione e utilizzo; 

• modifiche non necessarie a livello di protocollo di trasmissione; 

• modifiche non necessarie al programma proxy server. 

Tuttavia non si possono non considerare i seguenti elementi negativi: 

• maggior aumento del traffico; 

• necessità di implementare una logica di controllo per le operazioni di 

prefetching; 

• sfruttamento non ottimale della banda a disposizione. 

Come verrà spiegato in seguito in modo più approfondito, la scelta del meccanismo 

da utilizzare è ricaduta sul prefetching, sia per problemi tecnici legati al pushing, sia per una 

delle due ipotesi iniziali, ovvero la disponibilità di una banda satellitare pressoché infinita. 

49

3.1.5 Gestione del prefetching 


La decisione di utilizzare il prefetching richiede, come precedentemente evidenziato, 

la necessità di una logica di controllo, alla quale delegare il compito di gestire tale modalità 

operativa. Infatti, per poter richiedere “preventivamente” determinate informazioni, è 

innanzitutto necessario sapere quali saranno le informazioni che con molta probabilità 

saranno richieste in un prossimo futuro e su quelle andare ad effettuare il prefetching. 

La logica che si è deciso di utilizzare, anche alla luce dei buoni risultati conseguiti, 

riprende quindi le esperienze riportate da Hughes Network Systems (Cap.2) con il proprio 

Cumulative Caching, nonché alcuni dei fondamenti alla base dell’algoritmo di Static 

Caching (descritto nel Cap.1). Proprio i risultati positivi ottenuti da quest’ultimo, nonché 

l’assunzione fatta per il Cumulative Caching della Hughes Network Systems, secondo la 

quale utenti appartenenti ad una stessa area geografica sono portati a visitare gli stessi siti 

web, a causa spesso di ragioni relative al mirroring dei siti stessi, hanno condotto all’idea di 

memorizzare in cache in anticipo le informazioni della giornata precedente. 

Ogni giorno, tramite una analisi dei log delle 24 ore precedenti, vengono identificati 

ed ottenuti quelli che sono stati gli oggetti maggiormente richiesti e su quelli vengono 

eseguite le operazioni di prefetching. 

3.1.6 Indirizzamento delle richieste 

Vista la scelta di utilizzare una doppia istanza di Squid per ognuno dei due livelli di 

caching, si presenta il problema di decidere come gestire l’indirizzamento delle richieste 

verso le due istanze. 

In tal senso, le alternative erano due: 

1. layer 7 switching dedicato; 

2. indirizzamento in base ad estensione tramite Access Control List di Squid. 

La prima delle due soluzioni (Fig.3-4) prevede l’utilizzo di una macchina dedicata 

che effettui solamente le funzionalità di switch di livello 7, ovvero il riconoscimento a livello 

applicativo e il conseguente indirizzamento delle differenti richieste alla rispettiva istanza di 

Squid (WD o MM), nel nostro caso, in base alla estensione del file richiesto. 

50


Fig. 3-4 - Layer 7 switching dedicato 

La seconda soluzione (Fig.3-5) prevede l’utilizzo di una configurazione in cui uno 

dei due Squid (WD Squid) faccia da front-end per l’altro (MM Squid), filtrando tutte le 

richieste in entrata e indirizzandole opportunamente allo MM Squid o risolvendole 

autonomamente a seconda della estensione del file richiesto. Tale operazione di filtraggio è 

resa possibile grazie all’utilizzo delle Access Control List (ACL) di Squid, che rendono 

possibili diverse tipologie di filtraggi, in base a informazioni quali estensione del file, url, 

indirizzo di destinazione, indirizzo di sorgente, etc. 

Fig. 3-5 - Layer 7 Switching tramite Squid e ACL 

51


La scelta finale su quale delle due soluzioni utilizzare, come descritto in seguito, è 

ricaduta sull’utilizzo delle ACL di Squid. 

3.1.7 Dimensionamento hardware 

Il problema del dimensionamento hardware del sistema di caching satellitare è stato 

tenuto in debita considerazione. Una delle ipotesi iniziali era infatti relativa allo spazio disco 

a disposizione e al basso costo attuale di una tale risorsa. Eppure, anche ipotizzando di avere 

uno spazio disco pressoché infinito, non è possibile trarre completamente vantaggio da tale 

opportunità per una serie di problemi legati sia alla gestione delle risorse hardware da parte 

di Squid, sia alle caratteristiche proprie del traffico Internet. 

Prima di tutto, bisogna infatti considerare che Squid è un programma che fa un uso 

intenso della RAM di sistema. Sicuramente l’uso maggiore di tale risorsa dipende dall’indice 

principale della cache. Questo indice è costituito da una tabella hash che mantiene una 

piccola quantità di metadati per ognuno degli oggetti in cache, quantità che diventa 

assolutamente non trascurabile se consideriamo il fatto che il numero di oggetti memorizzati 

in cache può arrivare a diversi milioni, direttamente legato quindi allo spazio disco riservato 

alla cache. Inoltre, vanno anche tenuti in considerazione gli utilizzi della memoria relativi ai 

differenti buffer utilizzati da Squid ogni volta che un client effettua una richiesta HTTP, 

oppure una richiesta viene inoltrata all’origin server, o ancora ogni volta che vengono 

effettuate operazioni di lettura scrittura da disco. Senza dimenticare gli oggetti normalmente 

mantenuti in memoria da Squid, come gli oggetti delle richieste attualmente servite dal 

programma. Quindi, tenendo conto di questo quadro di insieme, non si può non pensare ad 

un dimensionamento opportuno della RAM a seconda dello spazio disco che si vuole 

utilizzare, pena un forte degrado delle prestazioni dovuto alle operazioni di swapping su 

disco che Squid dovrebbe fare a causa dell’esaurimento della RAM a disposizione. 

Generalmente, si tende a dimensionare un cache server in base al traffico che dovrà 

sopportare nell’arco di tre, massimo cinque giorni, all’interno della rete di utilizzo. Sulla 

base di questo traffico si usa quindi dimensionare lo spazio disco e conseguentemente la 

dimensione della RAM, considerando che è ritenuta buona norma considerare, per il solo 

funzionamento di Squid, un quantitativo di RAM circa pari all’1% delle spazio disco messo 

52


a disposizione per il caching (es: spazio disco di 1TB necessità di un quantitativo di RAM 

pari a 10GB solo per Squid!). A tale riguardo, sono sicuramente interessanti alcuni dati 

forniti dalla Swelltech, cache vendor che fornisce soluzioni basate su Squid, che riporta 

[Coo02] una serie di dati (Tab.3-1) relativi al dimensionamento di un proxy server a seconda 

dello spazio disco riservato alla cache e della banda della rete in cui verrà utilizzato: 

NETWORK 

BANDWIDTH 

Reccomanded CACHE 

STORAGE size 

DSL 512Kbps 4 GB 128MB 

T1 1.5Mbps 8 GB 192 MB 

Dual T1 3Mbps 16 GB 256 MB 

Three T1 4.5Mbps 24 GB 384 MB 

Four T1 6Mbps 30 GB 512 MB 

Five T1 7.5 Mbps 36 GB 1024 MB 

Reccomanded RAM size 

Tab. 3-1 - Tabella per il dimensionamento di un proxy server Squid 

A queste considerazioni sull’utilizzo delle risorse hardware, se ne aggiungono altre 

relative alla natura del traffico. Bisogna infatti considerare che una buona parte del traffico 

Internet è di tipo non memorizzabile in cache, per tutta una serie di motivi legati alla natura 

dei contenuti che possono essere: 

• contenuti dinamici; 

• contenuti soggetti a diritti d’autore (es: alcuni video del sito della Cisco 

hanno una protezione DRM che ne impedisce la visualizzazione a chi non è 

stato espressamente autorizzato); 

• contenuti direttamente (vedi caso di header expiry-time=0) o indirettamente 

(contenuti posizionati a valle di una richiesta di autorizzazione) non 

memorizzabili. 

Per questi motivi, pur ipotizzando di avere a disposizione uno spazio disco 

praticamente infinito, non si può pensare di “memorizzare l’intera Internet!” 

A solo titolo di esempio, in Fig.3-6 viene riportato un grafico generato sulla base del 

traffico monitorizzato nella rete Elis (circa 25 IP), che riporta le diverse tipologie di richieste 

53


osservate. In questo caso, la percentuale delle richieste verso contenuti dinamici è pari a 

circa il 46% del traffico totale. 

Fig. 3-6 - Grafico della tipologia di traffico della rete Elis 

3.2 Le possibili architetture 

Le scelte effettuate in fase di progettazione hanno portato alla definizione di diverse 

architetture per il sistema SatSquid, riassumibili attraverso i seguenti elementi 

caratterizzanti: 

• due livelli di caching, un primo livello (L1) a monte del satellite e lato 

Content Broker (Telespazio) e diversi secondi livelli (L2) a valle del satellite, 

uno per ogni Service Provider; 

• doppia istanza di Squid per ognuno dei due livelli di caching, in modo da 

sfruttare al massimo gli algoritmi di rimpiazzamento supportati da Squid 

stesso; 

54


• indirizzamento delle richieste verso una istanza di Squid tramite l’utilizzo di 

un L7 Switch dedicato o tramite l’utilizzo di una delle due istanze di Squid, 

attraverso l’uso delle ACL; 

• meccanismi di pushing o prefetching per mascherare la latenza del canale 

satellitare; 

• utilizzo delle tecniche proprie dello static caching e della soluzione di Hughes 

Network Systems, per automatizzare le operazioni di prefetching. 

A questi elementi, va aggiunto la scelta di realizzare un sistema di gestione per il 

mirroring di siti web, come richiesto da specifiche del committente. 

Nelle sezioni successive vengono descritte le considerazioni ed i test che hanno 

determinato la scelta della architettura finale. 

3.2.1 Pushing vs. prefetching 

Il primo elemento, probabilmente quello più caratterizzante l’architettura in esame, è 

rappresentato dalla scelta della tecnica di reperimento delle informazioni: pushing vs. 

prefetching. Per poter utilizzare il pushing è stato necessario, visto l’impossibilità di Squid di 

usare tale meccanismo, reperire una sua versione appositamente modificata. In tal senso, il 

progetto relativo ad una versione push-based di Squid è considerato in fase di stallo. 

Solamente tramite contatti diretti con il mantainer del progetto è stato possibile avere una 

versione pre-alfa (non era neanche in fase di alfa!) di uno Squid v.2.5 stable6p3, ovvero di 

una versione 2.5stable6 di Squid alla terza modifica per il pushing, p3 appunto. Vista la fase 

altamente sperimentale di tale soluzione, non è stato possibile reperire informazioni corrette 

sul funzionamento di questa release. Di conseguenza, tutte le informazioni che vengono di 

seguito riportate sono frutto di test condotti sulla release stessa, attraverso lo “sniffing” della 

rete sottostante, tramite il programma di sniffing Ethereal. 

I test sono stati condotti installando e configurando opportunamente su due macchine 

diverse, una con funzionalità di L1 e l’altra con funzionalità di L2, la versione di Squid 

modificata per il pushing. Inoltre, sulle due macchine sono state configurate delle ACL per 

consentire: alla macchina L1 di effettuare il pushing dei dati sottoscritti sulla L2 che ne farà 

sottoscrizione e alla macchina L1, come verrà spiegato meglio in seguito, di riceve 

55


aggiornamenti in pushing dei dati sottoscritti dalle L2 da parte di un agente esterno. Il 

funzionamento del meccanismo di pushing è il seguente: 

1. un agente esterno (Fig.3-7), in funzione sulla macchina L2, effettua una 

richiesta HTTP alla macchina L1, inviando una GET opportunamente 

modificata: “GET httpdist3128://www.google.it HTTP/1.0”, aggiungendo 

dist3128 per indicare allo Squid che risiede sulla L1 che sta inviando una 

richiesta di sottoscrizione e che si aspetta una risposta sulla porta 3128 dello 

stesso IP dal quale ha effettuato la richiesta. La modifica all’URL è necessaria 

in quanto l’agente esterno a Squid si occupa di effettuare la sottoscrizione “a 

nome” dello Squid stesso, indicando su quale porta della stessa macchina sia 

in ascolto quest’ultimo per ricevere le risposte. 

Fig. 3-7 - Sottoscrizione di un contenuto da parte agente esterno 

2. Lo Squid che risiede su L1 riceve la richiesta di GET opportunamente 

modificata dall’agente esterno su L2 (Fig.3-8), ne effettua il parsing 

eliminando l’aggiunta dist3128 e memorizzando al contempo la richiesta di 

sottoscrizione per la url indicata (http://www.google.it) e infine risponde allo 

Squid su L2 in ascolto sulla porta indicata nella url, ovvero la 3128, come se 

questo avesse effettuato una normale GET con la URL in oggetto 

(http://www.google.it). 

56


Fig. 3-8 - Memorizzazione della richiesta di sottoscrizione e risposta alla GET 

3. D’ora in poi, lo Squid sulla L1 avrà memorizzato la richiesta di sottoscrizione 

relativa allo Squid L2. Tuttavia, il controllo degli aggiornamenti e l’eventuale 

conseguente invio dell’oggetto sottoscritto non sono a carico dello Squid L1, 

è invece necessario un altro agente esterno, che può in questo caso anche 

risiedere su una macchina diversa dalla L1 stessa (basta configurare 

opportunamente la regola della ACL relativa ai permessi di pushing sulla L1), 

che si occupi di controllare eventuali aggiornamenti dei file sottoscritti dalle 

L2 e in quel caso li prelevi inviandoli in pushing alla L1 stessa (Fig.3-9), 

tramite una semplice PUT HTTP. 

Fig. 3-9 - Aggiornamento del contenuto da parte di un agente di PUSHING 

4. Al momento della ricezione del file aggiornato, L1 controlla l’elenco dei file 

sottoscritti e invia a sua volta in pushing (tramite il metodo PUT dell’HTTP) 

57


tale file a tutte le L2 che ne avevano fatto richiesta di sottoscrizione (Fig.3- 

10). 

Fig. 3-10 - Aggiornamento del contenuto di L2 tramite PUT HTTP 

Dalla descrizione, si può notare come il funzionamento della soluzione di pushing 

non sia in realtà completamente autonomo, ma richieda la presenza di due agenti esterni, uno 

per effettuare le richieste di sottoscrizione e l’altro per controllare l’aggiornamento di tali 

oggetti sottoscritti e iniziarne la procedura di pushing. Questa modalità operativa diventa 

quindi del tutto analoga a quella che viene utilizzata per il prefetching: anche in questo caso 

infatti è necessario un agente esterno che faccia richiesta anticipata allo Squid dei file che 

intende far memorizzare allo stesso. Il motivo di un tale funzionamento del pushing è 

sicuramente da ricondurre alla volontà da parte del mantainer di tale progetto di utilizzare, 

congiuntamente a tale tecnica, il multicast: così facendo infatti sarebbe possibile, con un solo 

invio di un file a L1, far inviare ad essa in multicast (quindi con una sola trasmissione) il file 

contemporaneamente a tutte le L2 che ne avevano fatto richiesta di sottoscrizione, 

ottimizzando l’utilizzo della banda. 

Tuttavia, la versione di Squid modificata, pur supportando il pushing, non supporta il 

multicast. Quindi, oltre ad un funzionamento non completamente autonomo, veniva a 

mancare anche il vantaggio di poter sfruttare al meglio la banda a disposizione. Se a questo 

aggiungiamo due bachi che sono stati riscontrati durante la fase di testing, risultano evidenti 

i motivi che hanno condotto a preferire la soluzione che implementa il prefetching. A tale 

scopo è stata progettata una logica di controllo che, funzionando autonomamente, effettua 

regolarmente procedure di analisi dei log della giornata precedente per decidere cosa 

richiedere in prefetching. 

I bachi a cui si accennava poco sopra sono: 

58


• problema nel valutare il grado di “freschezza” di un oggetto e quindi la 

possibilità di memorizzazione o meno in cache di tale oggetto; 

• problemi di funzionamento in modalità parent/sibling, quindi in una 

architettura di caching cooperativo. 

Il primo dei due problemi deriva da una mancata memorizzazione del valore del 

campo “time” inviato insieme ai documenti. Tale valore indica la data e l’ora di creazione di 

un documento e viene utilizzato da Squid per calcolare “l’età” di un documento attraverso 

una semplice sottrazione età=ora_corrente-time. Non memorizzando però bene il campo 

time, Squid impostava tale valore a zero, di conseguenza il valore di età si aggirava intorno 

ai 35 anni. Questo perché nei sistemi *nix i valori temporali sono espressi in secondi rispetto 

a quella che viene considerata l’epoch time, ovvero il 1° Gennaio 1970. L’unico modo per 

“forzare” questa versione push-based di Squid a memorizzare qualsiasi file era quella di 

impostare il valore della direttiva refresh_pattern all’interno del proprio file di 

configurazione ad un valore superiore ai 35 anni. Tale direttiva infatti indica a Squid qual è il 

valore massimo di età che un documento non deve superare per essere considerato “fresh” e 

quindi memorizzabile in cache. 

Il secondo baco è relativo al funzionamento in modalità parent/sibling. Nel file di 

configurazione di Squid è presente una direttiva che indica quale deve essere la dimensione 

massima di un oggetto memorizzabile in cache (max_obj_size). Il problema si verificava 

durante una modalità di funzionamento in cui si usava uno dei due Squid come switch di 

livello 7. In una configurazione siffatta, lo Squid che si trovava a fare da front-end, chiudeva 

la connessione con quello di back-end nel momento in cui, indirizzandogli una richiesta e 

ricevendo la risposta, il file trasferito superava la propria direttiva di max_obj_size. 

3.2.2 Indirizzamento delle richieste 

Vista la scelta di utilizzare una doppia istanza di Squid, era necessario implementare, 

come precedentemente accennato, una tecnica per instradare le richieste a seconda delle 

necessità. Inoltre, data anche la scelta di utilizzare Squid e conseguentemente Linux come 

sistema operativo, si è pensato ad una implementazione di uno switching di livello 7 tramite 

una macchina Linux dedicata. 

59


In tale ambiente operativo, la soluzione open-source più diffusa è rappresentata dal 

progetto Linux Virtual Server [Lin05a]. Questo progetto, che mira principalmente ad 

architetture di load balancing [Car02], mette a disposizione tre possibili soluzioni 

implementative, basate rispettivamente sull’utilizzo dei seguenti meccanismi. 

• NATting: tecnica di Network Address Translation che consente ad una 

macchina di front-end di effettuare il load balancing su delle macchine di 

back-end. Il front-end è un tramite per lo svolgimento della comunicazione 

client-server e si occupa di riscrivere gli header dei pacchetti TCP/IP in 

transito, modificando, di volta in volta, le informazione relative agli indirizzi 

IP e alle porte di sorgente e destinazione. 

• IP Tunneling [Lin05b]: meccanismo per l’incapsulamento di datagrammi IP 

in altri datagrammi IP (le macchine di front-end e back-end possono trovarsi 

in reti differenti ). 

• DirectRouting: meccanismo che prevede che una macchina front-end effettui 

la rescrittura a livello network dei pacchetti in transito, cambiandone il MAC 

address (le macchine di front-end e back-end devono trovarsi sullo stesso 

segmento di rete). 

Le soluzioni sopra descritte e implementate dal progetto LVS sono tuttavia soluzioni 

adatte per attuare uno switching di livello 4, non utilizzabili direttamente quindi per 

effettuare uno switching di livello 7. Per tale motivo, ci si è indirizzati verso un progetto 

parallelo a LVS, il progetto TCPHA [Dra05], che si occupa dell’implementazione di uno 

switching livello 7 sotto Linux, prendendo spunto dal progetto Linux Virtual Server e 

dall’utilizzo dell’IP tunneling e del TCP Hand-Off. Tale progetto prevede l’utilizzo di una 

architettura (Fig.3-11) in cui una serie di server di back-end sono direttamente indirizzati 

tramite l’ausilio di un server di front-end. Tutti i server componenti il cluster condividono 

uno stesso IP virtuale, quasi come se fossero, appunto, un unico server virtuale, pur 

utilizzando per le comunicazioni interne degli indirizzi IP reali, non visibili all’esterno. Una 

tale architettura viene identificata con il termine di one-way layer 7 switching [And03], in 

contrapposizione all’altra architettura possibile, la two-way layer 7 switching. Un sistema di 

switching livello 7 prevede la presenza di una macchina di front-end o switch, chiamato 

anche web switch (per sottolineare il ruolo di switching effettuato a livello di una richiesta 

60


web), posizionato davanti alle macchine sulle quali andranno poi indirizzate le richieste. Con 

il termine one-way si vuole sottolineare il fatto che il meccanismo di switching così 

realizzato, consente ai server di rispondere direttamente ai client, senza la necessità di far 

passare la propria risposta nuovamente attraverso il web switch. Al contrario, in una 

architettura two-way, tutte le risposte dei server devono transitare nuovamente per lo switch. 

Il progetto TCPHA, appartenente alla categoria degli one-way switch, realizza uno 

switching di livello 7 tramite l’utilizzo dei meccanismi di IP-Tunnelling e con l’ausilio di un 

protocollo di TCP Hand-Off (THOP) [And05][Car02]. Attraverso tale protocollo la 

macchina di front-end e la macchina di back-end si scambiano informazioni relative allo 

stato della connessione TCP [TCP05] inizialmente creata tra il client e il front-end, in modo 

da consentire al back-end di gestire direttamente le risposte con il client. Oltre alle 

informazioni relative alla creazione delle connessione TCP, il THOP (TCP Hand-Off 

Protocol) prevede anche lo scambio tra la macchina di front-end (o switch) e quelle di back- 

end di informazioni sullo stato attuale della connessione (chiusura, errori, etc) che 

consentono al front-end di reagire a determinati eventi. Infatti, pur potendo i server 

rispondere direttamente ai client, i pacchetti che questi ultimi indirizzano ai server (per 

esempio ACK) transitano ancora tramite la macchina di front-end. Questa, tramite una 

tabella hash in cui mantiene le informazioni relative ad una determinata connessione, 

indirizza tali pacchetti verso il server opportuno. Al momento della chiusura della 

connessione e alla ricezione del messaggio di notifica tramite il protocollo TCP Hand-Off, il 

front-end provvede ad eliminare dalla tabella le informazioni relative alla connessione 

appena terminata. 

61


Fig. 3-11 - Architettura Virtual Server tramite IP Tunneling 

. Il funzionamento dello switching livello 7 implementato dal progetto TCPHA 

tramite IP tunneling e THOP può essere così riassunto: 

1. un client invia una richiesta al server virtuale; 

2. la macchina di front-end risponde stabilisce la connessione col client e 

accetta la richiesta; 

3. la macchina di front-end analizza la richiesta e decide a quale server 

di back-end indirizzarla; 

4. la macchina di front-end incapsula (Fig.3-12) quindi il datagramma IP 

della richiesta in un altro datagramma IP, nel quale però vengono 

utilizzati gli indirizzi IP reali delle macchina sorgente (sè stessa) e 

destinazione (il server di back-end selezionato); 

62


5. il server di back-end riceve il datagramma IP, lo decapsula ritrovando 

la richiesta originale; 

6. il server di back-end risolve la richiesta rispondendo direttamente al 

client tramite il proprio IP virtuale. 

Fig. 3-12 - Flusso di incapsulamento/decapsulamento tra il forntend (LinuxDirector) e il backend (Real 

Server) 

E’ importante sottolineare come, in una tale architettura in cui diverse macchine 

rispondono ad un unico indirizzo IP virtuale, solamente una di queste (quella con 

funzionalità di fornt-end) deve rispondere alle interrogazioni ARP su tale indirizzo, 

altrimenti possono generarsi dei conflitti nonché degli indirizzamenti sbagliati [Lin05c], 

portando il client, per esempio, ad effettuare le richieste direttamente ad un server di back- 

end. Per risolvere tali problematiche, è possibile disabilitare (Fig.3-13) tramite l’interfaccia 

al kernel proc l’invio di risposte ARP per una determinata interfaccia di loopback associata 

all’indirizzo IP virtuale su ognuno dei server di back-end. 

63


# Abilitazione delle funzionalità di hiding delle interfacce 

echo 1 > /proc/sys/net/ipv4/conf/all/hidden 

# Nasconde tutti gli indirizzi dell’interfaccia di loopback tunl0 

echo 1 > /proc/sys/net/ipv4/conf/tunl0/hidden 

Fig. 3-13 - Comandi per disabilitare le risposte ARP per una interfaccia di loopback 

Il progetto TCPHA implementa, tramite dei moduli, il TCP Hand-Off all’interno del 

kernel di Linux. Il suo funzionamento si basa su due componenti: tcpha_fe (front-end) e 

tcpha_be (back-end). Il primo modulo, installato sulla macchina di front-end, si occupa di 

instradare le richieste al secondo modulo posizionato sulle macchine di back-end, seguendo 

una serie di regole memorizzate all’interno di un file di configurazione. 

Facciamo un esempio: il server di front-end risponde all’indirizzo IP 10.0.0.3 ed è 

posizionato davanti a due server di back-end, con indirizzi IP rispettivamente pari a 10.0.0.4 

e 10.0.0.5. Tutte e tre le macchine condividono l’IP virtuale 10.0.0.2 visibile ai client. 

Compilati i moduli, verranno installati rispettivamente il modulo tcpha_fe sulla macchina di 

front-end e i moduli tcpha_be sulle macchine di backend. Quindi, per ogni macchina sarà 

necessario modificare il relativo file di configurazione del modulo. Nel caso del front-end 

nel file tcphafe.conf andranno inseriti: 

inseriti: 

• raddr = x.x.x.x: indirizzo IP reale del front-end, quindi nel caso in esempio 

raddr = 10.0.0.3; 

• vaddr = x.x.x.x: indirizzo IP virtuale del cluster, quindi vaddr = 10.0.0.2; 

• server = x.x.x.x port: indirizzo e porta dei server di back-end, quindi server = 

10.0.0.4 666 e server = 10.0.0.5 666; 

• rule = x.x.x.x pattern: se una richiesta soddisfa la regola pattern, allora deve 

essere indirizzata al server di back-end all’indirizzo x.x.x.x, nel nostro 

esempio qualcosa come rule = 10.0.0.5 avi$ and rule = 10.0.0.4 .* 

Analogamente, nel caso delle macchine di back-end nel file tcphabe.conf andranno 

• raddr = x.x.x.x: l’indirizzo IP del back-end, nel caso della macchina 10.0.0.4 

quindi raddr = 10.0.0.4; 

64


• vaddr = x.x.x.x: indirizzo IP virtuale del cluster, nel nostro caso quindi vaddr 

= 10.0.0.2 

Lo sviluppo del progetto TCPHA purtroppo procede a rilento (non è ancora stato 

introdotto il supporto al kernel versione 2.6) ed è ancora in fase semi-sperimentale. Sono 

stati infatti riscontrati problemi sia in fase di compilazione (risolti attraverso piccole 

modifiche al codice), sia in fase di installazione dei moduli che ne hanno impedito il 

funzionamento. Per questo motivo si è deciso di utilizzare una delle due istanze di Squid 

come switching di livello 7, attraverso l’uso delle ACL opportunamente configurate. 

Sicuramente, l’utilizzo di una soluzione di switching di livello 7 dedicata e implementata 

tramite TCP handoff avrebbe consentito l’utilizzo ottimale delle risorse a disposizione: una 

tale soluzione infatti risulta ideale in tutti quei casi in cui il server di front-end può diventare 

un collo di bottiglia, in quanto impegnato nella gestione di numerosi server di back-end (da 

20 in su). Tuttavia, avendo nella nostra architettura solamente due server di back-end, dei 

quali uno dei due funziona contemporaneamente anche da server di front-end, il problema 

del collo di bottiglia diventa pressoché ininfluente. 

3.2.3 Mirroring separato 

Una delle problematiche chiave, così come evidenziata dal committente stesso, era la 

necessità di un meccanismo che consentisse di effettuare il mirroring di siti web. Per tale 

motivo è stata pensata la creazione di una interfaccia di management che consentisse la 

gestione di una tale procedura. Al fine di diminuire la possibilità di errori umani e di poter 

meglio tenere sotto controllo il funzionamento dell’intero sistema, si è ipotizzato di 

posizionare tale interfaccia solamente sulla cache L1, in modo che un unico amministratore 

possa occuparsi, su richiesta espressa degli amministratori delle varie L2, di inserimenti e 

rimozione dei siti sottoposti a mirroring. 

L’interfaccia di management è stata quindi spunto per ulteriori riflessioni: visti anche 

i test condotti in un ambito business (rete Elis, 25 IP) che hanno portato alla luce come, in un 

tale contesto di utilizzo, la richiesta di file multimediali sia una percentuale bassissima del 

totale del traffico generato (inferiore allo 0.5%), si è pensato di riutilizzare la doppia istanza 

di Squid, per ognuno dei due livelli, a favore del mirroring. Supponendo una applicazione in 

65


ambito business del sistema, si può pensare di dedicare una delle due istanze al normale 

caching dei siti, tramite anche l’ausilio della logica di controllo e delle operazioni di 

prefetching da essa eseguite, e di utilizzare l’altra, completamente per il mirroring dei siti 

web, attraverso l’eventuale uso di ACL che filtrano in base al dominio di appartenenza 

dell’url (come verrà meglio spiegato nel Cap.4). 

3.3 Architettura scelta: vantaggi e limiti 

Riassumendo quindi le varie scelte progettuali effettuate, l’architettura del sistema di 

caching satellitare SatSquid (Fig.3-14) può essere così riassunta: 

Fig. 3-14 - Architettura del sistema di caching satellitare SatSquid 

• adozione di Squid, il più diffuso e apprezzato programma proxy server open 

source e quindi, conseguenza naturale, uso del sistema operativo Linux; 

• due livelli di caching, al fine di ridurre il più possibile la latenza normalmente 

attribuibile al reperimento delle pagine presso l’origin server (le operazioni di 

prefetching infatti procedono ritardate nel tempo tra i due livelli, per dar 

modo alla L1 di avere già presenti in cache i dati al momento che la L2 ne 

faccia richiesta); 

66


• due istanze di Squid per ognuno dei due livelli di caching, con una doppia 

possibilità di utilizzo: sfruttamento massimo degli algoritmi di 

rimpiazzamento attraverso la distinzione di traffico multimediale e non, 

oppure uso di una delle due istanze, nel caso di utenza prettamente business, 

per una gestione dedicata al mirroring dei siti; 

• gestione dell’instradamento del traffico per la doppia istanza di Squid tramite 

ACL di Squid, sia nel caso di distinzione tra traffico multimediale e non, sia 

per indirizzare opportunamente il traffico generato verso i siti mirror; 

• tecniche di prefetching, realizzate tramite l’implementazione di un demone 

sempre in funzione sulle macchine di secondo livello, che analizzando ogni 

giorno i log della giornata precedente, decida cosa sia più conveniente andare 

a richiedere in prefetching, al fine di mascherare la latenza del canale 

satellitare; 

• mirroring di siti web attraverso una interfaccia di management situata sulla 

macchina di primo livello, con la possibilità di avere una macchina 

completamente dedicata al mirroring dei siti (Fig.3-15). 

Fig. 3-15 - Architettura finale "alternativa": mirroring dedicato 

67


La scelta dell’architettura finale del sistema SatSquid è avvenuta sulla base delle 

possibilità a disposizione e dei vantaggi e svantaggi offerti dalle soluzioni possibili. 

L’insieme demone/interfaccia di management costituisce sicuramente un valido strumento 

sia per il caching, sia per il mirroring di siti web. Ciò nonostante, le scelte effettuate hanno 

portato alla implicita accettazione di quelli che costituiscono i limiti di tale architettura. La 

decisione di adottare una doppia istanza di Squid, se da un lato consente di gestire meglio le 

differenti tipologie di traffico, dall’altro non consente un controllo completo dello spazio 

disco utilizzato. Infatti anche in tal senso è stata progettata la configurazione alternativa: una 

gestione separata del mirroring consente di avere un controllo completo dello spazio 

occupato. Infine, il mancato utilizzo del pushing coadiuvato dal multicast non consente un 

utilizzo ottimo della banda a disposizione. Tuttavia, proprio per quella che era l’assunzione 

iniziale, ovvero la disponibilità di una banda satellitare pressoché infinita, tale mancanza non 

costituisce un problema rilevante. 

68

4. Strumenti per la realizzazione di SatSquid 

4 Strumenti per la realizzazione di SatSquid 

Per la realizzazione del progetto sono state usate alcune applicazioni utili sia 

all’implementazione e al funzionamento del sistema realizzato, sia al monitoraggio dello 

stesso. In questo capitolo verranno descritti questi tool, riportandone le caratteristiche 

salienti e analizzando con maggiore dettaglio quelle tra queste ultime che sono state più 

importanti ai fini del progetto. In tal senso, verranno meglio evidenziate le caratteristiche di 

Squid (4.1) che hanno permesso lo sviluppo dell’architettura adottata, quindi sarà analizzato 

il protocollo SNMP (4.2) che ha permesso, attraverso una serie di tool quali MRTG e 

RRDTOOL (4.3), l’analisi e il monitoraggio dell’architettura scelta. Infine, verrà descritto il 

funzionamento di Calamaris (4.4), ottimo tool utilizzato per l’analisi dei log di Squid. 

4.1 Squid 

Il programma proxy server Squid, come precedentemente accennato, è un software 

rilasciato sotto licenza GPL, che permette di effettuare operazioni di proxying/caching su 

diversi protocolli, nonché di funzionare come transparent proxy o reverse proxy. Le 

potenzialità offerte da questo proxy server consentono di gestire finemente un sistema di 

proxying/caching attraverso una serie di parametri e impostazioni, selezionabili sia in fase di 

compilazione, sia all’interno del file di configurazione squid.conf (in Appendice A sono 

riportati alcuni file di configurazione d’esempio). Di seguito, vengono descritti gli elementi 

di Squid più significativi ai fini del progetto. 

4.1.1 Configurazione iniziale 

Le prime impostazioni sono anche le più importanti, dal momento che abilitano una 

serie di caratteristiche altrimenti inutilizzabili e sono da effettuare già in fase di 

compilazione del programma [Tag05b]. La procedura di configurazione ricalca le classiche 

tre fasi di un programma open source, ovvero: configure, make e make install. 

69


Allo script di configurazione è possibile passare numerosi parametri per abilitare 

diverse funzionalità. Sicuramente i più importanti ai fini del progetto in esame, come 

mostrato in Fig.4-1, sono i seguenti: 

• enable-async-io e enable-storeio=”ufs aufs”: queste due opzioni sono 

entrambe relative al meccanismo di accesso al disco utilizzato da Squid. La 

prima abilita una gestione asincrona di accesso al disco, la seconda attiva due 

sistemi di gestione di accesso disco: ufs e aufs. Squid infatti utilizza diverse 

tecniche di accesso al disco, tra le quali appunto ufs e aufs. La prima è il 

sistema di memorizzazione originario e nativo di Squid, si basa su una 

struttura di directory a 2 livelli dove i valori di default prevedono 16 directory 

per il primo livello (L1) e 256 per il secondo (L2). Tutti gli oggetti presenti 

nella cache di Squid sono immagazzinati come file all'interno del secondo 

livello, tutte le operazioni di I/O sono gestite in modalità sincrona 

direttamente dal Sistema Operativo e possono bloccare il funzionamento del 

processo principale di Squid sino al loro completamento. La seconda tecnica 

di accesso al disco viene usata proprio per risolvere tale problematica; infatti, 

utilizza il medesimo formato di storage su disco di ufs, tuttavia in questo caso 

tutte le operazioni di I/O sono gestite in modalità asincrona utilizzando il 

modello POSIX-thread. Aufs utilizza dei processi di tipo thread che gli 

consentono di eseguire le operazioni di disk I/O. Questo modello di storage 

permette di evitare il blocco del processo principale di Squid durante tutte le 

operazioni di disk I/O, in quanto le stesse vengono inoltrate ad un processo 

thread differente. 

• enable-removal-policies="lru heap": questo parametro attiva la possibilità di 

utilizzare diverse replacement policy all’interno di Squid. In particolare, 

consente di usare la più classica delle politiche di rimpiazzamento, LRU, 

nonché tutte le politiche basate su heap, tra le quali possiamo citare sia 

GDSF che LFUDA, precedentemente descritte (3.1.3). 

• enable-snmp: questa opzione abilita la gestione del protocollo SNMP da parte 

di Squid, consentendone così il monitoraggio remoto. Gli aspetti che è 

70


possibile monitorizzare sono elencati all’interno del file SQUID-MIB.txt, 

come verrà meglio descritto in seguito. 

• enable-err-languages="Italian English" e enable-default-err- 

language="Italian”: questi due ultimi parametri servono invece ad abilitare 

la comunicazione dei messaggi di errore in una lingua desiderata. Per tale 

motivo sono stati abilitati i messaggi di errore sia nella lingua inglese sia 

nella lingua italiana ed è stata selezionata quest’ultima come lingua di default. 

./configure --enable-async-io\ 

--enable-storeio="ufs aufs"\ 

--enable-removal-policies="lru heap"\ 

--enable-snmp\ 

--enable-err-languages="Italian English"\ 

--enable-default-err-language="Italian" 

4.1.2 ACL 

Fig. 4-1 - Script di configurazione di Squid 

Tra le numerose opzioni di configurazione di Squid, sicuramente rivestono un ruolo 

centrale quelle relative alle Access Control List [Tag05b], [Wes04]. 

Le ACL consentono di impostare diverse politiche di utilizzo per definire le modalità 

con cui permettere l’accesso a Squid stesso. Definendo delle liste di controllo di accesso, 

con diverse regole associate, è possibile impedire o consentire agli utenti di accedere a 

determinati siti o a determinati contenuti; inoltre, è possibile limitare l'accesso nell'utilizzo di 

particolari protocolli di rete. Squid implementa circa 20 differenti tipologie di ACL che 

consentono di filtrare il traffico su altrettanti parametri, tra i quali i più importanti sono: 

• src: indirizzo IP del sorgente (client); 

• dst: indirizzo IP del server di destinazione; 

• url_regex: espressione regolare che identifica una URL; 

• urlpath_regex: espressione regolare che identifica una URL-path, non viene 

specificato il protocollo e l'eventuale hostname; 

71


• port: seleziona e specifica il numero di porta per il server di destinazione 

(server); 

• proto: protocollo di trasferimento (HTTP, FTP, ecc.); 

• method: metodo di richiesta HTTP (get, post, ecc.); 

• browser: espressione regolare che identifica una richiesta che viene effettuata 

da un browser web specifico; 

• snmp_community: definizione di una SNMP community string. 

E’ importante sottolineare che una ACL si compone di elementi e regole e che le 

espressioni utilizzate all’interno delle ACL sono Case Sensitive: è necessario quindi fare 

attenzione nell’inserimento delle stesse. Un elemento di una ACL si compone di 3 parti: 

1. nome dell’ACL; 

2. tipologia dell’ACL; 

3. uno o più valori legati alla tipologia oppure un file contenente i valori. 

In Fig. 4-2 sono riportati alcuni esempi di elementi di ACL, il primo elemento 

IP_sorgente filtra tutte le richieste provenienti dall’indirizzo 10.0.0.4, il secondo elemento 

domino_dest filtra tutte le richieste indirizzate verso il dominio www.google.it, infine il 

terzo elemento metodo_richiesta filtra sul metodo GET dell’HTTP. 

acl IP_sorgente src 10.0.0.4 

acl dominio_dest dstdomain www.google.it 

acl metodo_richiesta method GET 

Fig. 4-2 - Esempi di elementi di ACL 

E’ inoltre possibile associare più valori ad un elemento di una ACL; tuttavia in tal 

caso è importante sottolineare come il filtraggio avviene secondo una logica OR, ovvero, 

prendendo ad esempio gli elementi in Fig.4-3, nel primo caso il filtraggio sarà effettuato 

sull’indirizzo di destinazione 10.0.0.4 oppure sull’indirizzo 10.0.0.20, nel secondo caso 

invece il filtraggio avverrà nel caso che il dominio di destinazione sia www.google.it oppure 

www.google.com. Nell’ultimo caso infine il filtraggio sarà effettuato solo se i metodi HTTP 

utilizzati sono GET oppure PUT. 

72

acl IP_sorgente_m src 10.0.0.4 10.0.0.20 


acl dominio_dest_m dstdomain www.google.it www.google.com 

acl metodo_richiesta_m method GET PUT 

Fig. 4-3 - Esempi di elementi ACL con valori multipli 

Introdotti quelli che sono gli elementi delle ACL, si può ora passare alle regole 

corrispondenti e tali elementi. Per ogni elemento è necessario specificare una regola che ha 

lo scopo di consentire o di negare il traffico filtrato dall’elemento stesso. Riferendosi agli 

esempi di Fig.4-4, si ha che la prima regola consente il transito del traffico filtrato 

dall’elemento IP_sorgente, ovvero consente il traffico generato dall’IP 10.0.0.4; la seconda 

regola consente il traffico filtrato dall’elemento dominio_dest, ovvero consente il traffico 

che ha come dominio di destinazione www.google.it. L’ultima regola infine non consente il 

traffico filtrato dall’elemento metodo_richiesta, quindi non consente il traffico rappresentato 

da metodi GET dell’HTTP. 

http_access allow IP_sorgente 

http_access allow dominio_dest 

http_access deny metodo_richiesta 

Fig. 4-4 - Esempi di regole di ACL 

Anche nel caso delle regole è possibile specificare più valori; in questo caso tuttavia 

è importante sottolineare che, al contrario degli elementi, le regole lavorano secondo la 

logica AND. Rifacendosi quindi alla Fig.4-5, la prima regola consente il passaggio del 

traffico proveniente dall’indirizzo 10.0.0.4 solamente se destinato al dominio 

www.google.it; la seconda regola nega il traffico generato dall’indirizzo 10.0.0.4 che sia 

contemporaneamente effettuato attraverso il metodo GET dell’HTTP. La terza regola infine 

non consente il traffico generato attraverso una GET HTTP e diretto verso il dominio 

www.google.it. 

http_access allow IP_sorgente dominio_dest 

http_access deny IP_sorgente metodo_richiesta 

http_access deny metodo_richiesta dominio_dest 

Fig. 4-5 - Esempi di regole ACL con valori multipli 

73


L’insieme quindi degli elementi e delle rispettive regole consente di controllare 

finemente il traffico in transito sul proxy server. Le ACL, come precedentemente accennato, 

sono infatti state usate nell’ambito del progetto per realizzare il meccanismo di 

indirizzamento delle richieste, andando a filtrare in base all’estensione del file richiesto 

(Fig.4-6) e, attraverso la regola cache_peer_access che consente di negare o meno l’accesso 

ad un determinato cache peer, indirizzando tale traffico dal front-end verso il back-end. La 

direttiva never_direct infine, opportunamente settata, impedisce al proxy di collegarsi 

direttamente all’origin server per la tipologia di traffico selezionata, un ulteriore controllo 

quindi per aumentare la sicurezza di instradare il traffico selezionato verso il back-end. 

# L7 SWITCHING tramite ACL 

acl MM urlpath_regex -i 

\.avi$ \.mpg$ \.mpeg$ \.mov$ \.divx$ \.xvid$ \.mkv$ \.wmv$ \.wav$ 

\.mp3$ \.ogg$ \.mpc$ \.asf$ \.wma$ \.iso$ \.bin$ \.img$ \.nrg$ \.vob$ 

\.mdf$ 

#Su 10.50.5.80 vanno solo i file MM 

never_direct allow MM 

cache_peer_access 10.50.5.80 deny !MM 

Fig. 4-6 - Insieme di ACL usate per effettuare l’indirizzamento delle richieste 

4.1.3 File di log 

Una ottima fonte di informazioni relativamente alle prestazioni e ai carichi di Squid è 

rappresentata dai propri file di log [Squ05b]. Questi file consentono non solo di avere 

informazioni di accesso, ma anche informazioni riguardanti errori di configurazione del 

sistema e informazioni sul consumo delle risorse. Diversi sono i file di log prodotti da Squid, 

alcuni di questi devono essere attivati in fase di compilazione, altri possono essere disattivati 

comodamente attraverso il file squid.conf, tra questi abbiamo: 

• cache.log: contiene i messaggi di errore e di debug generati da Squid (Fig.4- 

7). Questo file non offre molte informazioni utili in fase di analisi automatica 

dei log; generalmente viene utilizzato, previa attivazione dei messaggi di 

debug, per verificare il motivo di un funzionamento anomalo del proxy server. 

74


2005/04/21 17:29:56| Starting Squid Cache version 2.5.STABLE9 for 

i686-pc-linux-gnu... 

2005/04/21 17:29:56| Process ID 13272 

2005/04/21 17:29:56| With 1024 file descriptors available 

2005/04/21 17:29:56| Performing DNS Tests... 

2005/04/21 17:29:56| Successful DNS name lookup tests... 

2005/04/21 17:29:56| DNS Socket created at 0.0.0.0, port 32902, FD 5 

2005/04/21 17:29:56| Adding nameserver 195.103.122.10 from 

/etc/resolv.conf 

2005/04/21 17:29:56| Unlinkd pipe opened on FD 10 

2005/04/21 17:29:56| Swap maxSize 11264000 KB, estimated 866461 

objects 

2005/04/21 17:29:56| Target number of buckets: 43323 

… 

Fig. 4-7 - Esempio di file cache.log 

• useragent.log: necessita di essere espressamente attivato in fase di 

compilazione, attraverso il parametro enable-user-agent-log, e consente di 

tener traccia dei diversi browser utilizzati dai client. La creazione di tale file 

può appesantire un sistema Squid in produzione. 

• store.log: questo file di logging (Fig.4-8) può sicuramente essere utilizzato 

per reperire informazioni utili sul salvataggio dei file in cache. Esso infatti 

tiene traccia di tutti gli elementi trattati da Squid e in particolare di quelli 

salvati e di quelli rimossi dalla cache. Quindi, può essere utile per conoscere, 

ad esempio, informazioni su quali oggetti sono stati memorizzati e per quanto 

tempo sono stati mantenuti in cache. Un oggetto memorizzato in cache viene 

identificato con il termine SWAPOUT, mentre un oggetto rimosso dalla 

cache è identificato tramite il termine RELEASE. 

75


1113974963.327 RELEASE -1 FFFFFFFF D64DC3B5156D41116E4685E6651F5878 

404 1113916784 -1 -1 text/html 538/538 GET http://cdnaimtoday.aol.com/aimtoday_daypart/nav_middle 

1113974963.650 SWAPOUT 00 00005EC0 0F1E39BACA2F455A107BFD2EF51578FA 

200 1113978574 1113933213 -1 image/gif 2790/2790 GET 

http://cdn-aimtoday.aol.com/wpt_at_main_am/200504191353_rc_hlm1_i1_1_0 

1113974963.809 RELEASE -1 FFFFFFFF 89B143E593B2648C0B8B1424A82F3C09 

200 1113978574 -1 1113978574 application/x-javascript 147/147 

GET http://ar.atwola.com/html/93139375/508300829/aoladp? 

1113974963.978 RELEASE -1 FFFFFFFF ED7BD8D7618355C02D434D971F6A9359 

200 1113978575 1093543773 -1 text/html 903/903 GET 

http://creativeby.viewpoint.com/A7/N1040/M463/P174/Q2081/B_2_4/index_i 

frame_2_4.html? 

Fig. 4-8 - Esempio di file store.log 

• access.log: le informazioni più importanti reperibili per l’analisi dei log sono 

contenute all’interno di questo file (Fig.4-9). Attualmente è possibile avere 

due formati di logging relativi a tale file: un formato proprietario di Squid e 

un formato secondo il “common log file format” così come definito dal 

demone web del CERN. 

I due formati di logging contengono informazioni diverse e sicuramente la 

versione nativa di Squid fornisce informazioni di utilità maggiore nel caso si 

voglia monitorare una cache. 

1113377710.386 335 10.250.1.120 TCP_MISS/302 415 GET 

http://www.google.com/ - DIRECT/66.102.9.104 text/html 

1113377710.560 169 10.250.1.120 TCP_MISS/200 1425 GET 

http://www.google.it/ - DIRECT/66.102.9.104 text/html 

1113377711.960 419 10.50.5.81 TCP_MISS/301 400 GET 

http://g.msn.com/8HMBITIT/1945? - DIRECT/207.68.179.219 - 

1113377712.132 50 10.50.5.81 TCP_IMS_HIT/304 208 GET 

http://www.msn.it/img/it/it-it/MSNSito/messenger/v7/Local1.css - 

NONE/- text/css 

1113377712.141 2 10.50.5.81 TCP_IMS_HIT/304 208 GET 

http://www.msn.it/img/it/it-it/MSNSito/messenger/v7/main1.css - NONE/- 

text/css 

1113377712.998 93 10.50.5.81 TCP_HIT/200 18757 GET 

http://spe.atdmt.com/b/D3D3IITALMSN/Messenger_Slot_Machine_Turchese_16 

0x600.gif - NONE/- image/gif 

Fig. 4-9 - Esempio di access.log nel formato nativo di Squid 

76


Il formato del file di log nativo di Squid, rappresentato in Fig.4-10, consente 

di avere informazioni quali: 

- elapsed: rappresenta il tempo che la transazione ha occupato la cache, 

calcolato in millisecondi. Esso differisce a seconda del protocollo di 

livello transport utilizzato: TCP o UDP. In particolare: 

§ per l’HTTP/1.0 è il tempo che intercorre tra una accept() e una 

close(); 

§ per le connessioni persistenti è il tempo che trascorre tra lo 

scheduling della risposta e la fine dell’invio della stessa; 

§ per l’ICP è il tempo che intercorre tra lo scheduling di una 

risposta e l’invio effettivo della stessa. 

- Result codes: è divisa in due parti da uno slash, la prima parte è 

costituita dai codici specifici di Squid, mentre la seconda parte 

rappresenta i codici generati da Squid secondo il formato proprio 

dell’HTTP. Questa prima tipologia di codici risulta di grande utilità ai 

fini del monitoraggio della cache, in quanto consente di identificare le 

informazioni sul tipo di richiesta, su come è stata soddisfatta o il 

motivo per cui è fallita. Di seguito vengono mostrati alcuni tra i più 

significativi codici: 

§ TCP_HIT: una copia valida dell’oggetto era presente in cache; 

§ TCP_MISS: l’oggetto richiesto non era presente in cache; 

§ TCP_REFRESH_HIT: l’oggetto richiesto era presente in 

cache ma marchiato come STALE (vecchio). Tuttavia la 

richiesta IMS (If Modified Since) ha ricevuto un codice “304 

Not Modified”; 

§ TCP_REFRESH_MISS: l’oggetto era presente in cache ma 

STALE. La richiesta IMS ha ritornato un nuovo contenuto; 

§ TCP_IMS_HIT: l’oggetto richiesto a seguito di una richiesta 

IMS era presente in cache e ritenuto fresco; 

77


§ TCP_MEM_HIT: una copia valida dell’oggetto, oltre che in 

cache, era presente in memoria e quindi non ha richiesto 

l’accesso al disco. 

- Hierarchy codes: codici relativi alla gerarchia di cache. Sono 

composti da tre parti, la prima parte potrebbe essere rappresentata da 

un TIMEOUT, nel caso sia occorso un timeout durante l’attesa di tutte 

le richieste ICP ai vicini, la seconda parte rappresenta un codice che 

identifica come la richiesta è stata trattata (inviata ad un cache peer o 

diretta verso l’origin server), la terza e ultima informazione 

rappresenta l’indirizzo IP o l’hostname dove la richiesta è stata inviata. 

Di seguito vengono evidenziati i codici più significativi: 

§ DIRECT: l’oggetto è stato prelevato direttamente dall’origin 

server; 

§ DEFAULT_PARENT: non è stata inviata nessuna richiesta 

ICP, poiché è stato usato il cache peer marcato come default 

nel file di configurazione; 

§ FIRST_PARENT_MISS: l’oggetto è stato prelevato dal cache 

peer col valore più basso di RTT (Round Trip Time). 

time elapsed remotehost code/status bytes method URL rfc931 

peerstatus/peerhost type 

Fig. 4-10 - Formato del file di logging access.log proprietario di Squid 

4.1.4 Configurazioni varie 

Il file di configurazione di Squid, squid.conf, consente una impostazione fine del 

programma, permettendo di agire su un insieme innumerevole di impostazioni. Di seguito, 

vengono evidenziate solo alcune di esse, quelle che hanno avuto una rilevanza notevole ai 

fini del progetto. 

• cache_peer: questa direttiva serve per specificare le altre cache facenti parte 

della gerarchia. Il formato è quello specificato nell’esempio in Fig.4-11 e 

consente di definire, rispettivamente: l’hostname della cache, il proprio ruolo 

78


rispetto alla cache in questione, ovvero sibling (allo stesso livello della cache 

sulla quale si effettua l’impostazione) oppure parent (ad un livello superiore), 

la porta sulla quale tale cache sarà in ascolto per le richieste del proxy, la 

porta usata per interrogarla via ICP sul proprio contenuto, infine eventuali 

opzioni, tra cui quella rappresentata nell’esempio, proxy-only. Proprio questa 

opzione è stata fondamentale nell’architettura adottata in quanto ha consentito 

il funzionamento ottimale del meccanismo di indirizzamento delle richieste 

implementato tramite le ACL. L’opzione proxy-only, infatti, forza Squid che 

utilizza la cache specificata, tramite la direttiva cache_peer, a non salvare per 

sé il contenuto dei file scambiati con questa cache. Utilizzando questa 

opzione, è stato possibile impostare la cache di front-end in modo tale da non 

salvare in cache i file ricevuti dalla cache di back-end, impedendole così di 

diventare a sua volta una “replica” di quest’ultima e di vanificare così la 

divisione del traffico in base al contenuto. 

cache_peer 10.50.5.80 parent 3128 3130 proxy-only 

… 

Fig. 4-11 - Esempio di impostazione cache_peer usata per i test 

• maximum_object_size: questa direttiva consente di specificare le dimensioni 

massime di un oggetto in byte memorizzabile in cache. Proprio questa 

impostazione, come precedentemente descritto, è stata la causa di un bug 

nella versione pushing di Squid, poiché forzava lo Squid di front-end non 

solo a non memorizzare, ma addirittura a chiudere la connessione non appena 

il file che stava ricevendo dallo Squid di back-end raggiungeva tale limite. 

• refresh_pattern: l’impostazione relativa al refresh_pattern è molto importante, 

poichè consente di specificare le regole che permettono a Squid di verificare 

la freschezza di un file. Come mostrato nell’esempio in Fig.4-12, tale 

impostazione si compone rispettivamente di una espressione regolare (usata 

per identificare una url per esempio), di un valore min, di un valore percent e 

di un valore di max. Il primo dei tre valori rappresenta il tempo (in minuti) 

che un oggetto senza un valore di expiry time deve essere considerato fresco, 

il secondo rappresenta la percentuale del valore di age (calcolato come: 

79


age=ora_attuale-data_creazione_oggetto) per cui un oggetto senza expiry 

time esplicito deve essere considerato fresco, il terzo valore, infine, 

rappresenta il limite superiore sul tempo per cui un oggetto senza expiry time 

deve essere considerato fresco. 

refresh_pattern ^ftp: 1440 20% 10080 

refresh_pattern ^gopher: 1440 0% 1440 

refresh_pattern . 0 20% 4320 

Fig. 4-12 - Esempio di impostazioni del parametro refresh_pattern 

Come precedentemente accennato, tale direttiva è stata la fonte del bug più 

penalizzante della versione di Squid appositamente modificata per il pushing. 

Come mostra lo pseudocodice in Fig.4-13, Squid verifica la freschezza 

secondo un ordine ben preciso. Dal momento che tale versione di Squid non 

memorizzava correttamente il valore del campo relativo alla data di creazione 

dell’oggetto impostandolo a 0 (equivalente sotto i sistemi operativi *nix alla 

data del 1 Gennaio 1970), il valore di age era sempre pari a circa 35 anni. Di 

conseguenza, il secondo controllo in Fig.4-12 falliva sempre e l’unico modo 

per far memorizzare qualcosa in cache era quello di impostare il valore di 

max oltre i 35 anni. 

FRESH if expires < now, else STALE 

STALE if age > max 

FRESH if lm-factor < percent, else STALE 

FRESH if age < min 

Else STALE 

Fig. 4-13 - Pseudocodice per il controllo della freschezza di un oggetto di Squid 

4.2 SNMP 

Simple Network Management Protocol è un protocollo di livello applicativo [Coh95], 

[Cis02] basato principalmente su UDP, che facilita lo scambio di informazioni di gestione 

tra periferiche di rete. Esso consente all’amministratore di rete di gestire le prestazioni della 

stessa, trovare e risolvere problemi, nonché pianificarne uno sviluppo. Questo protocollo è 

80


stato sviluppato nel 1988 e da allora è diventato uno standard de facto per la gestione delle 

reti, poiché richiede un basso sforzo implementativo e consente ai produttori di aggiungere 

nuove funzionalità di gestione ai proprio apparecchi. Una rete gestita via SNMP consiste di 

due elementi chiave: 

1. agente: modulo software per la gestione di rete che risiede su una periferica 

monitorizzata. Esso raccoglie e immagazzina le informazioni relative alla 

periferica gestita e le rende in un formato compatibile con l’SNMP, può 

inoltre inviare dei messaggi asincroni per segnalare eventi al manager; 

2. manager: il manager o Network Management Station (NMS), presente su una 

rete gestita in una o più macchine, si occupa di monitorizzare e controllare le 

periferiche gestite. Esso possiede la potenza di calcolo e la memoria 

necessaria alla gestione della rete: interroga gli agenti, riceve le risposte, 

imposta delle variabili sugli agenti stessi e infine risponde ad eventi asincroni 

inviati da quest’ultimi. 

Come precedentemente accennato, gli agenti costituiscono l’interfaccia di gestione 

verso le periferiche di rete che implementano il protocollo SNMP. Queste periferiche 

possono essere apparati di rete specifici, per esempio router, bridge e switch, ma anche 

periferiche varie, come stampanti e altre collegabili in rete e infine anche programmi 

dedicati alle reti, tra i quali proprio Squid. Tali periferiche contengono al loro interno una 

serie di “oggetti gestiti” sui quali gli agenti prelevano informazioni: questi oggetti possono 

essere componenti hardware, parametri di configurazione, statistiche prestazionali e altro 

ancora e sono normalmente organizzati in una sorta di database virtuale di informazioni, 

chiamato Management Information Base (MIB), nel quale sono raccolte l’insieme delle 

proprietà relative ad ogni oggetto gestito. Ognuno di questi oggetti è identificabile 

univocamente da un Object Identifier (OID), rappresentato da una serie di numeri interi 

separati da punti. Tale struttura è alla base dell’organizzazione gerarchica del MIB, 

rappresentabile tramite un albero, in cui ogni livello è assegnato ad una differente 

organizzazione (Fig.4-14). 

Attualmente esistono tre versioni del protocollo SNMP: SNMPv1, SNMPv2 e 

SNMPv3. Mentre la versione 2 estende solamente alcune funzionalità della versione 1, la 

versione 3 implementa delle politiche di sicurezza più stringenti e uno schema di 

81


autenticazione forte, consentendo lo scambio di informazioni attraverso un canale 

crittografato. Infatti, è da sottolineare come, fino alla versione 2 del protocollo, l’accesso agli 

agenti da parte delle NMS sia stato caratterizzato dall’utilizzo di una schema di 

autenticazione debole, ossia basato sull’uso di password in chiaro, le community string. La 

community string, inviata dalle NMS in ogni messaggio SNMP, viene infatti intesa come 

una sorta di autenticazione, poiché le NMS che non conoscono il nome della comunità sono 

precluse dal poter effettuare operazioni SNMP. 

Fig. 4-14 - Albero gerarchico degli OID nel MIB 

Nel progetto in esame è stato fatto uso del protocollo SNMP e di alcuni tool specifici 

al fine di effettuare il monitoraggio dell’architettura scelta. Innanzi tutto, è stato necessario 

abilitare Squid al supporto SNMP [Tag05c], dapprima in fase di compilazione, attraverso la 

direttiva enable-snmp nello script di configurazione, quindi settando appositamente delle 

ACL, in modo da consentire o meno l’accesso all’agente SNMP di Squid (Fig4-15). 

82

## ACL SNMP ## 

acl snmppublic snmp_community public 

snmp_access allow localhost 

snmp_access allow snmppublic localhost 

snmp_access deny all 


Fig. 4-15 - Esempio di ACL per l'accesso SNMP su Squid 

Utilizzando come sistema operativo Linux, sono stati impiegati i tool disponibili in 

tale ambiente per il monitoraggio SNMP [Gue97]. In particolare sono stati usati i comandi 

da shell: 

• smnpwalk: lo scopo di questo comando è quello di “camminare” lungo 

l’albero gerarchico del MIB di Squid, così da individuare i valori più 

opportuni da monitorare; 

• smnpget: la funzionalità di questa utility è quella di prelevare il valore 

associato all’OID selezionato. 

4.3 MRTG e RRDTOOL 

Tuttavia, tali tool di SNMP non erano sufficienti per effettuare un monitoraggio 

costante e automatizzato. Di conseguenza, sono stati presi in considerazione due strumenti 

entrambi largamente utilizzati nell’ambito del monitoraggio di periferiche di rete via SNMP: 

MRTG e RRDTOOL [Tag05d], [MRT05], [Gen05], [Pru04]. 

Multi Router Traffic Grapher è una applicazione per la gestione di rete, in grado di 

monitorizzare qualsiasi periferica ad essa collegata che supporti il protocollo SNMP. 

Originariamente, MRTG era stato pensato per monitorizzare solamente le interfacce di un 

host di rete; allo stato attuale, consente l’interrogazione di qualsiasi OID supportato è in 

grado di costruire un grafico che ne rappresenti le variazioni. 

MRTG acquisisce informazioni SNMP eseguendo i seguenti task: 

• interroga l’host remoto e recuperare il valore di un OID specifico; 

• aggiorna il grafico delle variazioni con i nuovi valori e cancella il grafico 

precedente (i grafici sono immagini in formato PNG e possono essere 

memorizzati in locale o remoto); 

83


• memorizza i nuovi valori in un file di log (anche questo memorizzabile sia in 

locale sia in remoto). 

Per ogni host monitorizzato è richiesto un file di configurazione dedicato (.cfg), nel 

quale vengono definiti gli OID sui quali si vogliono ottenere informazioni. Su tale file verrà 

effettuato un parsing da MRTG dal quale estrarre gli OID da interrogare. 

Per creare questo file di configurazione è possibile lanciare lo script cfgmaker, 

specificando l’indirizzo dell’host da monitorare. Questo script provvede quindi ad 

interrogare l’host indicato per estrarre gli OID di tutte le interfacce di rete disponibili e su 

quelle costruisce il file di configurazione. Tale tool evidenzia quelle che sono le origini di 

MRTG: non a caso un file .cfg così creato riporta solamente gli OID relativi al traffico in 

ingresso e uscita delle interfacce di rete di un host, risultando quindi inadatto nel caso di 

Squid. Per creare un file di configurazione significativo per Squid, è stato analizzato l’intero 

MIB di Squid (disponibile nella cartella squid/share/mib.txt). In tale file è possibile trovare 

tutte le OID messe a disposizione da Squid, tra le più significative si possono trovare: 

• cacheSysStorage: dimensione dello spazio di swap in KB; 

• cacheNumObjCount: numero di oggetti memorizzati in cache; 

• cacheCurrentUnusedFDescrCnt: numero dei file descriptor disponibili; 

• cacheHttpHits: numero delle richieste HTTP ricevute; 

• cacheHitRatio: valore di hit ratio delle richieste. 

Il file di configurazione creato (riportato in Appendice B), presenta anche numerosi 

parametri, tra i quali quelli relativi alla generazione di grafici: dimensione dell’immagine, 

scala dei valori degli assi del grafico, colori impiegati, etc. Altri parametri riguardano la 

generazione automatica delle pagine html che è possibile creare usando i grafici prodotti da 

MRTG, altri ancora riguardano la selezione della lingua e il caricamento di una particolare 

MIB. Tra i numerosi parametri, uno in particolare, interval, consente di selezionare 

l’intervallo di monitoraggio, che può essere impostato ad un valore minimo di 5 minuti. Per 

scendere sotto tale soglia diventa necessario l’utilizzo di RRDTOOL, congiuntamente a 

MRTG. 

RRDTOOL è un database Round-Robin (da qui il nome), ovvero un database che 

memorizza dati dipendenti dal tempo, in modo da mantenere costanti le dimensioni del 

database, “ruotando” i dati memorizzati: quando il database si riempie, i nuovi dati vengono 

84


scritti sopra quelli vecchi. Di default, per ogni valore monitorizzato vengono creati database 

per tenere 1 giorno di dati ad alta risoluzione, una settimana di dati a 30 minuti, 2 mesi di 

dati a 2 ore e due anni di dati ad 1 giorno. Tale strumento risulta molto utile se accoppiato 

con MRTG, poiché libera quest’ultimo dal compito di creare i grafici delle variazioni dei 

dati raccolti, memorizzandoli all’interno del database per una elaborazione successiva. 

Grazie alla diminuzione del carico di MRTG, è possibile diminuire la frequenza di raccolta 

dati da una volta ogni 5 minuti ad una volta al minuto. 

Per poter utilizzare RRDTOOL come supporto alla memorizzazione dei valori 

raccolti sotto MRTG, è necessario modificare appositamente il file di configurazione di 

quest’ultimo, secondo quanto riportato nell’esempio in Fig.4-16. 

PathAdd: /usr/bin 

LibAdd: /usr/share/perl/gentoo-pods/5.8.2 

logformat: rrdtool 

Interval: 1 

Fig. 4-16 - Impostazioni per l'utilizzo di RRDTOOL all'interno di un .cfg di MRTG 

I valori così raccolti possono poi essere esportati in XML, al fine di essere elaborati 

in seguito. Nel corso del progetto, i valori raccolti sono stati esportati in XML e poi elaborati 

in Excel. In Fig.4-17 e Fig.4-18 sono riportati i grafici Excel rispettivamente della 

dimensione della cache e del numero di oggetti in essa contenuta, relativamente ad una 

giornata di monitoraggio SNMP. 

85


Fig. 4-17 - Dimensione della cache in un giorno di utilizzo 

Fig. 4-18 - Numero di oggetti in cache in un giorno di utilizzo 

86

4.4 Calamaris 


Per effettuare il testing dell’architettura è stato necessario reperire le numerose 

informazioni utili all’interno dei file di log di Squid. Al fine di automatizzare la procedura è 

stato utilizzato un tool molto noto nell’ambito dell’analisi dei file di log di proxy server: 

Calamaris [Bee05]. 

Questo programma, scritto in Perl, è stato creato inizialmente nel 1997, con il solo 

scopo di creare un tool per analisi statistiche dei log di Squid. In seguito, visto la crescente 

popolarità, è stato riscritto aggiungendo nuove caratteristiche, fino alla attuale versione 3 in 

fase di beta, utilizzata per l’analisi dei log dell’architettura scelta, che consente anche la 

creazione di grafici a partire dai risultati delle analisi effettuate. 

Attualmente Calamaris supporta differenti tipologie di file di log, a seconda del 

programma che li ha generati: 

• Squid V1.1.alpha1-V2.x 

• NetCache 

• Inktomi Traffic Server 

• Oops! proxy server 

• Compaq Tasksmart 

• Novell Internet Caching System 

• Netscape/iPlanet/SunONE Web Proxy Server 

• Squid with the SmartFilter-patch 

• Cisco Content Engines 

Il funzionamento del programma richiede la configurazione dello stesso, tramite il 

file di configurazione calamaris.conf (Appendice C). All’interno di tale file è necessario 

attivare le analisi che si vogliono effettuare sui log di interesse, nonché specificare se si 

vogliono o meno creare i grafici con i risultati di tali analisi. 

Tra le analisi di maggiore interesse vi sono sicuramente quelle relative alle 

percentuali di Hit Rate, di Byte/Hit Rate e tutte quelle analisi relative alla distribuzione di 

differenti tipologie di informazioni, quali: la tipologia delle richieste, la tipologia dei codici 

di risposta, i differenti domini visitati, i tempi di risposta delle richieste, le dimensioni dei 

file richiesti (Fig.4-19), etc. 

87


Fig. 4-19 - Distribuzione della dimensione e del numero dei file richiesti 

88

5. Progettazione e implementazione dei moduli software di SatSquid 

5 Progettazione e implementazione dei moduli 

software di SatSquid 

Le scelte di progetto evidenziate nel Cap.3 hanno guidato la fase di implementazione 

dell’architettura di SatSquid. In particolare, la scelta di utilizzare Squid come sistema proxy 

server di riferimento ha portato alla necessità di una attenta configurazione dello stesso, al 

fine di realizzare una architettura di caching su due livelli, con due istanze di Squid per 

livello. 

Come evidenziato nel Cap.4, grazie alle opzioni disponibili all’interno del file di 

configurazione di Squid, è stato possibile implementare un indirizzamento delle richieste, 

distinguendo la tipologia di traffico da trattare per ognuna delle due istanze. Consolidata 

l’architettura di base, è stato quindi necessario implementare SPD (Satellite Prefetching 

Daemon), il demone che si occupa di effettuare l’analisi dei log e il conseguente prefetching 

degli elementi più richiesti, e MMI (Mirroring Management Interface), l’interfaccia di 

management per il mirroring dei siti web. Nel corso di questo capitolo verrà innanzitutto 

descritto il funzionamento dell’architettura software (5.1), in seguito saranno presentati SPD 

(5.2) e MMI (5.3), che costituiscono gli elementi caratterizzanti l’architettura implementata. 

5.1 Architettura software di SatSquid 

Le architetture software progettate consentono di mascherare la latenza tipica del 

canale satellitare. Per comprendere meglio il funzionamento dell’architettura di base di 

SatSquid, di seguito vengono presentati due esempi: il primo (Fig.5-1) relativo al caso di una 

richiesta di un normale documento web (WD), il secondo (Fig.5-2) relativo alla richiesta di 

un documento di tipo multimediale (MM). 

Nel primo esempio, un client richiede un normale documento web al secondo livello 

di caching. La richiesta, come precedentemente accennato (Cap.3), viene indirizzata al proxy 

di front-end. Quest’ultimo, identificata tramite le ACL la tipologia della richiesta (WD), 

ricerca nella propria cache la presenza dell’oggetto richiesto. Nel caso tale oggetto sia 

presente in cache e considerato “fresco”, lo restituisce direttamente al client, altrimenti 

provvede ad inoltrare la richiesta al corrispondente proxy di primo livello. Questo, nel caso 

89


abbia in cache l’oggetto richiesto, lo restituisce al proxy di secondo livello, che a sua volta, 

previa memorizzazione dello stesso nella propria cache, lo restituisce al client. 

Nell’eventualità in cui, invece, anche il proxy di primo livello non possieda in cache 

l’oggetto richiesto, si occupa di prelevarlo dall’origin server, di memorizzarlo nella propria 

cache e quindi lo invia al proxy di secondo livello. Quest’ultimo, memorizzato in cache 

l’oggetto, lo restituisce al client che ne aveva fatto richiesta. 

Fig. 5-1 - Funzionamento dell'architettura software nel caso di richiesta di tipo WD 

Nel secondo esempio, invece, la richiesta effettuata da un client è di tipo 

multimediale (MM). Il proxy di front-end del secondo livello, tramite l’utilizzo delle ACL, 

indirizza la richiesta MM direttamente al proxy di back-end del secondo livello. Questo, nel 

caso abbia memorizzato in cache l’oggetto richiesto, provvede ad inviarlo al client, 

indirizzandolo attraverso il proxy di front-end. Quest’ultimo, tuttavia, non memorizza nella 

propria cache l’oggetto ricevuto dal back-end, ma si limita a indirizzarlo al client. Tale 

accorgimento è necessario al fine di evitare che il proxy di front-end diventi una replica di 

quello di back-end. Nel caso il proxy di back-end di secondo livello non possieda l’oggetto 

richiesto in cache, indirizza la richiesta al corrispettivo proxy di back-end di primo livello. 

Ancora una volta, nel caso questo possieda l’oggetto richiesto in cache, lo fornisce 

direttamente al proxy di back-end di secondo livello, che, previa memorizzazione nella 

propria cache, lo restituisce al client attraverso il proxy di front-end. Nel caso l’oggetto non 

risieda invece nella propria cache, il proxy di back-end di primo livello preleva l’oggetto 

90


direttamente dall’origin server, lo invia al proxy di secondo livello, che, dopo averlo 

memorizzato, lo invia al client, facendolo transitare per il front-end. 

Fig. 5-2 - Funzionamento dell'architettura software nel caso di richiesta di tipo MM 

Tali esempi non sono validi nel caso dell’architettura alternativa (mirroring dedicato), 

in quanto, in tal caso, non vengono effettuate distinzioni sulla tipologia del traffico, essendo 

il proxy di back-end, per ogni livello, dedicato esclusivamente al mirroring. Nel caso, quindi, 

di una richiesta verso un sito per il quale è stato effettuato il mirroring (Fig.5-3), il 

funzionamento dell’architettura è il seguente: la richiesta viene effettuata dal client verso il 

proxy di front-end del secondo livello di caching. Questo, tramite l’ausilio delle ACL, 

indirizza tale richiesta direttamente verso il server di back-end di pari livello, il quale, nel 

caso abbia memorizzato nella propria cache il contenuto richiesto, lo restituisce attraverso il 

server di front-end al client. Nell’eventualità in cui, invece, il server di back-end del secondo 

livello non possieda l’oggetto richiesto, provvede ad indirizzare la richiesta verso il server di 

back-end di primo livello. Quest’ultimo, a sua volta, invia l’informazione richiesta al proxy 

di secondo livello nel caso ne sia in possesso, altrimenti la richiede direttamente all’origin 

server, per poi inviarla. Anche in questo caso, come nei due precedenti, il server di front-end 

non memorizza in cache le informazioni ricevute dal server di back-end, al fine di evitare di 

costituirne una inutile replica. 

91


Fig. 5-3 - Funzionamento dell'architettura software alternativa 

Le funzionalità delle due architetture software appena descritte sono state espanse 

grazie all’implementazione di due elementi aggiuntivi: SPD e MMI. Tali elementi verranno 

meglio descritti nelle sezioni successive. 

5.2 SPD (Satelitte Prefetching Daemon) 

Il demone SPD costituisce il cuore del meccanismo di prefetching. Esso ha il 

compito di analizzare, nei momenti di minor carico (presumibilmente intorno alla 

mezzanotte), il file access.log.0 di Squid, creato nella giornata appena trascorsa, per 

raccogliere le URL più richieste in una lista, e iniziarne il prefetching. Il linguaggio scelto 

per la realizzazione del demone è il Python [Pyt05a]. Il Python è un linguaggio sviluppato 

nei primi anni 90 presso il CWI (Centrum voor Wiskunde en Informatica) di Amsterdam. 

Esso si caratterizza per essere un linguaggio di alto livello ad oggetti, interpretato e 

portabile: attualmente sono diverse le piattaforme che lo supportano, partendo da sistemi 

*nix, passando per Windows OS, OS/2, MAC, Amiga, fino ad arrivare ai sistemi Symbian 

dei moderni smartphone [Nok05]. La potenza di questo linguaggio è da ricercare 

sicuramente nella semplicità della sintassi (non banalizzante tuttavia) e quindi nella rapidità 

implementativa che consente in fase di sviluppo. Inoltre, è caratterizzato dalla presenza di 

una libreria standard “all inclusive”, ricca cioè di numerosi moduli e funzioni adatti agli 

92


scopi più disparati. Proprio queste sono state le caratteristiche che hanno portato alla scelta 

di tale linguaggio: rapidità di sviluppo e utilizzabilità a 360 gradi. 

Inoltre, al fine di fornire le funzionalità di demone e di poter quindi avviare il 

programma con cadenza regolare in determinati orari della giornata, sono stati utilizzati i 

servizi messi a disposizione dal demone cron [Bro05]. Questo demone è utilizzato in tutti i 

sistemi operativi *nix e ne esistono diverse implementazioni. Le funzionalità del demone 

cron sono quelle di permettere l’esecuzione di comandi, con credenziali impostate, a diversi 

intervalli e con una ripetitività selezionata. Cron si attiva all’avvio della macchina e rimane 

sempre in funzione, attivandosi ogni minuto per controllare la presenza di operazioni da 

eseguire (cron-job), all’interno di una lista di operazioni (/etc/crontab). Ogni riga all’interno 

del crontab contiene un comando preceduto da una serie di indicatori della sequenza 

temporale di esecuzione dello stesso e dalle credenziali di esecuzione per il comando. Gli 

indicatori della sequenza temporale sono rappresentati da cinque campi, rispettivamente: i 

minuti (0-59), le ore (0-23), i giorni del mese (1-31), i mesi (1-12) e i giorni della settimana 

(0-7, Lunedì è 1, Domenica è 0 e 7). I giorni della settimana e i mesi possono anche essere 

inseriti tramite delle abbreviazioni di tre lettere dei corrispettivi in lingua inglese (es: mon, 

tue, wed, jan, feb, etc). Infine ogni campo può anche contenere un intervallo di valori (es: 1- 

5) o una lista di valori separati da virgole (es: 1,2,3,4). In Fig.5-4 è riportato un esempio di 

alcune istruzioni all’interno del crontab. 

30 5 1 * * root rm -f /var/spool/cron/lastrun/cron.monthly 

* * * * * root test -x /usr/sbin/run-crons && /usr/sbin/runcrons 

il seguente: 

Fig. 5-4 - Esempio di istruzioni all'interno del crontab 

5.2.1 Funzionamento 

Il funzionamento di SPD, come mostrato anche nel diagramma di flusso di Fig.5-5 è 

• avvio del programma ogni giorno verso le 00:00, nel momento in cui si 

suppone esserci meno carico nel sistema; 

93


• parsing del file di configurazione del demone, al fine di determinare diversi 

parametri che sono necessari al corretto funzionamento dello stesso (per 

esempio: dimensione della cache, posizione del file access.log.0, attivazione 

della notifica del funzionamento via mail, etc); 

• preparazione, nel caso sia stata attivata l’opzione per la notifica di 

funzionamento via mail, delle intestazioni dei messaggi email di notifica; 

• analisi del file di log: l’intero file viene controllato richiesta per richiesta, 

effettuando un parsing della stessa al fine di individuarne le dimensioni e la 

URL di riferimento; per ogni richiesta viene quindi memorizzato il numero di 

occorrenze all’interno del file, allo scopo di creare una lista successiva, in cui 

le richieste sono ordinate in modo crescente in base al numero di occorrenze, 

ovvero dalla più richiesta alla meno richiesta; 

• inizio della fase di prefetching delle richieste, partendo, appunto, da quella 

con il maggior numero di richieste e tenendo man mano traccia delle 

dimensioni occupate, al fine di non superare il 70% delle dimensioni della 

cache stessa, per non avviare l’algoritmo di rimpiazzamento. Controllo sulla 

presenza di eventuali errori di funzionamento ed eventuale invio di mail di 

notifica nel caso sia stata abilitata, nel file di configurazione, la notifica del 

funzionamento via mail. 

94


Fig. 5-5 - Diagramma di flusso del funzionamento del demone SPD 

95


5.2.2 Implementazione 

Lo scopo del demone SPD è quello di mascherare la latenza insita nel canale 

satellitare, prelevando in anticipo (prefetching) i contenuti che con buona probabilità 

verranno richiesti in un prossimo futuro. Al fine di raggiungere tale scopo, tuttavia, è stata 

necessaria una implementazione dipendente dall’architettura utilizzata: architettura di base o 

architettura alternativa. 

Nel primo caso, infatti, vista la distinzione in base alla tipologia di traffico effettuata 

all’interno del sistema, è necessario utilizzare una istanza di SPD per ognuno dei proxy 

presenti nei due livelli di caching. Come mostrato in Fig.5-6, in questo modo viene 

effettuato il prefetching proprio in base alla tipologia di traffico. Inoltre, programmando le 

partenze delle fasi di prefetching in momenti differenti e temporalmente successivi tra i due 

livelli di caching, è possibile ridurre al minimo il ritardo necessario al reperimento delle 

informazioni. Così facendo, infatti, si elimina il ritardo normalmente necessario al 

prelevamento dell’informazione dall’origin server. 

Fig. 5-6 - Funzionamento delle varie istanze di SPD in una architettura base 

Nel secondo caso, invece, essendo i server di back-end completamente dedicati al 

mirroring dei siti Web, i demoni sono posizionati solamente sui server di front-end (Fig.5-7). 

Anche in questo caso, tuttavia, le fasi di prefetching sono temporalmente sfalsate e 

successive, al fine di consentire l’eliminazione del ritardo dovuto al prelevamento della 

informazioni dall’origin server. 

96


Fig. 5-7 - Funzionamento delle varie istanze di SPD in una architettura alternativa 

Per l’implementazione del demone SPD, come precedentemente accennato, è stato 

utilizzato il Python, linguaggio di programmazione ad alto livello [Pyt05a]. In questa sezione 

saranno evidenziati alcuni elementi tra i più significativi, che hanno caratterizzato la fase di 

implementazione dello stesso: 

• la configurazione tramite apposito file; 

• la gestione del logging e della notifica via mail; 

• il parsing dei log tramite espressioni regolari. 

5.2.2.1 File di configurazione 

Viste le differenti configurazioni in cui è possibile utilizzare il demone SPD (su tutte 

e due le istanze di Squid o solamente sul front-end), è stato scelto l’utilizzo di un apposito 

file di configurazione, in modo da adattare facilmente il programma ai diversi ambiti di 

applicazione. Tale file di configurazione, spd.cfg (Appendice D), è stato pensato risiedere 

nella directory dove si trovano normalmente i file di configurazione dei diversi applicativi in 

ambiente *nix, ovvero nella directory /etc. 

Questo file è stato diviso in tre sezioni: default, posta e smtp. La prima, fondamentale 

ai fini del corretto funzionamento del programma, contiene informazioni relative alla 

dimensione della cache dello Squid gestito da SPD e il percorso del file di log da analizzare 

per la creazione della lista di URL da prelevare in prefetching. Le altre due sezioni 

contengono, rispettivamente, le informazioni necessarie ad abilitare la notifica via mail del 

97


logging effettuato da SPD e le eventuali credenziali di accesso al server SMTP per l’invio 

della posta. 

Per la realizzazione della sezione di parsing del file di configurazione è stato 

utilizzato una apposito modulo del Python, ConfigParser [Pyt05d]. Questo modulo consente 

di dividere il file di configurazione in sezioni, rappresentate attraverso il nome della sezione 

racchiuso tra parentesi quadre (per esempio “[Posta]”), e di inserire delle coppie 

“nome=valore” oppure “nome:valore” per ogni sezione. Inoltre, consente anche la 

possibilità di inserire dei commenti all’interno di tale file, facendoli precedere dal carattere 

“#” o “;”. In Fig.5-8 è riportato un esempio di una sezione contenente valori e commenti. 

[DEFAULT] 

# Dimensione della cache di squid in MB 

dim_cache = 1000 

# Path assoluto del file di log da analizzare 

log_from = /usr/local/squid/var/logs/access.log.0 

Fig. 5-8 - Una sezione del file di configurazione spd.cfg 

Definita la struttura del file di configurazione, il modulo ConfigParser mette a 

disposizione una serie di funzioni per il parsing di tale file e il recupero, ad esempio, delle 

informazioni relative ad un dato valore in una sezione specifica, consentendo anche di 

specificare a priori la tipologia dell’informazione recuperata (numero intero o valore 

booleano). In Fig.5-9 è riportato un esempio di codice relativo al prelevamento delle 

informazioni contenute nella sezione DEFAULT del file di configurazione spd.cfg. 

# Utilizzo della sezione DEFAULT 

try: 

[…] 

dim_cache = config.getint('DEFAULT','dim_cache') 

# Controllo della sezione [Posta] 

try: 

[…] 

mail = config.getboolean('POSTA','mail') 

Fig. 5-9 - Parsing di valori del file spd.cfg 

98


5.2.2.2 Gestione del logging e notifica via mail 

Al fine di facilitare il monitoraggio del demone SPD, sono state implementate, 

attraverso l’ausilio dei moduli Python smtplib [Pyt05b] e logging [Pyt05e], il logging delle 

operazioni compiute dal demone durante il proprio funzionamento e l’eventuale invio della 

notifica sul proprio stato di funzionamento via mail all’amministratore del sistema (previa 

impostazione all’interno del file di configurazione). 

Innanzi tutto, è stato realizzato il logging del demone, salvando le informazioni 

necessarie all’interno di un apposito file (/root/spd.log). Il modulo logging mette a 

disposizione le funzioni e le classi necessarie a realizzare le funzionalità di logging, in 

particolare attraverso i metodi delle istanze della classe Logger. La notifica dei messaggi di 

errore viene invece affidata agli oggetti handler. Questi ultimi sono responsabili di notificare 

i messaggi di cui si prendono carico in diverse forme e modalità, a seconda della propria 

tipologia. Alcuni tra gli handler più significativi sono: 

• FileHandler: permette l’invio dei messaggi in un file sul disco; 

• DatagramHandler: consente l’invio dei messaggi attraverso un socket UDP; 

• SocketHandler: consente l’invio dei messaggi attraverso un socket TCP/IP; 

• HTTPHandler: permette l’invio dei messaggi ad un server HTTP, attraverso i 

metodi GET e POST dell’HTTP stesso. 

I messaggi di logging possono essere opportunamente formattati e sono associabili a 

diversi livelli di importanza. In questo modo è possibile impostare un handler affinché 

gestisca solamente messaggi con un determinato livello di importanza scelto o al massimo 

con un livello superiore. I livelli di importanza sono rispettivamente: DEBUG, INFO, 

WARNING, ERROR e CRITICAL. In Fig.5-10 è riportato un esempio di codice utilizzato 

per impostare il meccanismo di logging su un apposito file di testo. 

99


p = logging.getLogger('spd_log') 

p.setLevel(logging.INFO) 

try: 

except: 

hdlr = logging.FileHandler(log_to,'w') 

print 'Error: ', sys.exc_info()[0], sys.exc_info()[1] 

format = logging.Formatter('%(asctime)s: %(filename)s - 

%(levelname)s: %(message)s') 

hdlr.setFormatter(format) 

hdlr.setLevel(logging.INFO) 

p.addHandler(hdlr) 

p.info('\n------------------------------------------------------------ 

---------\nspd: avvio\n----------------------------------------------- 

----------------------\n') 

Fig. 5-10 - Inizializzazione del logging su file di testo per il demone SPD 

Successivamente alla creazione e alla gestione del logging del demone, è stata anche 

inserita la possibilità di notificare via mail all’amministratore di sistema lo stato di 

funzionamento del demone, riportando nella mail anche l’indirizzo al quale collegarsi per 

effettuare la registrazione e quindi per consultare tale file di logging. A tal proposito, si è 

fatto uso del modulo smtplib che consente la creazione e l’invio di email attraverso il 

protocollo SMTP. Questo modulo consente la creazione di oggetti sessione SMTP client 

attraverso i quali inviare email, permettendo anche, eventualmente, di effettuare una fase di 

autenticazione per l’invio della posta. Tre differenti tipologie di messaggi vengono creati in 

fase di avvio e sono quindi usati nel testo della mail a seconda della notifica che si vuole 

inviare. In Fig.5-11 è riportato il codice usato per inviare una mail in caso di un errore grave, 

tale da impedire il corretto funzionamento del demone SPD. 

100


# Apertura del file di log da analizzare 

try: 

except: 

fd = open(log_from,'r',) 

p.error(str(sys.exc_info()[0])+str(sys.exc_info()[1])) 

hdlr.close() 

if mail: 

server = smtplib.SMTP(smtp) 

if login: 

server.login(smtp_login,smtp_passwd) 

server.sendmail(from_addr, to_addr, msg3) 

server.quit() 

sys.exit(1) 

Fig. 5-11 - Codice per l'invio di una mail di notifica in caso di errore 

5.2.2.3 Espressioni regolari e parsing del log 

Il parsing del file di log di Squid è stato realizzato attraverso l’ausilio delle 

espressioni regolari, in particolare è stato usato il modulo Python re [Pyt05c]. Tale modulo 

consente di effettuare operazioni di matching di espressioni regolari tramite l’utilizzo della 

funzione “search(pattern, string)” che ricerca nella stringa il pattern definito nella chiamata. 

La definizione del pattern, ovvero dell’espressione regolare da utilizzare per il 

riconoscimento, è realizzata in Python facendo uso di combinazioni di caratteri. In 

particolare, il carattere più usato e importante in una espressione regolare è il carattere 

backslash (“\”). Quest’ultimo, opportunamente combinato con altri caratteri, consente di 

indicarne particolari significati o di utilizzare determinati caratteri, senza attribuire loro 

speciali significati che normalmente avrebbero. Per esempio: al fine di indicare all’interno di 

una espressione regolare lo stesso carattere di backslash, per effettuarne un matching, è 

necessario indicare un doppio backslash (“\\”), quindi, per poter trovare un doppio backslash 

normalmente usato nella identificazione di una URL è necessario usare la seguente scrittura 

“\\\\”. Di seguito sono riportati alcuni caratteri speciali, molto usati nella definizione delle 

espressioni regolari. 

101


• “.”: permette il matching di qualsiasi carattere tranne il carattere newline. 

• “^”: consente di effettuare il matching a partire dall’inizio di una riga. 

• “$”: permette il matching a partire dalla fine di una riga. 

• “*”: consente alla espressione regolare risultante di effettuare il matching di 

zero o più ripetizioni della espressione regolare che precede tale carattere. Per 

esempio ab* permette il matching di ‘a’, ‘ab’ o di ‘a’ seguito da un numero 

qualsiasi di ‘b’. 

• “+”: permette il matching di una o più ripetizioni della espressione regolare 

precedente. Per esempio: ab+, non effettua il matching della sola ‘a’, ma di 

‘a’ seguito da un numero di ‘b’ variabile, ma diverso da zero. 

• “[]”: consente di specificare un insieme di caratteri, sia individualmente sia 

come intervallo tra due caratteri separati da un “-“. I caratteri speciali non 

sono attivi all’interno dell’insieme. 

• “(…)”: consente il matching di qualsiasi espressione regolare dentro le 

parentesi e indica l’inizio e la fine di un gruppo. Il contenuto di un gruppo 

può essere recuperato dopo che il matching dello stesso è avvenuto con 

successo. 

• “\d”: permette il matching di qualsiasi numero decimale, è equivalente 

all’insieme [0-9]. 

• “\w”: consente di effettuare il matching di qualsiasi carattere alfanumerico, 

compreso il carattere underscore. E’ equivalente all’insieme [a-zA-Z0-9_]. 

Combinando opportunamente una serie dei caratteri sopra descritti, è stato possibile 

realizzare il matching del formato del file di logging di Squid e, attraverso l’utilizzo dei 

gruppi, è stato possibile anche reperire le informazioni necessarie alla creazione della lista di 

URL, ovvero la dimensione e l’URL stessa presente in ogni richiesta. In Fig.5-12 è presente 

il codice utilizzato per effettuare il matching delle richieste all’interno del file di log di Squid. 

102

for line in fd: 


# Espressione regolare per trovare solo le HIT ed estrarne l'url 

reg = re.search('_HIT/\d+ (\d+) \w+ (.*)( - )', line) 

if reg: 

url = reg.group(2) # Recupero la URL dalla regexp 

dim = reg.group(1) # Recupero la DIM dalla regexp 

Fig. 5-12 - Codice necessario al matching delle richieste nel file di log di Squid 

5.3 MMI (Mirroring Management Interface) 

L’interfaccia di management, MMI, consente di eseguire tutte le operazioni 

necessarie ad effettuare il mirroring di un determinato sito web, permettendo di scegliere il 

grado di profondità (fino ad un massimo di 3) e un tempo di refresh dei contenuti 

(selezionabile tra un elenco preimpostato). Gli utenti che possono accedere a tale interfaccia 

sono di due tipologie: 

• un utente admin, che ha la possibilità di eseguire operazioni di gestione di 

altri utenti e di siti (URL) su cui effettuare il mirroring per una determinata 

cache di secondo livello; 

• un utente user, il quale, non possedendo privilegi di amministratore, non può 

gestire altri utenti o URL, ma si limita a visualizzare informazioni relative ai 

siti mirror della propria cache e a consultarne i log. 

5.3.1 Funzionamento 

Le componenti fondamentali della MMI risiedono sulla cache di primo livello. Solo 

su quest’ultima è infatti possibile sia per gli admin, sia per gli user effettuare la procedura di 

login nel sistema, al fine di rendere la gestione degli utenti più controllabile e sicura. Alcuni 

componenti sono anche posizionati sui secondi livelli di cache, allo scopo di consentirne il 

monitoraggio. 

In particolare, nel caso dell’architettura di base, gli elementi costituenti la MMI sono 

stati posizionati sui proxy di front-end di entrambi i livelli di caching (Fig.5-13). Il motivo di 

tale disposizione è da ricercare proprio nelle caratteristiche dell’architettura utilizzata: 

103


dovendo infatti effettuare il mirroring di siti Web, è necessario che le richieste per tali siti 

vengano inoltrate direttamente al proxy di front-end di ogni livello, che, a sua volta, le 

instrada opportunamente a seconda della tipologia di traffico. Inoltre, utilizzando un sistema 

di caching a due livelli, si è deciso, in tale architettura, di avviare il download dei siti Web 

sul secondo livello con un ritardo di 15 minuti rispetto a quello sul primo livello, in modo da 

consentire ad L1 di recuperare preventivamente dalla rete quanto verrà richiesto in un 

secondo tempo da L2. 

Fig. 5-13 - Funzionamento della MMI nell’architettura base 

Nel caso dell’architettura alternativa (Fig.5-14), invece, il posizionamento degli 

elementi fondamentali della MMI interessa i proxy di back-end anziché quelli di front-end. 

La scelta è stata dettata, ancora una volta, dall’architettura utilizzata: in tal caso, infatti, 

essendo i proxy di back-end totalmente dedicati al mirroring di siti Web, le richieste per il 

mirroring vengono indirizzate direttamente ad essi. Discorso analogo all’architettura base, 

invece, per quanto riguarda lo sfasamento di 15 minuti tra l’inizio del download di siti Web 

sul primo livello e quello sul secondo livello del sistema di caching. 

104

fondamentali. 


Fig. 5-14 - Funzionamento MMI nell’architettura alternativa 

5.3.2 Implementazione 

La realizzazione della MMI è stata possibile grazie all’ausilio di alcune componenti 

• PHP [php05], un linguaggio di scripting open-source, utilizzato per la realizzazione 

di pagine web dinamiche, ovvero di pagine il cui contenuto viene generato nel 

momento in cui queste vengono richieste al server web. Esso opera lato server 

permettendo che il codice venga eseguito sul server prima che la pagina sia inviata al 

browser; inoltre, viene definito HTML-embedded, poiché inserito direttamente 

all’interno di pagine HTML. A differenza di altri linguaggi di programmazione, 

come ad esempio C++ e Java, il cui codice sorgente, per poter essere eseguito, deve 

prima essere compilato, il PHP è un linguaggio interpretato, ovvero tradotto ed 

eseguito istruzione per istruzione. Nello scenario della programmazione web, esso è 

tra i più utilizzati e apprezzati. 

• MySQL [mys05], database relazionale open-source che può essere utilizzato su 

qualsiasi piattaforma software, da Windows alla famiglia Unix e Unix-Like 

comprendendo in quest'ultima naturalmente anche Linux, FreeBSD e MacOsX. 

105


• Apache [apa05a], il server web più diffuso e apprezzato in ambito Internet, 

disponibile per diverse piattaforme: Aix, Darwin, Freebsd, Hpux, Linux, MacOsX, 

NetWare, Os2, Os390, Solaris, Windows, etc. E’ un prodotto altamente scalabile, 

poichè mediante la gestione di estensioni - chiamati moduli - è possibile arricchirne 

le funzionalità, integrandolo con svariati linguaggi di programmazione, come ad 

esempio PHP, Python, Perl, Ruby oppure con moduli dedicati a comunicazioni sicure 

(SSL). 

• Wget [gnu05], un’applicazione che consente di effettuare il download non interattivo 

di file Web, lavorando in background senza aver bisogno della presenza di un utente 

per svolgere la propria funzione. Esso può anche essere opportunamente impostato 

per scaricare un sito fino ad un livello di profondità scelto e proprio per questo è stato 

utilizzato nell’implementazione della MMI. Nel progetto in esame, per l’istruzione di 

wget, si è scelto di dare la possibilità di selezionare tra otto frequenze, (ogni 30 

minuti, ogni ora, ogni 2 ore, ogni 6 ore, ogni 12 ore, 1 volta al giorno, 1 volta alla 

settimana, 1 volta al mese), caratterizzate da orari di inizio sfasati tra loro in modo da 

minimizzare il numero di esecuzioni simultanee di cron-job. L’istruzione di wget, 

inoltre, risulta caratterizzata da una serie di parametri opzionali, tra i quali si è scelto 

di utilizzare: 

▪ “-l” per fissare il livello di profondità; 

▪ “-r” per abilitare il download ricorsivo; 

▪ “-p” per scaricare tutti i file necessari alla visualizzazione di una pagina; 

▪ “-P” per stabilire in quale cartella scaricare i siti Web; 

▪ “--delete-after” per cancellare i file dopo il download. 

5.3.2.1 Il database 

Il database, realizzato tramite MySQL, è stato strutturato, nell’architettura di base, 

secondo cinque tabelle: cache, siti, siti_cache, tipo_utenti, utenti. 

La tabella cache elenca le varie cache L2 o meglio i vari front-end di livello 2 

contraddistinti dal loro indirizzo IP. 

La tabella siti archivia le url dei siti Web di cui si vuole fare il mirroring, insieme con 

il corrispondente livello di profondità e frequenza di refresh. 

106


La tabella siti_cache è una tabella di collegamento che serve per gestire la relazione 

molti a molti tra le due tabelle precedenti. 

La tabella tipo_utenti definisce i vari profili utente ed è precaricata una tantum 

all’atto della creazione della tabella stessa. 

La tabella utenti elenca i vari utenti con relativa password, e-mail, profilo ed 

identificativo della cache associata nel caso di utente senza privilegi di amministratore. 

Le relazioni che legano tra loro tali tabelle sono rappresentate in Fig.5-15 e possono 

essere descritte come segue. 

• La tabella cache è in relazione “uno a uno” con la tabella utenti, poiché si è 

deciso di associare ad ogni utente un unico indirizzo IP, quello relativo alla 

propria cache, mentre è in relazione “molti a molti” con la tabella siti, poiché 

il mirror di un sito può essere richiesto su più cache e ogni cache può 

memorizzare più siti mirror. 

• La tabella tipo_utenti, invece, è in relazione “uno a molti” con la tabella 

utenti, in quanto è possibile inserire più utenti di tipo user. 

Fig. 5-15 - Relazioni tra le tabelle del database di MMI in configurazione base 

Nell’architettura alternativa (Fig.5-16), il database risulta sempre strutturato secondo 

le cinque tabelle. Alla tabella cache, però, viene aggiunto un nuovo campo, ip_be, che tiene 

107


conto dell’indirizzo IP della macchina di back-end di livello 2, necessario per le operazioni 

di inserimento, modifica e rimozione sul crontab corrispondente. Infatti, in tale architettura, 

è la macchina di back-end quella interessata al caching di siti mirror. 

Fig. 5-16 - Relazione tra le tabelle del database di MMI in configurazione alternativa 

5.3.2.2 Il software di gestione 

Il software di gestione MMI, sviluppato in PHP, consente, a mezzo di un’interfaccia 

di autenticazione (Fig.5-17), di accedere ad un’area amministratori, se si è registrati come 

utente con privilegi di amministratore o ad un’area utenti in caso contrario. 

108


Fig. 5-17 - Interfaccia di autenticazione 

Un amministratore può effettuare operazioni di inserimento, modifica e rimozione sia 

di utenti (di tipo admin o user) che di url di siti Web di cui si vuol fare il mirroring fino ad 

un livello di profondità selezionato. La modalità con cui vengono eseguite tali operazioni 

sarà descritta in maniera più dettagliata nei sottoparagrafi successivi. 

Un utente, invece, può consultare in qualsiasi momento i log relativi alle richieste 

ricevute e le url dei siti mirror, che vengono scaricati con una certa frequenza sulla propria 

cache. 

Per entrambe le tipologie di utente, l’accesso all’area loro consentita apre una 

sessione che termina mediante un’operazione di “log out”. Inoltre, opportuni controlli nel 

codice (Fig.5-18) impediscono ad utenti non autorizzati di accedere anch’essi a tali aree, 

rendendo la struttura più robusta in termini di sicurezza. 

109

function denied_access() { 

} 


session_start(); 

$user = $_SESSION['username']; 

# connessione al database 

include ("../connect.php"); 

$query = "SELECT * FROM utenti WHERE nome_utente = '$user'"; 

$result = mysql_query($query, $db); 

$row = mysql_fetch_array($result); 

# chiusura connessione 

include ("../close.php"); 

# se il login viene bypassato, viene negato l'accesso 

if ($user == NULL || $row['id_tipo_utente'] != 0) { 

session_destroy(); 

return true; 

} 

else { 

return false; 

} 

Fig. 5-18 - Codice per il controllo dei diritti di accesso 

L’implementazione della MMI è stata conseguita con poche differenze tra 

l’architettura di base e quella alternativa. Di seguito verranno descritti i componenti (Fig.5- 

19) costituenti la MMI, evidenziando di volta in volta le eventuali differenze sopra accennate. 

110


Fig. 5-19 - Diagramma di flusso del funzionamento di MMI 

111


5.3.2.2.1 Inserimento di un utente 

L’operazione di inserimento di un utente avviene mediante un’interfaccia grafica 

(Fig.5-20), dove tutti i campi sono stati imposti come obbligatori e pertanto controllati da un 

codice Javascript [jav05] che impedisce il processamento dei dati immessi quando uno o più 

di essi risultino incompleti o riempiti secondo un formato non corretto. 

Fig. 5-20 - Interfaccia di inserimento utente 

Nell’architettura alternativa è presente, però, un ulteriore campo (Fig.5.21) per 

l’eventuale inserimento dell’indirizzo IP del proxy di back-end da associare, insieme a 

quello di front-end, a un nuovo utente non amministratore. Il motivo di tale scelta, come 

precedentemente accennato, è dovuto alla necessità di effettuare operazioni di inserimento, 

modifica e rimozione sul crontab della macchina di back-end. 

112


Fig. 5-21 - Interfaccia di inserimento utente in configurazione alternativa 

La modalità con cui viene effettuata l’operazione di inserimento utente, comunque, è 

ben rappresentata dal diagramma di flusso di Fig.5-22. 

113


Fig. 5-22 - Diagramma di flusso dell'inserimento utente 

Al momento dell’inserimento, se l’utente risulta già presente nel database, viene 

proposto all’amministratore di modificarlo o di ripetere l’operazione di inserimento, 

altrimenti viene esaminato il tipo di utente che si vuole inserire. Se l’utente è di tipo 

amministratore, viene inserita una nuova riga all’interno della tabella utenti, altrimenti viene 

aggiunta una riga nella tabella cache e una ancora nella tabella utenti, dove viene riportato 

l’id della cache risultato dall’inserimento precedente; questo avviene perché all’utente di tipo 

non amministratore corrisponde univocamente l’indirizzo IP della cache associata, pertanto 

quest’ultimo passo viene eseguito solo se l’indirizzo IP immesso non risulta già presente nel 

database. In Fig.5-23 è riportato il codice che realizza i due casi appena descritti. 

114


$queryUtenti = "INSERT INTO utenti (id_utente, nome_utente, password, 

email, id_tipo_utente, id_cache) VALUES ('', '$username', '$password', 

'$email', '$tipo', '0')"; 

[…] 

$queryInsertCache = "INSERT INTO cache (id_cache, ip_cache) VALUES 

( '', '$ip')"; 

$queryUtenti = "INSERT INTO utenti ( id_utente, nome_utente, password, 

email, id_tipo_utente, id_cache) VALUES ('','$username', '$password', 

'$email', '$tipo', '$idCache')"; 

Fig. 5-23 - Codice relativo all'inserimento utenti 

L’esito delle operazioni effettuate in questa sezione, come in quelle che seguono, 

viene sempre stampato a video, sia esso positivo o negativo, consentendo, quindi, di 

effettuare una nuova operazione. 

5.3.2.2.2 Modifica di un utente 

Con l’operazione di modifica di un utente si è tenuto conto dell’eventualità in cui si 

possa inserire una tipologia di utente errata. Dal menù “modifica utente” si accede ad una 

pagina dove si può scegliere se ricercare l’utente da modificare o visualizzare tutti gli utenti 

presenti nel database (Fig.5-24) per poi caricare i dati relativi a quello selezionato. 

115

Fig.5-25. 


Fig. 5-24 - Interfaccia di modifica utente 

Possono verificarsi quattro casi di utilizzo, rappresentati nel diagramma di flusso di 

116


Fig. 5-25 - Diagramma di flusso della modifica utenti 

Un primo caso che si può presentare, una volta confermati i cambiamenti apportati, è 

quello in cui si modifica un tipo amministratore in un tipo utente. In tal caso viene inserita 

una nuova riga nella tabella cache, dopodiché viene aggiornata la corrispondente riga della 

tabella utenti, riportando il nuovo indirizzo IP immesso, purché esso non risulti già inserito 

nel database (Fig.5-26). 


('', '$ip')"; 

[…] 

$queryUpdate = "UPDATE utenti SET nome_utente='$username', 

password='$password', email='$email', id_tipo_utente='$tipo', 

id_cache='$idCache' WHERE id_utente = '$id_utente'"; 

Fig. 5-26 - Codice per la modifica di un amministratore in un utente 

Un secondo caso è la modifica di un amministratore che comporta semplicemente 

l’aggiornamento di un’opportuna riga della tabella utenti (Fig.5-27). 

117




id_cache='0' WHERE id_utente = '$id_utente'"; 

Fig. 5-27 - Codice per la modifica di un amministratore 

Un terzo caso si può avere quando si modifica un tipo utente in un tipo 

amministratore. In tale circostanza, l’indirizzo IP associato alla cache dell’utente non è più 

necessario, quindi viene rimossa la corrispondente riga dalla tabella cache e viene aggiornata 

la riga interessata sulla tabella utenti. In Fig.5-28 è riportato il codice relativo a tale caso. 

$queryDeleteCache = "DELETE FROM cache WHERE ip_cache='$ipCache'"; 

[…] 



id_cache='0' WHERE id_utente = '$id_utente'"; 

Fig. 5-28 - Codice per la modifica di un utente in amministratore 

Quarto ed ultimo caso riguarda la modifica di un utente di tipo non amministratore. 

Qui si controlla se l’indirizzo IP della cache associata all’utente è stato modificato. Se è 

rimasto invariato, si aggiorna semplicemente la riga interessata sulla tabella utenti, altrimenti, 

purché il nuovo indirizzo IP non risulti già inserito nel database, viene rimossa dalla tabella 

cache la riga relativa a tale indirizzo prima della modifica, ne viene inserita una nuova, 

corrispondente al nuovo indirizzo IP e viene aggiornata la corrispondente riga della tabella 

utenti, che tiene conto anche del nuovo indirizzo immesso (Fig.5-29). 


password='$password', email='$email', id_tipo_utente='$tipo' WHERE 

id_utente = '$id_utente'"; 

[…] 

$queryDeleteCache = "DELETE FROM cache WHERE ip_cache='$ipCache'"; 

[…] 


('', '$ip')"; 

[…] 



id_cache='$idCache' WHERE id_utente = '$id_utente'"; 

Fig. 5-29 - Codice per la modifica di un utente 

118


5.3.2.2.3 Rimozione di un utente 

Analogamente alla modifica, dal menù “rimozione utente” si accede ad una pagina 

dove si può scegliere se ricercare l’utente da eliminare o visualizzare tutti gli utenti presenti 

nel database per selezionare quello che si vuole rimuovere. 

L’operazione di cancellazione di un utente è stata implementata in modo da impedire, 

mediante un opportuno controllo, la rimozione di un amministratore nel caso in cui fosse 

l’unico presente nel database con tali privilegi. 

Qualora fosse consentita, però, la rimozione di un amministratore, essa si 

risolverebbe nella cancellazione dalla tabella utenti di un’opportuna riga, come mostra il 

codice in Fig.5-30. 

$queryDeleteUtenti = "DELETE FROM utenti WHERE id_utente='$idUtente'"; 

Fig. 5-30 - Codice per la rimozione di un amministratore 

La richiesta di cancellazione di un utente, invece, si risolverebbe in maniera analoga, 

eliminando però anche una riga dalla tabella cache, quella che tiene memoria dell’indirizzo 

IP della cache associata (Fig.5-31). 

$queryDeleteUtenti = "DELETE FROM utenti WHERE id_utente='$idUtente'"; 

[…] 

$queryDeleteCache = "DELETE FROM cache WHERE ip_cache='$ip'"; 

Fig. 5-31 - Codice per la rimozione di un utente 

5.3.2.2.4 Inserimento di un sito mirror 

L’inserimento di un sito mirror ha senso quando la url immessa non risulta già 

associata all’indirizzo IP digitato (in tal caso verrebbe proposto all’amministratore di 

apportare modifiche o di riprovare l’operazione di inserimento) e quando l’indirizzo IP 

immesso è presente nel database. 

L’operazione di inserimento avviene tramite un’interfaccia mostrata in Fig.5-32. 

119


Fig. 5-32 - Interfaccia per l'inserimento di un sito mirror 

Anche in questa circostanza, c’è da puntualizzare la differenza con l’architettura 

alternativa per la presenza del campo relativo all’indirizzo IP della macchina di back-end di 

livello 2 (Fig.5.33). 

120


Fig. 5-33 - Interfaccia per l'inserimento di un sito mirror in configurazione alternativa 

L’operazione di inserimento è descritta dal diagramma di flusso in Fig.5-34. 

L’inserimento è stato implementato in modo che una stessa URL venga inserita più 

volte nella tabella siti, con id diversi ed altrettanti conseguenti inserimenti nella tabella di 

collegamento siti_cache, purchè la coppia livello di profondità / frequenza di refresh ad essa 

associata risulti ogni volta diversa. 

121


Fig. 5-34 - Diagramma di flusso dell'inserimento di un sito mirror 

Nel caso di inserimento di una URL già esistente nel database, il livello di profondità 

e la frequenza di refresh vengono aggiornati nel crontab L1 secondo il livello di profondità 

maggiore e la frequenza di refresh più elevata associate a tale URL e rilevate nel database. 

122


Nel crontab L2, invece, i valori inseriti sono pari a quelli immessi, con frequenza di refresh, 

però, impostata con un ritardo di 15 minuti rispetto a quella digitata. 

Nel caso di inserimento di una URL non presente nel database, si procede 

all’inserimento di una nuova riga nella tabella siti, una nella tabella di collegamento 

siti_cache e una nelle tabelle del cron L1 ed L2, con valori di profondità e refresh pari a 

quelli immessi (Fig.5-35). 

$queryInsert= “INSERT INTO siti (id_sito, url, profondita, refresh) 

VALUES (‘’, ‘$url’, ‘$level’ ,’$refresh’)”; 

[…] 

$queryInsertSitiCache = “INSERT INTO siti_cache (id_sito, id_cache) 

VALUES (‘$idSito’, ‘$idCache’)”; 

[…] 

$fp=fopen(“../../../../../../etc/crontab”,”a+”); // path da 

personalizzare!!! 

Fputs($fp,$refresh . “ root /usr/bin/wget –r –l “ . $level . “ –p –P 

/home/destinazione “ . $url . “\n”); 

fclose($fp); 

Fig. 5-35 - Codice per l'inserimento di una URL non presente nel database 

In entrambi i casi, per l’architettura alternativa, segue un’operazione di 

aggiornamento del file di configurazione di Squid sul front-end di livello 2, 

/usr/local/squid/etc/squid.conf, mediante l’inserimento di opportune ACL che consentono di 

inoltrare le richieste di mirroring sulla macchina di back-end (Fig.5-36). 

$name = substr($site, 8, 10); 

$aclname = str_shuffle($name); 

# inserimento nel file squid.conf del Front-End L2 

$fp=fopen("../../../../usr/local/squid/etc/squid.conf","a+"); 

fputs($fp,"acl " . $aclname . " url_regex -i ^" . $site . "\n"); 

fputs($fp,"cache_peer_access " . $ipBe . " allow\n"); 

fputs($fp,"never_direct allow " . $aclname . "\n"); 

fclose($fp); 

Fig. 5-36 - Codice per l'inserimento delle ACL in squid.conf nel caso di architettura alternativa 

5.3.2.2.5 Modifica sito mirror 

L’operazione di modifica di un sito mirror è stata implementata in modo da poter 

modificare solo i campi relativi alla profondità e al refresh. Come si intuisce dal diagramma 

di flusso di Fig.5-37, in tale sezione si tiene conto dei quattro casi che si possono presentare. 

123


Fig. 5-37 - Diagramma di flusso della modifica di un sito mirror 

Il primo è relativo al caso in cui la URL prima della modifica risulti associata a più di 

un indirizzo IP e le modifiche apportate vengano a coincidere con quelle associate ad 

un’altra identica URL presente nel database. Tale caso comporta l’aggiornamento dell’id 

della URL all’interno di un’opportuna riga della tabella siti_cache e l’aggiornamento del 

crontab L1 ed L2 sulla base dei valori modificati di profondità e/o refresh, come evidenziato 

dal codice in Fig.5-38. 

124


$queryUpdateSitiCache = "UPDATE siti_cache SET id_sito='$idUrl' WHERE 

id_cache='$idCache' AND id_sito='$idSito'"; 

………………………… 

$array = file ("../../../../../../etc/crontab"); 

$lenght = count($array); 

$i=0; 

$found = false; 

while (($i < $lenght) && ($found == false)) { 

if (substr_count($array[$i], $RefreshBeforeUpdateString . " root 

/usr/bin/wget -r -l " . $LevelBeforeUpdate . " -p -P /home/toni " . 

$url) > 0) { 

$array[$i]=$newRefreshString . " root /usr/bin/wget -r -l 

" . $newLevel . " -p -P /home/toni " . $url . "\n"; 

$found = true; 

} 

$i++; 

} 

$fp=fopen("../../../../../../etc/crontab","w+"); // path da 


$j=0; 

while ($j < $lenght) { 

fputs($fp, $array[$j]); 

fclose($fp); 

$fp=fopen("../../../../../../etc/crontab","a+"); // path da 


$j++; 

} 

fclose($fp); 

Fig. 5-38 - Codice per la modifica di una URL associata a più L2 con campi identici 

Il secondo riguarda il caso in cui la URL prima della modifica non risulti associata ad 

alcun indirizzo IP e le modifiche apportate vengano a coincidere con quelle associate ad 

un’altra identica URL presente nel database. Questa situazione comporta ancora 

l’aggiornamento del campo id_sito di un’opportuna riga della tabella siti_cache, insieme con 

l’aggiornamento del crontab L1 ed L2; in più, è necessaria la rimozione dalla tabella siti 

della riga relativa alle vecchie impostazioni della URL (Fig.5-39). 

$queryDeleteSiti = "DELETE FROM siti WHERE id_sito='$idSito'"; 

Fig. 5-39 - Codice per la modifica di una URL con una unica associazione, ma associazioni multiple a 

seguito della modifica 

Il terzo caso tiene conto invece del fatto che la URL prima della modifica risulti 

associata a più di un indirizzo IP e che non sia presente alcun altra identica URL con i campi 

così modificati. Una tale situazione comporta l’inserimento di una nuova riga nella tabella 

siti relativa all’URL con profondità e/o refresh modificati, l’aggiornamento della 

125


corrispondente riga sulla tabella siti_cache con il nuovo id_sito e l’aggiornamento del 

crontab L1 ed L2 (Fig.5-40). 

$queryInsert= "INSERT INTO siti (id_sito, url, profondita, refresh) 

VALUES ('', '$url', '$level' ,'$refreshTime')"; 

………………………… 

$queryUpdateSitiCache = "UPDATE siti_cache SET id_sito='$newIdSito' 

WHERE id_cache='$idCache' AND id_sito='$idSito'"; 

Fig. 5-40 - Codice per la modifica di una URL associata a più L2 con campi diversi 

Il quarto ed ultimo caso, in cui la URL prima della modifica non risulti associata ad 

alcun indirizzo IP e non sia presente nessun’altra identica URL con i campi così modificati, 

comporta semplicemente l’aggiornamento di un’opportuna riga della tabella siti con i valori 

modificati di profondità e/o refresh e l’aggiornamento del crontab L1 ed L2 sulla base di tali 

valori, come mostrato dal codice in Fig.5-41. 

$queryUpdate = "UPDATE siti SET profondita='$level', 

refresh='$refreshTime' WHERE url='$url' AND profondita='$oldLevel' AND 

refresh='$oldRefresh'"; 

Fig.5-42. 

Fig. 5-41 - Codice per la modifica di una URL con una unica associazione 

5.3.2.2.6 Rimozione di un sito mirror 

L’operazione di rimozione di un sito mirror è descritta dal diagramma di flusso in 

126


Fig. 5-42 - Diagramma di flusso della rimozione di un sito mirror 

Essa comporta la sola cancellazione di un’opportuna riga dalla tabella siti_cache se 

ci sono altri indirizzi IP associati alla URL selezionata, altrimenti viene rimossa anche la riga 

della tabella siti relativa alla URL in questione (Fig.5-43). 

127


$queryDeleteSitiCache = "DELETE FROM siti_cache WHERE 

id_cache='$idCache' AND id_sito='$idSito'"; 

………………………… 

$queryDeleteSiti = "DELETE FROM siti WHERE id_sito='$idSito'"; 

Fig. 5-43 - Codice per la rimozione di un sito in mirroring 

A questo punto, se nel database esistono altre URL uguali a quella rimossa, viene 

aggiornato il crontab L1 e viene rimossa la riga corrispondente alla URL eliminata nel 

crontab L2, altrimenti viene rimossa la riga corrispondente alla URL cancellata in entrambi i 

crontab L1 ed L2 (Fig.5-44). 

# rimozione dal crontab 

$array = file ("../../../../../../etc/crontab"); 


$i=0; 



if (substr_count($array[$i], $refreshTime . " root /usr/bin/wget 

-r -l " . $level . " -p -P /home/toni " . $url . "\n") > 0) { 


} 

$i++; 

} 

$fp=fopen("../../../../../../etc/crontab","w+"); // path da 


$j=0; 


if ($j != $i-1) { 


fclose($fp); 

$fp=fopen("../../../../../../etc/crontab","a+"); // path 

da personalizzare!!! 

} 

$j++; 

} 

fclose($fp); 

Fig. 5-44 - Codice per la rimozione delle operazioni nel crontab 

Anche in tale circostanza, per l’architettura alternativa, segue un’operazione sul file 

di configurazione di Squid del front-end L2. In questo caso però si tratta di una rimozione 

delle opportune righe inserite per inoltrare le richieste di mirroring sul proxy di back-end 

(Fig.5-45). 

128


$array = file ("../../../../usr/local/squid/etc/squid.conf"); 


$i=0; 



if (substr_count($array[$i], "url_regex -i ^" . $site) > 0) { 


} 

$i++; 

} 

$fp=fopen("../../../../usr/local/squid/etc/squid.conf","w+"); // path 

da personalizzare!!! 

$j=0; 


if ($j != $i-1 && $j != $i && $j != $i+1) { 


fclose($fp); 

$fp=fopen("../../../../usr/local/squid/etc/squid.conf","a+"); // 

path da personalizzare!!! 

} 

$j++; 

} 

fclose($fp); 

Fig. 5-45 - Codice per la rimozione di un sito in mirroring nel caso di configurazione alternativa 

129

6 Testing e analisi dei risultati 

6. Testing e analisi dei risultati 

Completate le fasi di progettazione e implementazione, si è proceduto con una serie 

di test, con lo scopo di validare l’architettura progettata. Tali test sono stati condotti 

attraverso alcuni strumenti atti a simulare sia il comportamento di un insieme di utenti, sia le 

caratteristiche tipiche di una connessione satellitare. Nel corso del capitolo sarà innanzitutto 

presentata l’architettura di testing (6.1), comprensiva degli strumenti di testing utilizzati, 

quali il log_player e l’emulatore di rete netem, quindi verranno mostrati (6.2) i risultati 

ottenuti durante le simulazioni e la relativa analisi (6.3). 

6.1 Architettura di testing 

Lo scopo del testing effettuato era quello di validare il funzionamento 

dell’architettura e in particolare l’efficacia del demone SPD, elemento ritenuto fondamentale 

nell’architettura progettata. A tal fine sono state utilizzate due macchine così assemblate: 

- PC1 

- PC2 

• Processore AMD AthlonXP 2400+; 

• Sistema Operativo Linux (distribuzione Gentoo); 

• Kernel 2.6.10-r7; 

• 512MB di RAM; 

• 160GB di HD; 

• NIC 3COM 100Mbit/sec; 

• NIC NVIDIA 1Gbit/sec. 

• Processore Intel Pentium M 1.5GHz; 

• Sistema Operativo Linux (distribuzione Gentoo); 

• Kernel 2.6.11-r11; 

• 512MB di RAM; 

• 40GB di HD 

• NIC Bradcomm 1Gbit/sec. 

130


Le due macchine sono state collegate tra loro tramite un cavo incrociato, utilizzando 

le schede di rete con velocità di connessione pari ad 1Gbit/sec, in modo da creare un 

collegamento veloce ed a bassa latenza. Inoltre, il PC1 è stato collegato ad Internet per 

mezzo di una connessione asimmetrica di tipo ADSL da 2Mbit/sec in download e da 

512Kbit/sec in upload. 

Al fine di rendere la fase di testing significativa, è stata riposta particolare attenzione 

nel rendere l’ambiente di esecuzione quanto più possibile riproducibile e 

contemporaneamente vicino ad un reale caso di utilizzo. Proprio in tale ottica, è stata pensata 

l’implementazione di un testing di tipo trace driven e l’utilizzo del log_player e del netem, 

che verrano descritti nelle sezioni successive. 

Come mostrato in Fig.6-1, l’architettura utilizzata per i test prevede il collegamento 

delle due macchine tra loro tramite cavo incrociato (in una rete di indirizzi privati di classe C, 

192.168.0.1/24), mentre il collegamento del PC1 ad Internet avviene passando attraverso un 

HAG (Home Access Gateway) tramite un cavo di rete su connessione Ethernet a 10Mbit. 

L’HAG, a sua volta, è collegato ad Internet tramite una connessione a 2 Mbit/sec, come 

precedentemente accennato. In tale configurazione, il PC2 è stato utilizzato per generare il 

traffico attraverso l’ausilio dei web log e del programma log_player, mentre sul PC1 sono 

stati installati e opportunamente settati una istanza di Squid e di SPD, al fine, rispettivamente, 

di soddisfare le richieste e di attuare il meccanismo di prefetching. 

Fig. 6-1 - Architettura di testing 

131

6.1.1 IRCache e Web log 


Uno dei problemi riscontrati nella fase di testing è stato quello di decidere come 

rendere il test il più possibile riproducibile e contemporaneamente vicino alla realtà. Per 

questo motivo si è pensato di realizzare un testing di tipo trace driven, utilizzando dei Web 

log di proxy operanti. Vista la difficoltà di reperire dei web log significativi e soprattutto 

attuali (in rete si trovano numerosi web log, datati però dal 1996 al 1998 circa), si è deciso di 

fare ricorso al progetto IRCache [Irc05]. Questo progetto, iniziato nel 1995 dal NLANR 

(National Laboratory for Applied Network Research) e dalla UCSD (University of 

California, San Diego) e dalla NSF (National Science Foundation), raccoglie i log di circa 

dieci proxy localizzati negli Stati Uniti, con lo scopo di favorire lo sviluppo di Squid e 

fornire dati per ricercatori universitari e altre organizzazioni. Questi log vengono raccolti e 

catalogati giorno per giorno, con un ritardo massimo di 24 ore, per ognuno dei dieci proxy, 

per una durata massima di una settimana. Ogni settimana, quindi, l’insieme dei log viene 

sostituito con quello della settimana successiva. In questo modo, tramite un account presso 

la IRCache, è stato possibile prelevare dei log attuali (dall’1 al 4 Giugno 2005) di circa 

quattro giorni di utilizzo di un proxy situato a Boulder, California. Questi log contenevano 

un totale di oltre 600 mila richieste, con una media di circa 170 mila richieste giornaliere. 

Purtroppo il progetto IRCache non specifica la tipologia di proxy (regionale, locale o 

dipartimentale) a cui appartenevano tali log e, come verrà meglio evidenziato in seguito, tale 

elemento ha influenzato i risultati dei test, in quanto la conoscenza della posizione del proxy 

costituisce un fattore importante per meglio analizzarne le prestazioni. 

6.1.2 Log_stripper, log_player e log_cleaner 

Durante tutta la fase di testing sono stati utilizzati una serie di tool appositamente 

creati, tramite il linguaggio di alto livello Python, necessari ad eseguire alcune funzioni 

importanti per il testing stesso: log_player, log_stripper e log_cleaner. 

Il primo, log_player.py, si è reso necessario vista l’assenza di un vero e proprio 

“player” di web log adatto allo scopo. Questo programma si occupa di effettuare il parsing 

dei log che gli vengono forniti, raccogliendo, per ogni richiesta, il metodo HTTP, la URL e il 

tempo di interarrivo rispetto alla richiesta precedente. Dal parsing del log, esso crea una lista 

132


che utilizza per effettuare le stesse identiche chiamate fatte dagli utenti, rispettandone i tempi 

di interarrivo. Data l’eventualità di più richieste concorrenti o comunque in rapidissima 

sequenza, log_player è stato implementato con un processo principale che si occupa del 

parsing dei log e della creazione della lista delle richieste effettuate. Quindi, le richieste vere 

e proprie vengono generate da processi multithreading, in modo da consentire eventualmente 

la presenza di più chiamate concorrenti. Ogni thread riceve dal processo principale il metodo 

HTTP e la URL da richiedere e si occupa quindi di creare la connessione con il proxy al fine 

di completare tale compito. Rimane poi in attesa della risposta prima di chiudere la 

connessione e morire, in modo da simulare il corretto comportamento di un normale utente. 

Così facendo, infatti, impedisce che Squid, a causa della chiusura prematura della 

connessione (come sarebbe successo nel caso di richiesta e successiva morte del thread senza 

attesa di risposta), arresti il processo di prelevamento del file dall’origin server, non 

consentendone una successiva memorizzazione in cache. Non è stato posto un limite al 

numero dei thread utilizzabili dal processo principale, dal momento che la risoluzione di una 

rrichiesta HTTP avviene notoriamente in un tempo molto breve, tale da non provocare un 

pericolo di saturazione delle risorse disponibili. Analogamente, non sono state utilizzate 

connessioni persistenti, poiché l’utilizzo previsto per log_player era ristretto al campo del 

testing in oggetto, dove era previsto l’impiego di una connessione diretta e molto veloce 

(Gigabit Ethernet) tra la macchina su cui era in esecuzione tale tool e quella su cui era in 

esecuzione il proxy. 

Il secondo tool, log_stripper.py, è stato creato per risolvere il problema del notevole 

overhead computazionale derivante dalla fase di analisi dei log da parte del programma 

log_player, viste le grandi dimensioni dei log stessi (circa 25MB per ogni file di log). Il 

compito di log_stripper è quello di raccogliere i log da analizzare e di effettuarne un parsing 

al fine di creare un unico file di log, scritto in formato CSV e opportunamente “ripulito” da 

tutte le informazioni non necessarie. Il file così creato (valori.txt) contiene, per ogni riga, il 

metodo del protocollo HTTP utilizzato, la URL richiesta e il tempo trascorso rispetto alla 

richiesta precedente. In tal modo, questo file risulta di più facile gestione per il player dei 

log, passando da una dimensione di 90MB ad una di circa 8MB. 

Il terzo e ultimo tool, log_stripper.py, è stato implementato con lo scopo di ripulire i 

log, generati a seguito del testing, dalle chiamate prodotte dal demone SPD. Il problema era 

133


riscontrabile nell’utilizzo del tool di analisi dei log Calamaris e portava ad avere dei risultati 

non corretti. Infatti, all’interno dei log creati dall’istanza di Squid utilizzata per il testing, 

venivano a trovarsi anche le richieste effettuate dal demone SPD durante la fase di 

prefetching. E tra queste richieste era possibile anche avere delle hit in cache. Di 

conseguenza, i risultati dell’analisi statistica condotta con Calamaris, in particolare la 

percentuale di hit riscontrata nel proxy, sarebbe stata alterata dalla presenza di hit prodotte 

dal demone SPD e non dagli utenti simulati. Per eliminare tale problema, log_stripper è stato 

utilizzato per “ripulire” i file di log prodotti nel testing da tutte le chiamate prodotte dal 

demone SPD. 

6.1.3 Netem 

Il solo utilizzo di un Web log e dei tool appena descritti, tuttavia, non era sufficiente 

a rendere il testing quanto più possibile vicino alla realtà di una connessione satellitare. Per 

tale motivo è stato utilizzato l’emulatore di rete Netem (Network Emulator) [Net05]. 

Netem è una disciplina di accodamento che funziona sotto sistema operativo Linux 

ed è basata su NISTnet [Nis05], un emulatore di rete scritto dal NIST (National Institute of 

Science and Technology). NISTnet, così come Netem, consente di emulare il 

comportamento di una rete WAN, utilizzando una macchina con sistema operativo Linux 

come router, sul quale far transitare il traffico che si vuole “manipolare”. Le differenze 

sostanziali tra i due sono da ricercare nel fatto che, mentre NISTnet è un tool completo, che 

fornisce quindi numerose funzionalità e gira solo su kernel della serie 2.4 (lo sviluppo di 

NISTnet è stato infatti sospeso), Netem, invece, è un tool che fornisce solo una serie di 

funzionalità mirate e può girare indifferentemente sia su kernel della serie 2.4 sia su quelli 

della serie 2.6. 

Le funzionalità messe a disposizione da Netem sono, relativamente alla gestione del 

traffico, le seguenti: 

• ritardo costante; 

• ritardo variabile; 

• scelta della distribuzione dei tempi di ritardo; 

• perdita di pacchetti; 

134

• duplicazione dei pacchetti; 

• riordinamento dei pacchetti. 


Per utilizzare Netem è stato necessario ricompilare il kernel della macchina PC1 

(Kernel 2.6.10) e installare il pacchetto iproute2 [Ipr05], contenente una serie di tool per 

gestire in maniera avanzata il routing del traffico di rete sotto Linux. Quindi, prima di far 

partire ogni test, è stato impostato un ritardo costante sulla interfaccia di rete del PC1 

collegata ad Internet pari a 500msec, allo scopo di simulare il ritardo normalmente 

riscontrabile in un canale satellitare. In Fig.6-2 è riportato il comando utilizzato per 

impostare tale ritardo. 

# tc qdisc add dev eth0 root netem delay 500ms 

Fig. 6-2 - Comando per impostare un ritardo fisso di 500msec con Netem 

6.2 Test e risultati 

Al fine di valutare l’architettura implementata, sono state condotte due serie di test, 

dipendenti dalle dimensioni scelte per la cache di Squid, rispettivamente posta pari a 4GB e 

300MB. Quindi, per ognuna delle due serie, i test sono stati condotti in una doppia modalità, 

che prevedeva o meno l’utilizzo del demone SPD. In questo modo, la durata complessiva dei 

test è stata pari a 16 giorni. 

Di seguito vengono riportati i risultati ottenuti dall’analisi dei log, prodotti durante i 

test, condotta tramite il tool Calamaris, divisi in due serie in base alla dimensione della cache, 

4GB o 300MB. 

6.2.1 Dimensione della cache pari a 4GB 

I risutati sono ordinati in modo da presentare prima i valori ottenuti dal solo utilizzo 

di Squid (Fig.6-3 e Tab.6-1) e poi quelli ottenuti dall’utilizzo di Squid e del demone SPD 

insieme (Fig.6-4 e Tab.6-2). 

135

6.2.1.1 Risultati solo Squid 


Fig. 6-3 - Valori di HIT, MISS ed ERROR per cache a 4GB senza SPD 

status request % sec/req Byte % kB/sec 

HIT 159259 23.62 0.12 665199K 50.26 34.15 

TCP_HIT 79312 11.76 0.00 535306K 40.45 2378.46 

TCP_MEM_HIT 61482 9.12 0.00 97420480 7.19 13055.56 

TCP_REFRESH_HIT 12536 1.86 1.54 31297342 2.31 1.59 

TCP_NEGATIVE_HIT 5929 0.88 0.00 4292538 0.32 6718.92 

MISS 503858 74.73 1.83 641534K 48.48 0.70 

TCP_MISS 501442 74.37 1.83 638064K 48.21 0.70 

TCP_REFRESH_MISS 2416 0.36 1.83 3553340 0.26 0.79 

ERROR 11151 1.65 62.75 17051078 1.26 0.02 

TCP_DENIED 6195 0.92 0.00 9838880 0.73 12664.14 

TCP_MISS 4956 0.74 141.18 7212198 0.53 0.01 

Sum 674268 100.00 2.43 1323384K 100.00 0.81 

Tab. 6-1 - Valori di HIT, MISS ed ERROR per cache a 4GB senza SPD 

136

6.2.1.2 Risultati Squid e SPD 


Fig. 6-4 - Valori di HIT, MISS ed ERROR per cache a 4GB con SPD 


HIT 159379 23.64 0.15 686106K 50.31 28.23 

TCP_HIT 79045 11.72 0.00 543933K 39.88 1508.60 

TCP_MEM_HIT 62467 9.26 0.00 100864K 7.40 1062.66 



MISS 501811 74.42 1.70 658292K 48.27 0.77 

TCP_MISS 499515 74.08 1.70 654922K 48.02 0.77 


ERROR 13078 1.94 74.91 19871571 1.42 0.02 

TCP_MISS 6883 1.02 142.33 10032689 0.72 0.01 

TCP_DENIED 6195 0.92 0.00 9838882 0.70 852.01 

Sum 674268 100.00 2.76 1363804K 100.00 0.73 

Tab. 6-2 - Valori di HIT, MISS ed ERROR per cache a 4GB con SPD 

137

6.2.2 Dimensione della cache pari a 300MB 


Anche in questo caso i risutati sono ordinati in modo da presentare prima i valori 

ottenuti dal solo utilizzo di Squid (Fig.6-5 e Tab.6-3) e poi quelli ottenuti dall’utilizzo di 

Squid e del demone SPD insieme (Fig.6-6 e Tab.6-4). 

6.2.2.1 Risultati solo Squid 

Fig. 6-5 - Valori di HIT, MISS ed ERROR per cache a 300MB senza SPD 


HIT 144645 21.45 0.09 625245K 48.10 47.84 

TCP_MEM_HIT 72725 10.79 0.00 115988K 8.92 14324.11 

TCP_HIT 56953 8.45 0.00 481621K 37.05 5783.40 



MISS 516920 76.66 1.69 655852K 50.45 0.75 

TCP_MISS 515205 76.41 1.69 653333K 50.26 0.75 


ERROR 12703 1.88 71.52 19334250 1.45 0.02 

TCP_MISS 6508 0.97 139.61 9495370 0.71 0.01 

TCP_DENIED 6195 0.92 0.00 9838880 0.74 13912.95 

Sum 674268 100.00 2.66 1299978K 100.00 0.72 

Tab. 6-3 - Valori di HIT, MISS ed ERROR per cache a 300MB senza SPD 

138

6.2.2.2 Risultati Squid e SPD 


Fig. 6-6 - Valori di HIT, MISS ed ERROR per cache a 300MB con SPD 


HIT 148146 21.97 0.10 680767K 49.67 44.38 

TCP_MEM_HIT 71684 10.63 0.00 121682K 8.88 1157.08 

TCP_HIT 61256 9.08 0.00 524123K 38.24 3128.05 



MISS 512658 76.03 1.85 669959K 48.88 0.71 

TCP_MISS 510926 75.77 1.85 667338K 48.69 0.71 


ERROR 13464 2.00 74.04 20408795 1.45 0.02 

TCP_MISS 7269 1.08 137.14 10569913 0.75 0.01 

TCP_DENIED 6195 0.92 0.00 9838882 0.70 946.20 

Sum 674268 100.00 2.91 1370656K 100.00 0.70 

Tab. 6-4 - Valori di HIT, MISS ed ERROR per cache a 300MB con SPD 

139

6.3 Analisi dei risultati 


Prima di analizzare i risultati raccolti durante la fase di testing è doveroso fare una 

premessa: il contesto del Web caching ha ormai raggiunto un buon grado di maturità, lo 

testimoniano i numerosi studi condotti sull’argomento nonché realtà quali quella di Squid, 

ormai sul mercato da più di 10 anni. A tal proposito, visto il già buon grado di maturità e 

ottimizzazione che prodotti come Squid hanno raggiunto, i margini di guadagno che si 

possono ottenere in tale campo sono davvero ristretti. Inoltre, la percentuale di risorse non 

memorizzabili in cache (sia perché generate dinamicamente e non rispondenti ai principi di 

località, sia per esplicita indicazione del gestore del sito) è in continuo aumento. Per dare una 

idea delle dimensioni di quanto appena accennato, i valori di hit rate ottenibili da una cache 

gestita da IRCache sono compresi in un range che oscilla tra il 18% e il 26%. Spesso, 

riuscire a guadagnare anche un solo punto percentuale in tale range non è affatto banale. 

Fatta questa debita premessa, si può passare all’analisi dei risultati ottenuti. 

I valori presi in considerazione ai fini dell’analisi sono i valori di hit rate e byte/hit 

rate, due indici tra i più importanti nella valutazione delle prestazioni di un sistema di 

caching. Come precedentemente indicato, i dati raccolti riguardano due differenti 

configurazioni di Squid, la prima con una dimensione della cache pari a 4GB, la seconda 

pari invece a 300MB. Inoltre, per ognuna delle due configurazioni, i test sono stati condotti 

sia con l’ausilio del demone SPD sia senza. 

Analizzando quindi i valori relativi all’hit rate si può notare dal grafico riportato in 

Fig.6-7 come, per una dimensione della cache pari a 4GB, il valore delle hit passi da un 

23.62% senza l’ausilio del demone ad un 23.64% dopo l’utilizzo dello stesso, con un 

aumento dello 0.08%, mentre, nel caso di dimensione della cache pari a 300MB, tale valore 

passi da un 21.45% senza demone ad un 21.97% con demone, con un aumento quindi del 

2.36%. Tali valori sono comprensibili se si considera la dimensione della cache e la 

dimensione del working set, ovvero l’insieme di dati memorizzati in cache “responsabile” 

dei valori di hit ottenuti. Evidentemente, nel caso di cache con dimensione pari a 4GB, il 

valore del working set è estremamente inferiore rispetto alla dimensione della cache stessa. 

Se a questa considerazione aggiungiamo il fatto che, dal monitoraggio effettuato durante i 

test, la dimensione massima dello spazio cache occupato raggiunto da Squid era pari a 

1.4GB, si può comprendere meglio la situazione: la dimensione della cache era così grande e 

140


la durata del test (4 giorni) non sufficiente a consentire uno svuotamento della stessa. Di 

conseguenza, utilizzando il demone e quindi un meccanismo di prefetching, la maggior parte 

degli oggetti richiesti in prefetching dal demone era comunque già presente in cache. Quindi, 

il prefetching stesso è risultato quasi del tutto ininfluente, poiché ha contribuito ad 

aumentare la dimensione del working set in maniera minimale. Ulteriore testimonianza è 

costituita dall’aumento del numero di hit ottenuto a seguito dell’uso di SPD, solamente 120 

hit su un totale di oltre 600 mila richieste. 

Diminuendo le dimensioni della cache e passando quindi al caso di dimensione 

cache pari a 300MB, il working set è stato parzialmente ridotto a seguito del minor spazio a 

disposizione: infatti il valore delle hit è sceso, nel caso di non utilizzo di SPD, da un 23.62% 

per dimensione cache pari a 4GB, ad un 21.45% per cache pari a 300MB. La riduzione 

riscontrata nel working set a seguito del cambiamento della dimensione della cache ha 

quindi portato ad un maggior beneficio riscontrabile tramite l’uso del demone SPD: in 

questo caso infatti, l’utilizzo del prefetching ha permesso di riportare in cache parte degli 

elementi del working set che ne erano stati rimossi a seguito del minor spazio di caching a 

disposizione. In questo caso l’aumento del numero di hit avuto a seguito dell’utilizzo di SPD 

è stato circa pari a 4300 hit. 

Fig. 6-7 - Hit rate al variare della dimensione della cache e della presenza di SPD 

141


Un discorso analogo è possibile se si considera il grafico dei valori di byte/hit rate in 

Fig.6-8, ottenuto dall’analisi dei dati raccolti durante la fase di testing. In questo caso si ha, 

considerando una dimensione della cache pari a 4GB, che il valore del byte/hit Rate passa da 

un 50.26% nel caso di non utilizzo di SPD ad un 50.34% nel caso di utilizzo dello stesso, 

con un aumento dello 0.16%, mentre, nel caso di dimensione della cache pari a 300MB, tale 

valore passa dal 48.10% senza SPD ad un 49.67% con SPD, con un aumento del 3.16%. Per 

i valori di byte/hit rate occorre tuttavia evidenziare come la differenza nel caso di utilizzo o 

meno del demone, per una cache pari a 300MB, sia più accentuata rispetto a quella avuta per 

i valori di hit rate nella medesima condizione. Tale differenza è da ricondurre all’algoritmo 

utilizzato nelle politiche di rimpiazzamento di Squid (LRU), che ha portato all’eliminazione 

dei file più grandi in dimensione ed usati meno di recente. Conseguentemente, il 

meccanismo di prefetching ha riportato tali file in cache, contribuendo così ad aumentare di 

oltre tre punti percentuale il valore di byte/hit rate, che dipende proprio dalla dimensione del 

file trasferito per ogni hit. Aumento che invece non è stato così accentuato per l’hit rate, 

poiché quest’ultimo non dipende dalle dimensioni dei file trasferiti per ogni hit. 

Fig. 6-8 - Byte/hit rate al variare della dimensione della cache e della presenza di SPD 

142


Dai risultati ottenuti e dall’analisi finora condotta su tali risultati emerge chiaro come 

il guadagno ottenibile da una meccanismo di prefetching dipenda fortemente dalle 

dimensioni della cache e del working set del carico utilizzato per i test: minore è la 

differenza tra questi due elementi e maggiore sarà il beneficio apportato dal prefetching 

stesso. Proprio a tal proposito è necessario ricordare quanto precedentemente accennato: è 

importante conoscere la provenienza del carico utilizzato per i test e, preferibilmente, 

utilizzare un carico quanto più vicino possibile a quello di reale impiego per l’architettura in 

esame. Purtroppo, i web log prelevati da IRCache non erano identificabili in tal senso (cache 

di livello regionale, locale, dipartimentale, etc), di conseguenza, molto probabilmente, la 

natura di tali log (forse regionale) era tale da necessitare un periodo di testing di differente 

durata, vista l’alta variabilità e disomogeneità del traffico. 

Ciò nonostante, seppur contenuto, il guadagno apportato dal demone è comunque 

visibile. In particolare, esso contribuisce a diminuire il gap che si viene a creare, al crescere 

dello spazio cache a disposizione, sia per quanto riguarda l’hit rate, sia per quanto riguarda il 

byte/hit rate, tra le configurazioni con cache di maggiore dimensione rispetto a quelle con 

cache di minore dimensione, gap che risulta più marcato nel caso invece di non utilizzo di 

SPD. 

Infine, dai test condotti si è evidenziato come la presenza di una architettura di proxy 

caching applicata al caso di una connessione satellitare costituisca un vantaggio in termini di 

riduzione della latenza percepita durante la navigazione. In Fig.6-9 è rappresentata la 

distribuzione dei tempi di risposta nel caso di utilizzo di una connessione LAN. In questo 

caso, si può notare come la presenza di una connessione veloce diminuisca i benefici 

apportati da un proxy. La maggioranza delle richieste (circa il 60%), infatti, viene 

normalmente risolta in un tempo inferiore o uguale a 500ms, grazie proprio alla velocità e 

alla bassa latenza della connessione. Un tale risultato non può invece ottenersi nel caso di 

connessione satellitare poiché, essendo la latenza minima pari proprio a 500msec, tali 

richieste verrebbero sicuramente risolte in un tempo superiore. 

143


Fig. 6-9 - Distribuzione dei tempi di risposta nel caso di connessione LAN 

Come si può infatti notare da Fig.6-10, dove è rappresentata la distribuzione nel 

tempo del traffico nel caso di una connessione satellitare simulata (500msec di ritardo 

costanti), in questo caso le richieste soddisfatte in un tempo pari o inferiore ai 500msec sono 

solo quelle restituite dalla cache, poiché la latenza del canale porterebbe, senza l’ausilio del 

proxy, ad una risoluzione in un tempo sicuramente più alto. 

144


Fig. 6-10 - Distribuzione dei tempi di risposta nel caso di connessione satellitare 

145

Conclusioni 

Conclusioni 

Il lavoro di tesi presentato è la risposta a due problematiche chiave per il committente 

Telespazio: la latenza del canale satellitare e la necessità di un meccanismo di mirroring dei 

contenuti web. 

Lo sviluppo del lavoro è stato condotto innanzi tutto attraverso una prima fase di 

technology assesment, nella quale sono stati studiati gli elementi che costituiscono i 

“mattoni” di un buon sistema di caching: le politiche di rimpiazzamento dei contenuti in 

cache. A seguito di questo studio, ne sono stati condotti altri miranti ad analizzare le 

soluzioni presenti sul mercato, cercando per ognuna di esse di ricavare pregi e difetti. Questi 

studi sono stati le basi di partenza per la fase successiva: la progettazione dell’architettura. 

Dalle analisi effettuate sulle politiche di rimpiazzamento e sugli elementi comuni nelle varie 

architetture attualmente presenti sul mercato, passando per i test condotti sulle soluzioni 

tecnologiche disponibili per la realizzazione del sistema, si è arrivati alla formulazione di 

una architettura finale. Tale architettura è stata in realtà sdoppiata, al fine di poter rispondere 

al meglio alle differenti esigenze che si possono presentare a seconda della natura del 

traffico caratterizzante il carico del sistema. E’ stata così presentata una versione base, che 

prevede la presenza di un doppio livello di caching (un primo livello a monte del satellite, un 

secondo livello a valle dello stesso), con due istanze di Squid per ogni livello. In questo 

modo si è mirato ad ottimizzare il rendimento del sistema sulla base delle differenti politiche 

di rimpiazzamento utilizzabili per ognuna delle due istanze di Squid, una prima per contenuti 

di tipo multimediale (di grandi dimensioni) e una seconda per “normali” contenuti Web (di 

dimensioni ridotte). Alternativamente alla versione base dell’architettura, è stata quindi 

presentata una seconda versione, che, analogamente alla prima, vede la presenza di un 

doppio livello di caching e di due istanze di Squid per ognuno dei due livelli, ma che allo 

stesso tempo di differenzia per la destinazione d’uso delle due istanze del proxy server. Sulla 

base del presupposto di un basso traffico multimediale e della necessità di un meccanismo di 

mirroring dei contenuti, essa mira ad uno sfruttamento massimo di quest’ultimo, dedicando 

completamente una delle due istanze di Squid, per ognuno dei due livelli di caching, al 

mirroring dei siti Web. Queste due architetture condividono infine l’utilizzo di tecniche di 

146

Conclusioni 

prefetching e di mirroring dei contenuti, al fine di mascherare il più possibile la latenza insita 

nella natura del canale satellitare. Proprio la necessità di utilizzare le tecniche sopra 

accennate ha portato ad una successiva fase di implementazione del sistema e in particolare 

di due moduli di supporto, SPD e MMI. Questi due moduli, quindi, consentono di sfruttare, 

rispettivamente, un meccanismo di prefetching e di mirroring dei contenuti, operando il 

primo in maniera del tutto automatica, attraverso l’analisi dei log della giornata precedente, 

il secondo tramite intervento manuale, atto a selezionare il sito sul quale effettuare il 

mirroring, specificandone un livello di profondità e una frequenza di refresh dei contenuti. Il 

risultato di tale lavoro è il sistema di proxy caching satellitare SatSquid. Esso è il frutto di 

una attenta considerazione sia delle problematiche che si dovevano affrontare, sia delle 

ipotesi di progetto fatte in fase iniziale: il basso costo delle capacità di storage (e quindi la 

possibilità di creare cache di grandi dimensioni a fronte di una ridotta spesa economica) e la 

disponibilità di una banda satellitare pressoché infinita (data anche l’eventualità di creare un 

satellite espressamente dedicato allo scopo). Come già evidenziato, tuttavia, si è potuto trarre 

vantaggio solamente dalla seconda delle due ipotesi, dal momento che la disponibilità di uno 

spazio disco illimitato è risultata essere una possibile fonte di problemi, dovuti alla necessità 

di un oneroso dimensionamento hardware della struttura. Le scelte effettuate, così come 

precedentemente mostrato, hanno portato all’adozione di alcune implicite limitazioni (l’uso 

non ottimale della banda disponibile, visto il mancato utilizzo del pushing coadiuvato dal 

multicast), in parte compensate dalle ipotesi di progetto (banda satellitare pressoché infinita). 

Nell’ultima fase del lavoro, infine, sono stati condotti una serie di test sperimentali su un 

prototipo del sistema, con l’intenzione di riprodurre, quanto più possibile, un reale caso di 

utilizzo. A tal proposito, è stata realizzata una simulazione trace-driven, basata su Web log 

attuali (giugno 2005). 

I risultati di tali sperimentazioni sono stati quindi raccolti e, proprio dalla loro analisi, 

è stato possibile trarre alcune conclusioni, la più significativa delle quali riguarda il 

guadagno apportato dai moduli di supporto SPD e MMI. Come è stato evidenziato 

nell’analisi condotta sui risultati sperimentali, tale margine di guadagno, nel caso specifico 

relativamente al meccanismo di prefetching, risulta limitato e strettamente legato sia alla 

natura del traffico utilizzato per le simulazioni (trace log di proxy regionali, locali, 

dipartimentali, etc), sia alle dimensioni della cache rispetto al working set creato dal suddetto 

147

Conclusioni 

traffico. In tal senso, uno dei possibili sviluppi futuri è proprio quello relativo al testing 

dell’architettura, da compiersi, appunto, su un traffico quanto più vicino possibile a quello su 

cui poi tale architettura verrà effettivamente utilizzata, andando a bilanciare la durata del test 

medesimo in base alla natura del traffico stesso. Altri possibili sviluppi potrebbero essere 

indirizzati verso un affinamento dell’algoritmo di prefetching, andando ad analizzare di volta 

in volta l’eventuale convenienza di richiedere un elemento in prefetching: se il tempo 

necessario al prelevamento di tale elemento risultasse di molto superiore rispetto al RTT 

della connessione satellitare, non ci sarebbe grosso beneficio a richiederlo in prefetching. In 

tal modo, si potrebbe risparmiare sia sull’overhead dovuto alle operazioni di prefetching, sia 

sull’utilizzo della banda disponibile. 

Nonostante i ridotti margini di guadagno riscontrabili nel campo del caching, rimane 

comunque valido quanto sottolineato in fase di analisi dei dati sperimentali: la presenza di un 

sistema di proxy caching, nel caso di una connessione satellitare, costituisce un sicuro 

vantaggio in termine di riduzione della latenza percepita, in quanto tutto il traffico che 

consente di risparmiare verrebbe altrimenti ritardato di almeno 500msec. 

148

Appendice A 

Appendice A 

In questa appendice sono riportati i file di configurazione squid.conf delle macchine 

utilizzate per effettuare i test all’interno della struttura Elis. Le macchine, in configurazione 

doppia istanza di Squid, funzionavano una da front-end (Calamaro) e l’atra da back-end 

(Andromeda). 

Squid.conf (Calamaro) 

######################################### 

# BINDING # 

######################################### 

http_port 8080 

icp_port 3130 

######################################### 

# CACHE_PEER # 

######################################### 

cache_peer 10.50.5.80 parent 3128 3130 proxy-only 

hierarchy_stoplist cgi-bin ? 

acl QUERY urlpath_regex cgi-bin \? 

no_cache deny QUERY 

######################################### 

# CACHE_MEMORY_MANAGEMENT # 

######################################### 

cache_mem 50 MB 

cache_swap_low 90 

cache_swap_high 95 

maximum_object_size 4096 KB 

minimum_object_size 0 KB 

149

maximum_object_size_in_memory 100 KB 

cache_replacement_policy heap GDSF 

memory_replacement_policy lru 

cache_dir aufs /usr/local/squid/var/cache 1000 16 256 

######################################### 

# LOGS_MANAGEMENT # 

######################################### 

cache_access_log /usr/local/squid/var/logs/access.log 

cache_log /usr/local/squid/var/logs/cache.log 

cache_store_log /usr/local/squid/var/logs/store.log 

log_ip_on_direct on 

logfile_rotate 10 

# debug_options ALL,1 

######################################### 

# OPTIONS FOR TUNING THE CACHE # 

######################################### 



# Modifica dovuta al BUG!!!! 

#refresh_pattern . 35791393 20% 35791393 


######################################### 

# ACL # 

######################################### 

acl all src 0.0.0.0/0.0.0.0 

acl manager proto cache_object 

acl localhost src 127.0.0.1/255.255.255.255 

acl to_localhost dst 127.0.0.0/8 

acl SSL_ports port 443 563 

Appendice A 

150

acl Safe_ports port 80 # http 

acl Safe_ports port 21 # ftp 

acl Safe_ports port 443 563 # https, snews 

acl Safe_ports port 70 # gopher 

acl Safe_ports port 210 # wais 

acl Safe_ports port 1025-65535 # unregistered ports 

acl Safe_ports port 280 # http-mgmt 

acl Safe_ports port 488 # gss-http 

acl Safe_ports port 591 # filemaker 

acl Safe_ports port 777 # multiling http 

acl Safe_ports port 631 # cups 

acl Safe_ports port 873 # rsync 

acl Safe_ports port 901 # SWAT 

acl SSL_ports port 873 # rsync 

acl CONNECT method CONNECT 

acl Marcolinux src 10.50.5.166/255.255.255.255 

acl HostValidi src 10.50.5.0/255.255.255.0 10.250.1.120/255.255.255.255 

#acl uffcisco src 10.250.1.120/255.255.255.255 

acl PUSH method PUT 

#Attivazione MSN GAIM YAHOO & IRC 

acl AIM_port port 5190 

acl MSN_port port 1863 

acl YAHOO_port port 5050 

acl IRC_port port 6666 6667 6668 6669 

acl MULO_port port 4661 

acl POST method POST 

http_access allow POST HostValidi 

http_access allow CONNECT AIM_port HostValidi 

#http_access allow CONNECT AIM_port uffcisco 

http_access allow CONNECT MSN_port HostValidi 

http_access allow CONNECT YAHOO_port HostValidi 

http_access allow CONNECT IRC_port HostValidi 

http_access allow CONNECT MULO_port HostValidi 

# Only allow cachemgr access from localhost 

http_access allow manager localhost 

Appendice A 

151

http_access deny manager 

# Deny requests to unknown ports 

http_access deny !Safe_ports 

# Deny CONNECT to other than SSL ports 

http_access deny CONNECT !SSL_ports 

http_access allow PUSH localhost 

http_access deny PUSH Marcolinux 

#DA ATTIVARE SU CALAMARO 

#http_access allow PUSH Marcolinux 

http_access allow HostValidi 

http_access allow localhost 

#http_access allow uffcisco 

# And finally deny all other access to this proxy 

http_access deny all 

http_reply_access allow all 

icp_access allow all 

# L7 SWITCHING tramite ACL 

Appendice A 

acl MM urlpath_regex -i 

\.avi$ \.mpg$ \.mpeg$ \.mov$ \.divx$ \.xvid$ \.mkv$ \.wmv$ \.wav$ \.mp3$ \.ogg$ \. 

mpc$ \.asf$ \.wma$ \.iso$ \.bin$ \.img$ \.nrg$ \.vob$ \.mdf$ 

#Su andromeda vanno solo i file MM 

never_direct allow MM 

cache_peer_access 10.50.5.80 deny !MM 

######################################### 

# SNMP # 

######################################### 


snmp_access allow Marcolinux 



snmp_access allow snmppublic marcolinux 


152

######################################### 

# ADMINISTRATIVE PARAMETERS # 

######################################### 

cache_mgr m.crucianelli@elis.org 

cache_effective_user squid 

cache_effective_group squid 

visible_hostname er-calamaro 

log_icp_queries on 

store_avg_object_size 13 KB 

Appendice A 

153

Squid.conf (Andromeda) 

######################################### 

# BINDING # 

######################################### 

http_port 3128 

icp_port 3130 

######################################### 

# CACHE_PEER # 

######################################### 

hierarchy_stoplist cgi-bin ? 

acl QUERY urlpath_regex cgi-bin \? 

no_cache deny QUERY 

######################################### 

# CACHE_MEMORY_MANAGEMENT # 

######################################### 

cache_mem 100 MB 

cache_swap_low 90 

cache_swap_high 95 

maximum_object_size 2000000 KB 

minimum_object_size 512 KB 

maximum_object_size_in_memory 2048 KB 

cache_replacement_policy heap LFUDA 

memory_replacement_policy lru 

cache_dir aufs /home/telespazio/cache 10000 16 256 

######################################### 

# LOGS_MANAGEMENT # 

######################################### 

Appendice A 

154

cache_access_log /home/telespazio/logs/access.log 

cache_log /home/telespazio/logs/cache.log 

cache_store_log /home/telespazio/logs/store.log 

log_ip_on_direct on 

logfile_rotate 10 

#debug_options ALL,9 

######################################### 

# OPTIONS FOR TUNING THE CACHE # 

######################################### 


#refresh_pattern ^ftp 35791393 20% 35791393 




#refresh_pattern . 35791393 20% 35791393 


######################################### 

# ACL # 

######################################### 

acl all src 0.0.0.0/0.0.0.0 

acl manager proto cache_object 

acl localhost src 127.0.0.1/255.255.255.255 

acl to_localhost dst 127.0.0.0/8 

acl SSL_ports port 443 563 

acl Safe_ports port 80 # http 

acl Safe_ports port 21 # ftp 

acl Safe_ports port 443 563 # https, snews 

acl Safe_ports port 70 # gopher 

acl Safe_ports port 210 # wais 

acl Safe_ports port 1025-65535 # unregistered ports 

acl Safe_ports port 280 # http-mgmt 

acl Safe_ports port 488 # gss-http 

Appendice A 

155

acl Safe_ports port 591 # filemaker 

acl Safe_ports port 777 # multiling http 

acl Safe_ports port 631 # cups 

acl Safe_ports port 873 # rsync 

acl Safe_ports port 901 # SWAT 

acl SSL_ports port 873 # rsync 

acl CONNECT method CONNECT 

acl PUSH method PUT 

acl Marcolinux src 10.50.5.166/255.255.255.255 

acl HostValidi src 10.50.5.0/255.255.255.0 

acl Calamaro src 10.50.5.21/255.255.255.255 

# Only allow cachemgr access from localhost 

http_access allow manager localhost 

http_access deny manager 

# Deny requests to unknown ports 

http_access deny !Safe_ports 

# Deny CONNECT to other than SSL ports 

http_access deny CONNECT !SSL_ports 

http_access allow PUSH localhost 

#http_access deny PUSH Marcolinux 

#DA ATTIVARE SU CALAMARO 

#http_access allow PUSH Marcolinux 

http_access allow HostValidi 

#http_access allow localhost 

# And finally deny all other access to this proxy 

http_access deny all 

http_reply_access allow all 

icp_access allow all 

Appendice A 

156

######################################### 

# SNMP # 

######################################### 


snmp_access allow Marcolinux 

snmp_access allow Calamaro 


snmp_access allow snmppublic Marcolinux 



######################################### 

# ADMINISTRATIVE PARAMETERS # 

######################################### 

cache_mgr m.crucianelli@elis.org 

cache_effective_user squid 

cache_effective_group squid 

visible_hostname andromeda-calamaro 

log_icp_queries on 

store_avg_object_size 512 KB 

always_direct allow all 

Appendice A 

157

Appendice B 

Appendice B 

In questa appendice è riportato un esempio di un file di configurazione utile al 

monitoraggio di diversi parametri via SNMP attraverso il tool MRTG. Nell’esempio in 

questione sono state impostate anche tutte le opzioni relative alla creazione di grafici con 

MRTG stesso, mentre sono lasciate commentate le opzioni necessarie all’integrazione con 

RRDTOOL. 

Configurazione MRTG 

### Global Config Options 

#WorkDir: /home/cala/MRTG 

Htmldir: /home/cala/MRTG/andro 

Imagedir: /home/cala/MRTG/andro/image 

Logdir: /home/cala/MRTG/andro/log 

EnableIPv6: no 

# Disabilito la raccolta dati per anni e mesi 

Suppress[_]: ym 

#DA ATTIVARE per RRDTOOL 

#PathAdd: /usr/bin 

#LibAdd: /usr/share/perl/gentoo-pods/5.8.2 

#logformat: rrdtool 

LoadMIBs:/usr/share/snmp/mibs/IF-MIB.txt,/usr/share/snmp/mibs/UCD-SNMP- 

MIB.txt,/usr/share/snmp/mibs/SQUID-MIB.txt 

Language: italian 

RunAsDaemon: yes 

#Interval: 1 #DA ATTIVARE per RRDTOOL 

Interval: 5 

###################################################################### 

158

# System: Andromeda 

Appendice B 

# Description: Linux Andromeda 2.6.9-vidalinux1 #1 Wed Dec 15 17:51:35 EST 2004 

i686 

# Contact: m.crucianelli@elis.org 

# Location: "Net Lab" 

###################################################################### 

###################################################################### 

# 

# Monitoraggio Schede di Rete 

# 

###################################################################### 

Title[^]: Analisi del traffico per 

PageTop[^]:Analisi del traffico per 

PageTop[$]: di Andromeda 

### Interface 2 >> Descr: 'eth0' | Name: '' | Ip: '10.50.5.80' | Eth: '00-10-5abe-bd-8a' 

### 

Target[andro_eth0]: ifInOctets.2&ifOutOctets.2:public@10.50.5.80 

SetEnv[andro_eth0]: MRTG_INT_IP="10.50.5.80" MRTG_INT_DESCR="eth0" 

MaxBytes[andro_eth0]: 12500000 

Title[andro_eth0]: IF 2 -- Andromeda 

PageTop[andro_eth0]: Interface 2 

 

System: Andromeda in "Net Lab" 

Maintainer: m.crucianelli@elis.org 

Description:eth0 

ifType: ethernetCsmacd (6) 

ifName: 

Max Speed: 12.5 MBytes/s 

Ip: 10.50.5.80 (50-5-21.elis.org) 

 

### Interface 3 >> Descr: 'eth1' | Name: '' | Ip: '192.168.0.195' | Eth: '00-0bcd-20-c7-ac' 

### 

159

Target[andro_eth1]: ifInOctets.3&ifOutOctets.3:public@10.50.5.80 

SetEnv[andro_eth1]: MRTG_INT_IP="192.168.0.195" MRTG_INT_DESCR="eth1" 

MaxBytes[andro_eth1]: 12500000 

Title[andro_eth1]: IF 3 -- Andromeda 

PageTop[andro_eth1]: Interface 3 

 



Description:eth1 

ifType: ethernetCsmacd (6) 

ifName: 

Max Speed: 12.5 MBytes/s 

Ip: 192.168.0.195 () 

 

###################################################################### 

# 

# Monitoraggio SQUID 

# 

###################################################################### 

Title[^]: Analisi 

Title[$]: per lo Squid di Andromeda 

PageTop[^]: Analisi 

PageTop[$]: per lo Squid di Andromeda 

Appendice B 

### CPU >> Descr: 'CPU' | Name: '' | Ip: '10.50.5.80' | Eth: '00-10-5a-be-bd-8a' 

### 

Target[andro_cpu]: ssCpuUser.0&ssCpuUser.0:public@10.50.5.80 

AbsMax[andro_cpu]: 100 

MaxBytes[andro_cpu]: 100 

Title[andro_cpu]: della Cpu % 

Options[andro_cpu]:gauge,noo 

YLegend[andro_cpu]: CPU Utilization 

ShortLegend[andro_cpu]: % 

LegendI[andro_cpu]: CPU Utilization (percentage)&nbsp 

PageTop[andro_cpu]: del CPU Usage % 

 


160


Description:CPU % 

Max %: 100% 

 

Appendice B 

###SQUID CPU >> Descr: 'CPU' | Name: '' | Ip: '10.50.5.80' | Eth: '00-10-5a-be-bd- 

8a' ### 

Target[andro_squid_cpu]: cacheCpuUsage&cacheCpuUsage:public@10.50.5.80:3401 

#SetEnv[10.50.5.80_2]: MRTG_INT_IP="10.50.5.80" MRTG_INT_DESCR="eth0" 

AbsMax[andro_squid_cpu]: 100 

MaxBytes[andro_squid_cpu]: 100 

Title[andro_squid_cpu]: Squid CPU % Usage 

Options[andro_squid_cpu]: absolute,noo 

YLegend[andro_squid_cpu]: Squid CPU Utilization 

ShortLegend[andro_squid_cpu]: % 

LegendI[andro_squid_cpu]: Squid CPU Utilization (percentage)&nbsp 

PageTop[andro_squid_cpu]: del CPU % Usage 

 



Description:CPU % 

Max %: 100% 

 

###SQUID Storage Swap size in kb >> Descr: 'CPU' | Name: '' | Ip: '10.50.5.80' | 

Eth: '00-10-5a-be-bd-8a' ### 

Target[andro_squid_swap]: cacheSysStorage&cacheSysStorage:public@10.50.5.80:3401 

MaxBytes[andro_squid_swap]: 1000000 

Title[andro_squid_swap]: Swap Space size 

Options[andro_squid_swap]: gauge,noo 

YLegend[andro_squid_swap]: Squid Swap Space size 

ShortLegend[andro_squid_swap]: KB 

LegendI[andro_squid_swap]: Squid Swap Space size&nbsp 

PageTop[andro_squid_swap]: Swap Space size 

 



Description:SwapSize 

161

Max %: 100% 

 

###SQUID Number of object stored in cache >> Descr: 'CPU' | Name: '' | Ip: 

'10.50.5.80' | Eth: '00-10-5a-be-bd-8a' ### 

Target[andro_squid_objnum]: 

cacheNumObjCount&cacheNumObjCount:public@10.50.5.80:3401 

MaxBytes[andro_squid_objnum]: 100000000 

Title[andro_squid_objnum]: del numero di oggetti in cache 

Options[andro_squid_objnum]: gauge,noo 

YLegend[andro_squid_objnum]: Squid Swap Space size 

ShortLegend[andro_squid_objnum]: Obj Number 

Appendice B 

LegendI[andro_squid_objnum]: Squid Number of object stored in cache&nbsp 

PageTop[andro_squid_objnum]: del numero di oggetti in cache 

 



Description:ObjNumber 

Max %: 100% 

 

###SQUID Number of available FD >> Descr: 'CPU' | Name: '' | Ip: '10.50.5.80' | 

Eth: '00-10-5a-be-bd-8a' ### 

Target[andro_squid_avFD]: 

cacheCurrentUnusedFDescrCnt&cacheCurrentUnusedFDescrCnt:public@10.50.5.80:3401 

MaxBytes[andro_squid_avFD]: 1500 

Title[andro_squid_avFD]: del numero di FD disponibili 

Options[andro_squid_avFD]: gauge,nopercent,noo 

YLegend[andro_squid_avFD]: SQUID Number of available FD 

ShortLegend[andro_squid_avFD]: Obj Number 

LegendI[andro_squid_avFD]: SQUID Number of available FD&nbsp 

PageTop[andro_squid_avFD]: del numero di FD disponibili 

 



Description:avFD 

Max %: 100% 

162

###SQUID Number of HHTP request received>> Descr: 'CPU' | Name: '' | Ip: 

'10.50.5.80' | Eth: '00-10-5a-be-bd-8a' ### 

Appendice B 

Target[andro_squid_httpreq]: 

cacheProtoClientHttpRequests&cacheProtoClientHttpRequests:public@10.50.5.80:3401 

MaxBytes[andro_squid_httpreq]: 10000000 

Title[andro_squid_httpreq]: del numero di richieste HTTP ricevute 

Options[andro_squid_httpreq]: noo 

YLegend[andro_squid_httpreq]: SQUID Number of HHTP request received 

ShortLegend[andro_squid_httpreq]: HTTP Req Number 

LegendI[andro_squid_httpreq]: SQUID Number of HHTP request received&nbsp 

PageTop[andro_squid_httpreq]: del numero di richieste HTTP ricevute 

 



Description:HTTPreq 

Max %: 100% 

 

###SQUID Number of cache HHTP HITS>> Descr: 'CPU' | Name: '' | Ip: '10.50.5.80' | 

Eth: '00-10-5a-be-bd-8a' ### 

Target[andro_squid_httphit]: cacheHttpHits&cacheHttpHits:public@10.50.5.80:3401 

MaxBytes[andro_squid_httphit]: 10000000 

Title[andro_squid_httphit]: del numero di HTTP HIT in cache 

Options[andro_squid_httphit]: noo 

YLegend[andro_squid_httphit]: Number of cache HHTP HITS 

ShortLegend[andro_squid_httphit]: HTTP HITS 

LegendI[andro_squid_httphit]: Number of cache HHTP HITS&nbsp 

PageTop[andro_squid_httphit]: del numero di HTTP HIT in cache 

 



Description:HTTP HITS 

Max %: 100% 

 

163

Appendice B 

###SQUID Number of cache HHTP ERR>> Descr: 'CPU' | Name: '' | Ip: '10.50.5.80' | 

Eth: '00-10-5a-be-bd-8a' ### 

Target[andro_squid_httperr]: 

cacheHttpErrors&cacheHttpErrors:public@10.50.5.80:3401 

MaxBytes[andro_squid_httperr]: 10000000 

Title[andro_squid_httperr]: del numero di HHTP ERR in cache 

Options[andro_squid_httperr]: noo 

YLegend[andro_squid_httperr]: Number of cache HHTP ERR 

ShortLegend[andro_squid_httperr]: HTTP ERR 

LegendI[andro_squid_httperr]: Number of cache HHTP ERR&nbsp 

PageTop[andro_squid_httperr]: del numero di HHTP ERR in cache 

 



Description:HTTP ERR 

Max %: 100% 

 

###SQUID Number of ICP msg Sent>> Descr: 'CPU' | Name: '' | Ip: '10.50.5.80' | 

Eth: '00-10-5a-be-bd-8a' ### 

Target[andro_squid_icpsent]: 

cacheIcpPktsSent&cacheIcpPktsSent:public@10.50.5.80:3401 

MaxBytes[andro_squid_icpsent]: 10000000 

Title[andro_squid_icpsent]: del numero di ICP msg inviati 

Options[andro_squid_icpsent]: noo 

YLegend[andro_squid_icpsent]: SQUID Number of ICP msg Sent 

ShortLegend[andro_squid_icpsent]: ICP SentMsg 

LegendI[andro_squid_icpsent]: SQUID Number of ICP msg Sent&nbsp 

PageTop[andro_squid_icpsent]: del numero di ICP msg inviati 

 



Description:ICP Sent MSG 

Max %: 100% 

 

164

Appendice B 

###SQUID Number of ICP msg Recv>> Descr: 'CPU' | Name: '' | Ip: '10.50.5.80' | 

Eth: '00-10-5a-be-bd-8a' ### 

Target[andro_squid_icprecv]: 

cacheIcpPktsRecv&cacheIcpPktsRecv:public@10.50.5.80:3401 

MaxBytes[andro_squid_icprecv]: 10000000 

Title[andro_squid_icprecv]: del numero di ICP msg Recv 

Options[andro_squid_icprecv]: noo 

YLegend[andro_squid_icprecv]: SQUID Number of ICP msg Recv 

ShortLegend[andro_squid_icprecv]: ICP RecvMsg 

LegendI[andro_squid_icprecv]: SQUID Number of ICP msg Recv&nbsp 

PageTop[andro_squid_icprecv]: del numero di ICP msg Recv 

 



Description:ICP Recv MSG 

Max %: 100% 

 

###SQUID Cache Current Swap Size>> Descr: 'CPU' | Name: '' | Ip: '10.50.5.80' | 

Eth: '00-10-5a-be-bd-8a' ### 

Target[andro_squid_currswap]: 

cacheCurrentSwapSize&cacheCurrentSwapSize:public@10.50.5.80:3401 

MaxBytes[andro_squid_currswap]: 10000 

Title[andro_squid_currswap]: della cacheCurrentSwapSize 

Options[andro_squid_currswap]: gauge,noo 

YLegend[andro_squid_currswap]: cacheCurrentSwapSize 

ShortLegend[andro_squid_currswap]: cacheCurrentSwapSize 

LegendI[andro_squid_currswap]: cacheCurrentSwapSize&nbsp 

PageTop[andro_squid_currswap]: della cacheCurrentSwapSize 

 



Description:cacheCurrentSwapSize 

Max %: 100% 

 

###SQUID Cache HTTP All service time>> Descr: 'CPU' | Name: '' | Ip: '10.50.5.80' 

| Eth: '00-10-5a-be-bd-8a' ### 

165

Target[andro_squid_httpalltime]: 

cacheHttpAllSvcTime.1&cacheHttpAllSvcTime.1:public@10.50.5.80:3401 

MaxBytes[andro_squid_httpalltime]: 10000 

Title[andro_squid_httpalltime]: del Cache HTTP All service time 

Options[andro_squid_httpalltime]: gauge,noo 

YLegend[andro_squid_httpalltime]: SQUID Cache HTTP All service time 

ShortLegend[andro_squid_httpalltime]: SQUID Cache HTTP All service time 

Appendice B 

LegendI[andro_squid_httpalltime]: SQUID Cache HTTP All service time&nbsp 

PageTop[andro_squid_httpalltime]: del Cache HTTP All service time 

 



Description:SQUID Cache HTTP All service time 

Max %: 100% 

 

###SQUID Cache HTTP HIT service time>> Descr: 'CPU' | Name: '' | Ip: '10.50.5.80' 

| Eth: '00-10-5a-be-bd-8a' ### 

Target[andro_squid_httphittime]: 

cacheHttpHitSvcTime.1&cacheHttpHitSvcTime.1:public@10.50.5.80:3401 

MaxBytes[andro_squid_httphittime]: 10000 

Title[andro_squid_httphittime]: del Cache HTTP Hit service time 

Options[andro_squid_httphittime]: gauge,noo 

YLegend[andro_squid_httphittime]: SQUID Cache HTTP Hit service time 

ShortLegend[andro_squid_httphittime]: SQUID Cache HTTP Hit service time 

LegendI[andro_squid_httphittime]: SQUID Cache HTTP Hit service time&nbsp 

PageTop[andro_squid_httphittime]: del Cache HTTP Hit service time 

 



Description:SQUID Cache HTTP Hit service time 

Max %: 100% 

 

###SQUID Cache ICP Query service time>> Descr: 'CPU' | Name: '' | Ip: '10.50.5.80' 

| Eth: '00-10-5a-be-bd-8a' ### 

Target[andro_squid_icpquerytime]: 

cacheIcpQuerySvcTime.1&cacheIcpQuerySvcTime.1:public@10.50.5.80:3401 

166

MaxBytes[andro_squid_icpquerytime]: 10000 

Title[andro_squid_icpquerytime]: del Cache ICP Query service time 

Options[andro_squid_icpquerytime]: gauge,noo 

YLegend[andro_squid_icpquerytime]: SQUID Cache ICP Query service time 

ShortLegend[andro_squid_icpquerytime]: SQUID Cache ICP Query service time 

Appendice B 

LegendI[andro_squid_icpquerytime]: SQUID Cache ICP Query service time&nbsp 

PageTop[andro_squid_icpquerytime]: del Cache ICP Query service time 

 



Description:SQUID Cache ICP Query service time 

Max %: 100% 

 

###SQUID Request Hit Ratio>> Descr: 'CPU' | Name: '' | Ip: '10.50.5.80' | Eth: 

'00-10-5a-be-bd-8a' ### 

Target[andro_squid_hitratio]: 

cacheRequestHitRatio.1&cacheRequestHitRatio.1:public@10.50.5.80:3401 

MaxBytes[andro_squid_hitratio]: 10000 

Title[andro_squid_hitratio]: del Request Hit Ratio 

Options[andro_squid_hitratio]: gauge,noo 

YLegend[andro_squid_hitratio]: SQUID Request Hit Ratio 

ShortLegend[andro_squid_hitratio]: SQUID Request Hit Ratio 

LegendI[andro_squid_hitratio]: SQUID Request Hit Ratio&nbsp 

PageTop[andro_squid_hitratio]: del Request Hit Ratio 

 



Description:SQUID Request Hit Ratio 

Max %: 100% 

 

###SQUID Request Byte Ratio>> Descr: 'CPU' | Name: '' | Ip: '10.50.5.80' | Eth: 

'00-10-5a-be-bd-8a' ### 

Target[andro_squid_byteratio]: 

cacheRequestByteRatio.1&cacheRequestByteRatio.1:public@10.50.5.80:3401 

MaxBytes[andro_squid_byteratio]: 10000 

167

Title[andro_squid_byteratio]: del SQUID Request Byte Ratio 

Options[andro_squid_byteratio]: gauge,noo 

YLegend[andro_squid_byteratio]: SQUID Request Byte Ratio 

ShortLegend[andro_squid_byteratio]: SQUID Request Byte Ratio 

LegendI[andro_squid_byteratio]: SQUID Request Byte Ratio&nbsp 

PageTop[andro_squid_byteratio]: del SQUID Request Byte Ratio 

 



Description:SQUID Request Byte Ratio 

Max %: 100% 

 

Appendice B 

168

Appendice C 

Appendice C 

In questa appendice è riportato il file di configurazione, calamaris.conf utilizzato per 

l’analisi del file di log tramite il tool Calamaris. In questo file possono essere abilitate o 

meno differenti tipi di analisi statistiche effettuabili sui log di Squid. 

calamaris.conf 

############################################################################### 

################## CONFIGURATION FILE FOR CALAMARIS V3 #################### 

############################################################################### 

# 

# Configuration file for calamaris V3.x 

# 

# This configuration file follows the perl syntax. To define variables, just 

# do it as you are used to do it. 

# $var = value; 

# undef($var); # same as $var = 0; 

# 

# To run calamaris with a configuration file, use: 

# cat access.log | ./calamaris --config-file calamaris.conf 

# 

# All command line arguments overwrites the configuration file items. 

# 

# Most of the configration items can be configured by commandline 

# arguments. Try 

# ./calamaris --help 

# 

# Other commandline arguments: 

# -L or --dump-loop: Loop (dumps the generated internal loop to STDERR for 

# debugging.) 

# 

# -C or --copyright copyright (prints the copyright) 

# -h or --help help (prints out this message) 

# -V or --version Version (prints version-info) 

# 

# On each section, you find a small description, the command line argument if 

# available, an example output (to give you an idea of this section), the 

169

# default value and how to use in this configuration file. 

# 

Appendice C 

############################################################################### 

# 

# IMPORTANT: 

# (*) These options break the privacy of your users. Please read the README 

# on this. 

# 

# Some items have to be configured in this configuration file, because no 

# command line options are available. Otherwise default values are taken! 

# 

############################################################################### 

############################################################################### 

############################# REPORT SECTION ############################## 

############################################################################### 

############################################################################### 

# 

# show 'n' Top-level and 'n' second-level destinations, 

# -1 = unlimited 

# 

# command line argument: -d n | --domain-report n 

# 

# Example output: 

# 

# Request-destinations by toplevel-domain 

# destination request % Byte % 

hit-% 

# --------------------------------------- --------- ------ -------- ------ ---- 

-- 

# *.de 360753 51.58 4576770K 47.41 

22.48 

# *.com 202536 28.96 4684139K 48.52 

18.88 

# 

# Request-destinations by 2nd-level-domain 

# destination request % Byte % 

hit-% 

# --------------------------------------- --------- ------ -------- ------ ---- 

-- 

170

Appendice C 

# *.plaxo.com 36 10.00 84835 8.00 

0.80 

# *.ebay.com 20 7.40 44735 5.50 

1.10 

# 

# 

# Default: 

# undef($domain_report); # (no top- and second-level destinations are 

# reported) 

# 

# Usage: 

# $domain_report = n; 

# 

$domain_report = -1; 

############################################################################### 

# 

# limit the display of lines to those with a minimum of requests. 

# 

# command line argument: --domain-report-limit n 

# 

# Default : 

# undef($domain_report_limit); # no limit. 

# 

# Usage: 

# $domain_report_limit = n; 

$domain_report_limit = 50; 

############################################################################### 

# 

# change all 2nd-level-reports to N-level-reports. 'n' can be 

# any number from 2 up. -1 means full report. 

# This is only useful, if $domain_report is set (see above). 

# 

# command line argument: -N n | --domain-report-n-level n 

# 

# 

# Default: 

# undef($domain_report_n_level); # (reporting of second-level destinations) 

171

# 

# Usage: 

# $domain_report_n_level = n; # (reporting of n-level destinations) 

Appendice C 

############################################################################### 

# 

# Error code distribution 

# 

# command line argument: --errorcode-distribution-report 

# 


# 

# TCP Response code distribution 

# status-code request % Byte % 

# ----------------------------------- --------- ------ -------- ------ 

# 000 (Used mostly with UDP traffic) 727633 2.93 3625190K 1.97 

# 100 (Continue) 4 0.00 687 0.00 

# 200 (OK) 20145830 81.19 171223M 95.12 

# 

# 

# Default: 

# undef($errorcode_distribution_report); # (no reporting) 

# 

# Usage: 

# $errorcode_distribution_report = [0|1]; 

$errorcode_distribution_report = 1; 

############################################################################### 

# 

# Object freshness report 

# Here you can find information about the freshness of objects in your cache. 

# 

# Calamaris looks for freshness tags like 'TCP_HIT', 'TCP_REFRESH_MISS', ... 

# and make statistics on it. With this information you can optimize the 

# caching behaviour of your cache depending on the objects content type. 

# E.g. squid admins could use this information to configure the 

# refresh_pattern. 

# 

172

# Default: 

# undef($object_freshness_report); # (no reporting) 

# 

# Usage: 

# $object_freshness_report = [0|1]; 

$object_freshness_report = 1; 

# Here you have to define the 'TRANSACTION HEADER' for your cache software! 

# 

# Note: the variable $refresh_tags is not used at the moment 

# Usage: the hash keys have to be one of this (see --input-format): 

# squid, squid-old, nc, elff, its or nse 

# Please adjust the 'TRANSACTION HEADER' according your cache manual. 

# 

# $xxx_tags{'hash keys'} = [( 'TRANSACTION HEADER 1', 

# 'TRANSACTION HEADER 2', 

# 'TRANSACTION HEADER 3' ... )]; 

# 

# $fresh_tags: all fresh hits 

# $stale_tags: all stale misses 

# $refresh_tags: not used at the moment 

# $mod_tags: hits which have been modified after an IMS 

# $unmod_tags: hits which have not been modified after an IMS 

# 

# Explanation: 

# all hits = $fresh_tags + $stale_tags 

# $stale_tags = $mod_tags + $unmod_tags 

# 

# The following list is not complete (as you can see) and may be incorrect. 

# If there is a need of improvement please notify. 

#Tags for squid 

$fresh_tags{'squid'} = [( 'TCP_HIT', 'TCP_MEM_HIT', 'TCP_IMS_HIT', 

'TCP_IMS_MISS' )]; 

$stale_tags{'squid'} = [( 'TCP_REFRESH_HIT', 'TCP_REFRESH_MISS', 

'TCP_REF_FAIL_HIT' )]; 

$refresh_tags{'squid'} = [( 'TCP_CLIENT_REFRESH' )]; 

$mod_tags{'squid'} = [( 'TCP_REFRESH_MISS' )]; 

$unmod_tags{'squid'} = [( 'TCP_REFRESH_HIT' )]; 

Appendice C 

173

#Tags for squid-old 

$fresh_tags{'squid-old'} = [( 'TCP_HIT', 'TCP_MEM_HIT', 'TCP_IMS_HIT', 

'TCP_IMS_MISS' )]; 

$stale_tags{'squid-old'} = [( 'TCP_REFRESH_HIT', 'TCP_REFRESH_MISS', 

'TCP_REF_FAIL_HIT' )]; 

$refresh_tags{'squid-old'} = [( 'TCP_CLIENT_REFRESH' )]; 

$mod_tags{'squid-old'} = [( 'TCP_REFRESH_MISS' )]; 

$unmod_tags{'squid-old'} = [( 'TCP_REFRESH_HIT' )]; 

#Tags for NetCache 5.5 

Appendice C 

$fresh_tags{'nc'} = [( 'TCP_HIT', 'TCP_HIT_ACCESS_DENIED', 'TCP_HIT_EJECT', 

'TCP_HIT_HIT_PARTIAL', 'TCP_HIT_HIT_VERIFY' )]; 

$stale_tags{'nc'} = [( 'TCP_HIT_IMS_NOTMOD','TCP_HIT_PRECONDITION_FAILED', 

'TCP_MISS_CACHE_VERSION', 'TCP_MISS_VERIFY', 'TCP_REF_FAIL_HIT' )]; 

$refresh_tags{'nc'} = [( 'TCP_MISS_RELOAD' )]; 

$mod_tags{'nc'} = [( 'TCP_MISS_VERIFY' )]; 

$unmod_tags{'nc'} = [( 'TCP_HIT_IMS_NOTMOD' )]; 

$fresh_tags{'elff'} = [( 'TCP_HIT', 'TCP_HIT_ACCESS_DENIED', 'TCP_HIT_EJECT', 

'TCP_HIT_HIT_PARTIAL', 'TCP_HIT_HIT_VERIFY' )]; 

$stale_tags{'elff'} = [( 'TCP_HIT_IMS_NOTMOD','TCP_HIT_PRECONDITION_FAILED', 

'TCP_MISS_CACHE_VERSION', 'TCP_MISS_VERIFY', 'TCP_REF_FAIL_HIT' )]; 

$refresh_tags{'elff'} = [( 'TCP_MISS_RELOAD' )]; 

$mod_tags{'elff'} = [( 'TCP_MISS_VERIFY' )]; 

$unmod_tags{'elff'} = [( 'TCP_HIT_IMS_NOTMOD' )]; 

############################################################################### 

# 

# measure peak requests 

# 

# command line argument: -p [new|old] | --peak-report [new|old] 

# 


# 

# Incoming request peak per protocol 

# prt sec peak begins at min peak begins at hour peak begins at 

# --- ---- ------------------ ----- ------------------ ------- ---------------- 

-- 

# UDP 0 0 0 

# TCP 348 04.Apr 04 04:33:58 3059 04.Apr 04 02:01:18 82479 04.Apr 04 

23:00:00 

174

Appendice C 

# --- ---- ------------------ ----- ------------------ ------- ---------------- 

-- 

# ALL 348 04.Apr 04 04:33:58 3059 04.Apr 04 02:01:18 82479 04.Apr 04 

23:00:00 

# 

# Incoming transfer volume per protocol 

# proto kB/hour peak begins at 

# ----- -------- ------------------ 

# UDP 0 

# TCP 1964368 04.Apr 04 22:00:00 

# ----- -------- ------------------ 

# ALL 1964368 04.Apr 04 22:00:00 

# 

# 

# Default: 

# undef($peak_report); # (no peak measurement is reported) 

# 

# Usage: 

# $peak_report = ['new'|'old']; 

# old = make old request-peak mesurement 

# new = make new request&byte-peak measurement 

# (both slow Calamaris significantly down.) 

$peak_report = 'new'; 

############################################################################### 

# 

# Performance: show throughput data for every 'n' minutes 

# 

# command line argument: -P n | --performance-report n 

# 


# 

# Performance in 60 minute steps 

# incomin hit miss direct sibling 

fetch 

# date request Byte kB/sec kB/sec kB/sec kB/sec kB/sec 

kB/sec 

# --------------- --------- ----- ------- ------- ------- ------- ------- ----- 

-- 

175

# 04.Apr 04 00:00 20217 211M 8.69 53.23 6.35 7.38 4.03 

1.11 

# 04.Apr 04 01:00 14685 169M 7.93 77.43 5.16 5.64 2.79 

13.18 

# 04.Apr 04 02:00 23450 388M 15.45 44.42 13.13 16.09 5.76 

1.14 

# 04.Apr 04 03:00 15092 284M 10.50 3.76 8.52 8.15 16.98 

0.39 

# 

# 

# Default: 

# undef($performance_report); # (no performance is reported) 

# 

# Usage: 

# $performance_report = n; 

$performance_report = 60; 

Appendice C 

############################################################################### 

# 

# Time 

# adjust the Performance-Report in minutes 

# 

# command line argument: -T | --performance-report-adjust 

# 

# 

# Default: 

# undef($performance_report_adjust); # don't adjust the Performance-Report 

# 

# Usage: 

# $performance_report_adjust = [0|1]; 

############################################################################### 

# 

# requester: show 'n' Requesters/User, -1 = unlimited 

# 

# command line argument: -r n | --requester-report n 

# 


# 

176

# Incoming TCP-requests by host 

# host request hit-% Byte hit-% sec 

kB/sec 

Appendice C 

# --------------------------------- --------- ------ -------- ------ ---- ----- 

-- 

# 10.1.1.1 186643 3.80 6366926K 0.22 1 

55.18 

# 10.1.4.2 86331 0.00 26654655 0.00 0 

130.18 

# 10.1.1.3 48482 7.43 13294970 20.33 0 

53.73 

# 10.1.5.10 48474 7.43 13289730 20.34 0 

57.84 

# 

# 

# Default: 

# undef($requester_report); # (no requester is be monitored) 

# 

# Usage: 

# $requester_report = n; 

$requester_report = -1; 

############################################################################### 

# 

# no-lookup 

# don't look IP-Numbers up 

# 

# command line argument: -n | --requester-report-no-dns-lookup 

# 

# 

# Default: 

# undef($requester_report_no_dns_lookup); # don't lookup IP-Numbers 

# 

# Usage: 

# $requester_report_no_dns_lookup= [0|1]; 

############################################################################### 

# 

# use ident information if available (*) 

177

# 

# command line argument: -u | --requester-report-use-user-info 

# 

# 

# Default: 

# undef($requester_report_use_user_info); # don't use login information 

# 

# Usage: 

# $requester_report_use_user_info= [0|1]; 

Appendice C 

############################################################################### 

# 

# targets for requester: show 'n' targets for every Requester, 

# -1 = unlimited), implies $requester_report = n (*) 

# If $requester_report is not set, $requester_report is set to 

# $requester_report_with_targets. 

# 

# command line argument: -R n | --requester-report_with_targets n 

# 

# Example: 

# 


# host / target request hit-% Byte hit-% sec 

kB/sec 

# --------------------------------- --------- ------ -------- ------ ---- ----- 

-- 

# 10.101.93.111 917 8.07 1529952 12.26 1 

1.94 

# *.the-arena.de 665 10.68 882366 14.49 0 

35.11 

# *.gmx.net 93 3.23 397865 15.00 0 

66.17 

# *.ebay.de 54 0.00 53779 0.00 0 

24.69 

# 

# 

# Default: 

# undef($requester_report_with_targets); # (no requester is monitored) 

# 

# Usage: 

# $requester_report_with_targets = n; 

178

$requester_report_with_targets = 3; 

Appendice C 

############################################################################### 

# 

# Response Time Diagram: 

# sum up the time distribution over all objects. 

# 

# command line argument: --response-time-report 

# 


# 

# TCP-Request duration distribution in msec 

# time request % Byte % 

# --------------- --------- ------ -------- ------ 

#

# 

# Usage: 

Appendice C 

# @response_time_report_interval = qw(0.001 0.1 0.2 0.5 1 2 5 10 20 50 100 200 

500 1000 2000 5000 10000 20000 50000 1e10); 

@response_time_report_interval = qw(0.001 0.1 0.2 0.5 1 2 5 10 20 50 100 200 500 

1000 2000 5000 10000 20000 50000 1e10); 

############################################################################### 

# 

# Size-Distribution-Report: 

# shows size-based distribution of requested 

# objects, smaller numbers result in more verbose reports. 

# choose 2, 10 or 100 for useful output. (You can also play 

# with this ;-)) 

# 

# command line argument: -D [2|10|100] | --size-distribution-report [2|10|100] 

# 


# 

# object-size (bytes) request hit-% Byte hit-% sec kB/sec 

# -------------------- --------- ------- ------- ------ ------- ------ 

# 0-0 138146 33.70 0 0.00 4 0.00 

# 1-9 7 0.00 35 0.00 0 0.01 

# 10-99 38240 0.00 2772033 0.00 10 0.01 

# 

# 

# Default: 

# undef($size_distribution_report); # (no reporting) 

# 

# Usage: 

# $size_distribution_report = [2|10|100]; 

$size_distribution_report = 100; 

############################################################################### 

# 

# status: show verbose status reports 

# 

180

# command line argument: -s | --status-report 

# 


# 

# Summary 

# lines parsed: 699415 

# invalid lines: 0 

# unique hosts/users: 363 

# parse time (sec): 136 

# 

# 

# Default: 

# undef($status_report); # (no status reporting) 

# 

# Usage: 

# $status_report = [0|1]; 

$status_report = 1; 

Appendice C 

############################################################################### 

# 

# show 'n' content-type, 'n' extensions and requested protocols, 

# -1 = unlimited 

# 

# command line argument: -t n | --type-report n 

# 


# 

# Requested content-type 

# content-type request % Byte % 

hit-% 

# --------------------------------------- --------- ------ -------- ------ ---- 

-- 

# text/html 223479 31.95 4600042K 47.65 

11.02 

# text/plain 116291 16.63 1460336K 15.13 

0.74 

# 

# Requested extensions 

# extensions request % Byte % 

hit-% 

181

Appendice C 

# --------------------------------------- --------- ------ -------- ------ ---- 

-- 

# 202347 28.93 4720924K 48.90 

4.65 

# 139819 19.99 1480113K 15.33 

5.59 

# gif 115411 16.50 186475K 1.93 

62.50 

# 

# 

# Default: 

# undef($type_report); # (no reporting) 

# 

# Usage: 

# $type_report = -1; 

############################################################################### 

# 

# switch to case-insensitive reporting (useful for extensions-report) 

# 

# command line argument: -c | --type-report-ignore-case 

# 

# 

# Default: 

# undef($type_report_ignore_case); # make the reports case sensitive 

# 

# Usage: 

# $type_report_ignore_case= [0|1]; 

$type_report_ignore_case= 1; 

############################################################################### 

############################# INPUT SECTION ############################### 

############################################################################### 

############################################################################### 

# 

# Logformat type: 

182

# sets the type of input logfiles 

# auto = tries to guess the input format 

# (This is the Default) 

# squid = Native-Logfile derived from Squid V1.1.beta26-V2.x 

# squid-extended = Native-Logfile with log_mime_hdrs enabled 

# derived from Squid V1.1.beta26-V2.x (*) 

# or Cisco Content Engines (*) 

# or Squid with SmartFilter-patch (*) 

# squid-old = Native-Logfile derived from Squid 

# V1.1.alpha1-V1.1.beta25 

# nc = Squid-style Logfiles derived from NetCache V?? (

# include: 

# no IPs are analyzed, except IP/range. (*) 

# command line argument: --ip-filter-include List 

# 

# List-Format: 1.1.1.1/32:1.1.2.0/24 

# 1.1.1.1/255.255.255.255:1.1.2.0/255.255.255.0 

# 

# 

# command line argument: 

# --ipfilter-exclude IP/range 

# --ipfilter-include IP/range 

# 

# Default: 

# undef($ipfilter_exclude); # no IPs are excluded 

# undef($ipfilter_include); # no IPs are included 

# 

# Usage: 

# $ipfilter_exclude = '1.1.1.1/255.255.255.255:1.1.2.0/255.255.255.0'; 

# $ipfilter_include = '1.1.1.1/255.255.255.255:1.1.2.0/255.255.255.0'; 

Appendice C 

############################################################################### 

# 

# no input via STDIN 

# This is useful when reading cache files. 

# 

# command line argument: -z | --no-input 

# 

# 

# Default: 

# undef($no_input); # (calamaris expects logfile via STDIN) 

# 

# Usage: 

# $no_input = [0|1]; 

############################################################################### 

# 

# Interval 

# defines which time-interval should be parsed 

184

# t has to be the format yyyymmddhhmmss 

# omitting the beginning or ending is allowed. 

# 

# command line argument: -I t1-t2 | --time-interval t1-t2 

# 

# 

# Default: 

# undef($time_interval); 

# 

# Usage: 

# $time_interval= 't1-t2'; 

$time_interval= '20050429090000-20050504230000'; 

Appendice C 

############################################################################### 

############################# OUTPUT SECTION ############################## 

############################################################################### 

############################################################################### 

# 

# Graph colours: 

# These values cannot be configured by commandline arguments! 

# If you want to change the default values, you have to use this 

# configuration items. 

# 

# Define the colours of the columns and text/axis/legend/labels. 

# The colours for Hit-% are automatically darkend. 

# 

# Default: 

# $column1_color = '#6699cc'; 

# $column2_color = '#ff9900'; 

# $text_color = '#222266'; 

############################################################################### 

# 

# image type 

# Sets the image type to gif, png, jpeg, gd or gd2. Only usefull when 

185

# --output-format graph is set. The supported images types are dependend 

# on your GD::Graph installation. 

# Calamaris tells you which formats are supported, if an error occurs. 

# 

# 

# Default: 

# $image_type = 'png'; 

# 

# Usage: 

# $image_type = ['gif'|'png'|'jpeg'|'gd'|'gd2']; 

Appendice C 

############################################################################### 

# 

# output format of the tables 

# 

# Better don't play with this ;-), no warranty what happen with the output, if 

# not used correctly 

# Please consider: 

# - you can not change the order of the table columns. 

# - you can switch off the output of single columns by using the keyword 'off'. 

# - don't change the numbers or '%'. Do you know, what you are doing? 

# - you can change the output of Request/sec and Byte/sec by using the 

# following keywords: 

# 

# kbps = kByte/sec 

# spkb = sec/kByte 

# bps = Byte/sec 

# spb = sec/Byte 

# rps = req/sec 

# spr = sec/req 

# rpms = req/msec 

# mspr = msec/req 

# off 

# % 

# 

# Default: the output is optimized to 79 character per line. 

# 

# This units (keywords) are not influenced by $unit, see below. 

186

# Incoming requests by method 

$formats[3] = [ 30, 9, '%', 'spr', 8, '%', 'kbps' ]; 

# Incoming UDP-requests by status 

$formats[4] = [ 30, 9, '%', 'mspr', 8, '%', 'kbps' ]; 

# Incoming TCP-requests by status 


# Outgoing requests by status 


# Outgoing requests by destination 


# Request-destinations by ${N}-level-domain 

$formats[8] = [ 26, 9, '%', '%', 'spr', 8, '%', '%', 'kbps' ]; 

# Request-destinations by toplevel-domain 


# TCP-Request-protocol 


# Requested content-type 


# Requested extensions 

$formats[12] = [ 16, 9, '%', '%', 'spr', 8, '%', '%', 'kbps', 11, 11 ]; 

# Incoming UDP-requests by host 




# Distribution Histogram 


# Performance in $P steps 

Appendice C 

$formats[16] = [ 15, 9, '%', 5, '%', 6, 'kbps', 'kbps', 'kbps', 'kbps', 'kbps', 

'kbps' ]; 

# UDP-Request duration distribution in msec 

$formats[17] = [ 16, 9, '%', '%', 'mspr', 8, '%', '%', 'kbps' ]; 

# TCP-Request duration distribution in msec 

$formats[18] = [ 16, 9, '%', '%', 'mspr', 8, '%', '%', 'kbps' ]; 

# UDP Response code distribution 


# TCP Response code distribution 


############################################################################### 

187

# 

# Hostname 

# Define the name for the Report Output 

# 'lookup' issues a lookup for the current host 

# FQDN means, give an full qualified domain name or any name you want. 

# 

# command line argument: -H ['FQDN|'lookup'] | --hostname ['FQDN|'lookup'] 

# 

# 

# Default: 

# undef($hostname); # The report output headline is without any hostname 

# 

# Usage: 

# $hostname= ['FQDN|'lookup']; 

Appendice C 

############################################################################### 

# 

# logo 

# Here you can define a HTML-string which should be included into the report 

# head. You can also define a filename, then the file is included into the 

# report head. It works only in combination with 

# $output_format = 'html' or 'html,graph'. 

# 

# command line argument: -l [string|filename] | --logo [string|filename] 

# 

# 

# Default: 

# undef($logo); # no logo is included into the html head 

# 

# Usage: 

# $logo= ' HTML-TEXT '; # define string 

# $logo= './calamaris_head.html'; # or define file 

############################################################################### 

# 

# Meta 

# includes the given strings in html-. You can also give a filename, then 

188

# the file is included in html-. It works only in combination with 

# $output_format = 'html' or 'html,graph'. 

Appendice C 

# This is useful to include CSS or JavaScript. It's up to you, to include some 

# more CSS Tags in the calamaris output. You have to edit the source code. 

# 

# The following CSS tags are defined already: 

# .TableDefinition 

# .TableHeadline 

# 

# command line argument: -M [string|filename] | --meta [string|filename] 

# 

# 

# Default: 

# undef($meta); # (no meta information is included) 

# 

# Usage: 

# $meta = ' 

# 

# '; # define string 

# $meta ='./calamaris.css'; # or define CSS-file 

############################################################################### 

# 

# output format (comma-seperated list) 

# (Default is plain formatted text) 

# mail = mail format 

# html = HTML format 

# html-embed = HTML format without HTML-headers 

# graph = enable graphics, needs GD::Graph, only useful with 

# html or html-embed (see also $output_path) 

# unformatted = plain unformatted output 

# 

# command line argument: -F [options] | --output-format [options] 

# 

# 

# Default: 

# undef($output_format); # Default is plain formatted text 

# 

# Usage: 

189

# $output_format = ['mail'|'html'|'html-embed'|'graph'|'unformatted']; 

$output_format = 'html,graph'; 

Appendice C 

############################################################################### 

# 

# output path 

# writes output calamaris statistics to /path. In case of 

# html-embed,graph or html,graph output, the graphics destination is /path. 

# If $output_path is not given, all graphics are written to the working 

# directory. './'. The Filename is index.html for html-output and 

# calamaris.txt on plain-output. 

# 

# command line argument: --output-path 'path' 

# 

# 

# Default: 

# undef($output_path); # Default is output path is working directory './' 

# 

# Usage: 

# $output_path= '/path'; 

$output_path= '/home/marco/calamaris'; 

############################################################################### 

# 

# output file 

# alters the filename of the output path. Else it is index.html on html-output 

# and calamaris.txt on plain-text-output. 

# 

# command line argument: --output-file 'filename' 

# 

# 

# Default: 

# undef($output_file); # Default is index.html or calamaris.txt 

# 

# Usage: 

# $output_file= 'filename'; 

190

Appendice C 

############################################################################### 

# 

# list Show 

# Shows only the defined reports (comma-seperated list) in the 

# specified order. The following numbers are defined (see ./calamaris -h): 

# 0 Summary 

# 1 Incoming request peak per protocol 

# 2 Incoming transfer volume peak per protocol 

# 3 Incoming requests by method 

# 4 Incoming UDP-requests by status 

# 5 Incoming TCP-requests by status 

# 6 Outgoing requests by status 

# 7 Outgoing requests by destination 

# 8 Request-destinations by 2nd-level-domain 

# 9 Request-destinations by toplevel-domain 

# 10 TCP-Request-protocol 

# 11 Requested content-type 

# 12 Requested extensions 

# 13 Incoming UDP-requests by host 

# 14 Incoming TCP-requests by host 

# 15 Size Distribution Diagram 

# 16 Performance in n minute steps 

# 17 UDP-Request duration distribution in msec 

# 18 TCP-Request duration distribution in msec 

# 19 UDP Response code distribution 

# 20 TCP Response code distribution 

# 

# Note: only putting out one report does not speed up Calamaris 

# as the internal operations were done based on the 

# report-switches. Default: Reports are displayed based on 

# activated reports. 

# 


# -S comma-separated-list | --show-reports comma-separated-list 

# 

# 

# Default: 

# undef($show_reports); # sort request size 

# 

191

# Usage: 

# $show_reports = 0,1,2,4,6; 

$show_reports = 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20; 

Appendice C 

############################################################################### 

# 

# Sort Order 

# changes the sort order in the reports to request size, 

# default is sorting by number of requests. 

# 

# command line argument: -O | --sort-order 

# 

# 

# Default: 

# undef($sort_order); # sort request size 

# 

# Usage: 

# $sort_order = [0|1]; 

############################################################################### 

# 

# define the Unit for the Byte-values, else it will be auto 

# K(ilo), M(ega), G(iga), T(era) 

# 

# command line argument: -U option | --unit option 

# 

# 

# Default: 

# undef($unit); # Default is yoto formatting of unit. 

# 

# Usage: 

# $unit = [K|M|G|T]; 

############################################################################### 

# 

# Define the graph size in pixel. 

# The image ratio (width : height) is 3 : 2. 

192

# 

# Default: 

# $width = 600; # the graph has a size of 600x400 Pixel 

# Usage: 

# $width = 300; 

Appendice C 

############################################################################### 

# 

# How many datasets should be drawn on the graph. 

# $x_scale = 30 is a good value, play with this -> no warranty what happens 

# if $x_scale is too big! 

# 

# Default: 

# $x_scale = 30; 

# Usage: 

# $x_scale = 10; 

############################################################################### 

############################# CACHE SECTION ############################### 

############################################################################### 

############################################################################### 

# 

# input-file 

# input-datafile for caching, to add many files separate them with a ':'. 

# 


# -i 'inputfile.dat' | --cache-input-file 'inputfile.dat' 

# 

# 

# Default: 

# undef($cache_input_file); # no input from cache file 

# 

# Usage: 

# $cache_input_file= 'file1:file2:file3'; 

############################################################################### 

# 

193

# output-file 

# output-datafile for caching, can be the same as $cache_input_file 

# 

# command line argument: -o filename.dat | --cache-output-file filename.dat 

# 

# 

# Default: 

# undef($cache_output_file); # no cachefile will be written 

# 

# Usage: 

# $cache_output_file = 'cache.dat'; 

Appendice C 

############################################################################### 

############################## MISC SECTION ############################### 

############################################################################### 

############################################################################### 

# 

# benchmark 

# prints a hash-sign (#) to STDERR for each n lines 

# processed 

# 

# command line argument: -b n | --benchmark n 

# 

# 

# Default: 

# undef($benchmark); # don't show hashes (#) 

# 

# Usage: 

# $benchmark = n; 

############################################################################### 

############################# DEBUG SECTION ############################### 

############################################################################### 

############################################################################### 

# 

194

# make some small tests (only for programmer) 

#$test = 1; 

Appendice C 

############################################################################### 

# 

# verbose 

# print information what Calamaris is doing. Useful for debugging. 

# 

# command line argument: -v | --verbose 

# 

# 

# Default: 

# undef($verbose); # don't write debug information 

# 

# Usage: 

# $verbose = [0|1]; 

############################################################################### 

# 

#Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004 Cord Beermann. 

#Calamaris comes with ABSOLUTELY NO WARRANTY. It is free software, and you are 

#welcome to redistribute it under certain conditions. See source for details. 

#Calamaris-Homepage: http://Calamaris.Cord.de/ 

# 

############################################################################### 

# $Id: calamaris.conf,v 3.0.0.4 2004/12/23 20:16:10 cord Exp $ 

195

Appendice D 

Appendice D 

In questa appendice è riportato il file di configurazione spd.cfg necessario al 

funzionamento del programma SPD. Tale file è diviso in sezioni: la sezione di default deve 

necessariamente essere presente per il corretto funzionamento del programma stesso. 

Spd.cfg 

##################################### 

# File di configurazione del demone # 

##################################### 

[DEFAULT] 

# Dimensione della cache di squid 

dim_cache = 1000000000 

# Path assoluto del file di log da analizzare 

log_from = /usr/local/squid/var/logs/access.log.0 

[POSTA] 

# Abilita l'invio di posta per notificare il logging del demone [on|off] 

mail = on 

# Indirizzo del mittente della posta (demone) 

# Inseribile nei formati [indirizo@posta.com | Nome Cognome 

] 

from_addr = Marco Crucianelli 

# Indirizzo del destinatario della posta 

# Inseribile nei formati [indirizo@posta.com | Nome Cognome 

] 

to_addr = m.crucianelli@elis.org 

196

[SMTP] 

# Valido solo se mail = on 

# Indirizzo del server SMTP da usare per inviare la posta 

smtp = exchange2003.elis.org 

# Abilita, se necessario, il login per l'invio della posta [on| off] 

login = on 

# Login per l'accesso al server SMTP 

smtp_login = m.crucianelli 

# Password per l'accesso al server SMTP 

smtp_passwd = prova 

Appendice D 

197

Glossario 

Glossario 

ACK Aknowledgement, ovvero informazione di conferma di avvenuta 

ricezione dei dati. Usata per esempio nel protocollo TCP 

ARP Address Resolution Protocol, è un protocollo utilizzato per 

effettuare un mapping di un indirizzo IP con il relativo indirizzo 

MAC della scheda di rete ad esso associata 

ARQ Automatic Repeat-Request è un protocollo utilizzato per il controllo 

(trasmissione) 

broadband 

d’errore nelle trasmissioni dati 

Modalità di trasmissione che consente di trasmettere attraverso un 

unico mezzo trasmissivo una molteplicità di segnali 

Buffer Circolare Buffer di dimensione fissata che memorizza informazioni fino al 

Business-To- 

Business 

massimo supportato dalla propria dimensione per poi scartare man 

mano i dati più vecchi per inserirne di nuovi, il tutto in maniera 

continua 

Orientamento al mercato di una azienda che fornisce prodotti e/o 

servizi non per una utenza finale, bensì per altre aziende 

Cache Spazio di memoria utilizzato per mantenere una copia di 

informazioni accedute frequentemente così da diminuire la latenza 

necessaria al prelevamento tali informazioni 

Cache peer Cache inserita all’interno di una struttura di caching cooperativo, in 

cui ogni cache (cache peer appunto )scambia dati e informazioni su 

essi con le altre cache della struttura 

Client Computer collegato ad una rete che effettua una richiesta di un 

documento ad un computer server 

Cluster Un insieme di computer indipendenti combinati assieme come un 

Database 

Relazionale 

unico sistema attraverso del software e una rete sottostante. Lo 

scopo è sia quello di raggiungere alta disponibilità di risorse (High 

Availability) sia alte prestazioni (High Performance Computing) 

Modello di database che consiste di diversi file separati che sono 

correlati l'un l'altro attraverso campi chiave. Si può accedere alle 

198

Glossario 

informazioni memorizzate in un file attraverso uno o più degli altri 

file, grazie alle relazioni stabilite tra questi 

(protezione) DRM Termine di largo significato, usato per identificare tutto in insieme 

di tecniche che consentono ad un fornitore di contenuti in formato 

elettronico di controllare come i propri contenuti vengono utilizzati 

da apparecchiature elettroniche che implementano tali tecnologie 

FEC Forward Error Correction è un sistema per il controllo d’errore nelle 

trasmissioni dati che consente la correzione di un determinato 

numero di bit di errore introdotti durante la comunicazione 

Funzione di Hash Funzione necessaria al calcolo dell’hash di una documento (et 

similia), di un identificativo unico 

Gateway (Internet) Computer che mette in comunicazione la rete di residenza di un 

insieme di client con Internet 

(licenza) GPL Licenza software inizialmente scritta da Richard Stallman, anche 

nota come copyleft che assegna i seguenti diritti: 

libertà di usare un programma per qualsiasi scopo; 

libertà di studiare come funziona un programma ed eventualmente di 

modificarlo; 

libertà di ridistribuire copie del programma stesso; 

libertà di migliorare il programma e di rilasciare lo copie al 

pubblico. 

(cache) Hit Si ha un hit in cache quando il dato richiesto è stato trovato in cache 

Internet Un insieme di reti eterogenee interconnesse tra loro tali da formare 

una “ragnatela” di connessioni a livello mondiale 

IP virtuale Usato in contrapposizione all’IP reale per indicare un indirizzo IP 

normalmente non associato ad una interfaccia fisica, ma, molto più 

spesso ad una periferica di loopback. 

ISP Internet Service Provider, fornitore di servizi per l’accesso ad 

Internet 

Layer 7 switching Modalitàdi switching delle richieste effettuata a livello applicativo 

Load Balancing Bilanciamento di un carico di lavoro (siano essere richieste web o 

199

altro) tra più macchine in maniera equa 

Località temporale Principio adottato nelle cache secondo il quale un documento 

Glossario 

acceduto di recente ha buone probabilità di essere acceduto ancora 

nell’immediato futuro 

Log File di testo in cui vengono memorizzati tutte gli eventi (generati e 

non) registrati da un determinato programma: web server, proxy, etc 

MAC address Indirizzo fisico di una periferica di rete, assegnato direttamente dal 

produttore della stessa. Non ne possono esistere due uguali 

M-Bone Rete virtuale (via software) che consente di effettuare multicast su 

tutta l’Internet incapsulando i pacchetti multicast in normali 

pacchetti unicast, in modo da risultare trasparente ai router unicast 

(sito) Mirror Copia identica di un sito, usata allo scopo di snellire l’accesso al sito 

originario 

(cache ) Miss Si ha un miss in cache quando il dato richiesto non è stato trovato in 

MSS (Maximum 

Segment Size) 

cache 

Dimensione massima di dati inviati in un segmento (unità di misura 

di trasmissione dati) nel protocollo TCP 

Multicast Modalità di trasmissione dati che prevede l’invio degli stessi dati in 

contemporanea ad un gruppo di client ben identificato di una rete. 

Una risposta per più richieste 

NAK Negative ACK, usato in contrapposizione al normale ACK, inviato 

Open Source 

(software) 

per confermare la ricezione di una informazione. Al contrario, il 

NACK, viene inviato solamente in caso di non ricezione 

dell’informazione 

Software il cui dodice e tutte le altre informazioni che lo riguardano 

sono pubblicamente disponibili e modificabili 

Origin Server Server a cui è originariamente diretta la richiesta di un documento 

da parte di un client. Termine usato in contrapposizione al proxy 

che, facendo le veci dell’origin server, restituisce al client tale 

documento prelevandolo dalla propria cache 

Policy di Politica adottata in un algoritmo di caching per scegliere gli oggetti 

200

Rimpiazzamento da rimuovere in cache 

Prefetching Tecnica che consiste nel richiedere anticipatamente una 

Glossario 

informazione che si ritiene verrà richiesta in un prossimo futuro, ma 

che ancora attualmente non è stata richiesta 

Proxy Computer, posizionato nei pressi di un Internet Gateway, che si 

Push (caching vs. 

Pull caching) 

Regressione 

logistica 

occupa di servire tutte le richieste dei client, prelevando i documenti 

richiesti dalla propria cache o andando ad interrogare l’origin server 

e memorizzando in cache l’eventuale risposta, prima di restituirla al 

client 

Meccanismo di caching che prevede l’invio e la successiva 

memorizzazione di un oggetto direttamente in una cache, senza la 

necessità che tale oggetto venga preventivamente richiesto da un 

client 

Tecnica che stima la probabilità che si verifichi un evento, attraverso 

l’utilizzo di fattori osservati assieme all'occorrenza o non occorrenza 

dell'evento, per stimare la probabilità che l'evento si verifichi in 

determinate circostanze. 

Reverse Proxy Posizionato, invece che vicino all’utente finale, vicino al sito per il 

quale effettuerà le funzionalità di proxy/cache (da qui il termine 

reverse), ha lo scopo di alleggerire il carico per il sito interessato 

Round Trip Time Tempo necessario all’invio di un pacchetto e alla ricezione 

dell’acknowledgement del pacchetto stesso 

RSVP Protocollo utilizzato dagli host per richiedere specifiche qualità di 

Satelliti 

Geostazionari 

servizio alla rete per particolari flussi di dati. Esso viene anche 

utilizzato dai router per fornire una determinata qualità di servizio 

lungo tutti i nodi della comunicazione e per mantenere lo stato 

necessario a garantire il servizio richiesto 

Satelliti che operano ad una altezza di circa 30000KM e ruotano in 

“sincrono” con il globo terrestre, tali da rimanere quasi “fermi” 

rispetto ad esso 

Server Web Computer che ospita una serie di documenti web. Esso fornisce al 

201

client che lo richiede copia di tali documenti 

Sniffer Programma che sfruttando la modalità di funzionamento 

Slow Start 

Algorithm 

Glossario 

“promiscuo” di una scheda di rete, catturi tutto il traffico in transito 

su tale scheda, quindi anche quello a lei non direttamente indirizzato 

Algoritmo del protocollo TCP che regola la quantità di informazioni 

inviabili nel caso di una nuova connessione o di timeout di una già 

esistente 

SO-HO Small Office-Home Office, ovvero uffici di piccole dimensioni, 

spesso assimilabili a posti di lavoro rappresentati dai telelavoratori 

Streaming Tecnica che prevede l’invio di contenuti di carattere multimediale in 

forma di flusso live (e quindi non interrompibile) di informazioni 

Testbed network Rete dove ingegneri e ricercatori possono implementare nuovo 

Three-Way- 

Handshaking 

tecnologie di rete, testarle e valutarle 

Meccanismo utilizzato dal protocollo TCP per la creazione di una 

connessione, che prevede lo scambio di tre pacchetti: il primo, SYN, 

per richiedere la creazione della connessione (richiedente), il 

secondo, SYN-ACK, per accettare la richiesta (ricevente) e il terzo e 

ultimo, ACK, per confermare la ricezione dell’accettazione 

(richiedente) 

Timestamp Relativamente ad una pagina web salvata in cache, rappresenta 

l’informazione di data e ora in cui quella pagina è stata creata 

TCP Protocollo di livello trasporto che fornisce meccanismi di controllo 

della comunicazione 

Transparent proxy Proxy server completamente trasparente all’utente finale che dovrà 

utilizzarlo. Molto utile e usato in ambito aziendale, poiché consente 

notevoli risparmi in termini di configurazione per l’amministratore 

di sistema, dal momento che non richiede settaggi per l’utente finale 

UDP Protocollo di livello trasporto che non fornisce meccanismi di 

controllo della comunicazione 

Unicast Modalità di trasmissione dati che prevede l’invio di tali informazioni 

202

ad un unico client della rete. Una risposta per una richiesta 

Glossario 

Url Uniform Resource Locator, fornisce l’identificativo della posizione 

di una copia di una determinata risorsa 

Wormhole caching Modalità di caching che prevede lo scambio di dati tramite l’utilizzo 

di wormholes, ovvero link che saltano i normali collegamenti di 

rete, per collegare punto punto due postazioni geograficamente 

molto distanti (eliminando così i problemi di latenza dovuti alla 

lontananza e alla conseguente necessità di transitare su numerosi 

percorsi e apparati di rete) 

203

Bibliografia 

[And03] M. Andreolini, M. Colajanni, M. Nuccio, “Kernel-based Web switches 

Bibliografia 

providing content-aware routing”, Proc. of 2nd IEEE Int'l Symposium on 

Network Computing and Applications (NCA'03), Cambridge, MA, April 

2003 

[Apa05] The Apache Software Foundation, http://www.apache.org, May 2005 

[Arl99] M. Arlitt, L. Cherkasova, J. Dilley, R. Friedrich, T. Jin, “Evaluating Content 

Management Techniques for Web Proxy Caches”, 

http://www.hpl.hp.com/techreports/98/HPL-98-173.html, April 1999 

[Bha04] Bhalekar, J. Baras, “Cumulative Caching For Reduced User-Perceived 

Latency For WWW Transfer On Networks With Satellite Links”, 

http://www.isr.umd.edu/~anibha/ICT-2004-Paper.pdf, IECT 2004, March 

2004 

[Bal04] Balamash, M. Krunz, “An Overview Of Web Caching Replacement 

Algorithms”, IEEE Communication Survey, Vol.6, N° 2, Second Quarter 

2004 

[Bee05] C. Beermann, “Calamaris”, 

http://cord.de/tools/squid/calamaris/Welcome.html.en, January 2005 

[Bro05] E. Brown, “Guida a Cron per Gentoo Linux”, http://www.gentoo.it/doc/cron- 

guide, March 2005 

[Car02] V. Cardellini, E. Casalicchio, M. Colajanni, P. S. YU, “The State of the Art in 

Locally Distributed Web-Server Systems”, ACM Computing Surveys, Vol. 

34, No. 2, June 2002 

[Che99] H. Chen, M. Abrams, T. Johnson, A. Mathur, I. Anwar, J. Stevenson, 

“Wormhole Caching with HTTP PUSH Method for a Satellite-Based Web 

Content Multicast and Replication System”, 

http://citeseer.ist.psu.edu/rd/93912320%2C100392%2C1%2C0.25%2CDown 

load/http://citeseer.ist.psu.edu/cache/papers/cs/5111/http:zSzzSzwww.ircache 

204

.netzSzCachezSzWorkshop99zSzPaperszSzchen- 

final.pdf/chen99wormhole.pdf, 1999 

[Cis02] “Simple Network Management Protocol”, 

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/snmp.pdf, 

February 2002 

[Coh95] Y. Cohen, “SNMP – Simple Network Management Protocol”, 

http://www2.rad.com/networks/1995/snmp/snmp.htm, 1995 

Bibliografia 

[Coo02] J. Cooper, “Designing a Web Caching Infrastructure for Your Network”, 

http://www.swelltech.com/support/sizecache/index.html, May 2002 

[Dil99] J. Dilley, M. Arlitt, S. Perret, “Enhancement and Validation of Squid's Cache 

Replacement Policy”, http://www.hpl.hp.com/techreports/1999/HPL-1999- 

69.html, May 1999 

[DRA05] Linux VS, “TCPHA Project”, http://dragon.linux-vs.org/~dragonfly/, May 

2005 

[Gen05] “HOWTO SNMP and MRTG Made Easy”, http://gentoo- 

wiki.com/HOWTO_SNMP_and_MRTG_Made_Easy, May 2005 

[Gnu05] GNU Wget 1.10 Manual, 

http://www.gnu.org/software/wget/manual/wget.html, May 2005 

[Gue97] D. Guerrero, “Network Management & Monitoring with Linux”, 

http://www.david-guerrero.com/papers/snmp/, June 1997 

[Hof99] M. Hofmann, T. S. Eugene Ng, K. Guo, S. Paul, H. Zhang, “Caching 

Techniques For Streaming Multimedia Over The Internet”, Bell-Lab 

Technical Memorandum, April 1999 

[Ino96] H. Inoue, K. Kanchanasut, S. Yamaguchi, “Adaptive WWW Cache 

Mechanism in the AI3 Network”, http://www.ai3.net/pub/inet97/inet97- 

w3cache.html, 1996 

[Ino97] H. Inoue, K. Kanchanasut, S. Yamaguchi, “An Adaptive WWW Cache 

Mechanism in the AI3 Network”, 

http://www.ai3.net/pub/inet97/cache_ppt/foils.html, June 1997 

[Ipr05] Linux routing manipulation tools, http://developer.osdl.org/dev/iproute2, June 

05 

205

[Irc05] IRCache, http://www.ircache.net/, June 2005 

[Jav05] JavaScript.com (TM) - The Definitive JavaScript Resource: 

JavaScript Tutorials, Free Java Scripts, Source Code and Other 

Scripting Resources, http://www.javascript.com, May 2005 

[Kri01] Krishnamurthy, J. Rexford, “Web Protocols and Practice. HTTP/1.1, 

Bibliografia 

Networking Protocols, Caching, and Traffic Measurement”, Addison Wesley, 

May 2001 

[Lin01] H. Linder e R. Donadio, “WestSees, issue 4: SatCAST - Satellite Multicast 

for Web Applications”, 

http://www.west.nl/whitepapers/SatCAST/TechArticle.html, April 2001 

[Lin05a] Linux Virtual Server, “Linux Virtual Server: how”, 

http://www.linuxvirtualserver.org/how.html, May 2005 

[Lin05b] Linux Virtual Server, “Virtual server via IP-tunnelling”, 

http://www.linuxvirtualserver.org/VS-IPTunneling.html, May 2005 

[Lin05c] Linux Virtual Server, “ARP problem in VS/TUN and VS/DR“, 

http://www.linuxvirtualserver.org/docs/arp.html, May 2005 

[Mat99] Mathur, M. Abrams, H. Chen, T. Oishi, T. Johnson, I. Anwar, “Adding 

Intelligence To Satellite-Based Internet Links: Architecture Of A Second- 

Generation Satellite-Based Internet Delivery System”, 

http://www.isoc.org/inet99/proceedings/4q/4q_2.htm, Inet99, 1999 

[Mog97] J. Mogul, F. Douglis, A. Feldmann, “Potential Benefits of Delta Encoding 

and Data Compression for HTTP”, Proceedings of SIGCOMM (1997) 

[MRT05] “MRTG Reference”, http://people.ee.ethz.ch/~oetiker/webtools/mrtg/mrtg- 

reference.html, May 2005 

[Mys05] MySQL: The World's Most Popular Open Source Database, 

http://www.mysql.com, May 2005 

[Net05] Netem, http://developer.osdl.org/shemminger/netem/, June 2005 

[Nis05] NIST net, http://www-x.antd.nist.gov/nistnet/, June 2005 

[Nok05] “Python for Series 60”, 

http://www.forum.nokia.com/main/1,6566,1_49,00.html, June 2005 

[Php05] PHP: Hypertext Preprocessor, http://www.php.net, May 2005 

206

[Pru04] F. Prunoiu, “MRTG Implementation Manual”, 

Bibliografia 

http://www.enterastream.com/whitepapers/mrtg/mrtg-manual.html, August 

2004 

[Pyt05a] Python, http://www.python.org/, May 2005 

[Pyt05b] Python Library Reference - SMTP protocol client, 

http://www.python.org/doc/2.4.1/lib/module-smtplib.html, June 2005 

[Pyt05c] Python Library Reference - Regular expression operations, 

http://www.python.org/doc/2.4.1/lib/module-re.html, June 2005 

[Pyt05d] Python Library Reference - Configuration file parser, 

http://www.python.org/doc/2.4.1/lib/module-ConfigParser.html, June 2005 

[Pyt05e] Python Library Reference - Logging facility for Python, 

http://www.python.org/doc/2.4.1/lib/module-logging.html, June 2005 

[Rab01] M. Rabinovich, O. Spatscheck, “Web Caching and Replication”, Addison 

Wesley, December 2001 

[Rou97] Rousskov, V. Soloviev, I. Tatarinov, “Static Caching”, 

http://www.cs.ndsu.nodak.edu/~rousskov/research/papers/wcw97/index.html, 

April 1997 

[Squ05a] Squid Web Proxy Cache, http://www.squid-cache.org/, May 2005 

[Squ05b] Squid FAQ, ”Squid Log Files”, http://www.squid-cache.org/Doc/FAQ/FAQ- 

6.html, May 2005 

[Tag05a] S. Tagliaferri, “I file sorgenti di Squid“, http://merlino.merlinobbs.net/Squid- 

Book/HTML/sec-source-code.html, April 2005 

[Tag05b] S. Tagliaferri, “Capire il funzionamento delle ACL”, 

http://merlino.merlinobbs.net/Squid-Book/HTML/sec-liste-di-controllo- 

acl.html, April 2005 

[Tag05c] S. Tagliaferri, “Due parole su SNMP”, http://merlino.merlinobbs.net/Squid- 

Book/HTML/sec-parole-snmp.html, April 2005 

[Tag05d] S. Tagliaferri, “MRTG e Squid”, [Tag05] S.Tagliaferri, “Due parole su 

SNMP”, http://merlino.merlinobbs.net/Squid-Book/HTML/sec-parole- 

snmp.html, April 2005 

207

Bibliografia 

[TCP05] TCPIP Guide, ”TCP Operational Overview and the TCP Finite State Machine 

(FSM)”, 

http://www.tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFinite 

StateMachineF.htm, May 2005 

[Zha04] Q. Zhang, Z. Xiang, W. Zhu, L. Gao, “Cost-Based Cache Replacement And 

Server Selection For Multimedia Proxy Across Wireless Internet”, IEEE 

Transaction On Multimedia, Vol.6, N°4, August 2004 

[Wes04] D. Wessels, “Six Things First-Time Squid Administrators Should Know”, 

http://www.onlamp.com/pub/a/onlamp/2004/02/12/squid.html, December 

2004 

208

L’autore, Marco Crucianelli, ringrazia vivamente l’Ing. Cardellini per 

il sostegno, la pazienza e i preziosi consigli dispensati; il Prof. Tucci 

per la disponibilità accordata; l’Elis tutta per il sostegno tecnico e 

umano dimostrati. 

Si ringrazia inoltre l’Università degli studi di Roma “Tor Vergata” e 

tutti coloro che hanno reso possibile questo lavoro. 

209

UNIVERSITA' DEGLI STUDI DI ROMA TOR VERGATA - TECA ELIS

Create successful ePaper yourself

Delete template?

Save as template?