Laboratorio del corso Progettazione di Servizi Web e Reti di Calcolatori Politecnico di Torino AA Prof. Antonio Lioy

Transcript

1 Laboratorio del corso Progettazione di Servizi Web e Reti di Calcolatori Politecnico di Torino AA Prof. Antonio Lioy Soluzioni dell esercitazione n. 2 a cura di Giacomo Costantini 19 marzo 2014 Indice Esercizio Esercizio Esercizio Esercizio Esercizio Esercizio

2 Esercizio 2.1 Attivare wireshark sull interfaccia di rete Ethernet (es. eth0, Local Area Network). Senza aprire altre applicazioni, catturare i pacchetti per qualche istante (ad esempio 1 minuto), quindi interrompere la cattura. Memorizzare i pacchetti catturati sul file prova.pcapng. Qual è la dimensione di tale file? Soluzione: Dopo 1 minuto di cattura la dimensione del file è dell ordine di qualche kb. È normale che anche in assenza di interazioni con il web da parte dell utente, ritroviamo molti pacchetti di rete. Questi pacchetti sono infatti tipicamente o messaggi di broadcast all interno della rete, oppure pacchetti generati dai programmi residenti nel computer, ecc. (Fig. 1) Figura 1: Esempio di cattura. Aprire in wireshark il file prova.pcapng ed eseguire i seguenti punti: 1. stimare approssimativamente il numero di pacchetti per secondo catturati nella precedente acquisizione; Soluzione: Per calcolare il numero di pacchetti per secondo catturati è sufficientemente dividere il numero di pacchetti, visualizzabile in wireshark nella barra in basso (Fig. 2), per il numero di secondi di cattura. Figura 2: Visualizzazione numero di pacchetti. 2. identificare se vi sono pacchetti UDP o TCP presenti. 2

3 Soluzione: Per verificare la presenza di messaggi UDP o TCP è sufficiente impostare nel filtro di visualizzazione a di Wireshark i comandi tcp per filtrare i tcp e udp per filtrare gli udp (Fig. 3). Eventualmente è anche possibile creare un filtro in cui si vedano entrambe le tipologie scrivendo tcp udp. Nota bene: come vediamo in Fig. 3, nella colonna protocol è visualizzabile solo il protocollo più in alto dello stack ISO/OSI relativo pacchetto interessato, per cui è possibile che ci siano pacchetti con valori non corrispondenti ad esempio a UDP pur utilizzando quel protocollo di livello 4. Quello che però notiamo è che nella seconda suddivisione della finestra è presente l intero stack ISO/OSI, in cui ogni riga corrisponde a un protocollo a partire dal livello 1 in su. Il pacchetto n.25 in Figura 3 a conferma di quanto detto presenta il protocollo UDP a livello 4 e NBNS a livello 7. In particolare NBNS sta per NetBios Name Service ed ha una funzione molto simile al DNS: traduce nomi human-readable in indirizzi IP; i servizi offerti da NBNS sono più limitati poichè il name space non è gerarchico come nel DNS, inoltre sopporta solo IPv4 e non IPv6. a Vedere slide n.17 del documento Figura 3: Esempio di filtraggio di messaggi UDP. Esercizio 2.2 Si vogliono analizzare i pacchetti DNS scambiati durante la risoluzione del nome A tal fine si segua la seguente procedura e si risponda alle domande proposte. Aprire wireshark, predisporlo alla cattura dei pacchetti DNS (specificando l interfaccia di rete) ed avviare la cattura dei pacchetti. Attraverso l applicativo nslookup eseguire la query richiesta. Fermare la cattura dei pacchetti e rispondere alle seguenti domande: 1. Quali protocolli della pila TCP/IP, partendo dal livello data-link, sono stati impiegati? Soluzione: Come detto precedentemente, per ogni pacchetto è possibile visualizzare i vari protocolli utilizzati nello stack ISO/OSI, semplicemente guardando nella seconda suddivisione della finestra principale. Pertanto, come possiamo vedere in Figura 4, i protocolli in questo caso sono Ethernet, IPv4, UDP e DNS. 3

4 Figura 4: Esempio di stack TCP/IP a partire dal livello Data Link. 2. Quali porte del protocollo di trasporto sono state usate? Il loro identificativo nelle prove in laboratorio, è fisso o variabile? Il loro identificativo è, in generale, necessariamente fisso/variabile (cioè, quanto riscontrato in laboratorio, è una regola sempre vera)? Soluzione: Innanzitutto dalla colonna Info, con la dicitura query e query response è possibile dedurre chi sia il client e chi il server nelle colonne Source e Destination. Una volta identificati, analizzando ad esempio i vari messaggi di query (Fig. 5) è possibile notare come la porta usata dal DNS Server sia sempre uguale e sia la porta numero 53. Per quanto riguarda la porta del client invece si nota come cambia ad ogni richiesta DNS ed è sempre superiore a Questo avviene perché il DNS Server deve sempre essere in ascolto di richieste DNS, per cui rimane in attesa sulla porta nota 53 a (porta privilegiata), lato client invece è sufficiente usare come porta mittente una qualsiasi porta utente (da 1024 a 65535) che sia libera, dunque ne viene assegnata una in automatico dal sistema operativo. Infatti non è necessario che il DNS Server conosca a priori l indirizzo e porta del Client, semplicemente accetta tutte le richieste, purché siano destinate alla porta 53/udp. a Vedere slide n.2 del documento Figura 5: Esempio di porte usate in una query DNS. 4

5 3. E possibile identificare la query richiesta al server DNS? In caso affermativo compilare i seguenti campi: Soluzione: è possibile identificare il pacchetto come query DNS dalla colonna Info, mentre aprendo la riga dello stack protocollare del protocollo DNS ed esaminando il contenuto della tendina Queries sono visualizzabili i campi richiesti (Fig. 7): a) Name: b) Type: A c) Class: IN Nello specifico il valore di tipo A sta ad indicare la richiesta di un indirizzo IPv4, mentre il valore di classe IN sta ad indicare il dominio Internet. Figura 6: Esempio di pacchetto di DNS query, con relativi campi di interesse. 4. E possibile identificare la risposta del DNS? In caso affermativo compilare i seguenti campi per un indirizzo IP a scelta tra quelli presenti della risposta: Soluzione: Come prima è possibile identificare il pacchetto come query response dalla colonna Info, mentre aprendo la riga dello stack protocollare del protocollo DNS ed esaminando il contenuto della tendina Answers sono visualizzabili i campi richiesti (Fig. 7): a) Name: b) Type: A c) Class: IN d) Addr: Per identificare più precisamente il traffico DNS è possibile definire un filtro per la visualizzazione? Soluzione: Per visualizzare il traffico DNS è sufficientemente scrivere dns come filtro di visualizzazione, o alternativamente udp.port==53 poiché abbiamo visto che si tratta della porta standard dei Server DNS (Fig. 8). Se volessimo invece impostare un filtro di intercettazione a per i messaggi DNS, l unico modo è scrivere udp port 53 nelle opzioni di interfaccia prima di cominciare la cattura. a Vedere slide n.12 del documento 5

6 Figura 7: Esempio di pacchetto DNS response, con relativi campi di interesse. Figura 8: Esempio di applicazione del filtro di visualizzazione sui soli pacchetti DNS. Esercizio 2.3 Si vogliono analizzare i protocolli coinvolti durante il trasferimento di una risorsa web. A tal fine si segua la seguente procedura e si risponda alle domande. Aprire l applicazione wireshark, predisporla alla cattura dei pacchetti (specificando l interfaccia di rete) ed avviare la cattura dei pacchetti. Usando l applicativo wget, scaricare il file al seguente indirizzo: lioy/01nbe/lab2/test1k.dat Soluzione: Innanzitutto occorre aprire il terminale e, se non è già stato installato wget, spostarsi (con il comando cd) nella cartella in cui è presente l applicativo wget. Dopodiché è sufficiente digitare: wget lioy/01nbe/lab2/test1k.dat 6

7 1. Quali protocolli della pila TCP/IP sono coinvolti nel trasferimento di questo file? Soluzione: Come visto in precedenza, è piuttosto semplice ricavare i protocolli usati per l invio di un pacchetto, e il risultato in questo caso è Ethernet, IPv4, TCP e HTTP. Riuscite ad identificare: 2. Le fasi di handshake del protocollo TCP? 3. le fasi di chiusura del protocollo TCP? Soluzione: La procedura di handshake del protocollo TCP prevede lo scambio tra Client e Server dei messaggi [SYN] [SYN, ACK] e [ACK] (Fig. 9, punto 2). La procedura di chiusura, come visto a lezione, prevederebbe lo scambio di messaggi [FIN, ACK], [FIN, ACK] e [ACK] tra Client e Server, ma come possiamo riscontrare questi messaggi sono sostituiti da un unico messaggio [RST,ACK] (Fig. 9, punto 3). Questo messaggio fa parte delle recenti implementazioni di TCP, e sta a significare che il Client sta facendo l Ackowledge di qualsiasi dato è stato inviato nel pacchetto precedente nella sequenza, e allo stesso tempo invia il flag Reset, che permette di chiudere immediatamente la connessione. Infatti il flag RST indica che il ricevente dovrebbe interrompere la connessione senza ulteriori interazioni con il mittente. Il ricevente può determinare se accettare la proposta o ignorarla in base al SN e all ACK del messaggio entrante. Figura 9: Esempio di handshake e chiusura di una connessione TCP. 4. Per ciascun pacchetto appartenente a queste fasi, riportate i valori dei vari flag TCP ed annotate il tempo trascorso in millisecondi tra i pacchetti appartenenti a ciascuna fase. Soluzione: Per visualizzare il tempo trascorso tra un pacchetto e l altro è sufficiente guardare la colonna Time, mentre per ogni pacchetto è possibile vedere i vari flag del TCP espandendo la tendina Flag. In questo modo si può verificare che in ogni pacchetto è posto a 1 solo il/i flag corrispondenti al ruolo nelle fasi di handshake-chiusura (Fig. 10). Esercizio 2.4 Si vuole analizzare il throughput del protocollo TCP durante il download di file con diverse dimensioni. Usando wget, scaricare i file proposti (URL base lab2/ seguita dal nome del file) e rispondere alle domande. 6. Eseguire il download del file test1k.dat e rilevare i seguenti dati: 7

8 Figura 10: Esempio di istante di tempo e flag in un pacchetto TCP. Soluzione: Al fine di visualizzare i byte trasferiti, il tempo richiesto per il download e il throughput medio, è sufficiente osservare i valori restituiti nel terminale usando il comando wget (Fig. 11). E da notare che in questo caso, scaricando il file da 1kB, il tempo medio non viene calcolato, per via del fatto che il tempo trascorso per lo scaricamento del file è inferiore a 1 s, cosa che non avviene per lo scaricamento di file più grandi come quello da 10MB. a. byte trasferiti: 1024 b. tempo richiesto per il download: 0 s c. throughput medio:.- kb/s Figura 11: Informazioni ricavabili dal prompt dei comandi eseguendo wget. 7. Eseguire il download del file test10k.dat e rilevare i seguenti dati: Soluzione: a. byte trasferiti: b. tempo richiesto per il download: 0.06 s c. throughput medio:.- kb/s 8. Eseguire il download del file test100k.dat e rilevare i seguenti dati: Soluzione: a. byte trasferiti: b. tempo richiesto per il download: 0.3 s c. throughput medio: 398 kb/s 8

9 9. Eseguire il download del file test1m.dat e rilevare i seguenti dati: Soluzione: a. byte trasferiti: b. tempo richiesto per il download: 1.9 s c. throughput medio: 544 kb/s 10. Eseguire il download del file test10m.dat e rilevare i seguenti dati: Soluzione: a. byte trasferiti: b. tempo richiesto per il download: 21 s c. throughput medio: 386 kb/s 11. Il throughput medio varia all aumentare delle dimensioni della risorsa? In caso affermativo spiegare per quale ragione. Soluzione: Dai 100k in poi possiamo riuscire a valutare l andamento del throughput medio, che però aumenta solo tra 100k e 1M, per poi diminuire da 1M a 10M. Nel secondo caso diminuisce probabilmente perché la finestra di trasmissione, tipica del TCP, è in grado di aumentare di dimensione solo fino a un certo valore massimo. Nel caso di 1M il valore viene raggiunto quasi alla fine della ricezione dell intero file, mentre nell ultimo trasferimento, poichè più lungo, tale valore massimo viene tenuto per gran parte del tempo senza più crescere, causando un throughput inferiore rispetto al caso di 1M. Altra motivazione possibile del calo del throughput potrebbe anche essere un effettivo stato di congestione della rete; in tal caso il client, che rileva questo stato, decide di decrementare la dimensione della finestra di trasmissione per tentare di risolvere il problema. Esercizio 2.5 Si vuole analizzare (mediante l utilizzo di un grafico) l andamento della TCP window durante il download di risorse con dimensioni diverse. Considerando gli stessi file proposti nell esercizio precedente, si segua la procedura proposta qui sotto per ciascun file: 1. usando gli applicativi wget e wireshark, si proceda alla cattura del traffico TCP relativo al download di un file a scelta; 2. salvare il traffico catturato in un file esterno; 3. personalizzare la finestra di visualizzazione aggiungendo una colonna separata che contenga il valore della TCP window; 4. esportare i pacchetti catturati nel formato CSV; 5. usando Excel, importare i dati dal formato CSV e costruire il grafico (in ascissa impostare il tempo o il numero del pacchetto, in ordinata impostare il valore della TCP window). Per inserire una nuova colonna in wireshark si segua la procedura: 1. dal menù di wireshark, selezionare Edit > Preferences > Columns; 2. aggiungere una nuova colonna specificando come Field Type il valore Custom; 3. Come Field Name impostare il valore tcp.window size. Infine rispondere alle seguenti domande: per ciascuna risorsa qual è la dimensione minima e massima della TCP window? 9

10 Soluzione: Importante: prima di esportare il file CSV selezionare, attraverso il filtro di selezione, i soli pacchetti inviati dal client al server, questo perché la dimensione della finestra TCP lato server è tipicamente fissa, mentre lato client può aumentare e diminuire a seconda del traffico che il client è in grado di ricevere di volta in volta. Per fare questo dunque è sufficiente scrivere il comando ip.src==<ip interfaccia PC>, come mostrato in Figura 12. Come valori della finestra TCP consideriamo i soli valori del trasferimento, ossia dopo l HTTP GET: dimensione minima e dimensione massima Figura 12: Filtraggio dei soli pacchetti inviati dal Client verso il Server. Spiegare il diverso andamento della TCP window per risorse con dimensioni diverse. Soluzione: Eseguendo i grafici per ogni dimensione del file si ottengono i risultati nelle Figure Il caso del file di 1 kb ovviamente non è considerato poiché viene trasmesso un solo pacchetto. Negli altri casi la finestra viene decrementata ogni qualvolta vengano persi dei pacchetti, che determina uno stato di congestione della rete, per venire reimpostate al valore massimo (65536) non appena si ritorna da questo stato. Nel caso del file da 10 kb, la dimensione della finestra rimane costante perchè il trasferimento è talmente breve che la probabilità di perdita di pacchetti è quasi nulla. Nei trasferimenti di dimensione più grande (e quindi più duraturi) invece tale probabilità aumenta e vi si aggiungono i problemi di condivisione dinamica della banda. Figura 13: numero di pacchetto - dimensione finestra TCP nello scaricamento del file 10k. Esercizio 2.6 Usando l applicativo Jperf si vuole analizzare l andamento del throughput per il protocollo UDP. A tal fine si segua la procedura proposta e si risponda alle domande. 10

11 Figura 14: numero di pacchetto - dimensione finestra TCP nello scaricamento del file 100k. Figura 15: numero di pacchetto - dimensione finestra TCP nello scaricamento del file 1M. Figura 16: numero di pacchetto - dimensione finestra TCP nello scaricamento del file 10M. Formare una coppia con un vostro compagno, in modo da avere due macchine a disposizione, diciamo computer A e computer B. Configurare Jperf sul computer A in modalità server e su computer B in modalità client, specificando per entrambi il protocollo UDP. Per il nodo in modalità client è necessario innanzitutto impostare l indirizzo IP del server Jperf. Soluzione: Impostare il Server come in Figura 17 ed il Client come in Figura 18. Durante l esercizio i parametri sul server non dovranno essere modificati, mentre sul client saranno da modificare di volta in volta la banda e/o il numero di stream paralleli. 11

12 Figura 17: (server) impostare mode:server e proto:udp. Figura 18: (client) impostare mode:client, proto:udp, indirizzo Server: l altro PC della coppia. Soluzione: Per rilevare il throughput e la percentuale di pacchetti persi è sufficiente guardare nella finestra di output del client, poiché il server, finito il trasferimento, segnala il throughput medio e la percentuale di pacchetti persi al client (Fig. 19). Dal client effettuare i seguenti test: 1. Impostare la banda a 1 Mbps ed il numero di stream paralleli a 1, svolgere il test e rilevare: 12

13 Figura 19: Output della console del client JPerf. Soluzione: a. throughput: 1000 kbit/s b. percentuale di pacchetti persi: 0% 2. Impostare la banda a 5 Mbps ed il numero di stream paralleli a 1, svolgere il test e rilevare: Soluzione: a. throughput: 5000 kbit/s b. percentuale di pacchetti persi: 0% 3. Impostare la banda a 5 Mbps ed il numero di stream paralleli a 5. Come varia il throughput rispetto al caso precedente? Ci sono pacchetti persi? Soluzione: a. throughput: 4816 kbit/s b. percentuale di pacchetti persi: 0.15% Vediamo che quando ci sono flussi paralleli di dati tipicamente il throughput si abbassa, infatti ci sarà un sistema di scheduling per gestire la concorrenza dei messaggi UDP. Inoltre questo sovraccarico di messaggi rende più facile la perdita di datagrammi. 4. Impostare la banda a 10 Mbps ed il numero di stream paralleli a 1, svolgere il test e rilevare: Soluzione: a. throughput: 9928 kbit/s b. percentuale di pacchetti persi: 0.047% 5. Impostare la banda a 10 Mbps ed il numero di stream paralleli a 5. Come varia il throughput rispetto al caso precedente? Ci sono pacchetti persi? Soluzione: a. throughput: 8347 kbit/s b. percentuale di pacchetti persi: 0.028% Vediamo che quando ci sono flussi paralleli di dati tipicamente il throughput si abbassa, infatti ci sarà un sistema di scheduling per gestire la concorrenza dei messaggi UDP. 13

14 6. Il throughput del protocollo UDP è superiore a quello del protocollo TCP? In caso affermativo, motivare la risposta. Soluzione: Come dimostrato da questo esercizio il throughput UDP è maggiore a quello del protocollo TCP, questo è dovuto all assenza in UDP di molti controlli come quelli di flusso e perdita dei dati, che sono invece implementati in TCP. Questo permette al protocollo UDP prestazioni migliori in caso di canali con poche perdite, potendo inviare il traffico sempre alla massima velocità possibile, e per questo motivo è ancora molto utilizzato. 14