Sistemi e Tecnologie della
Comunicazione
Lezione 22: transport layer: introduzione, funzionalita’
1
Funzione del livello di trasporto

Il livello di trasporto ha lo scopo di fornire allo
strato superiore un servizio di trasferimento dei
dati end to end, mascherando completamente al
livello superiore il fatto che tra i due host
terminali esista una rete di qualsiasi tipo,
topologia, tecnologia e complessita’



per OSI lo strato superiore e’ il livello di sessione
per TCP/IP lo strato superiore e’ il livello di
applicazione
Per assolvere le sue funzioni lo strato di trasporto
utilizza i servizi dello strato di rete
2
Necessita’ dello strato di trasporto

Perche’ introdurre un nuovo strato?





lo strato di rete opera su tutte le macchine attraversate dai dati,
indipendentemente
in mancanza di uno strato che operi esclusivamente sui nodi
terminali della comunicazione non si puo’ tenere sotto controllo
cosa accade ai dati una volta che lasciano l’host sorgente
lo strato di trasporto rende trasparente allo strato superiore la
complessita’ (l’esistenza!) della sottorete
La presenza di uno strato intermedio tra applicazione e rete puo’
offrire un meccanismo per rendere affidabile una comunicazione
su sottoreti inaffidabili
Inoltre offre al suo utente una interfaccia indipendente dalle
diverse tecnologtie dello strato di rete
3
Servizi forniti allo strato superiore

Lo strato di trasporto puo’ offrire



servizio affidabile orientato alla connessione
servizio inaffidabile non orientato alla connessione
In modo analogo ai servizi equivalenti dello strato di rete:

il servizio orientato alla connessione realizza un trasferimento dei
dati affidabile (controllo della integrita’, della completezza,
dell’ordine) e permette di gestire controllo di flusso; i dati
vengono trasferiti con un procedimento in tre fasi




si stabilisce la connessione
si inviano i dati attraverso la connessione
si chiude la connessione
il servizio non orientato alla connessione fornisce un meccanismo
di trasferimento dati “best-effort”: ogni blocco di dati viene
inviato e ci si dimentica di lui; se arrivano, bene, se no
l’applicazione dovra’ farsi carico di operare azioni correttive (se
necessarie)
4
Protocollo di trasporto


Il livello di trasporto realizza le sue funzioni comunicando
con il processo paritario secondo un protocollo definito
Le informazioni vengono scambiate tramite la
trasmissione di blocchi di dati



Il protocollo si dovra’ occupare dei meccanismi per gestire
i diversi eventi (ove necessari):






in OSI si chiamano TPDU (Transport Protocol Data Unit)
in TCP/IP si chiamano segmenti (ma spesso anche pacchetti)
come si stabilisce la connessione
come si chiude una connessione
controllo di flusso
controllo degli errori, ritrasmissioni e acknowledge
ordinamento in sequenza dei dati
Le problematiche sono simili a quelle del livello di data
link
5
Differenze rispetto al data link

Il fatto che a livello di trasporto i due terminali
siano separati da una rete provoca complicazioni


a livello 2 un frame o arriva o non arriva, mentre a
livello 4 la sottorete provoca ritardi e riapparizione di
pacchetti che si credevano perduti e quindi sono stati
ritrasmessi, con conseguente duplicazione
il numero delle connessioni cui il livello di trasporto
deve far fronte e’ molto piu’ elevato che nel caso del
data link layer: non sara’ possibile dedicare a tutte i
buffer necessari alle comunicazioni
6
Ritardo dei pacchetti e numeri di sequenza



Come visto a livello di data link, la gestione delle funzioni di
acknowledge e ritrasmissione prevede di utilizzare numeri di
sequenza sulle TPDU inviate in una connessione
Il fatto che la rete possa ritardare il recapito dei pacchetti comporta
delle necessita’ sulla scelta dei numeri di sequenza
Vediamo un esempio che mostra come partire sempre da 0 puo’
comportare dei problemi:



si stabilisce una connessione e si iniziano ad inviare TPDU con seq = 0
dopo 10 secondi la TPDU con seq = X si ferma in un router
congestionato; viene reinviata dopo il tempo di timeout e la connessione
si chiude
si apre subito un’altra connessione, nuovamente con seq = 0



stessi host, stesse porte: connessione identica alla precedente
a questo punto la TPDU originaria si sblocca ed arriva a destinazione
prima che una TPDU con seq = X della nuova connessione venga inviata
la vecchia TPDU verra’ accettata e si ha un errore
7
Ritardo dei pacchetti e numeri di sequenza

Per ovviare a questo problema, si devono prendere delle
precauzioni:

lo strato di rete deve essere in grado di invalidare pacchetti
troppo vecchi


in questo modo un numero di sequenza gia’ utilizzato puo’ essere
riutilizzabile dopo un tempo pari o superiore al tempo di vita
massimo dei pacchetti
la assegnazione dei numeri di sequenza iniziali deve essere fatta
in modo da essere sicuri che non esistano sulla rete TPDU con
numerazione valida


solitamente i numeri di sequenza iniziali di una connessione vengono
scelti (da chi inizia la connessione) con un valore legato ad un
orologio
una scelta opportuna rende impossibile avere ritardati con numeri di
sequenza validi che possano essere interpretati in modo errato
8
Stabilire la connessione


Il problema della inaffidabilita’ della sottorete e dei
duplicati ritardati si presenta anche nella fase di
inizializzazione della connessione
Per risolverli e’ stato sviluppato un meccanismo detto
handshake a 3 vie:



il client invia una TPDU di Connection Request priva di dati, in cui
propone un certo valore iniziale di sequenza
il server risponde con un acknowledge che riscontra il valore
iniziale di sequenza proposto dal client, ed un valore di sequenza
proposto dal server per il traffico in senso inverso
il client invia una terza TPDU che riporta l’acknowledge per il
numero di sequenza iniziale proposto dal server, e riporta
nuovamente il proprio numero di sequenza iniziale
(eventualmente questa TPDU puo’ anche trasportare i primi dati)
9
Handshake a tre vie

Il meccanismo visto risponde positivamente ai problemi di duplicati
sulla rete


sempre nella ipotesi che non possano esistere contemporaneamente
sulla rete TPDU con lo stesso numero di sequenza (vedi slide precedenti)
In figura a sinistra la procedura normale, a destra cosa accade se
arriva una Connection Request ritardata relativa ad una vecchia
connessione
10
Rilascio della connessione




Anche qui ci sono problemi da affrontare
La connessione puo’ essere rilasciata in modo asimmetrico o
simmetrico
Nel modo asimmetrico la
disconnessione viene decisa da
uno dei due, che invia una TPDU
Disconnect Request e chiude
Questo puo’ comportare la
perdita di dati, come mostrato in
figura: dopo la disconnessione
l’host 2 non accetta piu’ i dati in
ingresso
12
Rilascio simmetrico


Il rilascio simmetrico richiede che le parti siano entrambe
consapevoli e daccordo
Sorge il problema (insolubile) di essere entrambi sicuri
che l’altro sia daccordo (problema dei due eserciti)
13
Rilascio simmetrico (cont.)

La soluzione adottata usualmente e’ un handshake a tre
vie con timeout:





il primo invia una TPDU Disconnect Request, ma lascia la
connessione aperta in ricezione ed avvia un timer
il secondo invia in risposta una TPDU Disconnect Request
lasciando aperta la connessione, ed avvia un timer
il primo risponde alla DR ricevuta con una TPDU di ACK
e chiude la connessione
in caso di perdita delle TPDU i timeout provocheranno, a seconda
dei casi, una ritrasmissione dei DR o il rilascio definitivo della
connessione anche in assenza di riscontro
Questa soluzione garantisce quasi sempre che nessun
dato venga perduto
14
Rilascio simmetrico (cont.)
15
Controllo di flusso e buffering



Come visto per il data link layer, il controllo di flusso puo’ essere
gestito tramite un protocollo sliding window
Questo protocollo richiede che vengano dedicati buffer in
trasmissione per contenere le TPDU inviate e non ancora riscontrate,
e buffer in ricezione per contenere dati ricevuti in ordine non corretto
Tuttavia il livello di trasporto presenta problemi che non affliggono il
data link layer



un host puo’ dover gestire a livello di trasporto centinaia di connessioni
contemporanee: si devono trovare le risorse per i buffer
la dimensione dei buffer e’ un altro problema: le applicazioni possono
richiedere di trasferire blocchi dati di dimensioni molto differenti (dal
singolo carattere di una sessione telnet a svariati KB di un file transfer);
allocare buffer di dimensioni definite puo’ costituire un problema
E’ quindi necessaria una gestione dinamica dei buffer per le diverse
connessioni: la quantita’ di buffer disponibili varia nel tempo per la
singola connessione
16
Buffer dinamici come window size


L’utilizzo della gestione dinamica dei buffer permette al ricevente di
regolare la velocita’ del trasmittente in funzione della quantita’ di
buffer disponibili in ricezione; di fatto il numero di buffer disponibili in
ricezione definisce la window size
Quello che viene fatto dal protocollo e’ sostanzialmente la seguente
cosa:





il trasmittente (all’atto dell’attivazione della connessione) richiede un
certo numero di buffer in funzione delle sue esigenze
il ricevente risponde concedendo il numero di buffer che puo’ offrire, ed il
ricevente memorizza il numero e tiene conto della disponibilita’ di buffer
in ricezione durante tutta la trasmissione
ad ogni TPDU inviata il trasmittente riduce il numero di buffer che il
ricevente ha disponibili
quando arriva a zero il trasmittente si ferma
ad ogni acknowledge, il ricevente comunica quanti buffer ha disponibili

questo numero puo’ essere inferiore al buffer iniziale meno dati ricevuti e non
riscontrati: il trasmittente aggiorna la finestra di ricezione ad ogni ack ricevuto
17
Separazione ack/window size

Gli eventi “TPDU riscontrata” e “buffer liberato” nello strato di trasporto non
sono contemporanei




questo e’ essenzialmente dovuto al fatto che “chi libera il buffer” e’ un applicativo
scritto dall’utente (non dal progettista della rete), che magari riceve 4 KB di TPDU
ma le legge un byte per volta
Questo fatto obbliga a separare la funzione dell’acknowledge dalla
definizione della window disponibile (cioe’ dei buffer disponibili in ricezione)
Di fatto il ricevente puo’ inviare un riscontro relativo a tutte le TPDU ricevute,
ma comunque indicare disponibilita’ di buffer a zero (quindi bloccare il
trasmittente) perche’ l’applicativo non le ha prelevate
Quando l’applicativo libera uno o piu’ buffer, il ricevente inviera’ un nuovo
ack (relativo sempre all’ultima TPDU rucevuta) ma comunicando la nuova
disponibilita’ di buffer


questo puo’ generare uno stallo, perche’ le TPDU di controllo non vengono
riscontrate e non hanno timeout: se l’ultima TPDU (ack+nuovi buffer liberi) si
perde, il trasmittente resta fermo ed il ricevente pure
per risolvere questa situazione ogni host deve periodicamente trasmettere una
TPDU di controllo per fornire l’ack e la situazione dei buffer
18
Controllo della congestione



Quando il collo di bottiglia e’ la rete, il controllo di flusso
non e’ sufficiente
Il controllo di questa situazione nel livello di trasporto e’
compito del trasmittente
Il livello di trasporto non definisce meccanismi;
generalmente a livello pratico si utilizza la tecnica
seguente:



il trasmittente utilizza come parametro di misura il numero di
TPDU che non hanno ricevuto un ack prima del timeout
ciclicamente viene effettuata una analisi di questo dato
quando si verifica un aumento dei timeout, il trasmittente riduce
la velocita’ di trasmissione, ad esempio riducendo la window size
(anche se c’e’ disponibilita’ di buffer in ricezione)
19
Indirizzamento: TSAP


Un processo applicativo deve specificare a quale applicazione remota
vuole connettersi
Lo strato di trasporto puo’ servire contemporaneamente diverse
applicazioni




quando riceve una connection request, (o dati in una trasmissione
connection less) deve sapere a quale applicazione trasmetterli
E’ necessario quindi associare univocamente ad una applicazione un
punto di accesso al trasporto
In pratica si devono utilizzare indirizzi a livello di trasporto, per
identificare l’applicazione destinataria dei dati
Questi indirizzi in OSI sono chiamati TSAP (Transport Service Access
point)

in TCP/IP esiste una cosa equivalente: in questo caso gli indirizzi sono
chiamati porte
21
Quale TSAP?



Un applicativo server deve quindi registrarsi presso il
protocollo di trasporto (tramite la primitiva LISTEN) per
creare la associazione “applicazione-TSAP”
L’applicativo client, per connettersi con il server, deve
sapere a priori a quale TSAP remoto (di quale NSAP
remoto, cioe’ di quale indirizzo di rete) connettersi
Per conoscere l’NSAP, generalmente esiste un applicativo
di conversione nome-indirizzo che risolve questo
problema (si presuppone che almeno si conosca il nome)



in OSI si chiama servizio di directory (X.500)
in TCP/IP si chiama Domain Name System
Per conoscere il TSAP si puo’ (parzialmente) utilizzare un
sistema simile
22
TSAP “ben noti”

La soluzione adottata usualmente e’ quella di associare
sempre lo stesso TSAP a tutte le applicazioni server (sui
diversi host) che svolgono la stessa funzione






server
server
server
server
server
web
di posta elettronica
di connessione remota
di sincronizzazione oraria
di file transfer
L’applicativo client in questo modo puo’ specificare al
livello di trasporto a quale TSAP di quale host deve essere
fatta la connessione, in quanto il TSAP e’ predefinito dallo
standard dell’applicativo server
23
TSAP ad hoc

I TSAP ben noti sono quelli che offrono servizi standardizzati




servizi che rispondono ad un protocollo ben definito
generalmente lo standard specifica il TSAP da utilizzare (piu’ spesso si
limita a suggerirlo)
in TCP/IP esiste un sistema che, analogamente al DNS, associa una
stringa di caratteri alle porte dei servizi, ma a differenza del DNS non e’
distribuito: le associazioni si trovano in un file di testo residente sull’host
e letto dagli applicativi (/etc/services in unix-linux)
Se si devono utilizzare applicativi sviluppati per funzioni specifiche, la
strategia da utilizzare e’ quella di definire un TSAP per questo servizio
sulle sole macchine interessate dalla applicazione


il client in qualche modo deve essere messo al corrente del TSAP da
utilizzare
buona norma e’ quella di non utilizzare TSAP assegnati ai servizi
standardizzati
24