Transmission Control Protocol: differenze tra le versioni

Versione delle 15:12, 31 gen 2024

Versione delle 21:33, 19 mag 2024

Riga 84:

** '''FIN''' - se impostato a 1 indica che l'host mittente del segmento vuole ''chiudere la connessione TCP'' aperta con l'host destinatario. Il mittente attende la conferma dal ricevente (con un FIN-ACK). A questo punto la connessione è ritenuta chiusa per metà: l'host che ha inviato FIN non potrà più inviare dati, mentre l'altro host ha il canale di comunicazione ancora disponibile. Quando anche l'altro host invierà il pacchetto con FIN impostato, la connessione, dopo il relativo FIN-ACK, sarà considerata completamente chiusa.

* '''Window size''' [16 bit] - Indica la dimensione della ''finestra di ricezione'' dell'host mittente, cioè il numero di byte che il mittente è in grado di accettare a partire da quello specificato dall'acknowledgment number.

* '''[[Checksum]]''' [16 bit] - Campo di controllo utilizzato per la verifica della validità del segmento. È ottenuto facendo il complemento a 1 della somma [[complemento a uno]] a 16 bit dell'intero header TCP (con il campo checksum messo a zero), dell'intero payload, con l'aggiunta di uno pseudo header composto da: indirizzo IP sorgente (32bit),indirizzo IP destinazione (32bit), un byte di zeri, un byte che indica il protocollo e due byte che indicano la lunghezza del pacchetto TCP (header + dati).

* '''Urgent pointer''' [16 bit] - Puntatore a dato urgente, ha significato solo se il flag URG è impostato a 1 ed indica lo scostamento in byte a partire dal ''Sequence number'' del byte di dati urgenti all'interno del flusso.

* '''Options''' - Opzioni (facoltative) per usi del protocollo avanzati.

Riga 96:

L'utilizzo del protocollo TCP rispetto a [[User Datagram Protocol|UDP]] è, in generale, preferito quando è necessario avere garanzie sulla consegna dei dati o sull'ordine di arrivo dei vari segmenti (come per esempio nel caso di trasferimenti di file).

Al contrario UDP viene principalmente usato quando l'interazione tra i due host è [[idempotente]] o nel caso si abbiano forti vincoli sulla velocità e l'economia di risorse della rete (es. [[streaming]] in tempo reale, videogiochi [[Multigiocatore|multiplayer]]).

== Connessione ==

Riga 163:

In particolare il protocollo TCP adotta la politica di '''Conferma cumulativa''', ovvero l'arrivo di numero di riscontro indica al TCP trasmittente che il ricevente ha ricevuto e correttamente inoltrato al proprio processo applicativo il segmento avente numero di sequenza pari al numero di riscontro indicato (-1) ed anche ''tutti i segmenti ad esso precedenti''. Per tale motivo TCP lato trasmittente mantiene temporaneamente in un buffer una copia di tutti i dati inviati, ma non ancora riscontrati: quando questi riceve un numero di riscontro per un certo segmento, deduce che tutti i segmenti precedenti a quel numero sono stati ricevuti correttamente liberando il proprio buffer dai dati. La dimensione massima dei pacchetti riscontrabili in maniera cumulativa è specificata dalle dimensioni della cosiddetta [[finestra scorrevole]].

Per evitare tempi di attesa troppo lunghi o troppo corti per ciascun segmento inviato TCP lato trasmittente avvia un [[Timer (informatica)|timer]], detto ''timer di ritrasmissione RTO'' (Retransmission Time Out): se questi non riceve un ACK di riscontro per il segmento inviato prima che il timer [[SCADA|scada]], TCP assume che tutti i segmenti trasmessi a partire da questo siano andati persi e quindi procede alla ritrasmissione.

Si noti che, in TCP, il meccanismo dei numeri di riscontro non permette al ricevitore di comunicare al trasmettitore che un segmento è stato perso, ma alcuni dei successivi sono stati ricevuti (meccanismo ad ''Acknowledgment Number negativi''), quindi è possibile che per un solo pacchetto perso ne debbano essere ritrasmessi molti. Questo comportamento non ottimale è compensato dalla semplicità del protocollo.