1 Livello Trasporto

Transcript

1 Livello Trasporto
Livello Trasporto
Fornire un trasporto affidabile ed efficace dall'host di origine a quello di
destinazione, indipendentemente dalla rete utilizzata
Gestisce una conversazione diretta fra sorgente e destinazione
Il software di livello trasporto è presente solo sugli host, non nei router
della sottorete di comunicazione
Liv.
Servizi - vari tipi offerti ai
Applic.
livelli superiori, realizzati
tramite servizi del livello rete;
trasporto informazioni fra
Liv.
entità trasporto su diversi
Transport
host
• servizi affidabili orientati
alla connessione (tipici) Liv.
Network
• servizi datagram
TSAP
address
Transport
Entity
TPDU
Transport
Entity
NSAP
address
Trasporto
Isolare i livelli superiori dai dettagli implementativi della subnet di comunicazione
- primitive (di definizione di accesso ai servizi) semplici da utilizzare ed
indipendenti dai servizi dei livelli sottostanti
- usate dalle applicazioni di rete che si basano sui servizi di livello trasporto
Possibile specifica della QoS (Quality of Service) desiderata
specie per servizi con connessione
• max ritardo di attivazione della connessione
• throughput richiesto
• max ritardo di transito ammesso
• tasso d'errore tollerato
• distribuite
• tipo di protezione da accessi non autorizzati ai dati in transito
- fase di negoziazione della QoS fra entità, anche funzione dei servizi di rete
- accordo valido per la durata della connessione
Es. di Primitive - TPDU spedito
accept()
----- (Si blocca finché qualcuno cerca di connettersi)
connect()
conn.request
send()
dati
receive()
----- (Si blocca finché arriva un TPDU)
disconnect()
disconn.request
RT5.2
1
Protocolli
Protocolli di livello trasporto per realizzare le funzioni di
• controllo degli errori
• controllo di flusso
• riordino dei TPDU
Differenze fra livello data link (2) e trasporto (4)
• nel livello 2 un singolo canale di comunicazione fra entità paritarie
• nel livello 4 vi è l'intera subnet di comunicazione fra entità paritarie
A livello trasporto
• occorre indirizzare esplicitamente il destinatario
• è più complicato stabilire la connessione
• data la capacità di memorizzazione della rete, si possono ricevere TPDU
inaspettati a destinazione
• buffering e controllo di flusso richiedono un approccio differente che nel
livello data link, a causa del numero molto variabile di connessioni che si
possono avere di momento in momento
RT5.3
Protocolli
TSAP address (Transport Service Access Point address)
(NSAP address, informazione supplementare)
Es: Internet TSAP address (indirizzo TCP o UDP) (IP address:port number)
IP address -> NSAP address, port number -> l'informazione supplementare
determina implicitamente l'indirizzo di liv. 3 da usare per stabilire la connessione
altrimenti occorre un servizio per il mapping fra gli indirizzi di livello 4 e 3
Attivazione e disattivazione della connessione
problemi di gestione dei duplicati
attivazione: protocollo three-way handshaking
• il richiedente invia un TPDU di tipo conn.request con un numero x
proposto come inizio della sequenza
• il destinatario invia un TPDU di tipo ack con:
> conferma di x
> proposte di un proprio numero y di inizio sequenza
• il richiedente invia un TPDU di tipo dati contenente:
> i primi dati del dialogo
> la conferma di y
RT5.4
2
Protocollo three-way-handshake 1/2
Mittente
Destinatario
conn.request(seq=x)
ack(seq=y, ack=x)
Mittente
Destinatario
data(seq=x,ack=y)
conn.request(seq=x)
ack(seq=y, ack=x)
Funzionamento normale
reject(ack=y)
Duplicato di richiesta di attivazione
RT5.5
Protocollo three-way-handshake 2/2
Mittente
Destinatario
conn.request(seq=x)
ack(seq=y, ack=x)
data(seq=x, ack=z)
Duplicati di richiesta di attivazione
reject(ack=y)
e del primo TPDU dati
z precedente a y: destinatario scarta
RT5.6
3
Controllo del flusso
Protocolli a finestra scorrevole
Differenze fra livello 2 e 4
• il livello 2 non ha alcun servizio di appoggio (eccetto la trasmissione
fisica); Il livello 4 usa i servizi del livello 3 (affidabili o no)
• il numero di connessioni data link è relativamente piccolo e stabile nel
tempo, mentre le connessioni trasporto sono anche molte e di numero
ampiamente variabile nel tempo
• le dimensioni dei frame sono stabili, quelle dei TPDU molto più variabili
Se il livello trasporto dispone solo di servizi di livello 3 di tipo datagram
• l’entità (4) sorgente deve mantenere in un buffer i TPDU spediti finché
non sono confermati (come nel livello 2)
• l’entità (4) destinatario mantiene un pool di buffer globale e può perdere
TPDU; il mittente ritrasmette fino a conferma
RT5.7
Controllo del flusso e buffering
Se i servizi network di tipo affidabile
- se il mittente sa che il ricevente ha sempre spazio disponibile può evitare di
mantenere buffer, poiché ciò che spedisce arriva sicuramente a destinazione e
viene sempre accettato dal destinatario
- altrimenti il mittente deve mantenere i buffer perché il destinatario potrebbe
non accettare i TPDU
Gestione buffering - grande variabilità di dimensione dei TPDU
• pool di buffer uguali: poco adatto
• pool di buffer di dimensioni variabili: gestione più complessa, ma efficace
• singolo array (grande) per connessione, gestito circolarmente: adatto per
connessioni gravose, spreco di spazio per quelle con poco scambio
regole in base al tipo di traffico
• traffico bursty ma poco gravoso: niente buffer a destinazione, bastano
buffer alla sorgente
• traffico gravoso: buffer grandi a destinazione
accordo al setup di connessione
RT5.8
4
Multiplex 1/2
multiplexing delle conversazioni di livello trasporto su quelle di livello rete
per connessioni rete costose: più conversazioni trasporto su una di rete
upward multiplexing
TSAP
Trasporto
Rete
NSAP
Linea
del router
Data link
Fisico
RT5.9
Multiplex 2/2
per ottenere una banda superiore a quella consentita a una singola
connessione rete, ripartire la conversazione trasporto su più connessioni rete
downward multiplexing
TSAP
Trasporto
Rete
Data link
Fisico
NSAP
Canale
satellitare
Esempio:
•sottorete - controllo a finestra
scorrevole 8 bit
•canale fisico satellitare
540msec round-trip delay
•pacchetti 128 byte: max data
rate del mittente 28-1
pacchetti ogni 540msec banda di 484 kbps (ma la
banda del canale è 100 volte
superiore)
•una connessione a livello
trasporto su 10 di livello rete
-->banda 10 volte maggiore
RT5.10
5
Internet: livello trasporto
Due protocolli
• TCP (Transmission Control Protocol)
• UDP (User Data Protocol)
TCP : progettato per fornire un flusso di byte affidabile ed orientato alla
connessione da sorgente a destinazione su una rete non affidabile
• accetta dati dal livello applicazione
• li spezza in segment (TPDU, max 64 Kbyte, tipicamente ca. 1.500 byte)
• li consegna al livello 3, eventualmente ritrasmettendoli
• ricevere segmenti dal livello 3
• li rimette in ordine (elimina buchi e duplicati)
• consegna i dati ordinati al livello applicazione
Servizio full-duplex con gestione di ack e controllo del flusso
Servizi TCP ottenuti creando connessione di livello 4 identificata da una coppia
di punti d'accesso detti socket
socket number (TSAP)
IP address: Port number
Su un host anche più connessioni sullo stesso numero
RT5.11
Socket
Port number:16 bit
well-known port <256, riservati a servizi standard
Port number
Servizio
7
Echo
20
Ftp (control)
21
Ftp (data)
23
Telnet
25
Smtp
80
Http
110
Pop versione 3
- Flusso di byte, non di messaggi
in TCP sono non definiti/preservati i confini fra msg
- Le entità TCP suddividono il flusso dal livello applicazione in segmenti,
li trasmettono e li ricombinano in un flusso poi consegnato al livello
applicazione di destinazione
- Possibile invio immediato di dati - flag urgent che provoca l’interruzione della
applicazione
RT5.12
6
Protocollo TCP
• ogni byte del flusso TCP ha un numero d'ordine a 32 bit usato sia per il
controllo di flusso che per la gestione degli ack
• un segmento TCP <= 65.535 byte e formato da: header con parte fissa
(20 byte) e una parte opzionale e dati
• TCP usa un meccanismo di finestra scorrevole di tipo go-back-n con
timeout. Ritrasmissione a scadenza
Sequence number
# del primo byte nel campo dati
Ack. number
# del prossimo byte aspettato
TCP header length
quante parole di 32 bit nell'header
URG
1 se urgent pointer è usato, 0 altrimenti
ACK
1 se l'ack number è valido, 0 altrimenti
PSH
dati urgenti (pushed data), da consegnare senza aspettare buffer pieno
RST
richiesta di reset
SYN
in fase di setup della connessione
(SYN=1 ACK=0 richiesta connessione - SYN=1 ACK=1 accettata conn.)
FIN
per rilasciare una connessione
Window size
# byte spedibili a partire da quello che confermato con l'ack #
Checksum
simile a IP
RT5.13
Formato segmento TCP
32 bit
Source port
Destination port
Sequence number
Ack. number
UA PRS F
R CS S Y I
GK HT N N
TCP
header len.
Checksum
Window size
Urgent pointer
Options (zero o più parole di 32 bit)
Dati (opzionali)
Options fra le più importanti, negoziabili al setup:
•dimensione massima dei segmenti da spedire
•uso di selective repeat invece che go-back-n
•uso di NAK
RT5.14
7
Controllo della Congestione
TCP assume che, se gli ack non tornano in tempo, ciò sia dovuto a
congestione della subnet piuttosto che a errori di trasmissione
Problemi:
• scarsità di buffer a destinazione
• congestione della subnet
Gestione tramite una specifica finestra del mittente:
• finestra del buffer del ricevitore
• la congestion window, quanto è spedibile senza causare congestione
min
Gestione della congestion window
• dimensione iniziale: max segmento usato nella connessione
• per ogni ack a tempo la finestra raddoppia fino a un threshold poi
aumenta linearmente di un segmento per volta
• quando si verifica un timeout per un segmento:
• il valore di threshold viene impostato alla metà della dimensione
della congestion window
• la dimensione della congestion window viene impostata alla
dimensione del max segmento usato nella connessione
RT5.15
Esempio di controllo di congestione TCP
Congestion window è 40K, si verifica un timeout
40K
32K
Threshold
viene ridotta
(da 32K a 20K)
20K
16K
8K
4K
2K
1K
Congestion window è 1K
Congestion window torna ad 1K
RT5.16
8
Protocollo UDP
fornisce un flusso di byte non affidabile ed non connesso
utile per inviare dati senza connessione (es. client-server)
Header
32 bit
Source port
Destination port
UDP length
UDP checksum
funzione di calcolo del checksum disattivabile
es: traffico real-time per cui è più importante mantenere un'elevato
tasso di arrivo dei segmenti che evitare i rari possibili errori
RT5.17
9