Riassunto esame "Reti e sistemi informativi", prof. Cortesi

PROTOCOLLO UDP (USER DATAGRAM PROTOCOL)

Fa il minimo che un protocollo di trasporto debba fare. A parte la funzione multiplexing/demultiplexing e una funzione di controllo degli

errori molto semplice, non aggiunge nulla a IP.

Prende i messaggi dal processo applicativo

• Aggiunge il numero di porta di origine e di destinazione per il mux/demux

• Aggiunge altri due piccoli campi

• Passa il segmento risultante al livello di rete

• Il livello di rete incapsula il segmento in un datagramma IP ed effettua un tentativo di consegna all’host di destinazione in modalità best-

• effort

In UDP non esiste handshaking tra le entità di invio e di ricezione e livello di trasporto, per questo motivo si dice non orientato alla

connessione.

Per molte applicazioni è preferibile UDP a TCP in quanto:

Vi è un controllo più fine a livello applicazione

• Non vi è nessuna connessione stabilita e nessun relativo ritardo

• Non vi è nessuno stato di connessione (quindi un server UDP può

• sopportare molti più client attivi rispetto ad un server TCP)

Vi è un minor spazio usato per l’intestazione del pacchetto

•

SEGMENTI UDP

L’insolazione UDP presenta solo quattro campi di 2bit ciascuno.

Numeri di porta: consentono all’host di destinazione di trasferire i dati

• applicativi al processo corretto

Il campo lunghezza: specifica il numero di byte del segmento UDP

• Checksum: utilizzata dall’host ricevente per verificare se sono avvenuti errori nel segmento

•

La CHECKSUM UDP viene utilizzata per determinare se i bit del segmento UDP sono stati alterati durante il

loro trasferimento da sorgente a destinazione.

Lato mittente UDP effettua il complemento a 1 della somma di tutte le parole da 16 bit nel segmento, e

l’eventuale riporto finale viene sommato al primo bit. Tale risultato viene posto nel campo chekcsum del

segmento UDP.

TRASMISSIONE DATI AFFIDABILE SU UN CANALE CON ERRORI

Il compito dei protocolli di trasferimento dati affidabile è l’implementazione di un’astrazione di un canale affidabile tramite il quale si

possono trasferire i dati. Con un canale affidabile vengono evitati:

La presenza di errori

• La perdita di pacchetti

• 16

La non garanzia dell’ordine dei pacchetti

• La duplicazione di pacchetti

•

Sono inoltre introdotti:

Il controllo di flusso

• Il controllo di congestione

•

Nel caso in cui si rilevi un problema nella trasmissione dei pacchetti:

Rilevamento dell’errore: vengono utilizzate delle notifiche (acknowledgment) positive o negative per comunicare al mittente cosa sia

• stato ricevuto correttamente e cosa no, chiedendo quindi il rinvio

Feedback del destinatario: unico modo che ha il mittente per conoscere la versione del destinatario. Le risposte di notifica positive

• sono ACK e quello negative NAK

Ritrasmissione: un pacchetto ricevuto con errori sarà ritrasmesso dal mittente

•

In un protocollo che utilizza questi strumenti:

1. Il protocollo di trasporto lato mittente attende i dati da raccogliere dal livello superiore

2. Quando si verifica l’evento, il lato mittente crea un pacchetto contenente i dati da inviare, insieme

al checksum e spedisce il pacchetto

3. Il lato mittente si mette in attesa di un pacchetto ACK o NAK dal destinatario.

Se riceve un ACK sa che il pacchetto trasmesso più di recente è stato ricevuto correttamente e pertanto il protocollo ritorna

• allo stato di attesa dei dati provenienti dal livello superiore

Se riceve un NAK il protocollo ritrasmette l’ultimo pacchetto e attende una risposta alla ritrasmissione

•

Il mittente non invia nuovi dati finché non è certo che il destinatario abbia ricevuto il pacchetto corrente.

PROBLEMA ACK - NAK CORROTTI

Se un ACK o NAK è corrotto, il mittente non ha modo di sapere se il destinatario

abbia ricevuto correttamente l’ultimo blocco di dati trasmetti.

La soluzione a questo problema potrebbe essere semplicemente quella che prevede, in

ogni caso, il rinvio da parte del mittente qualora l’ACK o il NAK risulti alterato. Con

questa soluzione ovviamente, se il pacchetto dati trasmesso arriva correttamente la

prima volta, in seguito ad un ACK corrotto, con il relativo rinvio si introdurranno dei

pacchetti duplicati. Conseguentemente il destinatario, non sapendo se l’ultimo ACK

inviato sia stato ricevuto correttamente dal mittente, non può sapere a priori se un

pacchetto in arrivo è frutto di una ritrasmissione o è un pacchetto contenente dati

nuovi.

La soluzione generale al problema consiste nell’aggiungere un campo al pacchetto

dati, obbligando il mittente a numerare i propri pacchetti dati con un numero di

sequenza nel nuovo campo. Al destinatario sarà sufficiente controllare questo numero

per sapere se il pacchetto ricevuto rappresenti o meno una ritrasmissione. In accordo

con ciò, i pacchetti ACK e NAK non devono indicare il numero di sequenza per non

essere confusi con i pacchetti dati.

PROTOCOLLO SENZA NAK

In un'altra versione del protocollo, si possono avere le stesse funzionalità del

protocollo descritto precedentemente, utilizzando però solo notifiche di ACK.

Un mittente che riceve due ACK per lo stesso pacchetto (ossia riceve ACK duplicati) sa che il destinatario non ha ricevuto correttamente il

pacchetto successivo a quello confermato due volte.

Il destinatario deve ora includere il numero di sequenza del pacchetto di cui invia l’acknowledgement all’interno del messaggio ACK, e il

mittente deve ora controllare il numero di sequenza del pacchetto confermato da un messaggio ACK ricevuto. 17

TRASMISSIONE DATI AFFIDABILE SU UN CANALE CON PERDITE E ERRORI

Supponiamo ora che il canale di trasmissione, oltre a danneggiare i bit, possa anche smarrire i pacchetti. Il protocollo ora deve preoccuparsi

di due aspetti aggiuntivi:

Rilevare lo smarrimento del pacchetto

• Cosa fare quando avviene la perdita

•

Nel caso in cui un pacchetto o un ACK corrispondente del ricevente venga smarrito, se questo è disposto ad attendere un tempo sufficiente

per essere certo dello smarrimento del pacchetto, allora può ritrasmetter il pacchetto.

Il problema è quello di quantificare questo timeout.

Nella pratica l’approccio adottato è scegliere in modo assennato un

valore di tempo tale per cui la perdita di pacchetti risulta probabile,

anche se non garantito. Se non si riceve un ACK in questo lasso di

tempo, il pacchetto viene ritrasmesso.

S e un pacchetto sperimenta un ritardo particolarmente largo, ma

comunque arriva a destinazione, il mittente potrebbe ritrasmetterle

introducendo pacchetto duplicati sula canale.

IMPLEMENTAZIONE DEL TIMEOUT

Implementare un meccanismo di ritrasmissione basato sul tempo

richiede un contatore in grado di

segnalare al mittente l’avvenuta scadenza di un dato lasso di tempo.

Il mittente dovrà essere in grado:

1. Inizializzare il contatore ogni volta che invia il pacchetto

2. Rispondere a un interrupt generato dal timer con l’azione

appropriata

3. Fermare il contatore

Il protocollo è detto Stop&Wait o anche ad alternanza di bit dato che i

numeri di sequenza dei pacchetti si alternano tra 0 e 1.

TRASFERIMENTO DATI AFFIDABILI CON PIPELINE

Il protocollo mostrato precedentemente è corretto dal punto di vista

funzionale, ma non ottimo dal punto di vista prestazionale proprio

per il fatto che si tratta di un protocollo stop-and-wait.

Se definiamo l’utilizzo del canale come la frazione di tempo in cui

il mittente è stato effettivamente occupato nell’invio di bit sul

canale, un’analisi delle prestazioni mostra che il protocollo presenta

effettivamente un throughput molto basso.

Una soluzione a questo problema è quello di consentire al mittente

di inviare più pacchetti senza attendere gli acknowledgement.

Dato che molti pacchetti in transito dal mittente al destinatario

possono essere visualizzati come il riempimento di una tubatura,

questa tecnica è nota come pipelining.

Conseguenze su un protocollo di trasferimento dati affidabile:

• L’intervallo di numeri di sequenza disponibili deve essere incrementato, dato che ogni pacchetto in transito deve presentare un

numero di sequenza e univoco e che ci potrebbero essere più pacchetti in transito ancora in attesa di acknowledgement.

• I lati di invio e ricezione dei protocolli possono dover memorizzare in un buffer più di un pacchetto e in particolare quei pacchetti

trasmessi, ma il cui acknowledgement non è ancora stato ricevuto. 18

TRASPORTO ORIENTATO ALLA CONNESSIONE: PROTOCOLLO TCP

Le caratteristiche principali del protocollo TCP sono:

CONNECTION-ORIENTED: prima di effettuare lo scambio di dati, i processi devono effettuare una three-way handshake (i processi

• devono scambiarsi tre segmenti al fine di instaurare la connessione).

FULL DUPLEX DATA: su una stessa connessione TCP tra due processi residenti su due host diversi, il flusso di dati può fluire

• contemporaneamente nelle due direzioni.

END-TO-END: in quanto lo stato della connessione risiede completamente nei due sistemi periferici, per cui gli elementi intermedi di

• rete sono completamente ignari della connessione.

PUNTO A PUNTO: ha luogo tra un singolo mittente e un singolo destinatario (non è realizzabile il multicast).

• SENZA ERRORI, SEQUENZA ORDINATA

• PIPELINED: controllo di lusso e di congestione impostano la TCP window.

• CONTROLLO DI FLUSSO: il mittente non invia più di quanto il ricevente non possa accettare.

• BUFFET SU MITTENTE E RICEVENTE: TCP dirige i dati al buffer di invio della connessione, uno dei buffer

• riservato durante l’handshake a tre via, da cui di tanto in tanto preleverà blocchi di dati e li passerà al livello di rete.

La massima quantità di dati prelevabili e posizionabili in un segmento viene limitata dalla dimensione massima di segmento (MSS,

maximum segment size).

MSS rappresenta la massima quantità di dati a livello applicazione nel segmento e non la massima dimensione del segmento TCP con

intestazioni incluse.

Questo valore viene generalmente impostato determinando prima la lunghezza del frame più grande che può essere inviato a livello di

collegamento dall’host mittente locale, la cosiddetta unità trasmissiva massima (MTU) e poi scegliendo un MSS tale che il segmento TCP

(una volta incapsulato in un datagramma IP) stia all’interno di un singolo frame a livello di collegamento, considerando anche la lunghezza

dell’intestazione TCP/IP normalmente pari a 40 byte.

STRUTTURA DEI SEGMENTI TCP

La Protocol Data Unit (PDU) di TCP è detta segmento. Ciascun segmento viene normalmente imbustato in