R. Cusani F. Cuomo, Telecomunicazioni - Transport layer: Introduzione e funzionalità, Maggio 2010

Transcript

1 1 20: Transport layer: Introduzione e funzionalità Sommario 2 Funzione del livello di trasporto Ritardo dei pacchetti e numeri di sequenza Handshake a tre vie Rilascio Controllo di flusso e buffering Controllo della congestione TSAP (Transport Service Access point) 1

2 Funzione del livello di trasporto 3 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 complessità per OSI lo strato superiore è il livello di sessione per TCP/IP lo strato superiore è il livello di applicazione Per assolvere le sue funzioni lo strato di trasporto utilizza i servizi dello strato di rete Necessità dello strato di trasporto 4 Perchè 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 può tenere sotto controllo cosa accade ai dati una volta che lasciano l host sorgente lo strato di trasporto rende trasparente allo strato superiore la complessità (l esistenza!) della sottorete Uno strato intermedio tra applicazione e rete offre 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 2

3 Servizi forniti allo strato superiore 5 Lo strato di trasporto può offrire un servizio: affidabile orientato alla connessione inaffidabile non orientato alla connessione con caratteristiche analoghe ai servizi equivalenti dello strato di rete il servizio orientato alla connessione realizza un trasferimento dei dati affidabile (controllo della integrità, 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 Servizi forniti allo strato superiore 6 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 dovrà farsi carico di operare azioni correttive (se necessarie) 3

4 Protocollo di trasporto 7 Il livello di trasporto realizza le sue funzioni comunicando con il processo paritario secondo un protocollo definito Le informazioni sono scambiate trasmettendo 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 dovrà 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 Differenze rispetto al data link 8 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 è molto più elevato che nel caso del data link layer: non sarà possibile dedicare a tutte i buffer necessari alle comunicazioni 4

5 Ritardo dei pacchetti e numeri di sequenza 9 Come per il 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 necessità sulla scelta dei numeri di sequenza Partire sempre da 0 può comportare dei problemi, esempio: 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 (continua) Ritardo dei pacchetti e numeri di sequenza 10 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 verrà accettata e si ha un errore 5

6 Ritardo dei pacchetti e numeri di sequenza 11 Per ovviare a questo problema, si devono prendere delle precauzioni lo strato di rete deve poter invalidare pacchetti troppo vecchi in questo modo un numero di sequenza già utilizzato può essere riutilizzabile dopo un tempo pari o superiore al tempo di vita massimo dei pacchetti la assegnazione dei numeri di sequenza iniziali deve assicurare 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 Stabilire la connessione 12 Il problema della inaffidabilità della sottorete e dei duplicati ritardati si presenta anche nella fase di inizializzazione della connessione Per risolverli si usa un meccanismo detto handshake a 3 vie: 1. il client invia una TPDU di Connection Request priva di dati, in cui propone un certo valore iniziale di sequenza 2. 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 3. 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 può anche trasportare i primi dati) 6

7 Handshake a tre vie 13 Risolve i problemi di duplicati sulla rete, a meno che non esistano contemporaneamente sulla rete TPDU con stesso numero di sequenza procedura normale Connection Request ritardata relativa ad una vecchia connessione Handshake a tre vie (cont.) 14 Esempio: arriva una Connection Request ritardata relativa ad una vecchia connessione, seguita dalla TPDU di ack finale, anch essa ritardata Poiché host 2 ha proposto come seq il valore y e riceve l ack per z, si accorge che deve scartare la TPDU 7

8 Rilascio della connessione 15 Anche qui ci sono problemi da affrontare La connessione può 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 può comportare la perdita di dati: dopo la disconnessione l host 2 non accetta più i dati in ingresso Rilascio simmetrico 16 Rilascio simmetrico avviene con 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 8

9 Rilascio simmetrico (cont.) 17 Rilascio simmetrico (cont.) 18 9

10 Controllo di flusso e buffering 19 Come per il data link layer, il controllo di flusso può essere gestito tramite un protocollo sliding window Ciò implica di dedicare buffer in trasmissione per contenere le TPDU inviate e non ancora riscontrate, e buffer in ricezione per contenere dati ricevuti in ordine non corretto A livello di trasporto sorgono problemi rispetto al livello data link un host può dover gestire a livello di trasporto centinaia di connessioni contemporanee: occorrono risorse per i buffer 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 può costituire un problema Buffer dinamici come window size 20 Gestione dinamica dei buffer per le diverse connessioni: la quantità di buffer disponibili varia nel tempo per la singola connessione Ciò permette al ricevente di regolare la velocità del trasmittente in funzione della quantità di buffer disponibili in ricezione; di fatto il numero di buffer disponibili in ricezione definisce la window size Meccanismo protocollare: 1. il trasmittente (all atto dell attivazione della connessione) richiede un certo numero di buffer in funzione delle sue esigenze 2. il ricevente risponde concedendo il numero di buffer che può offrire, ed il ricevente memorizza il numero e tiene conto della disponibilità di buffer in ricezione durante tutta la trasmissione (continua) 10

11 Buffer dinamici come window size ad ogni TPDU inviata il trasmittente riduce il numero di buffer che il ricevente ha disponibili 4. quando arriva a zero il trasmittente si ferma 5. ad ogni acknowledge, il ricevente comunica quanti buffer ha disponibili (questo numero può essere inferiore al buffer iniziale meno dati ricevuti e non riscontrati: il trasmittente aggiorna la finestra di ricezione ad ogni ack ricevuto) Separazione ack/window size 22 Gli eventi TPDU riscontrata e buffer liberato nello strato di trasporto non sono contemporanei questo è essenzialmente dovuto al fatto che chi libera il buffer è 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 (cioè dei buffer disponibili in ricezione) Di fatto il ricevente può inviare un riscontro relativo a tutte le TPDU ricevute, ma comunque indicare disponibilità di buffer a zero (quindi bloccare il trasmittente) perchè l applicativo non le ha prelevate 11

12 Separazione ack/window size 23 Quando l applicativo libera uno o più buffer, il ricevente invierà un nuovo ack (relativo sempre all ultima TPDU rucevuta) ma comunicando la nuova disponibilità di buffer questo può generare uno stallo, perchè 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 Controllo della congestione 24 Quando il collo di bottiglia è la rete, il controllo di flusso non è sufficiente Il controllo di questa situazione nel livello di trasporto è 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 velocità di trasmissione, ad esempio riducendo la window size (anche se c è disponibilità di buffer in ricezione) 12

13 Modifica dinamica dei timeout 25 La definizione del valore dei timeout ha conseguenze sulla efficienza del trasporto i tempi di intervallo tra trasmissione e ricezione di ACK variano in funzione del carico sui router attraversati valori efficienti in condizioni di scarico possono generare ritrasmissioni in condizioni di carico, anche in assenza di congestione valori troppo lunghi sono inefficienti Il trasporto può utilizzare la misura continua del rtt per calibrare dinamicamente i valori di timeout utilizzati si utilizza sempre una soglia che identifica una condizione di congestione della sottorete Indirizzamento: TSAP (Transport Service Access point) 26 Un processo applicativo deve specificare a quale applicazione remota vuole connettersi Lo strato di trasporto può servire al tempo stesso più applicazioni quando riceve una connection request, (o dati in una trasmissione connection less) deve sapere a quale applicazione trasmetterli è 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 13

14 Quale TSAP? 27 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, cioè 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 può (in parte) utilizzare un sistema simile TSAP ben noti 28 La soluzione adottata usualmente è 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 può specificare al livello di trasporto a quale TSAP di quale host deve essere fatta la connessione, in quanto il TSAP è predefinito dallo standard dell applicativo server 14

15 TSAP ad hoc 29 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 (più 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 è distribuito: le associazioni si trovano in un file di testo residente sull host e letto dagli applicativi (/etc/services in unix-linux) TSAP ad hoc 30 Se si devono utilizzare applicativi sviluppati per funzioni specifiche, la strategia da utilizzare è 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 è quella di non utilizzare TSAP assegnati ai servizi standardizzati 15