Esercizio 1...
Esercizio 2...
La prima cosa che dobbiamo fare è calcolare il ritardo di propagazione.
Per farlo utilizziamo la formula:
Nel contesto di scambio di richieste tra client e server abbiamo definito l'RTT, ovvero il tempo che impiega un pacchetto per propagarsi verso il server e tornare indietro.
RTT quindi percorre 300 km di andate e 300 km di ritorno. Dunque lo spazio che ci serve per calcolare il tempo che si impiega per un RTT è
Quando non è specificato il mezzo, supponiamo che si tratti di rame.
La velocità di propagazione nel rame è di
Applichiamo la formula:
Sappiamo che TCP necessita di stabilire la connessione all'inizio (handshake a tre vie).
Quello che si vede in figura è ciò che avviene.
Le prime tre frecce fanno parte dell'handshake a tre vie, la prima è una richiesta di associazione, la seconda è una conferma, la terza è una conferma di aver ricevuto conferma, insieme a questo pacchetto viene spedita anche la richiesta del dato. Nell'ultima linea viene spedito il dato.
Sappiamo che gli oggetti da trasferire sono 9:
- 1 pagina html da 1000 byte (H)
- 8 immagini da 25 kbyte (O)
Calcoliamo quanto impiega il router a trasmettere tali oggetti:
Connessione persistente...
Nel caso di una connessione persistente abbiamo:
- un RTT di handshake (
- 1/2 RTT che trasporta la richiesta + 1/2 RTT che trasporta la risposta, il che vuol dire che abbiamo un RTT totale a cui dobbiamo sommare il tempo per trasmettere la risposta che è una volta
Il problema dice che possiamo trascurare i messaggi di controllo di HTTP, quindi possiamo ignorare il tempo per trasmettere una GET.
Connessione non persistente...
Nel caso di una connessione non persistente abbiamo:
- un RTT di handshake (
- 1/2 RTT che trasporta la richiesta + 1/2 RTT che trasporta la risposta, il che vuol dire che abbiamo un RTT totale a cui dobbiamo sommare il tempo per trasmettere la risposta che è una volta
Il problema dice che possiamo trascurare anche i pacchetti di chiusura della connessione TCP.
Esercizio 3...
Domanda a...
La URL richiesta è: home.deib.polimi.it/cesana/index.html
Domanda b...
La versione di HTTP usata è 1.1
Domanda c...
Il browser richiede una connessione persistente (connection: keep alive)
Domanda d...
Serve per personalizzare il tipo di risposta verso il browser che la richiede. (Esempio: in questo modo il server sa se il browser richiedente è uno smartphone e dunque se necessita della versione mobile del sito)
Esercizio 4...
Il numero di oggetti che abbiamo in totale è 11:
- 1 html
- 10 altri
la dimensione di ciascun oggetto è di
Il collegamento client-server è in grado di trasferire a capacità di
La dimensione del pacchetto per l'apertura della connessione è uguale a quella del pacchetto per richiedere i dati che è di
Dobbiamo calcolare il tempo totale per ricevere la l'intera pagina web nei seguenti casi:
a) il client https apre in parallelo in modalità non persistente tutte le connessioni TCP necessarie, in tal caso si assuma che il data rate di ciascuna connessione TCP sia
Il client richiede la pagina web, una volta ricevuta scopre di dover scaricare altri 10 oggetti.
Per scaricare il file html:
L'espressione è uguale alla precedente:
Adesso:
a) il client https apre un'unica connessione TCP persistente per scaricare tutti gli oggetti...
Viene aperta una sola connessione TCP, utilizzando i risultati già calcolati prima, per richiedere gli oggetti:
c) Il client apre 11 connessioni in serie non persistenti...
Questa volta verranno inviate 11 richieste diverse. Ogni connessione TCP viene chiusa.
Esercizio 5...
Scrivi soluzione, vedi tablet
Esercizio 6...
Quando il testo degli esercizi afferma pacchetti di controllo TCP e GET di lunghezza trascurabile intende che il pacchetto è come se venisse trasferito all'istante. Tuttavia va applicato comunque ad esso il tempo di propagazione (RTT).
Soluzione...
Il client sta già occupando la banda con altri 9 trasferimenti (di lunga durata), aggiungendo il nuovo trasferimento abbiamo che la banda viene equamente suddivisa tra 10 connessioni.
Quindi abbiamo:
Connessione TCP persistente...
Per stabilire la connessione TCP il client invia il primo ACK (che si propaga per
Gli RTT totali per stabilire la connessione e ricevere il primo oggetto (HTML) sono 2, visto che le GET e gli ACK sono trascurabili, al questo tempo dobbiamo aggiungere solo il tempo per trasmettere il documento HTML.
Connessione TCP non persistente aprendo connessioni in parallelo...
La connessione TCP viene stabilita allo stesso identico modo di prima.
Quindi per ricevere il file HTML passano
A questo punto (dopo aver ricevuto il file HTML) la connessione TCP è stata chiusa, quindi occorre riaprirla. Tuttavia, a questo punto, allocando 11 connessioni TCP parallele la banda per ciascun trasferimento cambia, prima avevamo 10 trasferimenti paralleli, adesso ne abbiamo 9 (quelli dati dal testo, di lunga durata) + 11 di quelli che vengono creati adesso, in totale 20. Abbiamo per ogni trasferimento che:
Il tempo per ricevere l'oggetto è:
Esercizio 6...
Soluzione...
- I record di risorsa presenti in questo scenario sono: NS, A, CNAME e MX.
- A quello locale, che se non ce l'ha inoltra la richiesta ad un altro server DNS remoto
- Nel server DNS autoritativo
- 142.81.17.206
- 2
- (dns.enterprise.com, 146.54.245.111, A)
- A
- MX
Esercizio 7...
Soluzione...
- Un'architettura P2P centralizzata mantiene in un sistema centrale gli indirizzi dei peer che partecipano ad un certo trasferimento di file. Nel contesto di BitTorrent i tracker svolgono questo ruolo. Nel contesto di Napster vi era un vero e proprio database in cui erano indicizzati gli utenti registrati al servizio e i file che rendevano disponibili al download.
- Guardando l'immagine, l'host A richiede al server centralizzato il nome del file che vuole scaricare. Il server risponde con una lista di IP in cui è possibile reperire tale file, in questo caso D è l'unico host a possedere tale file. Allora l'host A, invia una richiesta all'host D per il file in questione. Viene stabilita la connessione TCP e il file viene trasferito.
Esercizio 8...
Soluzione...
Caso 1...
Il client A effettua la richiesta:
GET / HTTP/1.1
Host: www.unito.it
Connection: close
User-agent: Mozzilla/5.0
Accept-language: it
La richiesta giunge al proxy, il proxy non ha in locale la pagina richiesta, si verifica cache miss.
Il proxy inoltra la richiesta al server. Il server risponde:
HTTP/1.1 200 OK
Connection: close
Date: ...
Server: ...
Last-Modified: ...
Content-length: ...
Content-type: text/html
(data data data data data …)
Il proxy salva la pagina (per successive richieste) e inoltra la risposta al client.
Caso 2...
Il client A effettua la richiesta:
GET / HTTP/1.1
Host: www.unito.it
Connection: close
User-agent: Mozzilla/5.0
Accept-language: it
La richiesta giunge al proxy, il proxy ha in locale la pagina richiesta, si verifica cache hit.
Il proxy inoltra la risposta (della pagina che ha in cache):
HTTP/1.1 200 OK
Connection: close
Date: ...
Server: ...
Last-Modified: ...
Content-length: ...
Content-type: text/html
(data data data data data …)
Il proxy potrebbe inviare anche una richiesta HTTP if-modified-since per capire se il documento che possiede già è stato modificato, e in tal caso richiedere la nuova versione del documento.
Caso 3...
Il client A effettua la richiesta:
GET / HTTP/1.1
Host: www.unito.it
Connection: close
User-agent: Mozzilla/5.0
Accept-language: it
La richiesta giunge direttamente al server a cui la richiesta è destinata.
Il server inoltra la risposta (della pagina che ha in cache):
HTTP/1.1 200 OK
Connection: close
Date: ...
Server: ...
Last-Modified: ...
Content-length: ...
Content-type: text/html
(data data data data data …)
Esercizio 9...
Soluzione...
- Si (200 OK), ed è stato fornito il 7 marzo 2008 alle 12:39:45GMT (nell'header Date)
- Il 10 dicembre 2005 alle 18:27:46GMT
- 3874
- <!doc
- Si (Connection: Keep-Alive)
Fine esercizi forniti a lezione...
Esercizi con ordine casuale dal libro di testo (edizione 7)...
R4...
No, in un'applicazione P2P tipicamente il server invia file, mentre i client li ricevono.
Inoltre, un host potrebbe comportarsi sia da client che da server.
P1...
a) falso
b) vero
c) falso
d) falso
e) falso
P7...
A cui dovrebbe essere sommato il tempo per trasmettere la richiesta HTTP.
E il tempo per la trasmissione delle query DNS.
P24...
- a) Si, in SR il mittente riceve ACK selettivi. Immaginiamo una finestra di dimensione 3. Il mittene invia 3 pacchetti: 1, 2 e 3. Il destinatario invia gli ACK. Il timer del mittente scade e il mittente rispedisce i pacchetti 1, 2 e 3. Il destinatario li riceve e invia nuovamente gli ACK. Ad un certo punto al mittente arrivano i primi 3 ACK inviati dal destinatario, fa avanzare la finestra a 4, 5 e 6. E dopo un po' arrivano i secondi ACK inviati dal destinatario (che sono fuori dalla finestra).
- b) Si, in GBN il mittente riceve ACK per i pacchetti che sono giunti con successo a destinazione, facendo avanzare la finestra. Può succedere che il pacchetto successivo ad una consegna riuscita venga smarrito, in tal caso il mittente GBN riceverebbe ACK per l'ultimo pacchetto ricevuto con successo.
- c) Si
- d) Si
R14...
- a) Falso, B invierà ACK
- b) Falso, la finestra di ricezione è dinamica dipende dallo spazio libero in un certo momento nel buffer
- c) Vero
- d) Falso, il numero di sequenza di un segmento da inviare dipende dal numero di ACK ricevuto
- e) Vero
- f) Falso
- g) Vero