Internet - TCP: Transmission Control Protocol

Il Transmission Control Protocol (TCP), si assume la responsabilità di instaurare un collegamento tra due utenti, di rendere affidabile il trasferimento di dati e comandi tra essi ed infine di chiudere la connessione. Esso è capace di trasferire un flusso continuo di dati fra due utenti in entrambe le direzioni (full-duplex), decidendo quando bloccare o continuare le operazioni a suo piacimento.
Poiché il TCP fa veramente poche assunzioni riguardo l'hardware sottostante, è possibile implementarlo sia su una singola rete come una ethernet sia su un complesso variegato quale l'internet.
Tale protocollo, come 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, come ulteriore funzionalità, tiene una traccia di ciò che è stato trasmesso ed eventualmente ritrasmette quella parte di informazione che è andata perduta lungo il tragitto.

Come l'UDP, il TCP permette a più programmi applicativi su una stessa macchina di comunicare contemporaneamente, e 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 fondamentale differenza con l'UDP è che il TCP garantisce un servizio di trasporto affidabile (Reliable Delivery Service), ponendo rimedio 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'importanza dell'affidabilità del flusso permessa da tale protocollo è il motivo per cui il complesso del protocollo TCP/IP ha tale nome.

L'affidabilità di questo servizio è caratterizzata da cinque proprietà:

Stream Orientation: quando due programmi applicativi trasferiscono dati (stream of bits), il flusso nella macchina di destinazione passa al ricevente esattamente come è stato originto nella macchina sorgente.

Virtual Circuit Connection: dal punto di vista del programmatore e dell'utente, il servizio che il TCP fornisce è analogo a fornire una connessione dedicata.

Buffered Trasfer: i routers interessati dal trasferimento sono provvisti di buffers 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 c'è modo di distinguere i records 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 qualunque messaggio è troppo grande per un singolo pacchetto TCP (gli standard consigliano una dimensione di 576 byte compreso l'header del IP) si procede a dividerlo in segmenti di lunghezza fissa e poi, arrivato a destinazione, si controlla che siano in ordine e si riassemblano, in modo che tale operazione risulti del tutto invisibile ai due utenti.
Poiché queste funzionalità sono necessarie per molte applicazioni, sono state messe tutte insieme in questo protocollo piuttosto che inserirle, come parte del programma, in ogni applicativo che ne ha bisogno.
L'affidabilità è garantita da una tecnica di fondamentale importanza 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 più banale e meno efficiente l'utente sorgente, dopo aver trasmesso un pacchetto, aspetta di ricevere il suo ACK prima di spedire il successivo; inoltre fa anche partire un "cronometro" per il timeout, allo scadere del quale, se non ha ricevuto risposta, ritrasmette quello stesso pacchetto:

Un semplice protocollo del tipo "stop and wait" come questo abbassa notevolmente le prestazioni della rete, sprecando gran parte della banda disponibile nell'attesa dell'ACK relativo al pacchetto precedente; infatti un canale full-duplex è utilizzato come se fosse un half-duplex.
Tale problema è accentuato se i pacchetti devono attraversare lungo il cammino molti componenti quali bridge, router, repeater che, ovviamente, introducono un ritardo fisso di elaborazione, più una componente dovuta al traffico in rete.

Sliding Windows

L'introduzione del protocollo Sliding Windows (finestre scorrevoli) rende molto più efficiente la trasmissione e quindi l'utilizzo della banda, perchè 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 in figura:

Le dimensioni della finestra possono variare fino ad un massimo di 64 Kbytes. Una finestra di ampiezza opportuna riuscirebbe quasi, ipotizzando di non perdere pacchetti, a saturare completamente la banda di trasmissione.
Infatti appena il primo pacchetto della finestra 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.
Al contrario, se 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, lavorando quindi con una generazione impulsiva del carico in rete.
Il meccanismo di acknowledgment può essere un "go back N" o un "go back N selective repeat", nel senso che le disposizioni dei reference sono molto labili, specificando solo che ogni pacchetto deve essere riconosciuto in qualche modo. Gli standard specificano invece chiaramente 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. Siccome 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 anche perché fornisce al ricevente un mezzo per governare la mole di dati spediti dall'utente sorgente. 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 è detto segment. I segmenti sono scambiati per stabilire connessioni, trasferimenti di dati, inviare ACK, comunicare la dimensione della Sliding Windows e 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 mostra il formato del segmento TCP:

Ciascun segmento è diviso in due parti: un TCP header ed un TCP data.
Un header ha una lunghezza di almeno 20 byte e comprende molti campi; i più importanti sono sicuramente il "port number" e il "sequence number", sia della sorgente che della destinazione.
Il numero di porta serve per distinguere fra loro dei trasferimenti che avvengono contemporaneamente; ovviamente devo conoscere 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 per ordinare i pacchetti in ricezione e per 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.