Reti: Il TCP-IP Parte 7

TCP - Transmission Control Protocol

Il Transmission Control Protocol (TCP), permette di instaurare un collegamento tra due utenze, di rendere affidabile il trasferimento dei dati e dei comandi tra di esse e di chiudere la connessione.

Il protocollo è in grado di trasferire un flusso continuo di dati fra due utenze in entrambe le direzioni (full-duplex), decidendo quando bloccare o continuare le operazioni.

E' possibile implementarlo sia su una singola rete come una ethernet sia su un sistema più complesso come l'internet.

Questo protocollo, come anche l'UDP, si colloca, nel modello a strati, sopra l'Internet Protocol Layer (IP), che gestisce il trasferimento e l'instradamento del singolo pacchetto fino a destinazione, ma, oltre a questo, tiene una traccia di ciò che è stato trasmesso ed eventualmente ritrasmette quella parte di informazione che è andata persa lungo il tragitto.

Come l'UDP, anche il TCP permette, a più programmi applicativi su una stessa macchina, di comunicare contemporaneamente, quindi:

• demultiplexa il traffico dei pacchetti in ingresso a tali programmi;
• usa i numeri di porta per identificare la destinazione finale all'interno di una macchina.

La differenza fondamentale con l'UDP è che il TCP garantisce un servizio di trasporto affidabile (Reliable Delivery Service), rimediando alle cause di inaffidabilità proprie dell'IP (duplicazione e perdita di dati, caduta di rete, ritardi, pacchetti ricevuti fuori ordine, etc.), anche se ciò comporta una implementazione più complessa.

L'affidabilità del flusso di tale protocollo è il motivo per cui il complesso del protocollo si definisce con la sigla TCP/IP. L'affidabilità di questo servizio è caratterizzata da cinque proprietà:

• Stream Orientation - quando due programmi applicativi trasferiscono i dati (stream of bits), il flusso di essi nella macchina di destinazione passa al ricevente esattamente come esso è stato originato nella macchina sorgente.
• Virtual Circuit Connection - dal punto di vista del programmatore e dell'utente, il servizio che il TCP offre è analogo al fornire una connessione dedicata.
• Buffered Trasfer - i routers interessati dal trasferimento sono provvisti di buffer per rendere più efficiente il trasferimento e minimizzare il traffico di rete.
• Unstructured Stream - il TCP/IP stream service non adotta un flusso di dati strutturato; ovvero non vi è modo di distinguere i record che costituiscono il flusso dati.
• Full-duplex Connection - la connessione fornita dal TCP/IP stream service permette un trasferimento di flusso contemporaneo ed indipendente in entrambe le direzioni, senza apparente interazione.

Se un qualsiasi messaggio è troppo grande per un singolo pacchetto TCP (gli standard consigliano una dimensione di 576 byte compreso l'header del IP) esso viene diviso in segmenti di lunghezza fissa quindi, arrivato a destinazione, si effettua il controllo circa l'ordine e si riassembla, in modo che tale operazione risulti del tutto invisibile agli operatori.

Poiché queste funzionalità sono necessarie per molte applicazioni, sono state inserite tutte in questo protocollo piuttosto che metterle, come parte del programma, in ogni applicativo che ne necessita.

L'affidabilità del processo è garantita da una tecnica nota come acknowledgement with retransmission (riscontro con ritrasmissione). Tale tecnica prevede che il destinatario invii un messaggio di acknowledgement (ACK) al mittente, una volta ricevuto un pacchetto. Il mittente mantiene una copia di ciascun pacchetto spedito e la rimuove dal buffer di trasmissione solo dopo aver ricevuto l'ACK relativo ad essa.

Nella configurazione di base (ma meno efficiente) il mittente, dopo aver trasmesso un pacchetto:

• aspetta di ricevere il suo ACK prima di spedire il successivo;
• fa anche partire un "cronometro" per il timeout, allo scadere del quale, se non ha ricevuto risposta, ritrasmette quello stesso pacchetto

Un protocollo come questo, del tipo "stop and wait", abbassa di molto le prestazioni della rete, sprecando gran parte della banda disponibile nell'attesa dell'ACK relativo al pacchetto precedente, perché un canale full-duplex è utilizzato come se fosse un half-duplex.

Tale problema si accentua se i pacchetti, durante il percorso, devono attraversare molti componenti quali bridge, router, repeater che introducono un ritardo fisso di elaborazione, dobbiamo aggiungere, inoltre, altri ritardi dovuti al traffico in rete.

Sliding Windows

L'introduzione del protocollo Sliding Windows (finestre scorrevoli) rende molto più efficiente la trasmissione, quindi l'utilizzo della banda, perchè ciò permette al mittente di trasmettere tutti i pacchetti nella finestra senza dover aspettare l'ACK; via via che arrivano i vari ACK, il TCP fa slittare la finestra in avanti trasmettendo dei nuovi pacchetti dinamicamente, come rappresentato nella seguente figura:

Le dimensioni della finestra possono variare fino ad un massimo di 64 Kbytes. Una finestra di ampiezza opportuna riuscirebbe quasi, nella eventualità che non si perdano pacchetti, a saturare completamente la banda di trasmissione.

Appena il primo pacchetto della finestra, infatti, arriva a destinazione, parte subito un ACK: se il round-trip di quel collegamento è abbastanza piccolo, o la finestra sufficientemente grande, in modo che l'ACK arrivi prima che il trasmettitore abbia esaurito la finestra, allora il flusso di dati è continuo e pari alle potenzialità massime della rete.

Se invece il round-trip è lento, si può avere la cosiddetta "silly window syndrome", che consiste in un comportamento anomalo del TCP. Il trasmettitore spedisce i pacchetti nella finestra e poi perde molto tempo aspettando i relativi ACK prima di passare ai dati successivi,.

Il meccanismo di acknowledgment può essere un "go back N" o un "go back N selective repeat", intendendo che le disposizioni dei reference sono molto labili, specificando solo che ogni pacchetto deve essere riconosciuto in qualche modo.

Gli standard, invece, specificano che tale meccanismo deve essere cumulativo, nel senso che un ACK è relativo ad un certo numero di byte della finestra, non ad un pacchetto, e che gli ACK successivi riconosceranno altri byte in modo cumulativo.

Ad esempio, supposto di lavorare con ACK da 500 byte:

• il primo ACK conferma i primi 500 byte;
• il secondo assicura che sono stati ricevuti i primi 1000 byte;
• il terzo garantisce fino a 1500 byte

.....e così via.

Dato che, però, la dimensione dei pacchetti non è fissata, non è detto che un ACK corrisponda ad un solo pacchetto TCP.

Possiamo allora definire la "finestra di acknowledgment" (da non confondere con quella di trasmissione) come:

il numero di byte, ovvero il numero di pacchetti TCP, una volta fissata la loro dimensione, riconosciuti da un singolo ACK.

Avere una finestra di acknowledgment ampia limita il traffico in rete generato dagli ack, poiché lo stesso numero di byte trasmesso viene riconosciuto valido con meno pacchetti ACK.

Il meccanismo della finestra è molto importante perché fornisce al ricevente un mezzo per governare la mole di dati spediti dall'utente di origine. Infatti, nell'header dei pacchetti TCP esiste un campo specifico, detto "window", tramite il quale il ricevente indica al trasmittente la dimensione in byte della finestra che è disposto attualmente a ricevere (finestra del ricevente). Questo accordo avviene quando il ricevente spedisce un ACK (che è anche esso un pacchetto TCP) nel quale specifica innanzitutto l'ultima posizione riconosciuta valida e, a partire da questa, il numero di byte che attualmente può accettare.

Headers

L'unità di trasporto tra i software TCP di due macchine è definito segment. I segmenti sono scambiati per:

• stabilire connessioni;
• trasferimenti di dati;
• inviare ACK;
• comunicare la dimensione della Sliding Windows;
• chiudere le connessioni.

Poichè il TCP usa il piggybacking (trasmissione contemporanea di dati in entrambe le direzioni), un ACK che viaggia da una macchina A ad una macchina B potrebbe viaggiare in uno stesso segmento in cui viaggiano i dati tra A e B, sebbene l'ACK sia riferito ai dati spediti tra B ed A.

La figura seguente mostra il formato del segmento TCP:

Ciascun segmento è diviso in due parti:

• un TCP header;
• un TCP data.

Un header ha una lunghezza di almeno 20 byte e comprende diversi campi; i più importanti sono il "port number" e il "sequence number", sia della sorgente che della destinazione.

Il numero di porta serve per distinguere fra loro i trasferimenti che avvengono contemporaneamente  (devono essere conosciuti anche i numeri di porta degli altri tre nodi).

Il numero di sequenza identifica la posizione dei byte dati nel flusso spedito all'interno del segmento; serve ad ordinare i pacchetti in ricezione e verificare di non averne perso nessuno; da notare che tale numerazione riguarda i byte non i pacchetti, nel senso che se si usano pacchetti da 500 byte, il primo è numerato 500, il secondo 1000, il terzo 1500 e così via.

Un altro campo è il "acknowledgment number"; anche esso, come il "sequence number", è cumulativo e conta i byte anziché i pacchetti.

Il campo da 2 byte "window" è quello che consente al ricevente di indicare al trasmittente la dimensione della finestra da usare per il trasferimento in corso; da notare che due alla sedici fa 64 K, cioè la dimensione massima della finestra.

Gli ultimi due campi sono il "checksum" dell'header e un "urgent pointer" per alcuni casi particolari.

Ovviamente, in ricezione il livello TCP ritaglia l'header TCP, il livello IP ritaglia l'header IP, il livello di rete ritaglia l'header e il checksum relativo ad esso.

Fine della parte 7