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