Risposte Prima verifica - a.a. 2010-2011

Prima parte

• 1- Troviamo 3 intestazioni, per la precisione l'intestazione ethernet inserita dallo strato di collegamento, quella di rete inserita dallo strato IP, e quella di trasporto inserita da tcp o udp
• 2 - la cache ARP è una memoria utilizzata dallo strato di collegamento per memorizzarare le associazioni tra indirizzi ethernet ed indirizzi IP appresi durante il funzionamento dell'apparato, ed ha lo scopo di ridurre il traffico generato, non dovendo ripetere sempre le stesse domande
  
• 3 - viene inoltrato tramite l'interfaccia eth1, in quanto è quella a cui corrisponde la riga della tabella per cui sussiste la corrispondenza più lunga per la parte  prefisso dell'indirizzo di destinazione
• 4 - i pacchetti che possono essere consegnati sono solo quelli di risposta a precedenti pacchetti  in uscita dal nat, perché per questi il nat ha già memorizzato la porta effimera usata all'interno della lan, che ha sostituito con una propria nel pacchetto uscente, e che permette di reimpostare l'indirizzo interno corrretto per quello entrante.
• 5 - il controllo di flusso consiste nella possibilità per l'entità ricevente di regolare l'intensità del traffico prodotto dalla relativa sorgente. Si realizza mediante la comunicazione da parte del ricevente di una dimensioine di finestra variabile, che viene impostata poi presso il mittente, in modo da variare la quantità di bytes che possono essere trasmessi prima di iniziare a ricevere riscontri.
  
• 6 - la accept() è usata da una applicazione con ruolo di server tcp, allo scopo di dar corso ad una richiesta di conessione sopraggiunta da parte di un client.
• 7 - viene detta bloccante in quanto l'applicazione che la invoca non ri-ottiene il controllo finché non sopraggiunge una nuova connessione, lasciando quindi la CPU libera di eseguire altri compiti
  
• 8 - deve armare il segnale, comunicando al kernel l'indirizzo della subroutine di callback che deve essere eseguita a seguto della ricezione del segnale
  
• 9 - concerne la modalità di rappresentazione degli interi nel contesto della architettura di calcolo a disposizione, ovvero se questi sono memorizzati ponendo per primi i byte meno significativi (little endian) o più significativi (big endian). 
• 10 - Dato che gli indirizzi posti nei pacchetti sono scritti in modalità big endian, il loro ordine deve essere alterato nel caso in cui l'architettura li disponga in modo diverso

Seconda parte

• 11 - Come riscontrabile mediante la linguetta IP del menù Statistics/Conversation, ci sono 4 computer in comunicazione tra loro, e precisamente il 192.168.120.40 che dialoga con gli altri tre, ossia 82.211.81.208, 66.102.11.103 e 192.168.120.1
• 12 - dei quattro di cui sopra solo due si trovano nella LAN, dato che (usando ancora la statistica sulle conversation) si individuano solo due conversazioni Ethernet, la cui corrispondenza gli indirizzi IP può essere scoperta al pacchetto 236, che contiene una richiesta ARP. Notiamo che questultima non è diretta in broadcast, ma in unicast, quindi evidentemente chi la pone conosce già la corrispondenza, e vuole solo sincerarsi che sia ancora la stessa.
• 13 - Il DG ha indirizzo 00:16:6f:54:3b:a5, verificabile in base alla richiesta ARP di cui sopra, e dal fatto che dei due PS nella LAN, 102.168.120.40 è il client delle connessioni con l'eterno, ed i suoi pacchetti uscenti recano 00:16:6f:54:3b:a5 come ind. ethernet di destinazione
• 14 - come osservabile adottando un filtro di visualizzazione uguale a DNS, si richiede la risoluzione di www.ubuntu-it.org e di www.google-analytics.com
• 15 - usando il menù Statistics/HTTP/Requests si trova che sono indirizzate 35 richieste HTTP verso www.ubuntu-it.org
• 16 - sono state effettuate un totale di 4 connessioni TCP, come evidenziato dal menù Statistics/conversations
• 17-  l'espressione del display filter è tcp.flags.syn == 1, ottenibile individuando un pacchetto con SYN=1, aprendo l'header TCP, posizionandosi sul flag SYN, e richiedendo "Apply as a filter" dal menù contestuale attivabile con il tasto destro
• 18 - il SYN della seconda connessione si trova al pacchetto 18. Lo trovo grazie al display filter di cui sopra
• 19 - l'espressione del display filter è tcp.stream eq 2. La trovo mediante l'opzione "follow tcp stream" del menù contestuale
• 20 - la visualizzazione si ottiene impostando una serie di filtri del tipo del precedente. Conviene impostare un Tick interval = 0.1 sec e le unità dell'asse Y in bits/sec. Dalla disposizione temporale si nota che i flussi sono concorrenti, e l'intensità totale di traffico è la somma dei quattro. Notiamo poi che lo stream 3, dopo il traffico iniziale, produce ancora qualcosa verso la fine; l'1 ed il due limitano il traffico ai primi due secondi, ed il 4 produce traffico solo attorno al 18esimo secondo
  

Terza parte

• 21 - io uso zenmap che ci mette un pò, ma salva i risultati, e ne permette una analisi accurata
• 22 - 192.168.100.1 ha 19 servizi aperti; il 100.2 e 100.3 ne hanno 14, 100.2 ne ha 13, 100.156 ne ha 10, 100.138 ne ha 9, 1.4 ne ha 8. Per tentare di connettermi provo ad usare telnet IP porta; alcuni servizi rispondono con una stringa di benvenuto.
  
• 23 - sudo netstat --tcp --udp -l. Sono in ascolto delle porte TCP 111, 8080, 22, 631, 25, 60361, 17500; e delle porte UDP 50591, 38964, 68, 69, 17500, 611, 111, 5353
  
• 24 - si osserva una velocità di 8.51 Mbps
• 25 - nella finestra di IOGraph si possono impostare i filtri tcp.dstport==5001 (usato dal server) e tcp.dstport==47930 (usata dal client): ciò permette di constatare come il traffico sia diretto dal client verso il server, e quello nell'altro verso sia costituito dai soli ACK del TCP.
• 26 - il nuovo valore di velocità riportato dal lato client è di 84.1 Kbits/sec. Per tentare un analisi relativa a ciò che è avvenuto, confronto i risultati dei due capture: senza limiti e con limiti.
• Dal report Statistics/Summary osservo che si passa da 577 a 13 pacchetti/sec, con dimensioni medie 1965 e 763 bytes/pacchetto nei casi senza e con.
• Le trame Ethernet di dimensioni superiori ai 1500 bytes sono dette jumbo frame, ed evidentemente il mio computer le ha adottate nel tentativo di aumentare il più possibile la velocità: esaminando il capture del caso senza, si osserva che in corrispondenza delle trame jumbo il server risponde con una serie di ACK con numeri di sequenza che si incrementano di soli 1500 bytes, evidenziando che comunque nel tragitto questi pacchetti hanno subito frammentazione.
• nel caso senza, oltre a trovare un ritmo di segnalazione molto più elevato, osserviamo che la finestra annuciata dal server raggiunge la dimensione di  64096 dopo 63 msec, in corrispondenza del pacchetto 40, e la mantiene fino al pacchetto 144 (187 msec) dopodiché questa viene ancora incrementata fino a 84000 raggiunto al pacchetto 153 e mantentuto fino al 1020 (1.68 sec), dopodichè la dimensione di finestra aumenta ancora, raggiungendo 121632 bytes, e poi al pacchetto 3636 (6.39 sec) la finestra torna ad aumentare raggiungendo i 147712 bytes, valore mantenuto fino alla fine.
• La RFC 1323 definisce l'uso di una opzione di window scale presente nella intestazione TCP del pacchetto SYN, che modifica l'interpretazione del campo finestra, aggiungendo uno shift a sinistra che di fatto ne amplifica la dinamica dei valori.