TCP: gestione della connessione

1. Porte e connessioni TCP

Per offrire affidabilità e controllo di flusso, il TCP è orientato alla connessione. Prima di trasferire il byte stream, i due sistemi terminali devono quindi creare e riconoscere uno stato condiviso; al termine devono rilasciarlo senza confondere dati vecchi e dati nuovi. Questa gestione è interamente end-to-end: riguarda i due host, non i nodi attraversati.

Il punto di accesso locale al TCP non è identificato dal solo numero di porta. La concatenazione fra indirizzo IP dell'host e numero di porta costituisce un end-point, detto anche socket address. La notazione delle slide è immediata:

end-point = indirizzo IP + porta

137.204.57.85:80

Una connessione è univocamente determinata dall'associazione di due end-point. Per esempio, la coppia 137.204.57.85:80 ↔ 192.168.10.99:10364 identifica una connessione diversa da quella che raggiunge lo stesso server e la stessa porta partendo da un altro indirizzo o da un'altra porta del client.

2. La numerazione dei dati

Il TCP considera i dati applicativi come un flusso di byte, non come una sequenza di messaggi. Di conseguenza numera i singoli byte in uno spazio a 32 bit: il contatore avanza modulo 232, cioè modulo 4 Gbyte. Un segmento porta quindi il numero del primo byte trasportato, mentre la quantità di spazio consumata dipende dai byte contenuti.

La rete fra sorgente e destinazione non è un canale sequenziale. Un segmento può essere ritardato, duplicato e consegnato quando segmenti successivi sono già arrivati. Il riuso di un numero è sicuro soltanto quando non esistono più in rete vecchi segmenti con lo stesso numero di sequenza.

Questi valori mostrano perché i 32 bit non rendano il problema puramente teorico: aumentando la velocità, il contatore torna rapidamente sugli stessi valori. Il protocollo introduce perciò il Maximum Segment Lifetime (MSL), un limite al tempo di vita di un segmento. Il valore iniziale era 2 minuti; implementazioni più recenti usano 30 secondi.

Tre vincoli da tenere distinti

La numerazione risolve il riordinamento del byte stream, ma il suo riuso impone tre verifiche diverse. Tenerle separate evita di attribuire all'ISN un compito che appartiene al tempo di vita dei segmenti, o viceversa.

Incarnazioni successive della stessa connessione

Il pericolo non è soltanto il giro completo del contatore dentro una connessione. Dopo un crash, gli stessi due end-point possono creare una nuova istanza, o incarnazione, mentre in rete sopravvivono segmenti ritardati dell'istanza precedente. Se i numeri coincidessero, un vecchio segmento potrebbe apparire valido nella nuova connessione.

All'apertura ciascun host sceglie allora un Initial Sequence Number (ISN). Per ridurre le sovrapposizioni l'ISN varia nel tempo, per esempio seguendo un contatore interno con un offset casuale. Considerando che un riavvio richiede più di un MSL, il rischio si riduce fortemente; resta però necessario che i due host sincronizzino i rispettivi ISN all'apertura.

3. L'apertura: il Three-Way Handshake

Aprire una connessione non equivale a inviare un semplice avviso. La rete può perdere, duplicare o ritardare i pacchetti; inoltre entrambi gli host devono conoscere il numero iniziale scelto dall'altro. Il TCP risolve il problema con il Three-Way Handshake (TWH), uno scambio in tre passi che sincronizza entrambe le direzioni.

1. A → B: SYN=1, SeqN=x, ACK=0. A annuncia il proprio ISN x.
2. B → A: SYN=1, ACK=1, SeqN=y, AckN=x+1. B conferma x e annuncia il proprio ISN y.
3. A → B: SYN=0, ACK=1, SeqN=x+1, AckN=y+1. A conferma y; la sincronizzazione è completa.

Il primo segmento che porta dati da A usa SeqN=x+1, cioè lo stesso valore del campo AckN ricevuto nel passo precedente. Analogamente, il flusso di B comincia da y+1. Il SYN occupa una posizione nello spazio dei numeri di sequenza; un segmento che porta soltanto un ACK non la occupa e l'ACK non viene ritrasmesso come entità autonoma.

4. Recupero dagli errori in apertura

Il TWH resta efficace quando i segmenti di apertura si perdono. Se il primo SYN non arriva a B, A non riceve alcuna risposta: allo scadere del time-out invia nuovamente il SYN con lo stesso numero iniziale. Se invece si perde il SYN+ACK, A ritrasmette il SYN e B risponde di nuovo con SYN+ACK.

La cattura mostrata nelle slide rende visibili la scadenza del time-out del SYN, l'aumento progressivo dell'attesa tramite backoff esponenziale e infine un numero massimo di tentativi. Se il socket di destinazione non esiste, il rifiuto viene invece segnalato da un segmento con RST.

Leggere l'apertura in una cattura

Una traccia Wireshark permette di seguire il protocollo nello stesso ordine del diagramma: prima il SYN, poi il SYN+ACK, infine l'ACK. Le slide mettono in evidenza anche le opzioni presenti nei primi due segmenti, perché sono specificate proprio durante l'apertura.

1. SYN — primo pacchetto di apertura della connessione e annuncio dell'ISN del client.
2. SYN+ACK — risposta del server, conferma del primo ISN e annuncio del secondo.
3. ACK — conferma finale che completa la sincronizzazione dei due numeri.
4. assenza di risposta — scadenza del time-out, nuovo SYN e intervalli crescenti fino al massimo numero di tentativi.
5. RST — rifiuto esplicito quando il socket di destinazione non esiste.

Perché il TWH è robusto

Lo schema resiste anche all'instaurazione contemporanea da parte dei due host e ignora pacchetti di apertura ritardatari. La robustezza discende dal fatto che ogni lato deve sia proporre il proprio numero sia confermare quello ricevuto: un vecchio SYN isolato non completa da solo la sincronizzazione bilaterale.

5. La chiusura della connessione

Il TCP cerca una chiusura ordinata, o soft release, che non perda dati. Il fatto che un'applicazione non abbia più nulla da inviare non implica che abbia finito di ricevere: nella direzione opposta possono esserci dati già in viaggio o ancora da trasmettere.

Per questo il rilascio è trattato in modalità simplex: le due direzioni sono chiuse indipendentemente. L'host che termina la propria trasmissione invia FIN=1 ed esegue la chiusura attiva. Quando riceve l'ACK del FIN considera chiusa la direzione in uscita; se l'ACK non arriva entro il tempo previsto, rilascia comunque la connessione. L'altro host è inizialmente il lato della chiusura passiva e può continuare a inviare finché non emette il proprio FIN.

Perdita dell'ACK del FIN

Se l'ACK del primo FIN si perde, la sorgente del FIN attende il time-out e ripete il FIN. Il destinatario può quindi inviare nuovamente la conferma. In ogni caso, trascorso il tempo previsto senza ACK, la sorgente del FIN rilascia comunque la connessione: la procedura non può restare bloccata indefinitamente.

La sequenza logica del rilascio separato

6. La macchina a stati e TIME_WAIT

L'apertura, il trasferimento e la chiusura possono essere descritti con una macchina a stati finiti. La macchina completa del TCP distingue numerosi casi; per seguire il percorso ordinario bastano gli stati principali riportati nel widget. La rappresentazione completa mostrata nelle slide è attribuita a Fall e Stevens, TCP/IP Illustrated, Vol. 1, 2nd Ed.

Lo stato TIME_WAIT

Al termine della chiusura attiva l'host non passa subito a CLOSED: resta in TIME_WAIT per un intervallo pari a 2 MSL. Durante questa attesa potrebbe ricevere nuovamente il FIN dell'altro host, per esempio perché l'ACK precedente si è perso, e può quindi confermarlo ancora.

Il secondo obiettivo è garantire l'estinzione dei segmenti appartenenti a incarnazioni precedenti. Dopo la chiusura, la stessa coppia di end-point potrebbe creare una nuova connessione e riusare numeri già impiegati; l'attesa di due massimi tempi di vita separa le due incarnazioni e impedisce ai vecchi segmenti di attraversare quel confine.

7. Le primitive Berkeley socket

Le Berkeley socket sono la tipica interfaccia fra applicazione e TCP nei sistemi operativi. Le primitive trasformano il ciclo della connessione in operazioni che ricordano l'apertura, l'uso e la chiusura di un file, ma i percorsi del server e del client non sono simmetrici.

Workflow: apertura passiva e apertura attiva

Il server prepara l'apertura passiva con socket, bind e listen, poi si ferma in accept. Il client esegue l'apertura attiva con connect. Una volta instaurata la connessione, le due applicazioni alternano send e receive; infine chiamano close.

1. preparazione del server — socket(), bind() e listen() creano e rendono raggiungibile l'end-point passivo.
2. attesa — accept() pone il server in attesa di una richiesta accodata.
3. apertura attiva — il client crea la propria socket e invoca connect() verso il socket address del server.
4. connessione instaurata — accept() restituisce la socket connessa e le parti possono eseguire send() e receive().
5. rilascio — close() avvia la chiusura e rilascia l'indirizzo della socket.

Server iterativo e server concorrente

Un server iterativo usa un ciclo infinito per servire più richieste successive, ma le gestisce in sequenza: completa il lavoro su una connessione prima di tornare ad accettarne un'altra. Un server concorrente esegue invece uno SPAWN: genera un processo o thread worker per ogni connessione e torna immediatamente in ascolto.

Codice lato client: invio di una stringa

from socket import *
serverName = "hostname"
serverPort = 55000
clientSocket = socket(AF_INET, SOCK_STREAM)
clientSocket.connect((serverName,serverPort))
sentence = raw_input("Input lowercase sentence: ")
clientSocket.send(sentence)
modifiedSentence = clientSocket.recv(1024)
print "From Server:", modifiedSentence
clientSocket.close()

Codice lato server iterativo

from socket import *
serverPort = 55000
serverSocket = socket(AF_INET, SOCK_STREAM)
serverSocket.bind(("",serverPort))
serverSocket.listen(5)
print "The server is ready to receive"
while 1:
    connectionSocket, addr = serverSocket.accept()
    sentence = connectionSocket.recv(1024)
    capitalizedSentence = sentence.upper()
    connectionSocket.send(capitalizedSentence)
    connectionSocket.close()

Codice lato server concorrente

from socket import *
from thread import *
# Multithread server - function to serve client requests
def clientthread(conn):
    sentence = conn.recv(1024)
    capitalizedSentence = sentence.upper()
    conn.send(capitalizedSentence)
    conn.close()
# Main program
serverPort = 55000
serverSocket = socket(AF_INET, SOCK_STREAM)
serverSocket.bind(("",serverPort))
serverSocket.listen(5)
print "The server is ready to receive"
while 1:
    connectionSocket, addr = serverSocket.accept()
    start_new_thread(clientthread,(connectionSocket))

Il listato annotato permette di seguire le primitive del server concorrente una per una. Il codice conserva sintassi e nomi delle slide: l'obiettivo è riconoscere il workflow, dal socket di ascolto alla creazione del worker.

Verifica le tue conoscenze