Capitolo 3 Livello Trasporto .

Capitolo 3: Indice 3.1 Introduzione 3.2 Protocolli di livello trasporto 3.3 Il protocollo UDP (User Datagram Protocol) 3.4 Il protocollo TCP (Transmission Control Protocol)

Capitolo 3: Contenuti Si introducono i servizi generici che normalmente ci si aspetta dal livello trasporto, quali la comunicazione tra processi, l’indirizzamento, il multiplexing/demultiplexing, il controllo degli errori, della congestione e di flusso. Si descrivono i meccanismi di base del livello trasporto quali Stop-and-Wait, Go-Back-N e Selective-Repeat. Si approfondisce UDP, il più semplice dei due protocolli discussi nel capitolo. Si approfondisce il protocollo TCP. Per prima cosa se ne elencano le caratteristiche e i servizi, successivamente si illustra con un diagramma delle transizioni come tale protocollo fornisca un servizio orientato alla connessione. Infine si approfondiscono i servizi di controllo di flusso, degli errori e della congestione. 1.#

3.1 Introduzione Il livello trasporto fornisce un servizio di comunicazione tra processi fra i due livelli applicazione. Il servizio di comunicazione viene fornito tramite una connessione logica, che consente ai due livelli applicazione (che possono essere situati in qualsiasi parte del mondo) di lavorare come se ci fosse una connessione diretta attraverso la quale inviare e ricevere i messaggi.

Figura 3.1: Connessione logica a livello trasporto

3.1.1 I servizi del livello trasporto Come discusso nel Capitolo 1, il livello trasporto si colloca fra il livello rete e il livello applicazione: fornisce quindi servizi al livello applicazione e riceve servizi dal livello rete. In questo paragrafo si descrivono i servizi che possono essere forniti dal livello trasporto, nel paragrafo successivo si descrivono alcuni protocolli di questo livello.

3.1.1 Servizi (continuazione) Comunicazione tra processi Indirizzamento: i numeri di porta Intervalli ICANN Numeri di porta noti Numeri di porta registrati Numeri di porta dinamici Incapsulamento/decapsulamento Multiplexing e demultiplexing

3.1.1 Servizi (continuazione) Controllo di flusso Pushing e Pulling Controllo del flusso Impiego di due buffer Controllo degli errori Numero di sequenza Numero di riscontro Integrazione del controllo degli errori e del controllo di flusso Sliding Window

3.1.1 Servizi (continuazione) Controllo della congestione Servizi orientati alla connessione e servizi privi di connessione Servizi privi di connessione Servizi orientati alla connessione Automa a stati finiti 1.#

Figura 3.2: Livello rete e livello trasporto a confronto 1.#

Figura 3.3: Numeri di porta 1.#

Figura 3.4: Indirizzi IP e numeri di porta a confronto 1.#

Figura 3.5: Intervalli ICANN 1.#

Esempio 3.1 Nell’ambiente UNIX le porte note sono memorizzate nel file /etc/services. Per estrarre dal file la linea corrispondente all’applicazione desiderata si può utilizzare il comando grep: SNMP (Capitolo 8) utilizza due numeri di porta (161 e 162), ciascuno con uno scopo differente:

Figura 3.6: Socket address 1.#

Figura 3.7: Incapsulamento e decapsulamento 1.#

Figura 3.8: Multiplexing e demultiplexing 1.#

Figura 3.9: Controllo di flusso al livello trasporto 1.#

Figura 3.10: Controllo degli errori a livello trasporto 1.#

Figura 3.11: Finestra scorrevole con rappresentazione circolare 1.#

Figura 3.12: Finestra scorrevole con rappresentazione lineare 1.#

Figura 3.13: Servizi privi di connessione 1.#

Figura 3.14: Servizi orientati alla connessione 1.#

Figura 3.15: Servizi orientati alla connessione e privi di connessione rappresentati come FSM 1.#

3.2 Protocolli di livello trasporto È possibile sviluppare un protocollo di livello trasporto combinando un insieme dei servizi descritti nei paragrafi precedenti. Per meglio comprendere il comportamento di questi protocolli, si inizia descrivendo il più semplice possibile per poi aumentarne gradualmente la complessità. 1.#

3.2.1 Un protocollo semplice Si studia per primo un protocollo semplice, privo di connessione, senza controllo degli errori e del flusso. Si suppone che il destinatario sia in grado di gestire immediatamente tutti i pacchetti ricevuti; in altri termini, il destinatario non viene mai sovraccaricato dai pacchetti in arrivo. La Figura 3.16 illustra lo schema di questo protocollo. FSM 1.#

Figura 3.16: Protocollo semplice 1.#

Figura 3.17: FSM per il protocollo semplice 1.#

Esempio 3.2 La Figura 3.18 illustra un esempio di comunicazione usando questo protocollo. È molto semplice: il mittente invia pacchetti uno dopo l’altro senza pensare al destinatario.

Figura 3.18: Diagramma di flusso dell’Esempio 3.2 1.#

3.2.2 Stop-and-Wait Il secondo meccanismo preso in considerazione è orientato alla connessione ed è chiamato Stop and Wait; utilizza sia il controllo di flusso sia il controllo degli errori. Il mittente e il destinatario usano entrambi una finestra scorrevole di dimensione 1. Il mittente invia un pacchetto alla volta e ne attende l’ack (riscontro) prima di poter spedire il successivo. Per rilevare i pacchetti corrotti è necessario aggiungere un valore checksum (valore di controllo) a ogni pacchetto dati. 1.#

3.2.2 Stop-and-Wait (continuazione) Numeri di sequenza e di riscontro FSM Mittente Destinatario Efficienza 1.#

Figura 3.19: Stop-and-Wait 1.#

Figura 3.20: FSM per il meccanismo Stop and Wait 1.#

Esempio 3.3 La Figura 3.21 illustra un esempio di diagramma di flusso del meccanismo Stop and Wait. Il pacchetto 0 viene inviato e riscontrato. Il pacchetto 1 viene perso e rispedito alla scadenza del timeout. Il pacchetto 1 rispedito viene confermato e il timer viene interrotto. Il pacchetto 0 viene spedito e confermato, ma l’ack viene perso. Il mittente, scaduto il timeout, non può sapere se si sia perso il pacchetto o il riscontro: rispedisce quindi il pacchetto 0 che viene confermato.

Figura 3.21: Diagramma di flusso dell’Esempio 3.3 1.#

Esempio 3.4 In un sistema che utilizza un meccanismo Stop and Wait, l’ampiezza di banda del canale è di 1 Mbps; il tempo necessario a 1 bit per fare un viaggio di andata e ritorno è di 20 millisecondi. Quanto vale il prodotto banda-ritardo? Se i pacchetti dati del sistema hanno dimensione di 1000 bit, qual è la percentuale di utilizzo del canale? Souzione Il prodotto banda-ritardo è pari a (1 × 106) × (20 × 10–3) = 20 000 bit. Il sistema potrebbe inviare 20 000 bit nel tempo necessario ai dati per andare dal mittente al ricevente e per ottenerne il riscontro, tuttavia invia solamente 1000 bit. Si può affermare che il coefficiente di utilizzo del canale è solamente di 1000/20 000, ovvero del 5%.

Esempio 3.5 Qual è la percentuale di utilizzo del canale dell’Esempio 3.4, se si impiega un protocollo che può inviare fino a 15 pacchetti prima di fermarsi e preoccuparsi del riscontro? Soluzione Il prodotto banda-ritardo è sempre 20 000 bit. Il sistema può inviare fino a 15 pacchetti o 15 000 bit nel tempo di andata e ritorno. Quindi il coefficiente di utilizzo è di 15 000/20 000, ovvero del 75%. Naturalmente se vi fossero dei pacchetti persi o corrotti, la percentuale di utilizzo sarebbe inferiore poiché sarebbe necessario rispedirli.

3.2.3 Go-Back-N (GBN) Per migliorare l’efficienza di trasmissione (in altri termini per riempire la condotta) si devono avere più pacchetti in transizione mentre il mittente è in attesa dei riscontri. In questo paragrafo si discute un primo meccanismo che consente di raggiungere questo obiettivo, che è chiamato Go-Back-N (GBN) (riparti da N). Questo meccanismo, così come il successivo (Selective Repeat), adotta la tecnica del pipelining, ovvero permette di inviare più pacchetti senza dover attendere il riscontro ai primi pacchetti inviati. 1.#

3.2.3 Go-Back-N (continuazione) Numeri di sequenza e di riscontro Finestra di invio Finestra di ricezione Timer e rispedizione dei pacchetti 1.#

3.2.3 Go-Back-N (continuazione) FSM Mittente Destinatario Dimensione della finestra di invio Confronto fra Go-Back-N e Stop-and-Wait 1.#

Figura 3.22: Schema generale del meccanismo Go-Back-N 1.#

Figura 3.23: Finestra di invio per il meccanismo Go-Back-N 1.#

Direzione scorrimento Figura 3.24: Scorrimento della finestra di invio Direzione scorrimento 1.#

Figura 3.25: Finestra di ricezione per il meccanismo Go-Back-N 1.#

Figura 3.26: FSM per il meccanismo Go-Back-N 1.#

Figura 3.27: Dimensione della finestra di invio per Go-Back-N 1.#

Esempio 3.6 La Figura 3.28 illustra un esempio di diagramma di flusso con il meccanismo Go-Back-N. Si tratta di un caso in cui il canale in invio è affidabile, a differenza del canale nella direzione opposta. I pacchetti dati non vengono mai persi, ma alcuni riscontri risultano ritardati e uno viene perso. L’esempio dimostra come i riscontri cumulativi possono essere di aiuto nel caso in cui le conferme vengano ritardate o perse.

Figura 3.28: Diagramma di flusso dell’Esempio 3.6

Esempio 3.7 La Figura 3.29 illustra ciò che avviene quando si perde un pacchetto. I pacchetti 0, 1, 2 e 3 vengono inviati ma viene smarrito il pacchetto 1. Il destinatario riceve i pacchetti 2 e 3, ma questi vengono scartati poiché ricevuti fuori sequenza (il pacchetto atteso è il numero 1). Quando il destinatario riceve i pacchetti 2 e 3, invia un riscontro ACK 1 per indicare che si attende il pacchetto 1. Questi riscontri non sono utili al mittente poiché l’ackNo è uguale a Sf, non è strettamente maggiore di Sf; quindi vengono ignorati. Quando scade il timeout, il mittente rispedisce i pacchetti 1, 2 e 3, che vengono riscontrati.

Figura 3.29: Diagramma di flusso per l’Esempio 3.7 1.#

3.2.4 Selective-Repeat Il meccanismo Go-Back-N semplifica i compiti del destinatario, che tiene traccia di una sola variabile e non deve bufferizzare i pacchetti fuori sequenza: questi vengono semplicemente ignorati. È stato sviluppato un altro meccanismo, chiamato Selective-Repeat (SR) o ripetizione selettiva, che, come indicato dal nome, rispedisce i pacchetti selettivamente, ovvero solo quelli che sono realmente stati smarriti. Lo schema generale di questo protocollo è rappresentato nella Figura 3.30. 1.#

3.2.4 Selective-Repeat (continuazione) Finestre Timer Riscontri FSM Mittente Destinatario 1.#

Figura 3.30: Schema generale del meccanismo Selective-Repeat 1.#

Figura 3.31: Finestra di invio del meccanismo Selective-Repeat 1.#

Figura 3.32: Finestra di ricezione nel meccanismo Selective-Repeat 1.#

Esempio 3.8 Un mittente invia 6 pacchetti: 0, 1, 2, 3, 4 e 5. Riceve un riscontro con ackNo = 3. Qual è la sua interpretazione se il sistema utilizza GBN? E se utilizza SR? Soluzione Se il sistema utilizza GBN, significa che i pacchetti 0, 1 e 2 sono stati ricevuti correttamente e che il destinatario si attende il pacchetto 3. Se il sistema utilizza SR, significa che il pacchetto 3 è stato ricevuto integro, senza alcuna informazione riguardo ad altri pacchetti.

Figura 3.33 FSM per il meccanismo Selective-Repeat 1.#

Esempio 3.9 Questo caso è simile all’Esempio 3.7 (Figura 3.29) nel quale viene perso il pacchetto 1. La Figura 3.34 illustra il comportamento del Selective-Repeat in questo caso. Il mittente trasmette il pacchetto 0 che viene riscontrato. Il pacchetto 1 viene perso, i pacchetti 2 e 3 arrivano fuori sequenza e vengono riscontrati. Quando scade il timer, il pacchetto 1 (l’unico non riscontrato) è rispedito e riscontrato. La finestra di invio viene fatta scorrere.

Esempio 3.9 (continuazione) Nel destinatario è necessario distinguere fra la ricezione di un pacchetto e la sua consegna al livello applicazione. Il pacchetto 2 viene ricevuto e memorizzato (cella ombreggiata), ma non può essere consegnato al livello applicazione poiché manca ancora il pacchetto 1. Successivamente arriva il pacchetto 3, che viene memorizzato: ancora non può essere consegnato alcun pacchetto poiché manca sempre il pacchetto 1. Solo quando finalmente viene ricevuta una copia del pacchetto 1, i pacchetti 1, 2 e 3 possono essere consegnati al livello applicazione. I pacchetti possono essere consegnati al livello applicazione se si verificano due condizioni. Per prima cosa deve essere stato ricevuto un insieme di pacchetti consecutivi. Secondo, l’insieme deve partire dall’inizio della finestra.

Figura 3.34: Diagramma di flusso per l’Esempio 3.9 1.#

Figura 3.35: Dimensione della finestra nel meccanismo Selective-Repeat 1.#

3.2.5 Protocolli bidirezionali: piggybacking I quattro meccanismi discussi in precedenza sono tutti unidirezionali: i pacchetti dati scorrono solo in una direzione e i riscontri nella direzione opposta. I pacchetti dati vengono in realtà trasmessi solitamente in entrambe le direzioni: dal client al server e dal server al client. Quindi anche i riscontri devono viaggiare in entrambe le direzioni. Per migliorare l’efficienza dei protocolli bidirezionali viene utilizzata una tecnica chiamata piggybacking 1.#

Figura 3.36: Piggybacking nel meccanismo Go-Back-N 1.#

3.2.6 Protocolli Internet di livello trasporto Avendo discusso i concetti generali relativi al livello trasporto, si approfondiscono ora due dei protocolli di livello trasporto impiegati in Internet (Figura 3.37), UDP e TCP. Questi protocolli sono situati fra il livello applicazione e il livello rete e agiscono da intermediari fra i programmi applicativi e le operazioni della rete. 1.#

Figura 3. 37: Collocazione dei protocolli di livello trasporto nella Figura 3.37: Collocazione dei protocolli di livello trasporto nella pila TCP/IP 1.#

Tabella 3.1: Alcune porte note usate con UDP e TCP

3.3 Il protocollo UDP UDP (User Datagram Protocol) è un protocollo del livello trasporto inaffidabile e privo di connessione. Non aggiunge nulla ai servizi di IP eccetto la comunicazione tra processi. UDP è un protocollo molto semplice con un overhead (carico aggiuntivo) minimo. 1.#

3.3.1 Struttura dei datagrammi utente I pacchetti UDP sono chiamati datagrammi utente; la loro intestazione è costituita da 4 campi di 2 byte (16 bit) per un totale di 8 byte fissi, come rappresentato nella Figura 3.38. I primi due campi definiscono i numeri di porta di mittente e destinatario. Il terzo campo definisce la lunghezza totale, intestazione più dati, del datagramma utente. I 16 bit possono definire una lunghezza totale da 0 a 65 535 byte. 1.#

Figura 3.38: Formato dei datagrammi utente 1.#

Esempio 3.10 Il contenuto dell’intestazione di un datagramma UDP, espresso in esadecimale, è: a. Qual è il numero di porta del mittente? b. Qual è il numero di porta del destinatario? c. Qual è la lunghezza totale del datagramma? d. Qual è la lunghezza dei dati? e. Il pacchetto è diretto da un client a un server o viceversa? f. Qual è il processo client?

Esempio 3.10 (continuazione) Soluzione a. Il numero di porta mittente è definito dalle prime quattro cifre esadecimali (CB84)16, quindi è 52 100. b. Il numero di porta destinatario è definito dal secondo gruppo di quattro cifre esadecimali (000D)16 , quindi è 13. c. Il terzo gruppo di quattro cifre esadecimali (001C)16 definisce la lunghezza totale del pacchetto UDP, che è di 28 byte. d. La lunghezza dei dati è la lunghezza totale meno la lunghezza dell’intestazione, ovvero 28 – 8 = 20 byte. e. Poiché il numero di porta di destinazione è 13 (una porta nota), il pacchetto è dal client al server. f. Il processo client è il Daytime (si veda la Tabella 3.1).

3.3.2 Servizi UDP Comunicazione tra processi In precedenza sono stati presentati i servizi generici forniti da un protocollo di livello trasporto. In questo paragrafo si identificano quali servizi, fra questi, sono offerti da UDP. Comunicazione tra processi Servizio privo di connessione Controllo di flusso Controllo di errore 1.#

3.3.2 Servizi UDP (continuazione) Checksum Checksum opzionale Incapsulamento e decapsulamento Multiplexing e Demultiplexing Confronto fra UDP e il protocollo semplice 1.#

Figura 3.39: Pseudoheader per il calcolo del checksum 1.#

Esempio 3.11 Identificare il valore del checksum inviato in ciascuna delle seguenti situazioni. Il mittente decide di non calcolare il checksum. Il mittente decide di calcolare il checksum, ma il suo valore è costituito da tutti i bit a 1. Il mittente decide di calcolare il checksum, ma il suo valore è costituito da tutti i bit a 0.

Esempio 3.11 (continuazione) Soluzione Il valore inviato nel campo checksum ha tutti i bit a 0 per segnalare che il checksum non è stato calcolato. Quando il mittente complementa la somma, il risultato è costituito da tutti i bit a 0: il mittente complementa nuovamente il risultato prima di inviarlo. Il valore inviato è dunque costituito da tutti i bit a 1. La seconda operazione di complemento è necessaria per distinguere questo caso dal precedente. Questa situazione non può presentarsi nella realtà poiché implicherebbe che ogni valore utilizzato nel calcolo del checksum sia uguale a 0, cosa impossibile perché alcuni dei campi nello pseudoheader hanno necessariamente valori non nulli.

3.3.3 Applicazioni UDP Sebbene il protocollo UDP non soddisfi quasi nessuno dei requisiti di un protocollo affidabile del livello trasporto menzionati in precedenza, risulta particolarmente adatto in alcune applicazioni. La ragione è che alcuni servizi possono avere degli effetti collaterali inaccettabili o indesiderati e il progettista di un’applicazione deve spesso adottare dei compromessi per scegliere la soluzione ottimale. In questo paragrafo si descrivono per prima cosa alcune caratteristiche di UDP che possono essere prese in considerazione quando si progetta un programma applicativo, per poi illustrare alcune applicazioni tipiche. 1.#

3.3.3 Applicazioni UDP (continuazione) Caratteristiche di UDP Servizio privo di connessione Assenza del controllo degli errori Assenza di controllo della congestione Possibili campi di impiego del protocollo UDP 1.#

Esempio Come esempio si consideri l’applicazione DNS (si veda il Capitolo 2), che utilizza i servizi di UDP poiché in questo caso il client deve inviare una breve richiesta al server, per riceverne una rapida risposta. Richiesta e risposta possono essere contenute ciascuna in un singolo datagramma. Poiché viene scambiato un solo messaggio in ciascuna direzione, il client e il server non si devono preoccupare che i messaggi vengano consegnati fuori sequenza.

Esempio Un altro esempio è dato dall’applicazione SMTP, utilizzata nella posta elettronica, che non può utilizzare i servizi di UDP poiché un utente potrebbe voler inviare un messaggio voluminoso con informazioni multimediali (immagini, audio o video). Se l’applicazione usasse UDP e il messaggio non potesse essere contenuto in un singolo datagramma utente, questo dovrebbe essere suddiviso dall’applicazione in più datagrammi utente. In questo caso il servizio senza connessioni potrebbe creare dei problemi: i datagrammi utente potrebbero essere consegnati all’applicazione destinataria fuori sequenza e questa potrebbe non essere in grado di riordinare le parti. Un servizio privo di connessione comporta quindi un notevole svantaggio per le applicazioni che trasmettono messaggi voluminosi.

Esempio Si consideri il caso in cui si voglia prelevare via Internet un file particolarmente voluminoso. È assolutamente necessario utilizzare un livello trasporto che fornisce un servizio affidabile: sarebbe ovviamente inaccettabile avere parti del file corrotte o mancanti o anche assemblate fuori sequenza. Il ritardo nella consegna delle parti non costituisce invece un problema critico: è possibile attendere fino a quando il file è completamente trasferito prima di utilizzarlo. In questo caso UDP non è un protocollo adatto.

Esempio Si consideri un’applicazione interattiva in tempo reale, come Skype. Le informazioni audio e video vengono divise in frame e inviate una dopo l’altra. Se il livello trasporto dovesse rispedire un frame corrotto o mancante, si potrebbe perdere la sincronizzazione di tutta la trasmissione. L’utente potrebbe improvvisamente vedere lo schermo vuoto (magari congelato) in attesa dell’arrivo dei dati rispediti: sarebbe ovviamente intollerabile. Se invece ogni piccola parte delle immagini viene inviata con un singolo datagramma utente, l’UDP destinatario può facilmente ignorare i pacchetti smarriti o corrotti e consegnare i restanti al programma applicativo. Una piccola parte dello schermo potrebbe non essere aggiornata correttamente per un brevissimo periodo di tempo, ma la maggior parte degli utenti non lo noterebbe nemmeno.

3.4 Il protocollo TCP Il protocollo TCP (Transmission Control Protocol) è un protocollo orientato alla connessione e affidabile. Per fornire un servizio orientato alla connessione TCP prevede esplicitamente i meccanismi di apertura della connessione, di trasferimento dei dati e di chiusura della connessione. Per fornire un servizio affidabile utilizza una combinazione di meccanismi GBN e SR. 1.#

3.4.1 Servizi del protocollo TCP Il protocollo TCP fornisce un servizio di trasporto affidabile tra processi basato, come per UDP, sui numeri di porta. Comunicazione tra processi Orientamento al flusso di dati (stream oriented) Buffer di trasmissione e di ricezione Segmenti 1.#

3.4.1 Servizi del protocollo TCP (continuazione) Servizio full-duplex Multiplexing e demultiplexing Servizio orientato alla connessione Servizio affidabile 1.#

Figura 3.40: Trasmissione di un flusso 1.#

Figura 3.41: Buffer di trasmissione e di ricezione 1.#

Figura 3.42: Segmenti TCP 1.#

3.4.2 Numeri di sequenza e di riscontro TCP per realizzare un servizio di trasporto affidabile usa un meccanismo di numerazione che prevede due campi, chiamati numero di sequenza e numero di riscontro (ack). Questi due campi sono contenuti nell’intestazione dei segmenti TCP e fanno riferimento a un numero di byte e non a un numero di segmento. Sistema di numerazione Numero di byte Numero di sequenza Numero di riscontro 1.#

Esempio 3.12 Si supponga che si stia trasferendo un file di 5000 byte con una connessione TCP. Il primo byte viene numerato 10 001. Quali sono i numeri di sequenza dei vari segmenti, se i dati vengono inviati in cinque segmenti ciascuno contenente 1000 byte? Soluzione Ecco i numeri di sequenza di ciascun segmento: Segmento 1 → numero di sequenza: 10 001; byte contenuti: da 10 001 a 11 000 Segmento 2 → numero di sequenza: 11 001; byte contenuti: da 11 001 a 12 000 Segmento 3 → numero di sequenza: 12 001; byte contenuti: da 12 001 a 13 000 Segmento 4 → numero di sequenza: 13 001; byte contenuti: da 13 001 a 14 000 Segmento 5 → numero di sequenza: 14 001; byte contenuti: da 14 001 a 15 000

3.4.3 Formato dei segmenti Formato Aggiunta dello pseudoheader Il protocollo TCP riceve i dati in forma di messaggi dal livello applicazione e li incapsula in segmenti. Formato Aggiunta dello pseudoheader 1.#

Figura 3.43: Formato dei segmenti TCP 1.#

Figura 3.44: Flag di controllo 1.#

Figura 3.45: Aggiunta dello pseudoheader al segmento TCP 1.#

3.4.4 La connessione TCP Il protocollo TCP è orientato alla connessione, ovvero stabilisce un percorso virtuale fra il mittente e il destinatario. Tutti i segmenti appartenenti a un messaggio vengono spediti lungo questo percorso logico. Utilizzare un percorso virtuale per l’intero messaggio semplifica il processo di conferma e di ritrasmissione dei segmenti smarriti o danneggiati. 1.#

3.4.4 La connessione TCP (continuazione) Apertura della connessione Three-Way Handshaking Trasferimento dei dati Pushing dei dati Dati urgenti Chiusura della connessione Three-Way Handshaking Half-Close Reset della connessione 1.#

Figura 3.46: Apertura della connessione mediante three-way handshake 1.#

Figura 3.47: Trasferimento dati 1.#

Figura 3.48: Chiusura della connessione mediante three-way handshake 1.#

Figura 3.49: Half-close 1.#

3.4.5 Diagramma delle transizioni di stato Al fine di avere una visione globale di tutti gli eventi che si realizzano durante l’apertura di una connessione, la sua chiusura e il trasferimento dei dati, il protocollo TCP viene specificato come una macchina a stati finiti (FSM), come illustrato nella Figura 3.50. Scenari Scenario della half-close 1.#

Figura 3.50: Diagramma delle transizioni di stato 1.#

Tabella 3.2: Stati del protocollo TCP

Figura 3.51: Diagramma delle transizioni con chiusura della connessione half-close 1.#

Figura 3.52: Diagramma temporale per lo scenario di half-close 1.#

3.4.6 Finestre TCP Finestra di invio Finestra di ricezione Il protocollo TCP utilizza due finestre (di invio e di ricezione) per ciascuna direzione del trasferimento dei dati, il che significa quattro finestre nel caso di comunicazione bidirezionale. Per semplificare la discussione si ipotizza, sebbene non sia realistico, che la comunicazione sia esclusivamente unidirezionale (per esempio dal client al server); la comunicazione bidirezionale può essere vista come due comunicazioni unidirezionali con piggybacking. Finestra di invio Finestra di ricezione 1.#

Figura 3.53: Finestra di invio nel protocollo TCP 1.#

Figura 3.54: Finestra di ricezione nel protocollo TCP 1.#

3.4.7 Controllo di flusso Come già discusso, il controllo di flusso consente di bilanciare la velocità con cui un produttore genera i dati con la velocità con la quale un consumatore li utilizza. Il protocollo TCP separa il controllo di flusso dal controllo degli errori; in questo paragrafo si descrive il controllo di flusso astraendo dal controllo degli errori: si assume dunque che il canale logico fra il mittente e il destinatario TCP sia privo di errori. 1.#

3.4.7 Controllo di flusso (continuazione) Apertura e chiusura delle finestre Un esempio Riduzione delle finestre Chiusura totale della finestra 1.#

Figura 3.55: Flusso dei dati e feedback del controllo di flusso in TCP 1.#

Figura 3.56: Esempio di controllo di flusso Nota: si ipotizza una comunicazione unidirezionale dal client al server. Per questo motivo viene mostrata una sola finestra per lato. 1.#

Esempio 3.13 La Figura 3.57 schematizza le ragioni di questa regola. La parte (a) della figura illustra i valori dell’ultimo riscontro e di rwnd. La parte (b) illustra la situazione in cui il mittente ha inviato i byte da 206 a 214. I byte da 206 a 209 sono riscontrati ed eliminati. Il nuovo annuncio, tuttavia, definisce il nuovo valore 4 di rwnd, dove 210 + 4 < 206 + 12. Quando la finestra di invio viene ridotta, si crea un problema: il byte 214, già inviato, è all’esterno della finestra. La diseguaglianza discussa in precedenza costringe il destinatario a mantenere la parete destra della finestra come indicato nella parte (a), poiché il destinatario non sa quali dei byte da 210 a 217 sono stati già inviati.

Figura 3.57: Esempio 3.13 1.#

3.4.8 Controllo degli errori Il protocollo TCP è un protocollo di trasporto affidabile, ovvero garantisce al livello applicazione che i dati inviati verranno consegnati nel giusto ordine, senza errori, senza smarrimenti o duplicazioni. 1.#

3.4.8 Controllo degli errori (continuazione) Checksum Riscontri Riscontro cumulativo positivo (ACK) Riscontro selettivo (SACK) Generazione dei riscontri Ritrasmissione dei segmenti Riscontro allo scadere del timer RTO Ritrasmissione veloce (tre ACK duplicati) Segmenti fuori sequenza 1.#

3.4.8 Controllo degli errori (continuazione) FSM per il trasferimento dei dati in TCP FSM lato mittente FSM lato destinatario Alcuni scenari Operatività normale Segmento smarrito Ritrasmissione veloce Segmento in ritardo (delayed) Segmento duplicato Correzione automatica di un ACK smarrito Riscontro smarrito e rispedizione del segmento Stallo da smarrimento di un riscontro 1.#

Figura 3.58: FSM semplificata per il mittente TCP 1.#

Figura 3.59: FSM semplificata per il lato destinatario TCP 1.#

Figura 3.60: Operatività normale 1.#

Figura 3.61: Segmento smarrito 1.#

Figura 3.62: Ritrasmissione veloce 1.#

Figura 3.63: Riscontro smarrito 1.#

Figura 3.64: Riscontro smarrito corretto con la rispedizione del segmento 1.#

3.4.9 Controllo della congestione in TCP TCP utilizza diverse strategie per gestire la congestione nella rete, che sono descritte in questo paragrafo. Finestra di congestione Rilevare la congestione Le strategie di gestione della congestione Slow start: incremento esponenziale Congestion avoidance: incremento lineare 1.#

3.4.9 Congestione in TCP (continuazione) Strategie di transizione fra gli algoritmi TCP Taho TCP Reno TCP NewReno Additive increase, multiplicative decrease Throughput di TCP 1.#

Figura 3.65: Slow start, incremento esponenziale 1.#

Figura 3.66: Congestion avoidance: incremento lineare 1.#

Figura 3.67: FSM per il meccanismo di controllo della congestione di TCP Taho 1.#

Esempio 3.14 La Figura 3.68 illustra un esempio di controllo della congestione in un TCP Taho. TCP inizia il trasferimento dei dati e imposta la variabile ssthresh all’ambizioso valore di 16 MSS. Lo stato iniziale è lo slow start (SS) con cwnd = 1. La finestra di congestione cresce esponenzialmente ma avviene un timeout dopo il terzo RTT (prima di raggiungere il threshold). TCP assume che la rete sia congestionata, imposta il valore di ssthresh a 4 MSS (la metà del valore corrente di cwnd, che vale 8) e inizia un nuovo stato slow start (SS) con cwnd = 1 MSS. La finestra di congestione cresce esponenzialmente fino a quando raggiunge il nuovo valore di threshold. A questo punto il TCP passa nello stato congestion avoidance (CA), dove la finestra di congestione cresce linearmente fino a quando raggiunge cwnd = 12 MSS.

Esempio 3.14 (continuazione) A questo punto vengono ricevuti tre riscontri duplicati, un altro sintomo di congestione della rete. TCP dimezza nuovamente il valore di ssthresh a 6 MSS e passa nello stato slow start (SS). La crescita esponenziale di cwnd prosegue. Dopo RTT 15, la dimensione di cwnd è 4 MS. Dopo avere inviato quattro segmenti e ricevuto due soli riscontri, la dimensione della finestra raggiunge il valore di ssthresh (6), quindi TCP passa nello stato congestion avoidance. Il trasferimento dei dati continua in questo stato (CA) fino a quando viene chiusa la connessione, in corrispondenza di RTT 20.

Figura 3.68: Esempio di controllo della congestione con TCP Taho 1.#

Figura 3.69: FSM per il TCP Reno 1.#

Esempio 3.15 La Figura 3.70 illustra la stessa situazione della Figura 3.68, ma con TCP Reno. La dimensione della finestra di congestione cambia nello stesso modo fino a RTT 13, quando vengono ricevuti 3 riscontri duplicati. A questo punto TCP Reno riduce ssthresh a 6 MSS (come nel caso del TCP Taho) ma imposta il valore di cwnd a un valore molto più alto (ssthresh + 3 = 9 MSS) anziché 1 MSS. TCP Reno passa quindi nello stato di fast recovery. Si ipotizza che arrivino due altri ACK duplicati fino a RTT 15, mentre cwnd cresce esponenzialmente. Arriva ora un nuovo riscontro (non duplicato) che segnala la ricezione del segmento smarrito. TCP Reno passa quindi nello stato congestion avoidance, ma riduce prima la finestra di congestione a 6 MSS (il valore di ssthresh), ignorando l’intero stato fast recovery e ritornando nella traccia precedente.

Figura 3.70: Esempio di controllo della congestione con TCP Reno 1.#

Figura 3.71: AIMD: incremento additivo, decremento moltiplicativo 1.#

Esempio 3.16 Se MSS = 10 KB (kilobyte) e RTT = 100 ms nella Figura 3.71, è possibile calcolare il throughput come mostrato di seguito: Wmax = (10 + 12 + 10 + 8 + 8) / 5 = 9,6 MSS Throughput = (0,75 Wmax / RTT) = 0,75 × 960 kbps / 100 ms = 7,2 Mbps

Timer di ritrasmissione 3.4.10 Timer TCP Per garantire il corretto svolgimento delle operazioni, la maggior parte delle implementazioni TCP utilizza almeno quattro timer: Timer di ritrasmissione Round Trip Time (RTT) Algoritmo di Karn Back-off esponenziale Timer di persistenza Timer keepalive Timer tempo d’attesa (2MSL) 1.#

Esempio 3.17 Si consideri l’esempio ipotetico nella Figura 3.72, che illustra l’apertura di una connessione e parte della fase di trasferimento dati. Quando viene inviato il segmento SYN non esiste alcun valore per RTTM, RTTS o RTTD. Il valore di RTO è impostato a 6,00 secondi. RTO = 6

Esempio 3.17 (continuazione) Quando arriva il segmento SYN+ACK, viene misurato RTTM che è uguale a 1,5 secondi. I nuovi valori delle variabili sono: RTTM = 1,5 RTTS = 1,5 RTTD = 1,5 / 2 = 0,75 RTO = 1,5 + 4 × 0,75 = 4,5

Esempio 3.17 (continuazione) Quando viene inviato il primo segmento dati, inizia una nuova misurazione di RTT. Il mittente non inizia la misurazione di RTT quando invia il segmento ACK, dato che questo non usa alcun numero di sequenza e non vi è quindi alcun timeout associato. Quando viene inviato il secondo segmento, non inizia una nuova misurazione di RTT perché la misurazione precedente non è stata ancora completata. RTTM = 2,5 RTTS = 7 / 8(1,5) + 1 / 8(2,5) = 1,625 RTTD = 3 / 4(7,5) + 1 / 4|1,625 – 2,5| = 0,78 RTO = 1,625 + 4(0,78) = 4,74

Figura 3.72: Esempio 3.17 1.#

Esempio 3.18 La Figura 3.73 rappresenta la continuazione dell’esempio precedente: a fronte di una ritrasmissione si applica l’algoritmo di Karn. Il primo segmento inviato nella figura viene smarrito. Il timer RTO scade dopo 4,74 secondi: il segmento viene quindi ritrasmesso e il timer viene impostato al valore 9,48, il doppio del valore precedente. Questa volta viene ricevuto un ACK prima del timeout. Prima di calcolare il nuovo RTO, si attende l’invio di un nuovo segmento e la ricezione del relativo riscontro (algoritmo di Karn).

Figura 3.73: Esempio 3.18 1.#

3.4.11 Le opzioni L’intestazione TCP può contenere da zero fino a quaranta byte di informazioni opzionali, che vengono usati per inviare informazioni aggiuntive al destinatario o per ragioni di allineamento. Queste opzioni sono descritte nel sito web associato a questo volume. 1.#