Transmission Control Protocol

Da Wikipedia, l'enciclopedia libera.

In telecomunicazioni e informatica il Transmission Control Protocol (TCP), anche chiamato Transfer Control Protocol, è un protocollo di rete a pacchetto di livello di trasporto, appartenente alla suite di protocolli Internet, che si occupa di controllo di trasmissione ovvero rendere affidabile la comunicazione dati in rete tra mittente e destinatario. È definito nella RFC 793 e su di esso si appoggiano gran parte delle applicazioni della rete Internet. È presente solo sui terminali di rete (host) e non sui nodi interni di commutazione della rete di trasporto, implementato come strato software di rete all'interno del rispettivo sistema operativo ed il sistema terminale in trasmissione vi accede automaticamente dal browser attraverso l'uso di opportune chiamate di sistema definite nelle API di sistema.

Descrizione[modifica | modifica sorgente]

Il TCP può essere classificato al livello trasporto (OSI level 4) del modello di riferimento OSI, e di solito è usato in combinazione con il protocollo di livello rete (OSI level 3) IP. La corrispondenza con il modello OSI non è perfetta, in quanto il TCP e l'IP nascono prima del suddetto modello. La loro combinazione è indicata come TCP/IP e, alle volte, è erroneamente considerata un unico protocollo. Da qui, la difficoltà di una classificazione univoca per un protocollo che comprende, a pieno titolo, due livelli dello stack OSI (o pila ISO/OSI in italiano).

In linea con i dettami del livello di trasporto stabiliti dal modello ISO-OSI e con l'intento di superare il problema della mancanza di affidabilità e controllo della comunicazione sorto con l'interconessione su vasta scala di reti locali in un'unica grande rete geografica, TCP è stato progettato e realizzato per utilizzare i servizi offerti dai protocolli di rete di livello inferiore (IP e protocolli di livello fisico e livello datalink) che definiscono efficacemente il modo di trasferimento sul canale di comunicazione, ma che non offrono alcuna garanzia di affidabilità sulla consegna in termini di ritardo, perdita ed errore dei pacchetti informativi trasmessi, sul controllo di flusso tra terminali e sul controllo della congestione di rete, supplendo quindi ai problemi di cui sopra e costruendo così un canale di comunicazione affidabile tra due processi applicativi di rete. Il canale di comunicazione così costruito è costituito da un flusso bidirezionale di byte a seguito dell'instaurazione di una connessione agli estremi tra i due terminali in comunicazione. Inoltre alcune funzionalità di TCP sono vitali per il buon funzionamento complessivo di una rete IP. Sotto questo punto di vista TCP può essere considerato come un elemento di rete che si occupa di garantire una qualità di servizio minima su una rete IP sotto che è di tipo best-effort.

Il TCP nacque nel 1970 come frutto del lavoro di un gruppo di ricerca del dipartimento di difesa statunitense. I suoi punti di forza sono l'alta affidabilità e robustezza. La sua popolarità si deve anche grazie ad una sua implementazione diffusa dalla Università di Berkeley, rilasciata in California sotto forma di sorgenti (TCP Berkeley). Molte tuttavia sono le implementazioni e sviluppi che si sono succedute nel tempo come evoluzioni e miglioramenti (es. TCP Tahoe, TCP Reno, TCP New Reno).

Caratteristiche principali[modifica | modifica sorgente]

  • TCP è un protocollo orientato alla connessione, ovvero prima di poter trasmettere dati deve stabilire la comunicazione, negoziando una connessione tra mittente e destinatario, che rimane attiva anche in assenza di scambio di dati e viene esplicitamente chiusa quando non più necessaria. Esso quindi possiede le funzionalità per creare, mantenere e chiudere/abbattere una connessione.
  • Il servizio offerto da TCP è il trasporto di un flusso di byte bidirezionale tra due applicazioni in esecuzione su host differenti. Il protocollo permette alle due applicazioni di trasmettere contemporaneamente nelle due direzioni, quindi il servizio può essere considerato "Full-duplex" anche se non tutti i protocolli applicativi basati su TCP utilizzano questa possibilità.
  • Il flusso di byte viene frazionato in blocchi per la trasmissione dall'applicazione a TCP (che normalmente è implementato all'interno del sistema operativo), per la trasmissione all'interno di segmenti TCP, per la consegna all'applicazione che lo riceve, ma questa divisione in blocchi non è necessariamente la stessa nei diversi passaggi.
  • TCP garantisce che i dati trasmessi, se giungono a destinazione, lo facciano in ordine e una volta sola ("at most once"). Più formalmente, il protocollo fornisce ai livelli superiori un servizio equivalente ad una connessione fisica diretta che trasporta un flusso di byte. Questo è realizzato attraverso vari meccanismi di acknowledgment e di ritrasmissione su timeout.
  • TCP offre funzionalità di controllo di errore sui pacchetti pervenuti grazie al campo checksum contenuto nella sua PDU.
  • TCP possiede funzionalità di controllo di flusso tra terminali in comunicazione e controllo della congestione sulla connessione, attraverso il meccanismo della finestra scorrevole. Questo permette di ottimizzare l'utilizzo della rete anche in caso di congestione, e di condividere equamente la capacità disponibile tra diverse sessioni TCP attive su un collegamento.
  • TCP fornisce un servizio di multiplazione delle connessioni su un host, attraverso il meccanismo delle porte.

Confronto con UDP[modifica | modifica sorgente]

Le principali differenze tra TCP e UDP (User Datagram Protocol), l'altro principale protocollo di trasporto della suite di protocolli Internet, sono:

  • mentre TCP è un protocollo orientato alla connessione, pertanto per stabilire, mantenere e chiudere una connessione, è necessario inviare pacchetti di servizio i quali aumentano l'overhead di comunicazione. Al contrario, UDP è senza connessione ed invia solo i datagrammi richiesti dal livello applicativo;
  • UDP non offre nessuna garanzia sull'affidabilità della comunicazione ovvero sull'effettivo arrivo dei datagrammi, sul loro ordine in sequenza in arrivo, al contrario il TCP tramite i meccanismi di acknowledgement e di ritrasmissione su timeout riesce a garantire la consegna dei dati, anche se al costo di un maggiore overhead (raffrontabile visivamente confrontando la dimensione delle intestazioni dei due protocolli);
  • l'oggetto della comunicazione di TCP è il flusso di byte mentre quello di UDP è il singolo datagramma.

L'utilizzo del protocollo TCP rispetto a 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. instant messaging).

Segmento TCP[modifica | modifica sorgente]

La PDU di TCP è detta segmento. Ciascun segmento viene normalmente imbustato in un pacchetto IP, ed è costituito dall'intestazione (header) TCP e da un carico utile (in inglese payload), ovvero dati di livello applicativo. I dati contenuti nell'intestazione costituiscono un canale di comunicazione tra le due entità TCP, che viene utilizzato per realizzare le funzionalità dello strato di trasporto e non è accessibile agli strati dei livelli superiori.

Un segmento TCP è così strutturato:

TCP Header
Bit offset Bits 0–3 4–7 8–15 16–31
0 Source port Destination port
32 Sequence number
64 Acknowledgment number
96 Data offset Reserved CWR ECE URG ACK PSH RST SYN FIN Window Size
128 Checksum Urgent pointer
160 Options (optional)
160/192+  
Data
 
  • Source port [16 bit] - Identifica il numero di porta sull'host mittente associato alla connessione TCP.
  • Destination port [16 bit] - Identifica il numero di porta sull'host destinatario associato alla connessione TCP.
  • Sequence number [32 bit] - Numero di sequenza, indica lo scostamento (espresso in byte) dell'inizio del segmento TCP all'interno del flusso completo, a partire dall' Initial Sequence Number (ISN), negoziato all'apertura della connessione.
  • Acknowledgment number [32 bit] - Numero di riscontro, ha significato solo se il flag ACK è impostato a 1, e conferma la ricezione di una parte del flusso di dati nella direzione opposta, indicando il valore del prossimo Sequence number che l'host mittente del segmento TCP si aspetta di ricevere.
  • Data offset [4 bit] - Indica la lunghezza (in word da 32 bit) dell'header del segmento TCP; tale lunghezza può variare da 5 word (20 byte) a 15 word (60 byte) a seconda della presenza e della lunghezza del campo facoltativo Options.
  • Reserved [4 bit] - Bit non utilizzati e predisposti per sviluppi futuri del protocollo; dovrebbero essere settati a zero.
  • Flags [8 bit] - Bit utilizzati per il controllo del protocollo:
    • CWR (Congestion Window Reduced) - se settato a 1 indica che l'host sorgente ha ricevuto un segmento TCP con il flag ECE settato a 1 (aggiunto all'header in RFC 3168).
    • ECE [ECN (Explicit Congestion Notification) -Echo] - se settato a 1 indica che l'host supporta ECN durante il 3-way handshake (aggiunto all'header in RFC 3168).
    • URG - se settato a 1 indica che nel flusso sono presenti dati urgenti alla posizione (offset) indicata dal campo Urgent pointer. Urgent Pointer punta alla fine dei dati urgenti;
    • ACK - se settato a 1 indica che il campo Acknowledgment number è valido;
    • PSH - se settato a 1 indica che i dati in arrivo non devono essere bufferizzati ma passati subito ai livelli superiori dell'applicazione;
    • RST - se settato a 1 indica che la connessione non è valida; viene utilizzato in caso di grave errore; a volte utilizzato insieme al flag ACK per la chiusura di una connessione.
    • SYN - se settato a 1 indica che l'host mittente del segmento vuole aprire una connessione TCP con l'host destinatario e specifica nel campo Sequence number il valore dell' Initial Sequence Number (ISN); ha lo scopo di sincronizzare i numeri di sequenza dei due host. L'host che ha inviato il SYN deve attendere dall'host remoto un pacchetto SYN/ACK.
    • FIN - se settato 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 è settato 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.
  • Data - rappresenta il carico utile o payload da trasmettere cioè la PDU proveniente dal livello superiore.

Connessione[modifica | modifica sorgente]

Prima ancora del trasferimento dei dati su canale di comunicazione e delle operazioni di controllo di trasmissione sul flusso dei dati in ricezione, in trasmissione TCP si occupa di instaurare la connessione agli estremi tra i processi applicativi dei terminali in comunicazione attraverso la definizione del socket ovvero coppia indirizzo IP, porta sia del mittente che del destinatario. Si ricorda invece che la commutazione interna nei nodi della rete di trasporto dati segue invece tipicamente la commutazione di pacchetto ovvero senza circuito o connessione fissa dedicata tipica invece della commutazione di circuito. Il fine della connessione TCP è in ogni caso il riservamento di risorse tra processi applicativi che si scambiano informazioni o servizi tra loro (es. server e client). Al termine della connessione, TCP attua la fase dell'abbattimento della connessione. Le due procedure sono distinte e descritte a seguito. L'implementazione di applicazioni di connessione di rete a pacchetto ricade nell'ambito della cosiddetta programmazione socket.

Apertura di una connessione - Three-way handshake[modifica | modifica sorgente]

Three-way handshake

La procedura utilizzata per instaurare in modo affidabile una connessione TCP tra due host è chiamata three-way handshake (stretta di mano in 3 passaggi), indicando la necessità di scambiare 3 messaggi tra host mittente e host ricevente affinché la connessione sia instaurata correttamente. Consideriamo ad esempio che l'host A intenda aprire una connessione TCP con l'host B; i passi da seguire quindi sono:

  1. A invia un segmento SYN a B - il flag SYN è impostato a 1 e il campo Sequence number contiene il valore x che specifica l' Initial Sequence Number di A;
  2. B invia un segmento SYN/ACK ad A - i flag SYN e ACK sono impostati a 1, il campo Sequence number contiene il valore y che specifica l' Initial Sequence Number di B e il campo Acknowledgment number contiene il valore x+1 confermando la ricezione del ISN di A;
  3. A invia un segmento ACK a B - il flag ACK è impostato a 1 e il campo Acknowledgment number contiene il valore y+1 confermando la ricezione del ISN di B.

Il terzo segmento non sarebbe, idealmente, necessario per l'apertura della connessione in quanto già dopo la ricezione da parte di A del secondo segmento, entrambi gli host hanno espresso la loro disponibilità all'apertura della connessione. Tuttavia esso risulta necessario al fine di permettere anche all'host B una stima del timeout iniziale, come tempo intercorso tra l'invio di un segmento e la ricezione del corrispondente ACK.

Il flag SYN risulta utile nell'implementazione pratica del protocollo, e nella sua analisi da parte dei firewall: nel traffico TCP i segmenti SYN stabiliscono nuove connessioni, mentre quelli con il flag non attivo appartengono a connessioni già instaurate.

I segmenti utilizzati durante l'handshake sono solitamente 'solo header', ossia hanno il campo Data vuoto essendo questa una fase di sincronizzazione tra i due host e non di scambio di dati.

Il three-way handshake si rende necessario poiché la sequenza numerica (ISN) non è legata ad un clock generale della rete, inoltre ogni pacchetto IP può avere il proprio modo di calcolare l’Initial Sequence Number. Alla ricezione del primo SYN non è possibile sapere se, la sequenza ricevuta, appartenga ad un ritardo dovuto da una precedente connessione. Tuttavia, viene memorizzata l’ ultima sequenza usata nella connessione potendo così essere richiesta la verifica all’ host mittente, del SYN appartenente alla vecchia connessione.

Chiusura di una connessione - Four-way handshake[modifica | modifica sorgente]

Chiusura a 4 vie

Dopo che è stata stabilita, una connessione TCP non è considerata una singola connessione bidirezionale, ma piuttosto come l'affasciamento di due connessioni monodirezionali. Pertanto, ognuna delle parti deve terminare la sua connessione, e possono esistere anche connessioni aperte a metà, in cui solo uno dei due terminali ha chiuso la connessione e non può più trasmettere, ma può (e deve) ricevere i dati dall'altro terminale.

Di conseguenza, la chiusura della connessione si può effettuare in due modi: con un handshake a tre vie, in cui le due parti chiudono contemporaneamente le rispettive connessioni, o con uno a quattro vie, in cui le due connessioni vengono chiuse in tempi diversi.

L'handshake a 3 vie è omologo a quello usato per l'apertura della connessione, con la differenza che il flag utilizzato è il FIN invece del SYN. Un terminale invia un pacchetto con la richiesta FIN, l'altro risponde con un FIN + ACK, ed infine il primo manda l'ultimo ACK, e l'intera connessione viene terminata.

L'handshake a 4 vie invece viene utilizzato quando la disconnessione non è contemporanea tra i due terminali in comunicazione. In questo caso uno dei due terminali invia la richiesta di FIN, e attende l'ACK. L'altro terminale farà poi altrettanto, generando quindi un totale di 4 pacchetti.

Multiplazione e porte[modifica | modifica sorgente]

Ciascuna connessione TCP attiva è associata a un socket aperto da un processo (il socket è lo strumento offerto dal sistema operativo alle applicazioni per usare le funzionalità della rete). TCP si occupa di smistare i dati tra le connessioni attive ed i relativi processi. Per questo, a ciascuna connessione tra due host viene associato un numero di porta su ciascuno dei due host, che è un intero senza segno a 16 bit (0-65535), contenuto nell'apposito campo dell'header.

Una connessione TCP sarà quindi identificata dagli indirizzi IP dei due host e dalle porte utilizzate sui due host.

In questo modo, un server può accettare connessioni da più client contemporaneamente attraverso una o più porte, un client può stabilire più connessioni verso più destinazioni, ed è anche possibile che un client stabilisca contemporaneamente più connessioni indipendenti verso la stessa porta dello stesso server.

Server e Client[modifica | modifica sorgente]

I due processi che comunicano attraverso una connessione TCP hanno ruoli diversi:

  • Il processo che avvia una nuova connessione TCP è detto client, ed invia una richiesta di connessione verso una determinata porta.
  • Affinché la connessione venga stabilita, su quella porta deve esserci un processo server "in ascolto", che accetta di stabilire una connessione TCP.

Le porte conosciute e registrate sono quindi utilizzate dai processi server, e sono convenzionalmente associate a particolari servizi, in modo che un client sappia a quale porta connettersi per raggiungere un determinato server.

Il processo server, che è in ascolto su una certa porta, rimane bloccato in attesa che un client si colleghi. Il processo client richiede di stabilire una connessione verso un determinato server su una determinata porta. Normalmente la porta sorgente usata dal client viene allocata dinamicamente dal sistema operativo del client. Quando il TCP stabilisce la connessione, a entrambi i processi viene assegnato un socket tramite cui essi possono comunicare tra loro. Tipicamente il processo server effettua una fork, affida al figlio il compito di comunicare con il nuovo client e si rimette in ascolto. Da questo punto in poi, client e server hanno ruoli simmetrici, e utilizzano gli stessi strumenti per comunicare attraverso il socket.

Affidabilità della comunicazione[modifica | modifica sorgente]

Consegna ordinata ed eliminazione di duplicati[modifica | modifica sorgente]

Il Sequence number, o numero di sequenza, serve a identificare e posizionare in maniera ordinata il carico utile del segmento TCP all'interno del flusso di dati. Con la trasmissione tipica a commutazione di pacchetto della rete dati infatti ciascun pacchetto può seguire percorsi diversi in rete e giungere fuori sequenza in ricezione.

In ricezione TCP si aspetta di ricevere il segmento successivo all'ultimo segmento ricevuto in ordine ovvero quello il cui numero di sequenza è pari al numero di sequenza dell'ultimo pervenuto in ordine più la dimensione del carico utile del segmento in attesa (cioè del suo campo Data).

In relazione al numero di sequenza TCP ricevente attua le seguenti procedure:

  • se il numero di sequenza ricevuto è quello atteso invia direttamente il carico utile del segmento al processo di livello applicativo e libera i propri buffer.
  • se il numero di sequenza ricevuto è maggiore di quello atteso deduce che uno o più segmenti ad esso precedenti sono andati persi, ritardati dal livello di rete sottostante o ancora in transito sulla rete. Pertanto, memorizza temporaneamente in un buffer il carico utile del segmento ricevuto fuori sequenza per poterlo consegnare al processo applicativo solo dopo aver ricevuto e consegnato anche tutti i segmenti precedenti non ancora pervenuti passanti anch'essi per il buffer, aspettandone l'arrivo fino ad un tempo limite prefissato (time-out). All'istante di consegna del blocco ordinato di segmenti tutto il contenuto del buffer viene liberato. Dal punto di vista del processo applicativo, quindi, i dati arriveranno in ordine anche se la rete ha per qualsiasi motivo alterato questo ordine realizzando così il requisito della consegna ordinata dei dati.
  • se il numero di sequenza ricevuto è inferiore a quello atteso, il segmento viene considerato un duplicato di uno già ricevuto e già inviato allo strato applicativo e dunque scartato. Questo permette di realizzare l'eliminazione dei duplicati di rete.

Riscontro dei pacchetti e ritrasmissione[modifica | modifica sorgente]

Per ogni segmento ricevuto in sequenza inoltre TCP lato ricevente invia un Acknowledgment Number o numero di riscontro dell'avvenuta ricezione. Il numero di riscontro presente in un segmento riguarda il flusso di dati nella direzione opposta. In particolare, il numero di riscontro inviato da A a B è pari al numero di sequenza atteso da A e, quindi, riguarda il flusso di dati da B ad A.

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, 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, 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. Questa tecnica è detta Go-Back-N (vai indietro di N segmenti); l'alternativa, ovvero progettare il protocollo in modo tale che solo i pacchetti effettivamente persi vengano ritrasmessi, è detta Selective Repeat (ripetizione selettiva); l'utilizzo però di alcuni campi opzionali appositi permette l'utilizzo della ripetizione selettiva.

I numeri di riscontro e i relativi timer di ritrasmissione permettono quindi di realizzare la consegna affidabile, ovvero di garantire che tutti i dati inviati siano comunque consegnati nel caso in cui qualche pacchetto possa essere perso nel transito attraverso la rete (controllo di errore in termini di riscontro di trasmissione).

Controllo di flusso[modifica | modifica sorgente]

Exquisite-kfind.png Per approfondire, vedi Controllo di flusso.

L'affidabilità della comunicazione in TCP è garantita anche dal cosiddetto controllo di flusso ovvero far in modo che il flusso di dati in trasmissione non superi le capacità di ricezione ovvero di memorizzazione del ricevente con perdita di pacchetti e maggior peso e latenze nelle successive richieste di ritrasmissione. Viene attuato attraverso la specifica da parte del destinatario di un opportuno campo noto come RCV_WND (finestra di ricezione) il quale specifica il numero massimo di segmenti ricevibile dal destinatario.

Controllo di congestione[modifica | modifica sorgente]

Exquisite-kfind.png Per approfondire, vedi Controllo della congestione in TCP.

Infine l'ultimo tipo di controllo effettuato da TCP per garantire affidabilità alla comunicazione è il cosiddetto controllo della congestione ovvero far in modo che si limitino il più possibile fenomeni di congestione all'interno della rete per eccessivo traffico sui dispositivi di rete con perdita di pacchetti in transito e maggior peso e latenze nelle successive richieste di ritrasmissione, modulando nel tempo la quantità di dati in trasmissione in funzione dello stato interno di congestione. La particolarità di tale controllo è che viene effettuato agendo sulla trasmissione agli estremi cioè sui terminali di rete e non attraverso la commutazione interna alla rete grazie alle informazioni deducibili dal terminale stesso sullo stato della trasmissione dei pacchetti. Nello specifico, una volta "stimato" lo stato di congestione interno della rete avendo scelto come parametro di riferimento la perdita di pacchetti trasmessi desunta dai mancati ACK di riscontro dei pacchetti stessi, tale controllo viene poi attuato attraverso la definizione da parte del mittente di un opportuno campo noto come C_WND (finestra di congestione) la quale assegna, dinamicamente nel tempo, il numero massimo di segmenti da trasmettere al destinatario.

I timer del TCP[modifica | modifica sorgente]

Timer di ritrasmissione[modifica | modifica sorgente]

Come descritto sopra, il timer di ritrasmissione serve a verificare che ciascun segmento trasmesso venga riscontrato.

La corretta impostazione di questo timer è difficile ma molto importante, in quanto un timer troppo breve comporta ritrasmissioni inutili (il timer scatta mentre il riscontro o il pacchetto sono ancora in viaggio), mentre un timer troppo lungo comporta attese in caso di effettiva perdita di pacchetti. Ovviamente tale intervallo dovrà essere almeno pari al Round Trip Time cioè al tempo di percorrenza a due vie di un pacchetto per tornare al mittente sotto forma di ACK. Tale RTT, per la natura intrinseca della commutazione di pacchetto interna alla rete, è tipicamente variabile in maniera aleatoria. TCP allora aggiusta continuamente il timer di ritrasmissione basandosi su una stima a media mobile del Round Trip Time.

Timer di persistenza[modifica | modifica sorgente]

Come spiegato sopra, il TCP utilizza il metodo della finestra scorrevole per gestire il controllo di flusso di dati che il ricevente è in grado di accettare dal mittente. Tra i valori validi di questo campo vi è anche lo zero, a significare che il ricevente richiede l'interruzione momentanea dell'invio di dati.

Nel malaugurato caso in cui il pacchetto che riapre la finestra venga perso, il mittente del canale TCP rimarrà però in attesa indefinita. Per evitare questo, il TCP avvia un timer, detto timer di persistenza, ogni qual volta il ricevente chiude la finestra. Quando questo timer scade, il mittente invia un pacchetto sonda al ricevente, provocandone una risposta: in questo modo il mittente potrà essere sicuro che la finestra sia chiusa (ricevendo un altro pacchetto con campo Window a 0) o sbloccarsi dallo stallo (ricevendo un pacchetto con campo Window diverso da zero).

Timer di keepalive[modifica | modifica sorgente]

La RFC 793 che definisce il protocollo TCP non prevede particolari azioni da intraprendere quando non ci sono dati da trasmettere sulla connessioni. Alcune implementazioni però consentono di trasmettere periodicamente segmenti vuoti, detti keepalive, per evitare di mantenere indefinitamente in memoria connessioni con sistemi che potrebbero anche non essere più attivi. In molti sistemi il software applicativo ha la possibilità di scegliere se abilitare o meno i keepalive per ogni connessione.

Quando si usano i keepalive, è presente dunque il timer di keepalive: esso viene reimpostato alla ricezione o alla trasmissione di ogni segmento, e quando scade viene trasmesso un keepalive. Un valore tipico è di due ore.

Timed wait[modifica | modifica sorgente]

L'ultimo timer utilizzato da TCP è il timed wait. In pratica, prima di disconnettere effettivamente una connessione, i due estremi del canale attendono un tempo pari al doppio del tempo di vita di un comune pacchetto: questo evita che dei pacchetti possano rimanere circolanti per la rete anche dopo la chiusura.

Voci correlate[modifica | modifica sorgente]

Collegamenti esterni[modifica | modifica sorgente]

Telematica Portale Telematica: accedi alle voci di Wikipedia che parlano di reti, telecomunicazioni e protocolli di rete