1
Sistemi e Tecnologie della Comunicazione
Lezione 22: transport layer: introduzione, funzionalita’
2
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
3
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 l’utente della rete non 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
4
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)
6
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
in OSI si chiamano TPDU (Transport Protocol Data Unit) in TCP/IP si chiamano segmenti (ma spesso anche
pacchetti) Il protocollo si dovra’ occupare dei meccanismi per
gestire i diversi eventi (ove necessari): 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
7
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 pacchetto o arriva o non arriva, mentre a livello 4 la sottorete provoca ritardi e riapparizione di pacchetti che si credevano perduti e quindi 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
8
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 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
9
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
10
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 in cui propone un certo valore iniziale di sequenza
il server risponde con un acknowledge che riporta il valore iniziale di sequenza proposto dal client, ed il 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)
11
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
12
Handshake a tre vie (cont.)
In figura e’ mostrato cosa accade se arriva una Connection Request ritardata relativa ad una vecchia connessione, seguita dalla TPDU di acknowledge finale, anch’essa ritardata
Poiche’ host 2 ha proposto come seq il valore y e riceve l’acknowledge per z si accorge che deve scartare la TPDU
13
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
14
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)
15
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 ACKe chiude la connessione
in caso di perdita delle TPDU i timeout provocheranno, a seconda dei casi, una ritrasmissione o il rilascio definitivo della connessione anche in assenza di riscontro
Questa soluzione garantisce quasi sempre che nessun dato venga perduto
16
Rilascio simmetrico (cont.)
17
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
lo strato applicativo potrebbe liberare i buffer in ricezione in modo lento, generando una situazione in cui una TPDU e’ stata riscontrata in quanto ricevuta, ma il buffer allocato dalla TPDU non e’ ancora libero
18
Alternative in funzione della sottorete
In caso di sottorete inaffidabile, il trasmittente deve mantenere i dati nei buffer
in questo caso il ricevente potrebbe non utilizzare buffer specifici per la connessione, ma ad esempio un pool di buffer per tutti, richiedendo la disponibilita’ di buffer dinamicamente e scartando le TPDU in caso di indisponibilita’ (comunque il trasmittente conserva i dati)
Se la sottorete offre un servizio affidabile: se il ricevente rende disponibili buffer in ricezione, il
trasmittente potrebbe farne a meno se pero’ il ricevente non puo’ garantire spazio sufficiente
di buffer, l’affidabilita’ della sottorete garantisce il recapito ma non l’accettazione, quindi la risorsa di buffer deve essere allocata anche in trasmissione
19
Alternative in funzione della TPDU size
Se le TPDU hanno generalmente una dimensione simile si puo’ allocare un pool di buffer uguali
In caso contrario questa soluzione rappresenta uno spreco di risorse
utilizzare buffer di dimensioni medie puo’ essere piu’ efficiente, ma le TPDU di grosse dimensioni vanno a occupare piu’ buffer, complicandone notevolmente la gestione
possono essere utilizzati buffer a dimensione variabile, ma anche questo complica la gestione dei dati
una terza possibilita’ e’ l’utilizzo di un grosso buffer circolare per ogni connessione
in questo caso si semplifica la gestione dei buffer, ma di nuovo si ha spreco di risorse per connessioni a basso carico trasmissivo
20
Alternative in funzione della applicazione
Applicazioni che utilizzano TPDU piccole possono essere efficientemente gestite tramite un pool comune ed allocazione dinamica dei buffer in trasmissione e ricezione (TPDU piccole significa buona probabilita’ di trovare buffer disponibili)
Applicazioni tipo file transfer richiedono invece la disponibilita’ in ricezione di un pool di buffer pari alla window size (come nel caso del data link layer), per sfruttare al meglio la banda disponibile
21
Gestione dinamica dei buffer
Poiche’ le caratteristiche delle diverse connessioni possono cambiare rapidamente, e le esigenze sono differenti, la soluzione adottata e’ che le due parti regolino dinamicamente le allocazioni
ad esempio, se due stazioni dedicano un pool comune di buffer alle connessioni attive tra i due host, e ad un certo punto il numero di connessioni aumenta, il ricevitore potra’ comunicare al trasmittente che il numero di buffer per una singola connessione e’ diminuito
Il protocollo di trasporto deve prevedere questa possibilita’
22
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
23
Separazione ack/window size
Tuttavia, come gia’ detto, 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 trasmesse, ma comunque indicare disponibilita’ di buffer a zero (quindi bloccare il trasmittente)
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
24
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)
25
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
26
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
27
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 web server di posta elettronica server di connessione remota server di sincronizzazione oraria server 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
28
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
Top Related