Il protocollo TCP riesce ad offrire un servizio di trasferimento affidabile graz

ie all'utilizzo di:
- ack (cumulativi)
- numero di sequenza
- scelta di un timeout per la ritrasmissione.
Appena un mittente vuole inviare un segmento, a quest'ultimo viene associato un
numero di sequenza.
Alla ricezione di un segmento, il ricevitore manda un segmento di ack (normale s
egmento con campo flag
settato ad 1 - l'ack in piggybacking). Il TCP supporta ack cumulativi.
Inoltre, grazie al timeout, il mittente allo scadere del timer ritrasmetter il se
gmento di cui non ha
ricevuto l'ack (il mittente considera il segmento perso). A ricezione potrebbe a
rrivare
un segmento "doppione", in questo caso grazie al numero di sequenza il ricevitor
e capisce
che si tratta di un duplicato e lo scarta.
TCP connection oriented, nel senso che prima dell'effettivo trasferimento dei da
ti
c' una fase di instaurazione della connessione. La connessione viene stabilita me
diante
l'HANDSHAKING a 3 vie. (tale meccanismo si ritrova anche in fase di chiusura del
la connessione).
Bisogna che host mittente e destinatario conoscano il numero di sequenza dell'al
tro terminale.
Si tratta di un vero e proprio "dialogo" che si svolge in tre fasi:
- prima fase: il client (lato mittente) trasmette un segmento di SYN (con il fla
g SYN settato ad 1CC-per
segnalare che si tratta di un segmento di sincronizzazione), con un numero di se
quenza scelto arbitrariamente dal
mittente, che l'initial sequence number di dell'host mittente.
-seconda fase: il ricevitore riceve il segmento di syn e manda una conferma al m
ittente (con segmento in cui
flag ACK e SYN sono settati a 1). Questo segmento conterr anche il numero di
sequenza del ricevitore e il numero di ACK che sar posto = numero di sequenza del
mittente + 1-terza fase: il client manda anch'esso un ack al ricevitore (il segmento avr flag
ack settato a 1 e flag syn settato a 0: la fase di sincronizzazione finita).
Il suo numero di sequenza sar incrementato (tcp orientato al byte e non al numero
di segmenti) e il numero di ack sar
settato = numero di sequenza del ricevitore + 1.
I segmenti utilizzati durante questa fase di instaurazione sono solitamente "sol
o header", cio non contengono dati.
TCP offre un servizio di consegna affidabile dei messaggi e ORDINATA, grazie al
numero di sequenza.
Il numero di sequenza, infatti, serve ad identificare e posizionare in ordine il
carico utile del segmento TCP (il payload
applicativo) all'interno del flusso di dati.
A ricezione ci si aspetta di ricevere il segmento successivo all'ultimo segmento
ricevuto in ordine, ovvero quel segmento il
cui sequence number = sequence number dell'ultimo pervenuto in ordine pi la dimen
sione del carico utile del segmento in attesa).
Se il sequence number ricevuto= a quello atteso il carico utile del segmento vie
ne inviato direttamente al livello soprastante.
Se il sequence number > si deduce che sono stati persi o sono in transito sulla
rete. Quindi il ricevitore riceve un segmento fuori

sequenza. In questo caso non si sa esattamente cosa faccia il ricevitore (dipend

e dalle scelte implementative): o
bufferizza il segmento in attesa di ricevere segmenti con numero di sequenza att
eso, in modo tale che appena questi arrivano
pu liberare il buffer e mandare la sequenza in ordine a livello applicativo. Oppu
re scarta il segmento.
se il sequence number < di quello atteso vuol dire che un duplicato; viene dunqu
e scartato.
Altro elemento importante offerto dal TCP l'ACK number; per ogni segmento ricevu
to in sequenza il TCP lato ricevente invier un ACK; questo
ack = numero di sequenza atteso dal mittente + 1.
TCP adotta la politica degli ACK cumulativi, ovvero l'arrivo dell'ack
indica al mittente che il ricevitore ha ricevuto correttamente il segmento con n
umero di sequenza = numero di ack - 1 e anche tutti i segmenti
ad esso precedenti. TCP un protocollo di tipo pipelined: lato mittente TCP manti
ene in un buffer
una copia di tutti i segmenti inviati ma non ancora ackati. Appena riceve l'ack
sposta la sliding window.
La consegna affidabile viene anche gestita dalla scelta di un TIMER (lato mitten
te).
TCP offre inoltre un controllo del flusso (evitare di fare andare in overflow il
buffer del destinatario) facendo mantenere al ricevitore
una variabile denominata RECEIVE WINDOW (che fornisce al mittente un'indicazione
sullo spazio disponibile nel buffer del destinatario).
Tale spazio varia con il tempo in funzione dei pacchetti in arrivo e anche in fu
nzione della velocit di lettura del buffer stesso.
Dunque la dimensione dinamica. Definiamo ora delle variabili:
LastByteRead : Numero dell'ultimo byte nel flusso di dati letto dal processo app
licativo in B.
LastByteRcvd : Numero dell'ultimo byte copiato nel buffer di ricezione di B.
Dato che ogni segmento TCP non deve fuoriuscire dal buffer allocato si deve aver
e:
LastByteRcvd - LastByteRead <= RcvBuffer.
La finestra di ricezione, chiamata RcvWindow, posta uguale alla quantit di spazio
disponibile nel buffer: RcvWindow = RcvBuffer - (LastByteRcvd - LastByteRead)
Dato che lo spazio disponibile nel buffer varia con il tempo in funzione dei pac
chetti in arrivo e all'attivit di lettura del buffer stesso la dimensione di RcvW
indow anch'essa dinamica.
Quindi l'Host B comunica ad A quanto spazio ha a disposizione nel proprio buffer
posizionando il valore corrente di RcvWindow nel campo finestra di ricezione de
i segmenti che manda ad A. A sua volta l'host A mantiene due variabili che sono
LastByteSent e LastByteAcked (ultimo byte inviato, ultimo byte riscontrato). La
differenza tra questi due valori indica la quantit di dati inviati e non ancora r
iscontrati da A nella connessione. Mantenendo quindi la differenza LastByteSentLastByteAcked <= RcvWindow si garantisce che l'host A non mandi in overflow il b
uffer di ricezione dell'host B. Pu capitare, per, che il buffer di B si riempia e,
come conseguenza, l'host A rimanga bloccato e non possa trasmettere ulteriori d
ati. Per risolvere tale problema, il TCP fa s che l'host A continui ad inviare se
gmenti costituiti da un byte di soli zero quando la finestra di ricezione di B z
ero. Questi segmenti verranno scartati fino a quando il buffer di B non inizi a
svuotarsi. Una volta svuotato il buffer, l'host A ricever dei riscontri non nulli
della RcvWindow di B e da l continuer ad inviare (se ci sono ancora) dati all'hos
t B.