6.7) Il livello transport in Internet

Il livello transport di Internet è basato su due protocolli:

TCP (Transmission Control Protocol) RFC 793, 1122 e 1323;
UDP (User Data Protocol) RFC 768.

Il secondo è di fatto IP con l'aggiunta di un breve header, e fornisce un servizio di trasporto datagram (quindi non affidabile). Lo vedremo brevemente nel seguito.

Il protocollo TCP è stato progettato per fornire un flusso di byte affidabile, da sorgente a destinazione, su una rete non affidabile.

Dunque, offre un servizio reliable e connection oriented, e si occupa di:

accettare dati dal livello application;
spezzarli in segment, il nome usato per i TPDU (dimensione massima 64 Kbyte, tipicamente circa 1.500 byte);
consegnarli al livello network, eventualmente ritrasmettendoli;
ricevere segmenti dal livello network;
rimetterli in ordine, eliminando buchi e doppioni;
consegnare i dati, in ordine, al livello application.

E' un servizio full-duplex con gestione di ack e controllo del flusso.

6.7.1) Indirizzamento

I servizi di TCP si ottengono creando connessione di livello transport identificata da una coppia di punti d'accesso detti socket. Ogni socket ha un socket number che consiste della coppia:

IP address: Port number

Il socket number costituisce il TSAP.

I port number hanno 16 bit. Quelli minori di 256 sono i cosidetti well-known port, riservati per i servizi standard. Ad esempio:

Port number	Servizio

7	Echo
20	Ftp (control)
21	Ftp (data)
23	Telnet
25	Smtp
80	Http
110	Pop versione 3

Poiché le connessioni TCP, che sono full duplex e point to point, sono identificate dalla coppia di socket number alle due estremità, è possibile che su un singolo host più connessioni siano attestate localmente sullo stesso socket number.

Le connessioni TCP trasportano un flusso di byte, non di messaggi: i confini fra messaggi non sono né definiti né preservati. Ad esempio, se il processo mittente (di livello application) invia 4 blocchi di 512 byte, quello destinatario può ricevere:

8 "pezzi" da 256 byte;
1 "pezzo" da 2.048 byte;
ecc.

Ci pensano le entità TCP a suddividere il flusso in arrivo dal livello application in segmenti, a trasmetterli e a ricombinarli in un flusso che viene consegnato al livello application di destinazione.

C'è comunque la possibilità, per il livello application, di forzare l'invio immediato di dati; ciò causa l'invio di un flag urgent che, quando arriva dall'altra parte, fa sì che l'applicazione venga interrotta e si dedichi a esaminare i dati urgenti (questo succede quando, ad esempio, l'utente durante una sessione di emulazione di terminale digita il comando ABORT (CTRL-C) della computazione corrente).

6.7.2) Il protocollo TCP

Le caratteristiche più importanti sono le seguenti:

ogni byte del flusso TCP è numerato con un numero d'ordine a 32 bit, usato sia per il controllo di flusso che per la gestione degli ack;
un segmento TCP non può superare i 65.535 byte;
un segmento TCP è formato da:
- uno header, a sua volta costituito da:
  - una parte fissa di 20 byte;
  - una parte opzionale;
- i dati da trasportare;
TCP usa un meccanismo di sliding window di tipo go-back-n con timeout. Se questo scade, il segmento si ritrasmette. Si noti che le dimensioni della finestra scorrevole e i valori degli ack sono espressi in numero di byte, non in numero di segmenti.

Figura 6-13: Formato del segmento TCP

I campi dell'header hanno le seguenti funzioni:

Source port, destination port	identificano gli end point (locali ai due host) della connessione. Essi, assieme ai corrispondenti numeri IP, formano i due TSAP.
Sequence number	il numero d'ordine del primo byte contenuto nel campo dati.
Ack. number	il numero d'ordine del prossimo byte aspettato.
TCP header length	quante parole di 32 bit ci sono nell'header (necessario perché il campo options è di dimensione variabile).
URG	1 se urgent pointer è usato, 0 altrimenti.
ACK	1 se l'ack number è valido (cioè se si convoglia un ack), 0 altrimenti.
PSH	dati urgenti (pushed data), da consegnare senza aspettare che il buffer si riempia.
RST	richiesta di reset della connessione (ci sono problemi!).
SYN	usato nella fase di setup della connessione: SYN=1 ACK=0 richiesta connessione; SYN=1 ACK=1 accettata connessione.
FIN	usato per rilasciare una connessione.
Window size	il controllo di flusso è di tipo sliding window di dimensione variabile. Window size dice quanti byte possono essere spediti a partire da quello (compreso) che viene confermato con l'ack number. Un valore zero significa: fermati per un pò, riprenderai quando ti arriverà un uguale ack number con un valore di window size diverso da zero.
Checksum	simile a quello di IP; il calcolo include uno pseudoheader.
Urgent pointer	puntatore ai dati urgenti.
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.

Nel calcolo del checksum entra anche uno pseudoheader , in aperta violazione della gerarchia, dato che il livello TCP in questo calcolo opera su indirizzi IP.

Figura 6-14: Formato dello pseudoheader TCP

Lo pseudoheader non viene trasmesso, ma precede concettualmente l'header. I suoi campi hanno le seguenti funzioni:

Source IP address, destination IP address	indirizzi IP (a 32 bit) di sorgente e destinatario.
Protocol	il codice numerico del protocollo TCP (pari a 6).
TCP segment length	il numero di byte del segmento TCP, header compreso.

6.7.3) Attivazione della connessione

Si usa il three-way handshake visto precedentemente:

una delle due parti (diciamo il server) esegue due primitive, listen() e poi accept() rimanendo così in attesa di una richiesta di connessione su un determinato port number e, quando essa arriva, accettandola;
l'altra parte (diciamo un client) esegue la primitiva connect(), specificando host, port number e altri parametri quali la dimensione massima dei segmenti, per stabilire la connessione; tale primitiva causa l'invio di un segmento TCP col bit syn a uno e il bit ack a zero;
quando tale segmento arriva a destinazione, l'entity di livello transport controlla se c'è un processo in ascolto sul port number in questione:
- se non c'è nessuno in ascolto, invia un segmento di risposta col bit rst a uno, per rifiutare la connessione;
- altrimenti, consegna il segmento arrivato al processo in ascolto; se esso accetta la connessione, l'entity invia un segmento di conferma, con entrambi i bit syn ed ack ad uno, secondo lo schema sotto riportato.

Figura 6-15: Attivazione di una connessione TCP

I valori di x e y sono ricavati dagli host sulla base dei loro clock di sistema; il valore si incrementa di una unità ogni 4 microsecondi.

6.7.4) Rilascio della connessione

Il rilascio della connessione avviene considerando la connessione full-duplex come una coppia di connessioni simplex indipendenti, e si svolge nel seguente modo:

quando una delle due parti non ha più nulla da trasmettere, invia un fin;
quando esso viene confermato, la connessione in uscita viene rilasciata;
quando anche l'altra parte completa lo stesso procedimento e rilascia la connessione nell'altra direzione, la connessione full-duplex termina.

Per evitare il problema dei 3 eserciti si usano i timer, impostati al doppio della vita massima di un pacchetto.

Il protocollo di gestione delle connessioni si rappresenta comunemente come una macchina a stati finiti. Questa è una rappresentazione molto usata nel campo dei protocolli, perché permette di definire, con una certa facilità e senza ambiguità, protocolli anche molto complessi.

6.7.5) Politica di trasmissione

L'idea di fondo è la seguente: la dimensione delle finestre scorrevoli non è strettamente legata agli ack (come invece di solito avviene), ma viene continuamente adattata mediante un dialogo fra destinazione e sorgente.

In particolare, quando la destinazione invia un ack di conferma, dice anche quanti ulteriori byte possono essere spediti.

Nell'esempio che segue, le peer entity si sono preventivamente accordate su un buffer di 4K a destinazione.

Figura 6-16: Esempio di controllo del flusso TCP

Anche se riceve win=0, il mittente può comunque inviare:

dati urgenti;
richieste di reinvio dell'ultimo ack spedito (per evitare il deadlock se esso si è perso).

6.7.6) Controllo congestione

Il protocollo TCP assume che, se gli ack non tornano in tempo, ciò sia dovuto a congestione della subnet piuttosto che a errori di trasmissione (dato che le moderne linee di trasmissione sono molto affidabili).

Dunque, TCP è preparato ad affrontare due tipi di problemi:

scarsità di buffer a destinazione;
congestione della subnet.

Ciascuno dei problemi viene gestito da una specifica finestra mantenuta dal mittente:

la finestra del buffer del ricevitore (quella di cui all'esempio precedente);
la congestion window, che rappresenta quanto si può spedire senza causare congestione.

Il mittente si regola sulla più piccola delle due.

La congestion window viene gestita in questo modo:

il valore iniziale è pari alla dimensione del massimo segmento usato nella connessione;
ogni volta che un ack torna indietro in tempo la finestra si raddoppia, fino a un valore threshold, inizialmente pari a 64 Kbyte, dopodiché aumenta linearmente di 1 segmento alla 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 massimo segmento usato nella connessione.

Vediamo ora un esempio, con segmenti di dimensione 1 Kbyte, threshold a 32 Kbyte e congestion window arrivata a 40 Kbyte:

Figura 6-17: Esempio di controllo della congestione TCP

6.7.7) Il protocollo UDP

Il livello transport fornisce anche un protocollo non connesso e non affidabile, utile per inviare dati senza stabilire connessioni (ad esempio per applicazioni client-server).

Lo header di un segmento UDP è molto semplice:

Figura 6-18: Formato dello header UDP

La funzione di calcolo del checksum può essere disattivata, tipicamente nel caso di traffico in tempo reale (come voce e video) per il quale è in genere più importante mantenere un'elevato tasso di arrivo dei segmenti piuttosto che evitare i rari errori che possono accadere.

Torna al sommario | Vai avanti