Università di Napoli Federico II

Corso di Reti di Calcolatori

prof. G. Ventre

Simulazione del protocollo HTTP

Antonio Cagnazzo, 45/4111

Luca Coppola, 41/3809
Andrea D’Amore, 45/4231
Olindo Isabella, 45/4451

a.a. 2003/2004
 Cosa è HTTP
HTTP (Hyper Text Transfer Protocol) è un protocollo di trasferimento dati
nato per servire specificatamente gli ipertesti. L’ipertesto, sviluppato in maniera
teorica nel 1945 (cfr. Vannevar Bush) e messo in pratica, mediante Xanadu (cfr.
Ted Nelson) ed NLS - oN Line System - (cfr. Douglas Engelbart) negli anni '60,
è un’evoluzione del testo classico contenente al suo interno dei rimandi ad altri
testi, i collegamenti, i quali consentono di saltare da una pagina ad un’altra, e
quindi da un concetto ad un altro, dando così all'utente una metodologia
d’accesso all'informazione del tutto nuova. La funzione dell'ipertesto, infatti, è
quella di organizzare testi e risorse in un formato gestibile in maniera non
lineare, cosicché un documento possa contenere tutte le fonti di informazioni
aggiuntive consultabili solo se l'utente lo ritenga opportuno.

La storia di HTTP
La nascita del protocollo HTTP è legata strettamente al concetto di WWW
(World Wide Web) accresciutosi nel mezzo degli anni '80.
L'invenzione del protocollo HTTP, sviluppata al CERN (Consiglio Europeo
per la Ricerca Nucleare) di Ginevra, è dovuta al ricercatore inglese Tim
Berners-Lee. Egli scrisse un programma, chiamato Enquire, che lo aiutava a
ricordare i collegamenti tra le persone e i progetti all’interno del laboratorio.
Gli strumenti utilizzati per l’invenzione del Protocollo sono stati l'ipertesto ed
Internet, grazie al suo protocollo standardizzato TCP/IP. L'utilizzo di Internet è
dovuto alla possibilità di rendere accessibili gli ipertesti anche al di fuori della
macchina singola, in maniera del tutto trasparente all'utente, e di estendere la
rete di ipertesti ai laboratori esterni sparsi per il mondo.
Nel 1989 Berners-Lee propose al CERN di sviluppare un sistema informatico
che avrebbe creato una rete di informazioni.
Nel 1990, lavorando in proprio, scrisse l'HTTP.
2
 Il protocollo sarebbe dovuto servire per condividere documenti ipertestuali
attraverso Internet. Immediatamente si sentì l'esigenza di elaborare uno schema
per fornire indirizzi a tali documenti. Berners-Lee chiamò questi indirizzi URI
(Universal Resource Identifier).
Alla fine di quell'anno egli scrisse anche il primo browser (navigatore), un
programma client per ricevere e visualizzare documenti ipertestuali. Questo
client fu chiamato World Wide Web. Gli ipertesti furono formattati utilizzando
l'HTML (Hypertext Markup Language), sempre scritto da Berners-Lee. Le
pagine erano accessibili mediante un programma server di rete (il primo server
HTTP della storia: info.cern.ch).
Questa rete di informazione destò un fortissimo interesse sia nel mondo
scientifico che in quello governativo per la sua subitanea crescita: si raggiunsero
diecimila accessi al giorno sul server del CERN.
Tuttavia dopo qualche tempo si rese necessaria la scrittura di nuovi browser
che potessero girare sui più diffusi sistemi operativi, poiché Berners-Lee aveva
scritto il suo browser solo per il sistema NeXT. In quest'ottica si inserirono
alcuni dei colleghi di Berners-Lee, che scrissero Samba per Mac e, soprattutto,
Marc Andreessen che creò Mosaic, divenuto poi il famoso Netscape.
Il WWW ha avuto, dal suo creatore, sempre un’impostazione di carattere
open. L'entrata in gioco di altri programmatori ha in qualche modo modificato la
filosofia di base del progetto di Berners-Lee, che era quello di condividere
semplicemente ipertesti attraverso la rete mondiale. Infatti con il suo Mosaic
Marc Andreessen cominciò ad inserire negli ipertesti anche immagini. Lo stesso
Berners-Lee promosse la fondazione di una Comunità di sviluppo, che, pur
facendo rimanere il WWW open, ne controllasse gli sviluppi evitando un
degrado di tutti quei nobili intenti alla base stessa della rete.
Ad oggi la suddetta comunità è divenuta un importante centro di promozione
di software legati all’ulteriore sviluppo della rete. Il suo nome è W3C (World
Wide Web Consortium).

3
 Come funziona
HTTP lavora con degli oggetti, chiamati anche risorse, mediante operazioni
dette metodi.
Tale protocollo stabilisce le regole con le quali un client, cioè una macchina
che richiede una risorsa, può inviare le proprie richieste e con le quali il server,
la macchina cui la richiesta è stata inviata, risponde alle richieste medesime.
L’invio dei messaggi e il trasferimento delle risorse in sé viene demandato al
protocollo di trasferimento, mentre, tramite HTTP, è possibile elaborare
messaggi che possono essere interpretati, a livello applicazione, da macchine tra
loro collegate.
Ciò perché HTTP è stato creato pensando al suo uso sul protocollo TCP, già
da tempo consolidato. Questo ha permesso ad HTTP di essere semplice e veloce.
In un tipico “dialogo” tramite HTTP un client deve elaborare una richiesta,
codificata in ASCII, che ha una ben precisa sintassi: prima si esprime il metodo
del protocollo che si vuole utilizzare, poi si elenca l’URL (Uniform Resource
Locator) a cui il client si rivolge e infine si esplicita la versione di HTTP
utilizzata (i.e.  GET /index.html HTTP/1.1); dall’altra parte la risposta
del server è costituita da un'intestazione con al suo interno la riga di stato, varie
informazioni sulla data corrente, sul server, sulla data di ultima modifica, etc. ed
eventualmente il contenuto della risorsa stessa che a sua volta può essere ASCII
(American Standard Code for Information Interchange) o codificata MIME
(Multipurpose Internet Mail Extension).
La riga di stato è la prima riga del testo che costituisce la risposta del server
e contiene la versione di HTTP utilizzata, un codice numerico di 3 cifre che
indica se la richiesta è stata soddisfatta o meno e, in quest’ultimo caso, la causa
del mancato servizio, in ultimo la descrizione verbale del risultato
dell’operazione.

4
 Esistono oggi due principali versioni di HTTP in uso, la 1.0 e la 1.1.

HTTP 1.0 HTTP 1.1

Metodi implementati
GET: richiesta di lettura di una risorsa
HEAD: richiesta di lettura dell’intestazione di una risorsa
POST: aggiunta di informazioni ad una risorsa indicata
PUT: richiesta di memorizzazione di una
risorsa
DELETE: cancellazione di una risorsa
CONNECT: riservato per utilizzi futuri
OPTION: interrogazione di determinate
opzioni

Come si evince dalla precedente tabella, HTTP 1.0 implementa i metodi GET,
HEAD e POST, mentre HTTP 1.1 ne introduce di nuovi.
Caratteristiche ulteriori di HTTP 1.1 sono la possibilità di supportare il
caching e l’utilizzo delle connessioni persistenti.
Il caching consiste nella memorizzazione delle risorse richieste, per
riaccederle in maniera più veloce. Tale procedura si basa su un processo
chiamato proxy, che si occupa di gestire la cache (l’area di memoria utilizzata
per archiviare le risorse), e che si frappone tra il client e il server reale. Il client,
quando richiede una risorsa, si rivolge al proxy; se questo è in grado di fornirla,
la restituisce al client, evitando, così, un appesantimento dei processi del server
reale. Quando il server aggiorna le risorse, le affida al proxy, affinché le
gestisca. In questo modo il server può ottimizzare le proprie attività,
indipendentemente dal numero di richieste delle sue risorse.
Con le connessioni persistenti HTTP 1.1 riesce ad ottimizzare le transazioni
tra il client e il server, permettendo al primo di effettuare più richieste ad ogni
connessione stabilita, lasciandola attiva finché non la dichiari conclusa. Questo
permette al client di ottenere, ad esempio, più file di una pagina web, con una
sola connessione, invece di avere una connessione per ogni file. Con HTTP 1.0,
invece, il server chiude la connessione ad ogni oggetto inviato al client.
Le connessioni persistenti sono state introdotte per ottimizzare i tempi di

5
trasferimento su pagine dell’ordine dei Kbyte, contenenti diversi oggetti stavolta
dell’ordine di decine di Kbyte: questa situazione era molto comune all’epoca
dell’introduzione delle connessioni persistenti. Con la diffusione delle
connessioni a banda larga tale esigenza si sente di meno, perché sono aumentate
le dimensioni dei contenuti delle pagine e i ritardi di TCP nell’inizio dei
trasferimenti si avverte di meno (fonte W3C).

La suite Network Simulator

L’argomento centrale di questo lavoro è fondamentalmente la simulazione
degli aspetti salienti di HTTP. Stiamo parlando di un protocollo di livello
applicazione che, come è noto, risulta essere il livello più alto della pila standard
de iure ISO/OSI od anche della pila TCP/IP, standard de facto. È dunque
necessario l’utilizzo di un ambiente informatico di lavoro in cui sia possibile
“mettere le mani” anche nei livelli più bassi della pila.
Nell'ambito della simulazione da effettuare, utilizzeremo il simulatore di reti
NS (Network Simulator) versione 2.
NS è un software scritto in C++. Lo scenario di una simulazione viene
definito da uno script OTcl, che è una versione object oriented di Tcl (Tool
Command Language). In breve, utilizzando il linguaggio Otcl si gestiscono delle
classi di oggetti, implementate in C++ e organizzate in maniera gerarchica, che
costituiscono la base del simulatore.
NS è nato nel 1989 come variante del simulatore REAL. Dello sviluppo di
NS si occupano i ricercatori del VINT Project (Virtual InterNetwork Testbed),
un progetto che vede la collaborazione di UC Berkeley, LBL, USC/ISI, e Xerox
PARC, e che è supportato da DARPA (Defense Advanced Research Projects
Agency) .
NS, a seconda di quanto viene specificato nello script Otcl di input, può
produrre in output diversi tipi di trace files, che possono a loro volta essere

6
forniti in input ai programmi xgraph e nam. I trace files contengono
informazioni che riguardano la topologia della rete (nodi e collegamenti), gli
eventi della simulazione, i pacchetti che hanno viaggiato nella rete.
Il nam è nato nel 1990. E' un Network Animator che legge un nam trace file
prodotto da NS e apre una finestra nella quale dà vita ad un'animazione della
simulazione: mostra la topologia della rete, i flussi di pacchetti, i pacchetti in
coda nei buffer e quelli dropped, i link che si guastano o che si aggiustano, e
così via; attraverso una comoda interfaccia utente è possibile controllare diversi
aspetti della simulazione come il re-layout della topologia.
Xgraph è un programma che disegna grafici bidimensionali: legge i trace
files prodotti da NS ed apre una finestra nella quale visualizza alcuni risultati
della simulazione (come ad esempio lo sfruttamento della banda nel tempo).
La scelta cade su tale suite per la sua natura modulare e per la possibilità di
andare a gestire fenomeni ed aspetti di una topologia di rete che non si fermino
prettamente al solo livello applicazione. Infatti prima di giungere, come
spiegheremo in seguito, alla connessione tra client-cache-server o a quella più
semplice client-server, bisognerà prima effettuare i vari link sui livelli inferiori
della pila, a partire da quello puramente fisico per modellare la tipologia di
linea, a quello ad esempio di trasporto, poiché TCP è il substrato necessario per
il funzionamento del protocollo HTTP.

Obiettivo della simulazione

La problematica che affronteremo riguarda il processo di caching,
particolarmente utilizzato nelle transazioni HTTP.
La topologia sarà la seguente: un server a cui sono collegati due client, uno
direttamente, l’altro mediante una cache. Nella simulazione si sceglierà una
cache che implementa un algoritmo di consistenza delle pagine di tipo TTL
(Time To Live).

7
 Eseguiremo una particolare simulazione, cercando di modellare alla meglio le
reali connessioni domestiche. I due client richiederanno un’unica pagina al
server a cui sono collegati, il Client 0 inoltrerà le richieste direttamente al
Server, il Client 1 invece consulterà la Cache. Quest’ultima si comporterà quindi
come server per il Client 1, con la differenza che la pagina verrà inviata
unicamente se ancora valida, in caso contrario il client dovrà attendere che la
Cache la “scarichi” dal Server, comportandosi quindi come client nei confronti
di quest’ultimo.
Almeno inizialmente i due client richiederanno al server lo stesso set di pagine
in maniera concorrente. In tal caso, bloccando variabili in gioco come
throughput dei link (entrambi PSTN, Public Switched Telephone Network),
istanti di richiesta, dimensioni della pagina, potremo così confrontare l’attività
dei due client con un solo grado di libertà: la presenza o meno della cache.
Le nostre osservazioni verteranno sul miglioramento delle prestazioni relative
ai tempi di servizio dei due client. Per tempi di servizio intendiamo
quell’intervallo di tempo che intercorre tra l’emissione del GET da parte dei due
client e la ricezione delle risorse richieste inviate dal Server.
Dunque ci aspetteremo una notevole differenza nei tempi di servizio dei due
client dovuta al caching attuato sul Client 1.
La topologia modellerà due collegamenti domestici verso un unico server.
Il caso in analisi prevede perciò che il trasferimento della pagina risulta avere
la maggior parte del “peso” del tempo di servizio. Pertanto tali link avranno una
banda di 56 Kb/s con un ritardo di 10 ms e un algoritmo di gestione delle code

8
di tipo drop tail. Infine il terzo link tra cache e client avrà una banda di 10 Mb/s
ed un ritardo di 10 ns.
La simulazione riguarderà il traffico generato dalla topologia indicata nell’arco
di 900 secondi (15 minuti) e la dimensione della pagina sul server sarà di 60
Kbytes.

Le classi NS utilizzate
Per mettere in pratica ciò che ci siamo prefissi di raggiungere abbiamo
utilizzato solo classi messe già a disposizione dal Network Simulator. Come
spiegato esse sono organizzate in maniera gerarchica. La parent class è la
Tcl/Object. Spostandoci nei suoi sottolivelli è stato possibile conoscere
un'interessante classe di oggetti NS: la classe Http, che a sua volta comprende

tre sottoclassi: Http/Client, Http/Server e Http/Cache.

A livello di trasporto gli oggetti Http si appoggiano, per default, su un Agent
di tipo Tcp. Gli Agents sono gli oggetti che nella simulazione rappresentano i
processi e/o le entità di trasporto che si trovano su host e router.
La classe Http/Client modella il comportamento
di un semplice browser web: genera una sequenza
di richieste di pagine web con intervallo casuale tra
una richiesta e un'altra e un identificatore di pagina
anch'esso casuale. Ad un client è permesso

connettersi ad una sola cache, ma esso può connettersi a più server.  Bisogna

indicare a un client quale sia il set di pagine disponibili:  esso è un oggetto

appartenente alla classe PagePool e può contenere una o più pagine ed oggetti;

nel caso di PagePool/Math, classe da noi utlizzata, c’è una sola pagina (main

page). Inoltre si deve settare per il client una variabile casuale che determini gli

intervalli di tempo tra una richiesta e l’altra.
9
 La classe Http/Server modella il comportamento di

un server HTTP.  Anche  con  questo  tipo di  oggetto

bisogna indicare a un server quale sia il set di pagine

disponibile (lo   stesso   indicato   al   client).  Quando

inizia la simulazione il server attende di ricevere richieste.
La classe Http/Cache modella il
comportamento di una semplice cache HTTP di
ampiezza infinita. In particolare instanziamo la
Cache di tipo TTL/Plain, questa sottoclasse di
TTL (Time To Live, algoritmo per la consistenza)
permette di scegliere il threshold (la soglia) di
vita delle pagine espresso in secondi.
Per completare l’excursus grafico, di seguito riportiamo la gerarchia delle
rimanenti classi che abbiamo utilizzato nel codice della simulazione:
PagePool/Math e RandomVariable/Constant e RandomVariable/Exponential:

I log-file prodotti dagli Agent Http hanno estensione .log e consistono di una
riga per ogni evento verificatosi nella simulazione.

CAMPI EVENTO
Time ObjectID Object Values
Object Type Event Type Values

- Time è l'istante in cui si è verificato l'evento descritto.

- ObjectID è un identificatore numerico.

10
 - Object Values è a sua volta costituito da più campi:
1. Object Type: è una lettera maiuscola che indica se l'oggetto che ha

generato l'evento è un client (lettera C), una cache (lettera  E), o un

server (lettera S).

2. Event Type: è una sigla che indica il tipo di evento.

3. Values: è un elenco di valori diverso per ogni evento.

Nell’ultima parte di questo testo riporteremo prima tre tabelle esplicative dei
più significativi eventi associati all’azione dei Client, della Cache e del Server.

Il Codice
# Tesina di Reti di Calcolatori
#
# Gruppo
# Antonio Cagnazzo
# Luca Coppola
# Andrea D'Amore
# Olindo Isabella
#
# Simulazione del protocollo HTTP con implementazione del caching
# ***************************************************************

# Instanziamo un oggetto simulatore

set ns [new Simulator]

# Instanziamo un oggetto che e' collegato al file "outhttp.nam"

set nf [open outhttp.nam w]

# Specifichiamo a $ns di tracciare tutto

$ns namtrace-all $nf

# Definiamo la topologia della rete

set clientnode0 [$ns node]
set clientnode1 [$ns node]
set cachenode [$ns node]
set servernode [$ns node]

# Definiamo le connessioni fisiche della rete: il Client 0 collegato

# direttamente al Server ed il Client 1 collegato al server tramite
# la Cache. La linea tra Client 0 e Server ha una velocita' di 56Kbit/sec
# per simulare un utilizzo domestico con modem PSTN mentre la linea
# tra Client 1 e Cache e' molto veloce per simulare una cache residente
# sul client stesso. La Cache e' collegata al server da un'altra linea
# "lenta" a 56Kbit/sec.
# I ritardi sulle linee sono scelti in accordo a questo principio

11
# di simulazione
$ns duplex-link $clientnode0 $servernode 56Kb 10ms DropTail
$ns duplex-link $clientnode1 $cachenode 10Mb 10ns DropTail
$ns duplex-link $cachenode $servernode 56Kb 10ms DropTail
# Il metodo rtproto calcola le strade all'inizio della simulazione
$ns rtproto Session

# Dichiariamo l'oggetto per il log dei segnali relativi al protocollo HTTP

set log [open "http.log" w]

# Dichiariamo la PGP (Page Generator Pool), la sorgente delle pagine.

# Questa e' una sorgente a pagina unica (main page)
set pgp [new PagePool/Math]

# Definiamo la grandezza della main page con una variabile casuale

# di tipo Constant per poter confrontare in maniera omogenea i risultati
# relativi ai due client.
# La dimensione della main page e' stata scelta maggiore del comune
# per simulare il trasferimento di piu' risorse. In alternativa si
# sarebbe potuta usare la classe PagePool/CompMath per ottenere
# gli embedded objects della main page ma abbiamo riscontrato qualche
# problema nella simulazione poiche' l'uso di un Http/Client/Compound
# permette il trasferimento dei soli compound objects e non della main
# page.
# L'effetto ai fini della simulazione e' comunque il medesimo ma preferiamo
# l'uso di una sola pagina in sorgente per maggiore semplicita' di lettura
# dei risultati
set tmps [new RandomVariable/Constant]
$tmps set val_ 61440 # 60Kbyte
$pgp ranvar-size $tmps

# Definiamo la durata della vita della main page, scaduta la quale il

# server genera una nuova pagina ed emette un opportuno segnale (MOD)
set tmpa [new RandomVariable/Constant]
$tmpa set val_ 100 # espressa in secondi
$pgp ranvar-age $tmpa

# Instanziamo il Server e gli colleghiamo la sorgente di pagine

# precedentemente definita, infine gli diciamo di scrivere i propri
# segnali HTTP nell'oggetto $log
set server [new Http/Server $ns $servernode]
$server set-page-generator $pgp
$server log $log

# Instanziamo la Cache di tipo TTL/Plain, questa sottoclasse di TTL

# (Time To Live,algoritmo per la consistenza) permette di scegliere
# il threshold (la soglia) di vita delle pagine, e le diciamo
# di scrivere i propri segnali su $log
set cache [new Http/Cache/TTL/Plain $ns $cachenode]
$cache set thresh_ 50 # espressa in secondi
$cache log $log

# Creiamo i due client attaccandoli ai relativi nodi, colleghiamo loro

# $pgp e tramite la variabile casuale di tipo costante $tmp impostiamo
# le richieste a 30 secondi. Come per gli altri oggetti di tipo Http
# indichiamo di scrivere i messaggi HTTP nell'oggetto $log
set client0 [new Http/Client $ns $clientnode0]
set client1 [new Http/Client $ns $clientnode1]
set tmp [new RandomVariable/Constant ]
$tmp set val_ 30
$client0 set-interval-generator $tmp
$client1 set-interval-generator $tmp
$client0 set-page-generator $pgp
$client1 set-page-generator $pgp

12
$client0 log $log
$client1 log $log

# Dichiariamo l'inizio e la fine della simulazione con le due

# procedure sotto indicate
set startTime 1
set finishTime 900
$ns at $startTime "inizio-connessioni"
$ns at $finishTime "fine-connessioni"

# Codice relativo alle procedure

proc inizio-connessioni { } {
global ns server cache client1 client2
$client0 connect $server
$client1 connect $cache
$cache connect $server
$client0 start-session $server $server
$client1 start-session $cache $server
}

proc fine-connessioni { } {
global ns log nf
$ns flush-trace
flush $log
close $log
close $nf
exit 0
}

# Inizio simulazione
$ns run

La simulazione
L’analisi del modello proposto viene condotta in 5 prove. Queste differiscono
nella curva di richiesta delle pagine da parte dei Client e in quella
dell’aggiornamento delle pagine sul Server. Il codice illustrato in precedenza,
utilizzato per la prima prova, rimane quindi sostanzialmente immutato per le
successive: le poche righe di codice da sostituire vengono indicate prima di ogni
prova.

Prova 1
- Frequenza di aggiornamento della pagina su Server costante pari a 100 s;
- frequenza delle richieste di Client 0 e Client 1 costante pari a 30 s;
13
 - soglia di aggiornamento della pagina su Cache pari a 50 s.
Dopo aver opportunamente lanciato la simulazione (comando: ns
http.tcl), l’elaboratore ci ha presentato, come previsto, due files di trace:
outhttp.nam e http.log. Grazie ad essi possiamo ora produrre le
prossime tre illustrazioni, di cui la prima è solo un fotogramma esplicativo
dell’animazione fornitaci dal network animator.

La topologia, così come appare nel layout del network animator.

Alcune azioni della Cache (IMS e HIT) e i tempi di servizio del Client 1 in
relazione al Tempo di simulazione.
14
Tempi di servizio del Client 0 e del Client 1 in relazione al Tempo di
simulazione.

15
 Come promesso in precedenza, ecco rappresentate le tabelle con ovvio significato degli
eventi e dei simboli:

CACHE
Significato
Tipo di Evento Valori
HIT p <pageID> La cache possiede già la pagina
c <clientID> <pageID> il cui proprietario è il
s <serverID> server <serverID>

MISS p <pageID> La cache non possiede la pagina

c <clientID> <pageID> e spedirà una richiesta
s <serverID> al server <serverID> per ottenerla
z <RequestSize>
IMS p <pageID> Una cache vuole sapere se la
c <clientID> pagina <pageID> è stata
s <serverID> modificata in quanto il suo timer-
z <RequestSize> vita nella cache è scaduto
t <CacheEntryTime>
SND p <pageID> Il server invia una risposta
m <LastModifiedTime>
z <Size>
t <RequestType>
UPD p <pageID> Aggiornamento di una pagina
c <clientID>
s <serverID>
m <LastModifiedTime>
z <PageSize>
s <serverID>
ENT p <pageID> Introduzione di una pagina nella
c <clientID> cache
s <serverID>
m <LastModifiedTime>
z <PageSize>
s <serverID> 

CLIENT
Significato
Tipo di Evento Valori
GET p <pageID> Il client richiede una pagina
s <PageServerID>
z <RequestTime>
STA p <pageID> Il client si è accorto all'istante l che
s <OrigServerID> la pagina ricevuta è uguale a quella
l <StaleTime> che aveva già

RCV p <pageID> Il client riceve una pagina

s <PageServerID>

16
 l <ResponseTime>
z <PageSize>

SERVER
Significato
Tipo di Evento Valori
SND p <pageID> Il server invia una risposta
m <LastModifiedTime>
z <Size>
t <RequestType>
UPD p <pageID> Il server invia alla cache un
m <LastModifiedTime> aggiornamento di una pagina
z <Size>
MOD p <pageID> Il server annuncia che la pagina è
m <LastModifiedTime> stata modificata

Infine ecco come si presenta il file http.log, qui riportato per una interpretazione
“dati alla mano” degli eventi che si sono succeduti nel corso della simulazione:

31 i 0 C GET p _o86:0 s 3 z 43
31 i 1 C GET p _o86:0 s 2 z 43
31.000162 i 2 E MISS p _o86:0 c 1 s 3 z 43
31.059 i 3 S MOD p _o86:0 m 31.059000000000001 n 131.059
40.529 i 0 C RCV p _o86:0 s 3 l 9.5290000000003161 z 61440
40.529162 i 2 E ENT p _o86:0 m 31.059000000000001 z 61440 s 3
40.529162 i 2 E SND c 1 p _o86:0 z 61440
40.582026 i 1 C RCV p _o86:0 s 2 l 9.5820264600002076 z 61440
61 i 0 C GET p _o86:0 s 3 z 43
61 i 1 C GET p _o86:0 s 2 z 43
61.000066 i 2 E HIT p _o86:0 c 1 s 3
61.000066 i 2 E SND c 1 p _o86:0 z 61440
61.05293 i 1 C RCV p _o86:0 s 2 l 0.052930439999890666 z 61440
70.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428574836 z 61440
91 i 0 C GET p _o86:0 s 3 z 43
91 i 1 C GET p _o86:0 s 2 z 43
91.000066 i 2 E IMS p _o86:0 c 1 s 3 z 50 t 40.529162430000319 m 31.059000000000001
91.022924 i 3 S SND p _o86:0 m 31.059000000000001 z 43 t IMS-NM
91.044781 i 2 E SND c 1 p _o86:0 z 61440
91.097645 i 1 C RCV p _o86:0 s 2 l 0.097644725714189917 z 61440
100.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428574836 z 61440
121 i 0 C GET p _o86:0 s 3 z 43
121 i 1 C GET p _o86:0 s 2 z 43
121.000066 i 2 E HIT p _o86:0 c 1 s 3
121.000066 i 2 E SND c 1 p _o86:0 z 61440
121.05293 i 1 C RCV p _o86:0 s 2 l 0.052930439999897771 z 61440
130.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428574978 z 61440
131.059 i 3 S MOD p _o86:0 m 131.059 n 231.059
151 i 0 C GET p _o86:0 s 3 z 43
151 i 1 C GET p _o86:0 s 2 z 43
151.000066 i 2 E IMS p _o86:0 c 1 s 3 z 50 t 91.044780695714294 m 31.059000000000001
151.022924 i 3 S SND p _o86:0 m 131.059 z 61440 t IMS-M
160.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428574978 z 61440
160.492924 i 2 E ENT p _o86:0 m 131.059 z 61440 s 3
160.492924 i 2 E SND c 1 p _o86:0 z 61440
160.545788 i 1 C RCV p _o86:0 s 2 l 9.545787582858992 z 61440
181 i 0 C GET p _o86:0 s 3 z 43
181 i 1 C GET p _o86:0 s 2 z 43
181.000066 i 2 E HIT p _o86:0 c 1 s 3
181.000066 i 2 E SND c 1 p _o86:0 z 61440
181.05293 i 1 C RCV p _o86:0 s 2 l 0.052930440001489387 z 61440
190.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428574978 z 61440
211 i 0 C GET p _o86:0 s 3 z 43
211 i 1 C GET p _o86:0 s 2 z 43

17
211.000066 i 2 E IMS p _o86:0 c 1 s 3 z 50 t 160.49292355285749 m 131.059
211.022924 i 3 S SND p _o86:0 m 131.059 z 43 t IMS-NM
211.044781 i 2 E SND c 1 p _o86:0 z 61440
211.097645 i 1 C RCV p _o86:0 s 2 l 0.097644725715753111 z 61440
220.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428574978 z 61440
231.059 i 3 S MOD p _o86:0 m 231.059 n 331.05899999999997
241 i 0 C GET p _o86:0 s 3 z 43
241 i 1 C GET p _o86:0 s 2 z 43
241.000066 i 2 E HIT p _o86:0 c 1 s 3
241.000066 i 2 E SND c 1 p _o86:0 z 61440
241.05293 i 1 C STA p _o86:0 s 3 l 9.9939304400014919
241.05293 i 1 C RCV p _o86:0 s 2 l 0.052930440001489387 z 61440
250.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428574978 z 61440
271 i 0 C GET p _o86:0 s 3 z 43
271 i 1 C GET p _o86:0 s 2 z 43
271.000066 i 2 E IMS p _o86:0 c 1 s 3 z 50 t 211.04478069571425 m 131.059
271.022924 i 3 S SND p _o86:0 m 231.059 z 61440 t IMS-M
280.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428574978 z 61440
280.492924 i 2 E ENT p _o86:0 m 231.059 z 61440 s 3
280.492924 i 2 E SND c 1 p _o86:0 z 61440
280.545788 i 1 C RCV p _o86:0 s 2 l 9.5457875828557803 z 61440
301 i 0 C GET p _o86:0 s 3 z 43
301 i 1 C GET p _o86:0 s 2 z 43
301.000066 i 2 E HIT p _o86:0 c 1 s 3
301.000066 i 2 E SND c 1 p _o86:0 z 61440
301.05293 i 1 C RCV p _o86:0 s 2 l 0.052930439998249312 z 61440
310.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428574978 z 61440
331 i 0 C GET p _o86:0 s 3 z 43
331 i 1 C GET p _o86:0 s 2 z 43
331.000066 i 2 E IMS p _o86:0 c 1 s 3 z 50 t 280.49292355285752 m 231.059
331.022924 i 3 S SND p _o86:0 m 231.059 z 43 t IMS-NM
331.044781 i 2 E SND c 1 p _o86:0 z 61440
331.059 i 3 S MOD p _o86:0 m 331.05899999999997 n 431.05899999999997
331.097645 i 1 C RCV p _o86:0 s 2 l 0.097644725712541458 z 61440
340.491857 i 0 C STA p _o86:0 s 3 l 9.4328571428575287
340.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428574978 z 61440
361 i 0 C GET p _o86:0 s 3 z 43
361 i 1 C GET p _o86:0 s 2 z 43
361.000066 i 2 E HIT p _o86:0 c 1 s 3
361.000066 i 2 E SND c 1 p _o86:0 z 61440
361.05293 i 1 C STA p _o86:0 s 3 l 29.99393043999828
361.05293 i 1 C RCV p _o86:0 s 2 l 0.052930439998249312 z 61440
370.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428574978 z 61440
391 i 0 C GET p _o86:0 s 3 z 43
391 i 1 C GET p _o86:0 s 2 z 43
391.000066 i 2 E IMS p _o86:0 c 1 s 3 z 50 t 331.04478069571428 m 231.059
391.022924 i 3 S SND p _o86:0 m 331.05899999999997 z 61440 t IMS-M
400.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428574978 z 61440
400.492924 i 2 E ENT p _o86:0 m 331.05899999999997 z 61440 s 3
400.492924 i 2 E SND c 1 p _o86:0 z 61440
400.545788 i 1 C RCV p _o86:0 s 2 l 9.5457875828557803 z 61440
421 i 0 C GET p _o86:0 s 3 z 43
421 i 1 C GET p _o86:0 s 2 z 43
421.000066 i 2 E HIT p _o86:0 c 1 s 3
421.000066 i 2 E SND c 1 p _o86:0 z 61440
421.05293 i 1 C RCV p _o86:0 s 2 l 0.052930439998249312 z 61440
430.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428574978 z 61440
431.059 i 3 S MOD p _o86:0 m 431.05899999999997 n 531.05899999999997
451 i 0 C GET p _o86:0 s 3 z 43
451 i 1 C GET p _o86:0 s 2 z 43
451.000066 i 2 E IMS p _o86:0 c 1 s 3 z 50 t 400.49292355285752 m 331.05899999999997
451.022924 i 3 S SND p _o86:0 m 431.05899999999997 z 61440 t IMS-M
460.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428574978 z 61440
460.492924 i 2 E ENT p _o86:0 m 431.05899999999997 z 61440 s 3
460.492924 i 2 E SND c 1 p _o86:0 z 61440
460.545788 i 1 C RCV p _o86:0 s 2 l 9.5457875828557803 z 61440
481 i 0 C GET p _o86:0 s 3 z 43
481 i 1 C GET p _o86:0 s 2 z 43
481.000066 i 2 E HIT p _o86:0 c 1 s 3
481.000066 i 2 E SND c 1 p _o86:0 z 61440
481.05293 i 1 C RCV p _o86:0 s 2 l 0.052930439998249312 z 61440
490.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428574978 z 61440
511 i 0 C GET p _o86:0 s 3 z 43
511 i 1 C GET p _o86:0 s 2 z 43
511.000066 i 2 E IMS p _o86:0 c 1 s 3 z 50 t 460.49292355285752 m 431.05899999999997
511.022924 i 3 S SND p _o86:0 m 431.05899999999997 z 43 t IMS-NM
511.044781 i 2 E SND c 1 p _o86:0 z 61440
511.097645 i 1 C RCV p _o86:0 s 2 l 0.097644725712541458 z 61440
520.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428573841 z 61440
531.059 i 3 S MOD p _o86:0 m 531.05899999999997 n 631.05899999999997

18
541 i 0 C GET p _o86:0 s 3 z 43
541 i 1 C GET p _o86:0 s 2 z 43
541.000066 i 2 E HIT p _o86:0 c 1 s 3
541.000066 i 2 E SND c 1 p _o86:0 z 61440
541.05293 i 1 C STA p _o86:0 s 3 l 9.9939304400048741
541.05293 i 1 C RCV p _o86:0 s 2 l 0.052930440004843149 z 61440
550.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428573841 z 61440
571 i 0 C GET p _o86:0 s 3 z 43
571 i 1 C GET p _o86:0 s 2 z 43
571.000066 i 2 E IMS p _o86:0 c 1 s 3 z 50 t 511.04478069571428 m 431.05899999999997
571.022924 i 3 S SND p _o86:0 m 531.05899999999997 z 61440 t IMS-M
580.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428573841 z 61440
580.492924 i 2 E ENT p _o86:0 m 531.05899999999997 z 61440 s 3
580.492924 i 2 E SND c 1 p _o86:0 z 61440
580.545788 i 1 C RCV p _o86:0 s 2 l 9.5457875828622036 z 61440
601 i 0 C GET p _o86:0 s 3 z 43
601 i 1 C GET p _o86:0 s 2 z 43
601.000066 i 2 E HIT p _o86:0 c 1 s 3
601.000066 i 2 E SND c 1 p _o86:0 z 61440
601.05293 i 1 C RCV p _o86:0 s 2 l 0.052930440004843149 z 61440
610.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428573841 z 61440
631 i 0 C GET p _o86:0 s 3 z 43
631 i 1 C GET p _o86:0 s 2 z 43
631.000066 i 2 E IMS p _o86:0 c 1 s 3 z 50 t 580.49292355285741 m 531.05899999999997
631.022924 i 3 S SND p _o86:0 m 531.05899999999997 z 43 t IMS-NM
631.044781 i 2 E SND c 1 p _o86:0 z 61440
631.059 i 3 S MOD p _o86:0 m 631.05899999999997 n 731.05899999999997
631.097645 i 1 C RCV p _o86:0 s 2 l 0.097644725719078451 z 61440
640.491857 i 0 C STA p _o86:0 s 3 l 9.4328571428574151
640.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428573841 z 61440
661 i 0 C GET p _o86:0 s 3 z 43
661 i 1 C GET p _o86:0 s 2 z 43
661.000066 i 2 E HIT p _o86:0 c 1 s 3
661.000066 i 2 E SND c 1 p _o86:0 z 61440
661.05293 i 1 C STA p _o86:0 s 3 l 29.993930440004874
661.05293 i 1 C RCV p _o86:0 s 2 l 0.052930440004843149 z 61440
670.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428573841 z 61440
691 i 0 C GET p _o86:0 s 3 z 43
691 i 1 C GET p _o86:0 s 2 z 43
691.000066 i 2 E IMS p _o86:0 c 1 s 3 z 50 t 631.04478069571428 m 531.05899999999997
691.022924 i 3 S SND p _o86:0 m 631.05899999999997 z 61440 t IMS-M
700.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428573841 z 61440
700.492924 i 2 E ENT p _o86:0 m 631.05899999999997 z 61440 s 3
700.492924 i 2 E SND c 1 p _o86:0 z 61440
700.545788 i 1 C RCV p _o86:0 s 2 l 9.5457875828622036 z 61440
721 i 0 C GET p _o86:0 s 3 z 43
721 i 1 C GET p _o86:0 s 2 z 43
721.000066 i 2 E HIT p _o86:0 c 1 s 3
721.000066 i 2 E SND c 1 p _o86:0 z 61440
721.05293 i 1 C RCV p _o86:0 s 2 l 0.052930440004843149 z 61440
730.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428573841 z 61440
731.059 i 3 S MOD p _o86:0 m 731.05899999999997 n 831.05899999999997
751 i 0 C GET p _o86:0 s 3 z 43
751 i 1 C GET p _o86:0 s 2 z 43
751.000066 i 2 E IMS p _o86:0 c 1 s 3 z 50 t 700.49292355285741 m 631.05899999999997
751.022924 i 3 S SND p _o86:0 m 731.05899999999997 z 61440 t IMS-M
760.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428573841 z 61440
760.492924 i 2 E ENT p _o86:0 m 731.05899999999997 z 61440 s 3
760.492924 i 2 E SND c 1 p _o86:0 z 61440
760.545788 i 1 C RCV p _o86:0 s 2 l 9.5457875828622036 z 61440
781 i 0 C GET p _o86:0 s 3 z 43
781 i 1 C GET p _o86:0 s 2 z 43
781.000066 i 2 E HIT p _o86:0 c 1 s 3
781.000066 i 2 E SND c 1 p _o86:0 z 61440
781.05293 i 1 C RCV p _o86:0 s 2 l 0.052930440004843149 z 61440
790.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428573841 z 61440
811 i 0 C GET p _o86:0 s 3 z 43
811 i 1 C GET p _o86:0 s 2 z 43
811.000066 i 2 E IMS p _o86:0 c 1 s 3 z 50 t 760.49292355285741 m 731.05899999999997
811.022924 i 3 S SND p _o86:0 m 731.05899999999997 z 43 t IMS-NM
811.044781 i 2 E SND c 1 p _o86:0 z 61440
811.097645 i 1 C RCV p _o86:0 s 2 l 0.097644725719078451 z 61440
820.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428573841 z 61440
831.059 i 3 S MOD p _o86:0 m 831.05899999999997 n 931.05899999999997
841 i 0 C GET p _o86:0 s 3 z 43
841 i 1 C GET p _o86:0 s 2 z 43
841.000066 i 2 E HIT p _o86:0 c 1 s 3
841.000066 i 2 E SND c 1 p _o86:0 z 61440
841.05293 i 1 C STA p _o86:0 s 3 l 9.9939304400048741
841.05293 i 1 C RCV p _o86:0 s 2 l 0.052930440004843149 z 61440

19
850.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428573841 z 61440
871 i 0 C GET p _o86:0 s 3 z 43
871 i 1 C GET p _o86:0 s 2 z 43
871.000066 i 2 E IMS p _o86:0 c 1 s 3 z 50 t 811.04478069571428 m 731.05899999999997
871.022924 i 3 S SND p _o86:0 m 831.05899999999997 z 61440 t IMS-M
880.491857 i 0 C RCV p _o86:0 s 3 l 9.4918571428573841 z 61440
880.492924 i 2 E ENT p _o86:0 m 831.05899999999997 z 61440 s 3
880.492924 i 2 E SND c 1 p _o86:0 z 61440
880.545788 i 1 C RCV p _o86:0 s 2 l 9.5457875828622036 z 61440

La prova condotta illustra il caso poco usuale in cui richieste e aggiornamenti

delle pagine avvengono con frequenza costante mentre entrambi i client
richiedono la stessa pagina contemporaneamente. Tale caso fornirà un raffronto
con le prove via via più simili alla realtà.
Il Client 0 viene servito (RCV) 29 volte su 29 richieste (GET) con un tempo
medio di servizio pari a 9,4931 secondi mentre i tempi di servizio delle richieste
sono pressoché identici.
Il Client 1 trova 20 volte la pagina in cache (HIT + IMS in cui la pagina sul
Server non è cambiata) e per 9 volte deve attendere che il Server spedisca la
pagina aggiornata in Cache (ENT). Il primo aggiornamento avviene
successivamente alla prima richiesta poiché la Cache risulta vuota. Il tempo
medio di servizio è 3,0094 secondi mentre gli aggiornamenti danno luogo ad
istanze del caso peggiore pari al tempo di servizio del Client 0 maggiorato di
qualche centesimo di secondo per il trasferimento cache-client della pagina.
Da questa analisi qualitativa possiamo affermare che il caching limita
efficacemente il traffico HTTP verso il Server e contemporaneamente aumenta
la rapidità di fruizione delle risorse conservate in Cache. È necessario tuttavia
che la frequenza di aggiornamento delle risorse sia inferiore alla frequenza delle
richieste.

Prova 2
- Frequenza di aggiornamento della pagina su Server casuale modellata
secondo la curva esponenziale attorno alla media di 100 s;
- frequenza delle richieste di Client 0 e Client 1 costante pari a 30 s;

20
 - soglia di aggiornamento della pagina su Cache pari a 50 s;
La frequenza di aggiornamento viene modellata secondo un’esponenziale per
prendere in esame tempi di aggiornamento variabili, gli altri parametri
rimangono invariati.
Il Client 0 viene servito (RCV) 29 volte su 29 richieste (GET) con un tempo
medio di servizio immutato rispetto alla prima prova.
Il Client 1 trova 24 volte la pagina in cache, mentre la cache viene aggiornata 5
volte. Il tempo medio di servizio diminuisce in questa particolare prova a 1,7063
secondi. Tale diminuzione è dovuta alla distribuzione degli aggiornamenti della
pagina lungo l’asse dei tempi, infatti benché questa sia aggiornata 8 volte (MOD)
gli aggiornamenti sono disposti in maniera tale che più d’uno di questi capiti
nell’intervallo tra due richieste del Client 1. Verrà fornita allora solo la pagina
più recente.

Prova 3
- Frequenza di aggiornamento della pagina su Server casuale modellata
secondo la curva esponenziale attorno alla media di 100 s;
- frequenza delle richieste di Client 0 e Client 1 costante pari a 9 s;
- soglia di aggiornamento della pagina su Cache pari a 50 s.
Questo caso di prova esemplifica una situazione critica: la richiesta delle
pagine avviene con frequenza costante pari a 9 secondi, quindi con tempi
inferiori a quelli di servizio medi per il Client 0 e a quelli del worst case per il
Client 1 nella precedente prova (ca. 9,5 secondi in entrambi i casi).
Il Client 0 viene servito (RCV) 49 volte su 49 richieste (GET) con un tempo
medio di servizio immutato rispetto alla prima prova.
Il Client 1 trova 82 volte la pagina in cache, mentre la cache viene aggiornata 8
volte. Il tempo medio di servizio si riduce quindi ulteriormente a 0,8918
secondi.
La differenza tra il numero di richieste dei due client dipende dal fatto che il
21
Client 0 non inoltra tutte le richieste specificate nel codice. L’oggetto della
classe Http/Client è infatti implementato in modo che non effettui un’ulteriore
richiesta allo stesso server se questo è già impegnato in una risposta. Le richieste
così accumulate vengono scartate.
Il numero di richieste effettuate e poi eventualmente servite rispetto a quelle
previste è quindi un indice del traffico sulle linee. In questo caso il collegamento
Client 0 - Server sarà interessato da un traffico che impegnerà il canale per poco
più della metà del tempo, ma solo la metà delle richieste previste sarà effettuata
e andrà a buon fine.

Aumentando ancora la frequenza delle richieste, la situazione che interessa il

Client 0 permane e si estende in parte anche al Client 1. Infatti con una
frequenza di 7 richieste al secondo e quindi su 128 richieste previste, il Client 0
ne effettua 64 mentre il Client 1 ottiene indietro una pagina 121 volte.

Prova 4
- Frequenza di aggiornamento della pagina su Server casuale modellata
secondo la curva esponenziale attorno alla media di 100 s;
- frequenza delle richieste di Client 0 e Client 1 casuale modellata secondo la
curva esponenziale attorno alla media di 30 s;
- soglia di aggiornamento della pagina su Cache pari a 50 s.
In questa prova e nella successiva anche i tempi di richiesta vengono scelti
mediante una funzione pseudocasuale su una curva di andamento esponenziale
negativo. Questo accorgimento fa si che possano verificarsi i due casi critici:
l'aggiornamento rapido delle pagine e l'avvicendamento rapido delle richieste.
Inoltre i due client inoltreranno quantità di richieste non necessariamente uguali
in istanti differenti.
Il Client 0 riesce ad effettuare 24 richieste e in 23 casi riceve la pagina con la
solita media dei tempi di servizio; nell’ultimo caso la simulazione termina prima

22
del completo trasferimento di questa.
Il Client 1 effettua 25 richieste e in 6 casi sono necessari aggiornamenti della
pagina in cache. La media dei tempi di servizio per il Client 1 é di 0,6057
secondi.

Prova 5
- Frequenza di aggiornamento della pagina su Server casuale modellata
secondo la curva esponenziale attorno alla media di 100 s;
- frequenza delle richieste di Client 0 e Client 1 casuale modellata secondo la
curva esponenziale attorno alla media di 9 s;
- soglia di aggiornamento della pagina su Cache pari a 50 s.
Il caso critico di una richiesta in media ogni 9 secondi presenta risvolti
differenti rispetto a quelli della Prova 3:
Il Client 0 riesce ad effettuare 42 richieste - laddove a grandi linee ne sarebbero
previste 91- con la solita media dei tempi di servizio.
Il Client 1 effettua 91 richieste e in 7 casi sono necessari aggiornamenti della
pagina in cache. La media dei tempi di servizio per il Client 1 è di 1 secondo.

Aumentando la frequenza delle richieste a 7 secondi di media, il Client 1

effettua 114 richieste contro le previste 128, rendendosi così meno
efficiente che nel caso ideale discusso nella Prova 3 con la stessa
frequenza di richieste. La diminuzione delle prestazioni dipende dal fatto
che entrambi gli eventi sono stati scelti sulla curva esponenziale, come
previsto nella precedente prova.

23
 Conclusioni
Benché l’analisi sia stata condotta in maniera qualitativa, anche scegliendo
eventi distribuiti secondo una curva esponenziale è possibile riscontrare i
vantaggi dell’utilizzo del caching. Tali vantaggi si concretizzano sia nella
maggiore rapidità dei tempi di servizio ovvero nel numero di richieste servite,
sia nell’effettiva diminuzione del traffico verso il server.

24