Lezione n.4 SSIS INFORMATICA LIVELLO TRASPORTO TCPpages.di.unipi.it/ricci/Livello_Trasporto_05_12_07.pdf · Dipartimento di Informatica Università degli studi di Pisa Il livello

Dipartimento di InformaticaUniversità degli studi di Pisa

Laura Ricci1Il livello Trasporto

Lezione n.4SSIS INFORMATICALIVELLO TRASPORTO

TCP

Università degli Studi di Pisa Dipartimento di Informatica

5/12/2007Laura Ricci



UDP: MESSAGE ORIENTED PROTOCOL

• Molti protocolli di rete (es: UDP, ISO-OSI) sono basati sull'uso di messaggi

• Esempio:

l'applicazione passa al livello UDP un messaggio= blocco di dati di dimensione limitata

E' compito dell'applicazione costruire blocchi discreti di dati, rispettando la dimensione massima fissata.

Il blocco dei dati viene spedito ai livelli inferiori dello stack di protocolli. Ogni livello aggiunge un header al messaggio.

• Svantaggi: l'applicazione deve

Dividere i dati in blocchi

Se i dati da inviare non possono essere inseriti in un solo blocco, segmentare i dati in più blocchi



TCP: STREAM BASED COMMUNICATION

• TCP=Stream Oriented Protocol:

non richiede all'applicazione di suddividere i dati in blocchi

accetta dall'applicazione dati di qualsiasi dimensione e struttura

l'applicazione 'pompa uno stream di bytes' verso il livello TCP

• Il livello TCP

riceve bytes dalla applicazione e li passa al livello network (livello IP)

Il livello IP utilizza un protocollo 'orientato ai messaggi'

il compito di definire i blocchi di dati da spedire all'interno dei messaggi è spostato dal livello applicazione al livello TCP

Messaggi definiti da TCP = segmenti TCP

Il livello IP incapsula i segmenti TCP in datagrammi IP e li spedisce sulla rete



TCP:STREAM BASED COMMUNICATION



TCP: STREAM BASED COMMUNICATION

• Il TCP lavora a livello di bytes, piuttosto che a livello di messaggi

• TCP riceve bytes dalle applicazioni e, ad intervalli di tempo regolari, forma dei segmenti che passa al livello IP

• Maximum segment size (MSS) = definisce la dimensione massima dei segmenti. Scelto in modo da evitare eccessiva frammentazione ai livelli inferiori

• MSS stabilito al momento della connessione

• ad ogni byte dello stream viene assegnato un numero progressivo (numero di sequenza)

• i numeri di sequenza necessari per definire un protocollo affidabile sono associati ai bytes trasmessi

• Ogni segmento è individuato dal numero di sequenza delprimo byte in esso contenuto



TCP: FUNZIONALITA'

Funzionalità offerte dallivello TCP

• Affidabilità: assicura che i dati spediti arrivino effettivamente a destinazione e individua se i dati non sono arrivati ed in questo caso li ritrasmette

• Controllo del flusso: stabilisca la frequenza con cui i dati vengono spediti in modo da non mandare in overflow ilbuffer del destinatario

• Controllo della congestione: definisce un insieme di euristiche per determinare illivello di congestionamento della rete. Stabilisce la frequenza con cui i dati vengono spediti in funzione del livello di congestionamento individuato



TCP: FUNZIONALITA'

Il meccanismo defintio da TCP per garantire l'affidabilità è basato su

PAR= Positive Ackwnoledgement with Retrasmission

• Il mittente inizializza un timer quando spedisce un segmento

• Il valore del timer deve essere definito in modo da considerare il

RTT (round trip time) tra mittente e destinatario+ un certo ritardo

• Il destinatario invia un ack quando ha ricevuto il messaggio

• Quando il valore del timer diventa 0, il messaggio viene rispedito



POSITIVE ACK WITH RETRASMISSION



POSITIVE ACK WITH RETRASMISSION: PAR

• Meccanismi di tipo start-stop utilizzati quando

i partner scambiano piccole quantità di dati

lo scambio di dati è poco frequente

• Richiedono identificatori unici per i messaggi trasmessi, in modo da individuare eventuali segmenti duplicati

• Nel caso del meccanismo di start-stop è sufficiente un bit per identificare i messaggi (alternate bit protocol)

• Un protocollo di tipo start-stop non è proponibile per Internet, perchè è possibile scambiare frequentemente grosse quantità di dati

• Verso il protocollo TCP: prima modifica al PAR start-stop

Il mittente può inviare ulteriori segmenti prima di ricevere l'ack dei messaggi precedentemente inviati



PAR: OVERLAPPING TRASMISSION

• Supponiamo che i partner si scambino messaggi, tutti della stessa dimensione

• Il mittente associa ad ogni messaggio spedito

un identificatore unico

un timer inizializzato tenendo conto del RTT tra mittente e destinatario

• Il mittente rispedisce il messaggio se non riceve un riscontro positivo prima dello scadere del timer associato al messaggio

• Il destinatario

Mentre nel PAR start-stop il destinatario possiede al massimo un messaggio da riscontrare nel buffer di ricezione, ora è possibile che esistano più messaggi da riscontrare nel buffer di ricezione

Anche gli ack contengono degli identificatori che identificano il/i segmenti riscontrati



PAR: CONTROLLO DEL FLUSSO

• Il destinatario D può possedere nel buffer di ricezione più messaggi da riscontrare

• Il numero di messagi può crescere nel caso in cui D non possa inviare i riscontri immediatamente, perchè occupato in altre eleborazioni

• Occorre un meccanismo che consenta a D di notificare al mittente, insieme all'ack, una richiesta di 'rallentare' o 'interrrompere' la trasmissione di nuovi messaggi

• Controllo del flusso:

D invia al mittente M, insieme all'ack, un valore intero V che indica il massimo numero di messaggi non riscontrati che può gestire.

M interrompe la trasmissione di ulteriori messaggi nel caso in cui il numero di messaggi per cui non ha avuto riscontro raggiunga V

Il valore di V può essere modificato da D a seconda del proprio carico e di altri fattori



PAR: OVERLAPPING TRASMISSION



TCP:BYTE ORIENTED TRASMISSION

• TCP trasmette segmenti contenenti sequenze di bytes

• Il segmento viene considerato l'unità atomica di trasmissione:tutti i bytes di un segmento vengono inviati insieme e riscontrati insieme

• Un segmento viene riscontarto inviando il numero del primo byte che il destinatario attende (=numero dell'ultimo byte del segmento ricevuto +1)

• Mittente e destinatario devono accordarsi sui numeri di sequenza assegnati ai bytes scambiati. Questo avviene nel momento in cui viene stabilita la connessione

• Per ora supponiamo che alprimo byte venga assegnato numero di sequenza = 1



TCP: BUFFER DI INVIO

Consideriamo il buffer gestito dal mittente TCP: Il buffer di invio può

contenere le seguenti quattro categorie di dati:

• inviati per cui si è ricevuto l'ack

• inviati per cui non si è ricevuto l'ack

• non inviati, ma che possono essere inviati immediatamente, perchè il destinatario ha indicato nell'ultima comunicazione che ha spazio per riceverli

• non inviati e che non possono essere inviati immediatamente



TCP:BUFFER DI INVIO

Send Window

• Numero di bytes che il mettente può inviare senza attendere un riscontro da parte del destinatario

• Bytes di categoria 2 + bytes di categoria 3

Usable Window

• Indica i dati che possono essere ancora trasmessi senza attendere riscontro. Bytes di categoria 3



TCP BUFFER: MODIFICA DEI DATI

• Il mittente invia immediatamente i 6 bytes in categoria 3

• La usable Window diviene vuota

• Il mittente deve attendere il riscontro dei dati inviati prima di trasmettere nuovi dati



TCP: CUMULATIVE ACKNOWLEDGEMENT

• Invio dei riscontri da parte del destinatario: il destinatario riscontra la più lunga sequenza contigua di bytes che ha ricevuto a partire dall'ultimo riscontro inviato

• Esempio: i bytes dal 32 al 45 sono stati trasmessi in 4 segmenti diversi (bytes 32-34, 35-36, 37-41, 42-45).

• Il primo, secondo e il quarto segmento sono recapitati, il terzo segmento viene perso

• Il destinatario invia un ack cumulativo per i bytes dal 32 al 36 (32-34, 35-36)



TCP:CUMULATIVE ACKNOWLEDGEMENTS

Meccanismo dei cumulative acknowledgments

• Esempio: i bytes dal 32 al 45 sono stati trasmessi in 4 segmenti diversi (bytes 32-34, 35-36, 37-41, 42-45).

• Il primo, secondo e il quarto segmento sono recapitati, il tezo segmento viene perso

• Il destinatario può memorizzare i bytes dal 42 al 45, ma non può inviare un ack per questi dati, perchè questo implicherebbe che ha anche ricevuto i bytes 37-41



TCP: SLIDING WINDOW

• Supponiamo che il mittente riceva un ack per i bytes nel range 32-36

• I bytes 32-36 passano dalla categoria 2 (bytes inviati, ma non ancora riscontrati) alla categoria 1 (bytes inviati e riscontrati)

• meccanismo della sliding window: la send window viene spostata verso destra di 5 posizioni, alcuni bytes passano dalla categoria 4, non inviati e non inviabili immediatamente, alla categoria 3, non inviati, ma inviabili immediatamante

• il mittente può inviare ulteriori dati



TCP: CUMULATIVE ACKNOWLEDGEMENTS

• Cumulative TCP acknowledgments: indicano al mittente che tutti i bytes fino a quello riscontarto, sono stati ricevuti correttamente

• Il destinatario associa ad ogni ack la dimensione massima della finestra

• Il mittente modifica la dimensione della usable window a seconda della notifica ricevuta dal destinatario

• Viene utilizzato un timer per decidere quando ritrasmettere un segmento non riscontrato

• Problema:come vengono trattati i segmenti ricevuti fuori ordine? se si utilizzano i cumulative acknoledgments, il destinatario non ha

nessuna possibilità di notificare la ricezione di un segmento ricevuto fuori ordine

Esempio: se ho spedito 500 segmenti e solo il primo segmento della sequenza è stato perso, non ricevo alcun ack dal destinatario



TCP: POLITICHE DI RITRASMISSIONE

Politiche di ritrasmissione

• quando scade un timeout associato ad un segmento S spedito, il mittente non è in grado di capire se i segmenti successivi sono stati ricevuti correttamente dal destinatario

• due scelte possibili

Politica ottimistica: si ritrasmette solo il segmento per cui è scaduto il time out,con la speranza che gli altri segmenti siano stati ricevuti correttamente.

• Se i segmenti successivi sono andati persi, a loro volta è necessario attendere lo scadere del time out per ognuno di essi

Politica pessimistica: si ritrasmette il segmento e tutti quelli spediti successivamente per cui non si è ancora avuto riscontro

• I segmenti ricevuti correttamente vengono ricevuti più volte



TCP: SELECTIVE ACKNOWLEDGMENTS

TCP Selective Acknowledgments:

• Estensione dell'algoritmo base che introduce la possibilità di riscontrare singolarmente ogni segmento

• Possibile solo se i partner della comunicazione supportano l'algoritmo SACK

• I partner notificano di essere SACK enabled al momento dell'inizializzazione della connessione (SYN message)



TCP: FAST RETRASMISSION

• Nella versione base di TCP, un processo può solo confermare una sequenza contigua di segmenti

• Un segmento ricevuto fuori ordine non viene confermato, fintanto che i segmenti precedenti non sono stati ricevuti, però....TCP invia un ACK anche quando riceve un segmento fuori ordine

• Questo ACK indica il numero di sequenza del primo byte atteso dal mittente

• Esempio:

Se un processo P ha ricevuto il Segmento #4, ma non ha ricevuto il segmento #3, P invia un ACK riscontra l'ultimo segmento ricevuto correttamente, cioè il #2

In questo modo P indica “io sto aspettando il primo byte del segmento #3, ma in realtà ho ricevuto un segmento successivo fuori ordine” .... (continua pagina successiva....)




Esempio.....(continua dalla pagina precedente.....)

• Il mittente non sa che il Segmento #3 è stato perso, per cui continua ad inviare segmenti, ad esempio il Segmento#6, #7, ...

• Ogni volta che il destinatario riceve un segmento fuori ordine, invia un ACK che specifica che il primo byte atteso si riferisce al segmento #3

• Il mittente riceve una sequenza di ACK identici

deduce che il segmento #3 è stato perso, prima che il relativo time out scada

fast retrasmission: renvia il segmento #3 prima dello scadere del time-out




• Fast Retrasmission:

quando il mittente riceve tre o più ACK per lo stesso segmento,

ritrasmette immediatamente ilsegmento

questa ottimizzazione migliora la performance del protocollo



THREE-WAY HANDSHAKE

• Il livello TCP mantiene una struttura dati per ogni connessione aperta• TCB, Trasmission Control Block= contiene tutte le informazioni importanti

per la gestione della connessione Sockets e porte che identificano la connessione Buffers di ingresso/uscita Variabili per la gestione della sliding window (es: numero di bytes

ricevuti e riscontrati, dimensione della finestra, ecc.)• L'interazione tra i partners che intendono stabilire una connessione TCP

avviene secondo il modello client/server• Il client esegue una active open, tramite cui richiede di aprire una

connessione verso un server specifico. La 'active open' crea il TCB• Il server esegue una passive open tramite cui comunica al livello TCP che sta

attentendo richieste di connessione su una data porta. La passive open crea un TCB che non contiene riferimenti a socket e porta delclient



THREE-WAY HANDSHAKE

● la fase di apertura di una connessione è implementata mediante three way handshake (handshake=stretta di mano)

● Supponiamo che il processo P1 intenda stabilire una connessione con P2● P1 invia a P2 un messaggio di SYN e attende da P2 un messaggio di

ACK ● P2 indica che accetta la connessione inviando, a sua volta, un

messaggio di SYN e ricevendo l'ACK corrispondente● Il protocollo richiede 4 messaggi per stabilire la connessione● Ottimizzazione: P2 include nel messaggio di riscontro (ACK) il proprio messaggio di SYN che l'ACK (SYN+ACK). ● numero totale dei messaggi scambiati = 3, da cui 3-way handshakedopo

l’handshake ● Dopo il tree way handshake, i processi possono iniziare a scambiarsi i

segmenti contenenti i dati



TCP: THREE-WAY HANDSHAKE



TCP: THREE-WAY HANDSHAKE

Il three way handshake svolge diverse funzioni:

• Il server non conosce quale client intende stabilire il contatto. In questa fase il server acquisisce conoscenza sul client (indirizzo+porta delclient

• Sequence number synchronization. Ogni processo indica all'altro quale è il numero di sequenza che vuole utilizzare per il primo byte trasmesso

• Scambio di parametri vengono scambiati alcuni parametri che consentono di controllare la trasmissione



TCP : THREE WAY HANDSHAKE● Perchè il TCP non assegna sempre al primo byte spedito su una

connessione il numero di sequenza=1?● Il problema principale riguarda la possibilità di 'mischiare' segmenti

spediti su connessioni diverse● Esempio:

inviamo su una connessione un segmento contenente i bytes numerati da 1 a 30. La rete è congestionata, il segmento viene ritardato e la connessione viene chiusa.

La connessione viene riaperta in seguito e viene nuovamente attribuito il valore 1 al primo byte spedito.

Il destinatario può ricevere per primo il segmento precedentemente inviato, considerandolo come il primo segmento spedito sulla nuova connessione

● Assegnazione casulale dei numeri iniziali di sequenza. Diminuisce la probabilità di utilizzare un numero di sequenza relativo ad un pacchetto 'in ritardo' ancora presente sulla rete, ma relativo ad una connessione precedente



SELEZIONE DEI I NUMERI DI SEQUENZA

Assegnazione dei numeri iniziali di sequenza (ISN=Initial SequenceNumber)Soluzione 1:● Si inizializza un timer e si incremeta periodicamente,ogni 4 microsecondi,

modulo 4.294.967.295 (massimo valore rappresentabile su 32 bits)● il valore massimo viene raggiunto dopo 4 ore, se il contatore viene

incrementato ogni 4 microsecondi, ● la probabilità di utilizzare un numero di sequenza relativo ad un pacchetto

'in ritardo' ancora presente sulla rete, ma relativo ad una connessione precedente, diventa trascurabile

● Svantaggi: predicibilità dei numeri generatiSoluzione 2:● generazione casuale dei numeri di sequenza



TCP : SEQUENCE NUMBER SYNCHRONIZATION

● Al momento della apertura della connessione, ogni processo informa il partner sul'ISN scelto per quella connessione

● L'ISN viene inserito nel messaggio di SYN● Il partner conferma la ricezione del numero di sequenza mediante l'ACK



HEADER TCP



TCP: CONTROLLO DELLA CONGESTIONE

• Congestione: situazione in cui i routers intermedi devono gestire una grossa quantità di traffico. Questa situazione può provocare:

ritardo nella notifica di un segmento al processo destinatario

perdita di segmenti • Il meccanismo di controllo del flusso

considera unicamente i due partners dellaconnessione non considera il percorso effettuato dai pacchetti che includono i

segmenti TC P nei routers intermedi

• TCP non definisce un meccanismo che permetta di verificare direttamente lo stato della rete (esempio: messaggi espliciti ai routers)

• La congestione viene percepita indirettamente da TCP come una situazione che provoca la perdita di segmenti o l'arrivo ritardato di segmenti




• Senza alcun mccanismo di controllo, il fenomeno della congestione è autoalimentante:

● un router elimina uno o più pacchetti● l’host che ha inviato i pacchetti, quando vede scadere i loro timeout, li

rinvia● il numero di pacchetti in transito sulla rete aumenta

• TCP non può semplicemente ignorare quanto avviene a livello di routers tra i partner della connessione

● è opportuno definire un meccanismo che ● controlli il comportamento degli end hosts affinchè essi non

contribuiscano ad aumentare la situazione di congestione● renda gli end hosts 'coscienti dello stato della rete'● l'applicazione di questo meccanismo di 'regolazione' su tutte le

connessioni aperte sulla rete può contribuire a diminuire lo stato di congestionamento della rete stessa




Approcci generali per il controllo della congestione:

● controllo della congestione supportato dai routers (non implementato in TCP-IP) : i routers notificano esplicitamente il loro stato di congestione agli end systems (hosts). Gli hosts regolano di conseguenza il flusso dei segmenti spediti sulla rete

● controllo della congestione end to end:– i routers non forniscono alcun supporto per il controllo della

congestione.– gli host decidono autonomamente quando la rete risulta

congestionata in base all’osservazione del comportamento della retein seguito all’invio di segmenti TCP



TCP: RILEVAZIONE DELLA CONGESTIONE

Una situazione di congestione può provocare nei routers● L'overflow di uno o più buffers dei routers interessati● L'eliminazione di un datagram da parte del router● il datagram può contenere un segmento TCP

L'end host percepisce la congestione come perdita di un segmenti inviatilungo una connessione, che può avvenire a seguito di

● un time out● l'arrivo di tre ACK duplicati in successione● in seguito alla rilevazione di una situazione di congestione, l'end host può

rallentare la spedizione dei pacchetti sulla rete in modo da diminuire lo stato di congestione della rete



TCP: RILEVAZIONE DELLA CONGESTIONE

• Consideriamo il buffer gestito dal mittente

● i bytes di categoria 2 sono quelli inviati, ma non riscontrati● il controllo della congestione opera controllando il numero di bytes in categoria 2. La dimensione della finestra dei dati in categoria 2 (finestra di congestione, fcong) puo' essere ridotta ed aumentata dinamicamente, a seconda della percezione della congestione● il meccanismo ovviamente interagisce con il meccanismo di controllo del flusso, che opera sulla dimensione della send window




● L'algoritmo di controllo della congestione è basato su tre componenti● Incremento additivo e decremento moltiplicativo● Slow start● Ricezione ai timeout

● Incremento Additivo e Decremento Moltiplicativo● Quando il mittente rileva la perdita di un segmento, dimezza la

dimensione della finestra di congestione (decremento moltiplicativo)● Esempio:

● la dimensione della finestra di congestione può passare da 20Kbytes a 10 kbytes a 5 kbytes,....

● la dimensione della finestra di congestione non scende però al di sotto di un valore soglia

● Quando il mittente riceve in tempo un riscontro per un segmento precedentemente inviato, aumenta di poco la dimensione della propria finestra (aumento additivo)




AIMD = Additive Increase, Multiplicative Decrease

tempo

KB

La situazione illustrata in figura non considera la slow start



TCP: SLOW START

• TCP inizia la trasmissione dei segmenti con un valore molto basso della dimensione della finestra di congestione (frequenza bassa di trasmissione)

• In seguito, TCP incrementa esponenzialmente la frequenza di trasmissione,

• Esempio:

Si inizia inviando un segmento e se ne attende il riscontro

Se il segmento viene riscontrato prima di un time out, la dimensione della finestra di congestione, viene aumentata di 1 e si invaino due segmenti

Se entrambe i segmenti vengono riscontrati si incremente di 1 la dimensione della finestra di congestione per ognuno dei segmenti riscontrati, la dimensione della finestra di congestione diventa 4,...



TCP: SLOW START

Sorgente Destinazione



TCP: SLOW START● Quando la dimensione della finetstra di congestione supera un valore

S (soglia): la fase di slow-start termina ed inizia la fase di aumento additivo della finestra di congestione

● Andamento della trasmissione: crescita esponenziale dopo una partenza lenta, fino ad un evento di smarrimento. Quindi inizia una fase di andamento altalenante (AIMD)



TCP:CONTROLLO DI CONGESTIONE

• TCP Reno: reagisce in modo diverso ad un time out, rispetto ad un evento di ricezione di tre ack duplicati

• Ricezione di 3 ack duplicati: si dimezza la dimensione della finestra di congestione

• Ricezione di time out: si rientra nella fase di slow start. Riporta la dimensione della finestra di congestione al valore minumo

• Motivazione dell'algoritmo TCP Reno:

l'arrivo di tre ack duplicati implica che almeno alcuni dei segmenti successivi sono stati ricevuti dal destinatario. Quindi, a differenza del caso in cui si è ricevuto un time out, la rete ha conservato la capacità di consegnare un sottoinsieme dei pacchetti spediti

Il time out viene rileva una situazione potenzialmente più grave, per cui l'algoritmo tratta questo caso in modo più restrittivo

Documents

Lezione n.4 SSIS INFORMATICA LIVELLO TRASPORTO TCPpages.di.unipi.it/ricci/Livello_Trasporto_05_12_07.pdf · Dipartimento di Informatica Università degli studi di Pisa Il livello