Protocollo TCP

Il TCP è un protocollo di trasporto che assicura il trasporto affidabile. Mediante TCP è possibile costruire applicazioni che si basano sul trasferimento di file senza errori tra host remoti. Il protocollo TCP effettua anche un controllo di congestione end-to-end che limita il traffico di rete e consente agli utenti di condividere in modo equo le risorse.

Definiamo i contenuti dell'header:

• Sequence Number: numero di sequenza del primo byte nel payload
• Acknowledge Number: numero di sequenza del prossimo byte che si intende ricevere
• HLEN: lunghezza totale dell'header TCP, multiplo di 32
• Window: valore della finestra di ricezione come comunicato dal ricevitore al trasmettitore
• Checksum: medesimo di UDP
• Flags:
  • URG: Vale 1 se vi sono dei dati urgenti e quindi TCP deve passare in modalità urgente.
  • ACK: Vale 1 se il pacchetto è un ACK valido, cioè se contiene un acknowledge number valido
  • PSH: Vale 1 quando il trasmettitore intende usare il comando di PUSH: il ricevitore può anche ignorare il comando
  • RST: reimposta la connessione senza un tear down esplicito
  • SYN: usato durante il setup per comunicare i numeri di sequenza iniziale
  • FIN: usato per la chiusura esplicita di una connessione
• Options e padding: riempimento (fino a 32 bit) e campi opzionali

Definisce la dimensione massima del segmento che verrà usata nella connessione TCP. La dimensione è decisa dal mittente durante la fase di setup. Di default è 536 byte.

Definisce il fattore di scala della finestra. Fa sì che venga moltiplicato il valore del campo Window di un fattore pari a 2 elevato al valore contenuto nel campo fattore di scala. Di default è 1.

1. Il server fa una Passive Open, che comunica al TCP locale che è pronto per accettare nuove connessioni.
2. Il client che desidera comunicare fa una Active Open, che comunica al TCP locale che l'applicativo intende effettuare una connessione verso un dato socket.
3. Il client TCP estrae un numero di sequenza iniziale e invia un messaggio SYN=1 contenente il numero di sequenza. Eventualmente indica anche i parametri aggiuntivi. Il numero casuale serve a evitare problemi nel caso il setup non vada a buon fine.
4. Quando riceve SYN, il server TCP estrae un numero di sequenza iniziale e manda un segmento SYN=1 e ACK=1 contenendo AN pari al numero estratto dal client.
5. Il client TCP riceve il messaggio SYN/ACK del server e invia ACK con AN pari al numero estratto dal server. Inserisce anche la dimensione di finestra del server.
6. Il client notifica all'applicazione che la connessione è aperta.
7. Quando il TCP server riceve l'ACK del client, notifica al suo applicativo che la connessione è aperta.
   

1. Il TCP che chiude la connessione invia un messaggio FIN=1 con gli ultimi dati.
2. Il TCP che riceve il messaggio invia ACK per confermare, lasciando comunque la connessione aperta.
3. Il TCP che ha ricevuto il messaggio invia quindi un messaggio FIN=1.
4. Il TCP che ha inviato il messaggio iniziale risponde con un ACK finale.
   

La connessione può essere chiusa senza scambio di messaggio nei due versi, in quanto è possibile semplicemente interrompere la connessione impostando il flag di RESET.

Questo problema si manifesta sia nel buffer di ricezione che in quello di invio e rallenta la trasmissione.

Nel ricevitore il buffer di ricezione viene svuotato lentamente, di conseguenza i segmenti sono inviati con una finestra molto piccola e il trasmettitore deve inviare segmenti corti con molto overhead.

Nel trasmettitore l'applicazione genera dati lentamente, e quindi invia segmenti molto piccoli man mano che vengono prodotti.

Per evitare la Silly window syndrome nel ricevitore, esso mente al trasmettitore indicando una finestra nulla sino a che il suo buffer di ricezione non si è svuotato per metà o per una porzione almeno pari al MSS:

Per evitare la Silly window syndrome nel trasmettitore, esso invia la prima porzione di dati anche se corta, e gli altri dati vengono inviati solo se il buffer di uscita contiene dati sufficienti a riempire una MMS oppure, quando si riceve un AN per un segmento precedente.

TCP originariamente prevedeva una gestione speciale per i dati che richiedono di essere consegnati immediatamente, per ottenere l'invio immediato infatti l'applicazione può impostare il campo PUSH, anche se generalmente non è disponibile nelle interfacce offerte dai linguaggi di programmazione, infatti è automaticamente impostato nell'ultimo segmento che svuota il buffer.

TCP dispone di una modalità urgent, che però per dei cambiamenti negli standard RFC non è stabile. Gli RFC successivi ribadiscono il cambiamento più recente, tuttavia alcuni dispositivi seguono ancora quello vecchi. Inoltre i sistemi operativi implementano urgent in maniera differente, è consigliabile non usare.

Il meccanismo di controllo d'errore del TCP serve a recuperare pacchetti persi in rete. La causa principale di tale perdita è l'overflow di una delle code dei router attraversati a causa della congestione. I dati vengono ritrasmessi usando Go-Back-N con timeout:

• TCP mantiene nel buffer anche i segmenti fuori ordine.
• Quando arrivano segmenti mancanti la finestra scorre in avanti fino al primo segmento non riscontrato in quelli ricevuti fuori ordine.
• Viene mandato un ACK che riscontra collettivamente anche i segmenti fuori ordine.

La finestra di trasmissione dipende dal meccanismo di controllo di flusso e di congestione.

Se il destinatario fissa a 0 la finestra di ricezione la sorgente TCP interrompe la trasmissione, e riprende solo quando il destinatario invia un ACK con una dimensione della finestra diversa da 0. Tuttavia se questo ACK andasse perso la connessione rimarrebbe bloccata.

Per evitare questa situazione si usa un timer di persistenza che viene attivato quando arriva un segmento con finestra nulla. Se il timer di persistenza scade, viene inviato un piccolo segmento sonda, in questo modo se viene ricevuto un ACK si esce dallo stato critico, altrimenti al nuovo scadere del timeout si re invia di nuovo.

Il controllo di flusso dipende dalla capacità del ricevitore. Tuttavia attualmente non esistono meccanismi di controllo di congestione a livello rete, esso è delegato a TCP e quindi è end-to-end. Il modo più naturale per controllare il ritmo di immissione in rete dei dati per il TCP è quello di regolare la finestra di trasmissione.

Il trasmettitore mantiene una Congestion Window (CWND) che varia in base agli eventi osservati. Il trasmettitore non può trasmettere più del minimo tra RCVWND e CWND: L'idea di base del controllo di congestione del TCP è quella di interpretare la perdita di un segmento, come un evento di congestione, e la reazione è quella di ridurre CWND, quindi riduco il rate equivalente sulla connessione TCP che sto valutando.

Un evento di congestione si verifica quando il ritmo di trasmissione porta in congestione un link sul percorso in rete verso la destinazione. Un link è definito congestionato quando la somma dei ritmi di trasmissione dei flussi che lo attraversano è maggiore delle sue capacità.

In caso scada il timeout di ritrasmissione il TCP reagisce ponendo SSTHRESH pari alla metà dei byte trasmessi ma non riscontrati:

Di solito i "byte in volo" sono una buona approssimazione pari all'ultima CWND. Di conseguenza:

• CWND è minore di SSTHRESH e si entra nella fase di Slow Start
• Il trasmettitore invia un segmento e la sua CWND è incrementata di 1 ad ogni ACK.

A questo punto il trasmettitore trasmette tutti i segmenti a partire da quello per cui il timeout è fallito (Go-Back-N), e il valore a cui è posta SSTHRESH è una stima della finestra ottimale che eviterebbe futuri eventi di congestione.

È possibile dimostrare che in condizioni ideali il meccanismo di controllo del TCP è in grado di:

• Limitare la congestione in rete
• Consentire di dividere in modo equo la capacità dei link tra i diversi flussi

Le condizioni ideali sono alterate tra l'altro da:

• Differenti RTT per i diversi flussi
• Buffer nei nodi minori del prodotto bandaritardo

Questa feature aggiuntiva al TCP classico è usata per ottimizzare la ritrasmissione del singolo pacchetto perso.

Se arrivano degli ACK duplicati il pacchetto sarà andato perso, tuttavia saranno arrivati i pacchetti successivi. Se non c'è congestione possiamo incrementare CWND del numero di pacchetti sicuramente arrivati. Grazie a questa feature il trasmettitore trasmette il pacchetto perso dopo il terzo ACK duplicato:

1. Alla ricezione del terzo ACK consecutivo duplicato:
2. Viene ritrasmesso il pacchetto indicato dall'AN.
3. Si pone:
4. Per ogni ulteriore ACK duplicato ricevuto la CWND viene incrementata di 1.
5. Vengono trasmessi nuovi segmenti se consentito dai valori di CWND e RWND.
6. Appena arriva un ACK che riscontra nuovi dati si esce dalla fase di fast recovery e si pone di nuovo:

Esistono diverse versioni di TCP, ma sono tutte retrocompatibili con le versioni base. TCP è implementato nel sistema operativo, infatti esistono versioni come ECN che viola la comunicazione tra livelli differenti.
Esistono inoltre versioni adatte a connessioni ibride, dove le perdite sono dovute sia alla congestione che alla perdita sporadica legata a problemi di connessione radio.

La versione base TCP si chiama Tahoe.