| che cosa è la tecnica del Delayed Acknoledgement? | è una tecnica utilizzata per risolvere il problema della Silly Window Syndrome.
consiste nell'attentedre un tempo (max 200ms) prefissato prima di rispondere.
questo per fare in modo che eventuali dati che in questo tempo arrivano sul buffer di spedizione dell'ack potranno essere raggruppati e inviati insieme all’ack. |
| come si fanno a fare comunicare due processi? | i due processi hanno bisogno di due porte, una per ciascuno. per ottenere le porte i processi utilizzano una primitiva di sistema socke(),
la tupla che determina univocamente una trasmissione (socket) è data da:
- porta sorgente
- porta destinazione
- ip sorgente
- ip destinazione
- protocol selector |
| come fa un processo a conoscere l'indirizzo del suo destinatario? | tramite un servizio di livello 7 DNS che data un servizio ritorna l'ip del destinatario |
| quali sono le varie fasi del protocollo tcp? | - apertura di una connessione
- data transfer attraverso un canale bidirezionale con una affidabilità garantita sul byte stream
- chiusura della connessione con il four way handshake |
| quali sono i vari flag presenti nello header TCP? | SYN: per aprire la connessione
ACK : segmenti che portano un segmento di acknoledge
FIN: per chiudere la connessione
PSH: i byte di quel segmento dovrebbero uscire il più velocemente possibile dalle code(come urg ma per sequenze di byte)
URG: il campo urgent va preso in considerazione
RST: per resettare la connessione |
| come funziona la fase di apertura di connessione TCP? | è un meccanismo di negoziazione a 3 vie
- viene inviato un messaggio sequence [syn, seq = x]
- risposta con un messaggio [syn, ack, seq = y, ack = x+1]
(la connessione per il richiedente è ESTABLISHED)
- risposta di recezione dell'ack [ack, seq = x+1, ack = y+1]
(la connessione per il ricevente è ESTABLILSHED) |
| in quale modo viene utilizzato il campo window size nello header TCP durante una trasmissione? | il campo window size viene utilizzata dal ricettore per segnalare al trasmettitore la dimensione del buffer di ricezione che al momento è disponibile, questa viene segnalata con ogni messaggio di ACK.
una volta che il buffer è pieno, verrà segnalato al trasmettitore che smetterà di inviare dati, una volta liberato il buffer, un nuovo messaggio ACK di validazione dell'ultimo messaggio ricevuto verrà nuovamente inviato ma con il window size aggiornato al nuovo spazio libero del buffer |
| nell'ambito della trasmissione TCP, se viene perso il messaggio di windows update, (e il trasmettitore rimane in wait) come viene risolto? | viene introdotto un timer nel trasmettitore, una volta che scaduto il timer il ricevitore non ha ottenuto un messaggio di windows update, invia un messaggio probe che fa reinviare il messaggio windows update |
| a che cosa serve il keep alive timer? | è un timer che viene fatto partire dal server quando si aspetta che il client trasmetti dei nuovi messaggi[generalmente è settato a 2h].
se il timer scade il server invia un PROBE [nuovo timer 75s].
se la trasmissione è stata troncata allora dopo 10[75s] PROBE il server chiuderà la connessione |
| come utilizza l'ACK il protocollo TCP? | si comporta con un ack cumulativo con politica selective repeat, dove ogni messaggio di ACK segnala l'ultima finestra ricevuta nella giusta sequenza.
una volta ricevuto il messaggio mancante tutti i messaggi sul buffer vengono validati |
| a cosa serve il meccanismo fast retransmit? | vuole anticipare la ritrasmissione di una sequenza errata prima che scada il timer di retransmission time out.
il recettore dopo la recezione di tre messaggi di ACK fuori sequenza, interpreta ciò come un retransmission time out e anticipa la ritrasmissione dei messaggi fuori sequenza |
| perchè viene utilizzato il fast retransmit? | perchè generalmente è difficile dimensionare il timer in modo che questo sia valido in una dimensione di rete qualsiasi, in più questo dovrebbe tenere conto della dimensione del buffer di ricezione. per questo un fast retransmit consente di restare indipendenti da queste variabili, basandosi solamente sui messaggi di ack |
| cosa succede quando si ha un trasmettitore lento e un ricevitore molto veloce? (es tastiera e computer) | viene utilizzato la politica/algoritmo NAGLE:
il lato ricevitore ha un timer di piggybacking che consente di aspettare prima di inviare diversi messaggi di ack per un solo messaggio ricevuto.
i pacchetti da inviare possono subire clumping(se devo inviare a b c separati vengono inviati assieme) |
| nel caso in cui il trasmettitore è veloce e il ricevitore è lento che soluzione si utilizza? | il problema è che da parte del ricevitore vengono inviati tanti messaggi di windows update.
viene utilizzata la politica CLARK
Il ricevitore aspetta a mandare il segnale di window upd. per un tempo pari al minimo fra [0.5 del buffer di recezione e la maximum segment size] |
| come viene dimensionata la finestra di trasmissione in TCP? | fase di slow start: il trasmettitore trasmette un messaggio, ad ogni ack ricevuto la finestra viene raddoppiata fino ad avere raggiunto la dimensione di 32
fase di congestion avoidance: la window size viene incrementata ogni volta di 1 fino a raggiungere la maximum window size
fase di regressione: una volta che viene rilevata una congestione della rete la treshold della slow start viene dimezzata(verso un multiplo di 2) e ricomincia la procedura di crescita della finestra da 1 |
| quali tipi di errore possono essere rilevati con la crescita della window size? | errore di retransmission time out RTO: la finestra riparte dalla dimensione di 1 mentre viene abbassata la slow start threshold fino alla metà(più vicina ad un multiplo di 2)
errore di fast retransmit: quando il ricevitore segmenti fuori sequenza l'errore probabilmente indica la mancanza di pochi segmenti, quindi l'errore risulta lieve.
in questo caso la finestra viene dimezzata e si ricomincia con una crescita lineare |
| quali sono i valori di RTO di una connessione TCP appena inizializzata? | siccome non ci sono valori storici per quella connessione viene stabilito un valore di default di 3 secondi,
il secondo segmento viaggia con un tempo pari a 3 volte quello misurato dal primo |
| come viene calcolato il RTT round trip time? | a x RTT + (1-a) x M
a generalmente si assume 0.9 |
| in quale caso viene usata la politica KARN? | viene utilizzata in fase di riformulazione del RTT nel caso scadesse il timer di recezione dell'ACK, in tal caso si rischierebbe di sovradimensionare o sottodimensionare il nuovo timer il nuovo RTO sarà 2 volte il precedente |
| quale altra opzione esiste per TCP per il managing del tempo? | in ogni pacchetto inviato c'è un campo time stamp per la negoziazione del timer
- il trasmettitore scrive il proprio tempo nel time stamp del primo messaggio
- il trasmettitore per la politica secondo la quale l'ack viene mandato dopo un tot di messaggi, trasmete altri messaggi
- il ricevitore trasmette un ack cumulativo di uno specifico messaggio
- il trasmettitore una volta ricevuto l'ack è in grado di ricavare il RTT dello specifico messaggio e utilizzarlo per il RTT |
| come avviene la chiusura di una connessione TCP? | - il trasmettitore invia un messaggio [fin = 1, seq = x]
- il ricevitore risponde con un ack [ack = 1, ack = x+1]
- quando il ricevitore sarà anche lui pronto a finire la connessione invierà un messaggio [fin = 1, seq = y]
- il trasmettitore invia un ack [fin = 1, seq = y+1] |
| che cosa cambia nello header da TCP a UDP? | checksum opzionale in UDP
flag di controllo mancanti in UDP
data offset, reserved e flags non presenti in UDP
campo option assente |
| quale è la differenza fra http1 http2 e http3? | http3 a differenza dei precedenti utilizza il protocollo QUIC che consente di suddividere la connessioni in diversi stream... |
| quale è il ruolo del keep alive timer in una connessione TCP? | Il keep alive timer è un timer utilizzato in una connessione TCP per verificare che l'altra parte sia ancora connessa. Se il timer scade, il mittente invia un pacchetto vuoto, detto keep alive packet, all'altra parte. Se l'altra parte riceve il pacchetto, invia un pacchetto di ritorno, detto keep alive ack. Se il mittente non riceve un keep alive ack, può presumere che l'altra parte non sia più connessa e può chiudere la connessione.
generalmente il Keep Alive Timer è settato per un tempo compreso fra 30 sec e 2 minuti |
| in che cosa consiste la Silly Window Syndrome?
quali sono le possibili soluzioni? | Un processo di scrittura molto lento da parte del mittente nel buffer di trasmissione (o di
lettura da parte del ricevente) porta infatti all'invio di segmenti di dati molto piccoli, aumentando così il rapporto tra header e dati con un conseguente uso inefficiente del canale.
le soluzioni sono :
- Delayed Acknoledgement
- Algoritmo Nagle
- Algoritmo Clark |
| che cosa è la tecnica del Delayed Acknoledgement? | è una tecnica utilizzata per risolvere il problema della Silly Window Syndrome.
consiste nel fare attendere il server un tempo prefissato dopo la ricezione del dato, in questo modo gli eventuali dati che in questo tempo arrivano sul buffer di invio del mittente potranno essere raggruppati e inviati insieme all’ack del dato precedente correttamente ricevuto. |
| che cosa è l'algoritmo Nagle? | è una possibile soluzione al problema della Silly Window Syndrome,
il problema che cerca di risolvere è rappresentato da un produttore lento.
l'algoritmo consente al trasmettitore di poter aggregare più frame per poi poter ricevere un solo ack |
| a che cosa serve e che cosa prevede l'algoritmo Clark? | soluzione alla Silly Window Syndrome, in particolare quando si verifica che il ricevitore è lento e libera poco spazio di memoria buffer alla volta.
ritarda la spedizione del window update finchè il buffer del ricevitore
ha spazio libero pari a MSS
oppure quando il bufffer di ricezione si è liberato per metò |
| che cosa è il timer di KAM e a che cosa serve ? | il problema che risolve: se un segmento viene perso subito all’inizio, i calcoli di RTO non sono affidabili, stesso vale se RTO scada prima che arrivi l’ack per colpa della rete congestionata o altro.
Studiato e testato da Kam (non vengono date ulteriori spiegazioni a lezione) viene introdotto il timer RTOnew = 2*RTOold |
| quali tipi di chiusura di connessione consente il protocollo TCP? | - chiusura normale
-> Client manda un messaggio con bit FIN = 1 al server
-> Server riceve EOF ed effettua close validando il client
-> Server manda al client un segmento FIN = 1
-> Client valida con ACK il FIN del server
-> Client attende un timer dopo la ricevuta del FIN cosicchè se l’ack mandato dal client è stato perso un altro FIN arrivi al client dal server
- simultaneus close: Avviene quando si parla di peer to peer:
-> Entrambi gli attori mandano FIN
-> Entrambi mandano ACK per il FIN ricevuto
-> Entrambi attendono per essere sicuri che l’ack arrivi
- half close: caso client finisce la trasmissione ma il server deve ancora trasmettere
-> dopo invio della FIN del client essa viene validata dal Server
-> prima di chiudere, il server aspetta che tutti i pacchetti pendenti siano inviati
-> Al termine viene effettuata la chiusura attiva della parte destra (FIN)
-> Client valida con ACK la chiusura del server- |
| Come funziona l'opzione Time-Stamp su una connessione TCP in cui si suppone che il ricevente restituisca un ACK ad ogni segmento dati ricevuto? | L'opzione di time stamp è stata introdotta per aiutare TCP a calcolare il ritardo sulla rete (nel nostro caso RTT). Si tratta di un header aggiuntivo che utilizza il trasmettitore
per scrivere al suo interno l'orario nel quale è stato mandato un segmento. Il ricevitore, mandando l'ack relativo, risponderà facendo riferimento a quel time stamp, in modo
tale che il trasmettitore possa calcolare il Round Trip Time senza possibili ambiguità e capire quanto tempo è passato dal momento in cui è stato inviato il segmento.
E' molto utile in caso di finestre di trasmissione molto grandi (maggiori di 2^32). |
| L'attuale finestra di congestione (CW) TCP è pari a 16KB, MSS di 1KB e SST pari a 32KB. Stabilire i nuovi valori di SST e CW nell'ipotesi di ricevere un retransmission timeout. | CW = 16 KByte
MSS = 1 KByte
SST (Slow start threshold) = 32 KByte
Allora, in caso di RTO la SST diventa esattamente la metà dell'attuale flight size. Quindi SST = 8 Kbyte
La congestion window invece diventa MSS quindi 1 Kbyte: questo perché se scade RTO significa che la rete è molto congestionata (in quanto non arrivano neanche i 3 ACK
del fast retransmit). |
| Come descrivereste lo schema di ritrasmissione di TCP facendo riferimento a Go-bach-n e Selective Repeat. Analogie e differenze. | TCP in caso di ritrasmissione di segmenti persi si comporta come selective repeat in quanto utilizza buffer in lato ricezione che permette di memorizzare segmenti fuori sequenza.
In lato trasmissione invece è presente la politica di selective ack che si comporta similmente a selective repeat e permette di specificare quali segmenti sono arrivati al ricevitore, e quali invece devono ancora essere mandati.
Per quanto riguarda invece go back n, si comporta come questa politica in quanto usa ack cumulativi al posto di quelli selettivi. |
| Descrivere la natura out-of-band di FTP e come questa viene implementata su TCP. | Perché utilizza due connessioni separate per trasferire un file, una per il controllo e una per i dati.
Sono comunque due connessioni TCP che utilizzano la porta 20 e la porta 21 per il lato server. |
| Descrivere il Fast Retransmit di TCP e il suo comportamento in caso di errore. | Nel caso di fast retransmit il trasmettitore riceva 3 ACK fuori sequenza trasmette immediatamente il segmento indicato dal ricevitore.
E' stato introdotto in quanto il Retransmission Timeout è un periodo di tempo effettivamente troppo elevato, e quindi abbiamo bisogno di mandare il segmento che era stato perduto il prima possibile. |
| perchè è stato introdotto il fast retransmit? | E' stato introdotto in quanto il Retransmission Timeout è un periodo di tempo effettivamente troppo elevato, e quindi abbiamo bisogno di mandare il segmento che era stato perduto il prima possibile. |
| Una connessione TCP produce un segmento di dimensioni 2500 Byte. Descrivere i frammenti (con i relativi campi significativi) generati dal livello IP sottostante se la reti di transito é una LAN ethernet. | La lan ethernet ha dimensione massima di frame 1500Byte. Le token ring 4000Byte.
20 Byte della frame sono per l'header.
Il resto (1500-20) dev'essere divisibile per 8.
Campo payload = 1500-20 = 1480 che è divisibile per 8, quindi ok. E' uno dei due frammenti. Campo offset = 0 in quanto è il primo frammento
Campo payload = 2500 - 1480 = 1020
Campo offset (mi dice che non sto partendo dal byte iniziale ma da questo byte qui) = 1480 / 8 = 185 |
| Perché un sistema NAT genera una propria numerazione di porta TCP diversa da quella generata dalla stazione interna, sorgente del traffico ? | Perché due client potrebbero avere una stessa numerazione di porta, pur essendo su sistemi differenti. Se non usassimo una numerazione di porta interna al NAT e ci ritrovassimo un messaggio che dev'essere spedito su una porta 2500 in comune sia a una macchina A che ad una macchina B, non sapremmo a quale delle due macchine mandare quel messaggio. |
| L˙attuale finestra di congestione (CW) TCP é pari a 36KB, MSS di 1KB e SST di 32KB. Stabilire i nuovi valori di SST e CW nella ipotesi di aver ricevuto il terzo ACK duplicato. | La Slow Start Threshold viene portata a Flight Size / 2 quindi 18KB.
La congestion window invece viene portata a SST, quindi 18KB. |
| Una connessione TCP produce un segmento di dimensione 5000 Byte. Descrivere i frammenti (con i relativi campi significativi) generati dal livello IP sottostante se la rete di transito è una LAN Token Ring con dimensione massima di frame 4000 Byte. | Dimensione del segmento 5000 byte.
Rete di transito Token Ring (dimensione massima delle frame è 4000 byte).
Ho 20 byte di header.
1˚ Frammento:
Payload = 3980 non divisibile per 8 => payload = 3976
Offset = 0
2˚ Frammento:
Payload = 5000 - 3976 = 1024
Offset = 497 |
| In TCP è definita l˙opzione Selective-ACK. Questo è stato fatto perché la tecnica di ritrasmissione di default è Go-bach-n? | In teoria di default vengono utilizzati ack cumulativi, quindi tcp in ritrasmissione si comporta come go-back-n, ma è possibile negoziare in apertura della connessione TCP l'utilizzo di selective-ack che permette a tcp di comportarsi come selective repeat anche in questo ambito. |
| Descrivere la tecnica iterativa di risoluzione di un nome in DNS e dare una valida ragione per preferirla a quella ricorsiva. | E' preferibile in quanto il carico di lavoro viene distribuito solamente sulla macchina che ha fatto la richiesta di name resolution. |
| Sia data una connessione TCP con applicazione interattiva lato trasmissione che produce 10 Byte ogni 5 msec. Se la trasmissione avviene su un link da 100Kbps e 100msec di ritardo di propagazione, dimensionare i primi 2 segmenti inviati sulla connessione ipotizzando l˙uso dell˙algoritmo di Nagle. | Il primo segmento include 20B header TCP e 10B dati.
Viene trasmesso in Tx = (30 x 8) / 100000b = 2.4 msec.
Lo ack è ricevuto a sorgente dopo Tx + 2 Tp = 2.4 + 2 x 100 = 202.4 msec. In questo tempo la sorgente ha accumulato 202.4/ 5 = 40.48 caratteri. // da completare
Il secondo segmento comprende 20B header TCP + 10B dati, che vengono trasmessi in (30 x 8)/100000 = 2.4 msec.
Il relativo ack è ricevuto a sorgente dopo 2.4 + 100 + 100 = 202.4 msec. In questo tempo la sorgente ha accumulato 202.4/20 = 10 caratteri. Quindi il 3° segmento e tutti i successivi comprenderanno 10B dati. |
| Selective-ACK è un˙opzione che TCP consente di attivare in fase di apertura connessione. Evidenziare i suoi vantaggi rispetto alla tecnica di Fast Retransmit. | I vantaggi di selective-ack sono diversi dato che trasmetto segmenti che permettono di identificare i segmenti che non sono arrivati e quelli già ricevuti.
Se uso gli ack cumulativi e in trasmissione perdo diversi segmenti, prima dell'intervento del fast retransmit passano comunque 3 ack fuori sequenza, il che vuol dire che ricevo 3 segmenti che vengono poi bufferizzati: non ho modo però di tenere conto di quali segmenti perdo oltre a quello iniziale, ed è qui che ci conviene usare selective-ack. Inoltre usando ack cumulativi e la ritrasmissione seguendo uno schema go-back-n dovrei ritrasmettere a partire dal primo segmento perso, ed è un enorme traffico inutile se ho già bufferizzato dei segmenti ricevuti correttamente: usando selective-ack dovrò ritrasmettere solamente i segmenti che sono stati effettivamente persi. |
| Come viene dimensionata la congestion window in una connessione TCP? | Dato che non sappiamo lo stato attuale della rete nel livello sottostante, c'è bisogno di partire con cautela tramite la tecnica di slow start.
La finestra di congestione viene inizializzata a 1MSS per poi crescere in modo esponenziale fino alla slow start threshold. Successivamente crescerà in modo lineare (fase di congestion avoidance) fino a raggiungere la dimensione del buffer di ricezione che è la soglia massima.
In caso di errore abbiamo un sintomo di congestione della rete sottostante.
dimensione della finestra = min(finestra di congestione, buffer di ricezione)
Si possono distinguere due differenti situazioni di congestione: congestione "lieve", in cui vengono quindi ricevuti tre ack consecutivi fuori sequenza. Il fatto di aver ricevuto gli ack consente di assumere che la |
| quali protocolli di real time esisto? | - RTP real time protocol (esclusivamente traffico dati)
- RTCP real time control protocol (informazioni di controllo) |
| che cosa è e a che cosa serve il persist timer? | il persist timer viene usato quando il sender aspetta che il buffer di ricezione venga liberato e venga rispedito l'ultimo ack con la windows update.
se scade il persist timer viene generato un messaggio probe al quale viene risposto con un windows update |
