TCP (Tran­smis­sion Control Protocol): pre­sen­ta­zio­ne del pro­to­col­lo di tra­smis­sio­ne

Quando vogliamo col­le­gar­ci a Internet, con poche semplici mosse rea­liz­zia­mo una con­nes­sio­ne tra router e computer o di­spo­si­ti­vo mobile – sia via cavo sia mediante accesso wireless. Non dobbiamo fare nient’altro, poiché l’accesso alla rete funziona in modo au­to­ma­ti­co così come l’ot­te­ni­men­to di un indirizzo Internet in­di­vi­dua­le per la ricezione e l’invio dei dati. A rendere possibile questo mec­ca­ni­smo è una raccolta di diversi pro­to­col­li de­no­mi­na­ta anche famiglia di pro­to­col­li Internet. Uno dei primi e più im­por­tan­ti membri di questa famiglia è il Tran­smis­sion Control Protocol (TCP). Esso sta­bi­li­sce le modalità di scambio dei dati tra i di­spo­si­ti­vi collegati nella rete.

Il Tran­smis­sion Control Protocol, ab­bre­via­to con TCP o pro­to­col­lo TCP, è un accordo stan­dar­diz­za­to per la tra­smis­sio­ne dei dati tra diversi utenti di una rete in­for­ma­ti­ca. Le origini di questo pro­to­col­lo risalgono al 1973, anno in cui gli in­for­ma­ti­ci Robert E. Kahn e Vinton G. Cerf pub­bli­ca­ro­no una prima versione del pro­to­col­lo nell’ambito del loro lavoro di ricerca. Per arrivare alla stan­dar­diz­za­zio­ne del TCP nella RFC 793 sarebbero tuttavia serviti altri otto anni. Da allora è stata elaborata tutta una serie di migliorie ed espan­sio­ni che, tuttavia, non hanno ri­guar­da­to il nucleo del pro­to­col­lo, giunto invariato fino ad oggi. La versione attuale del pro­to­col­lo, spe­ci­fi­ca­ta nella RFC 7323, è stata messa a punto nel 2014.

Lo stato di sviluppo odierno del pro­to­col­lo TCP permette a due punti terminali all’interno di una rete in­for­ma­ti­ca comune di rea­liz­za­re una con­nes­sio­ne at­tra­ver­so cui può avvenire una tra­smis­sio­ne bi­di­re­zio­na­le dei dati. Nell’ambito di questa con­nes­sio­ne, le eventuali perdite di dati vengono ri­co­no­sciu­te e corrette au­to­ma­ti­ca­men­te; per questo, il TCP viene de­no­mi­na­to anche pro­to­col­lo af­fi­da­bi­le. Nella famiglia di pro­to­col­li Internet, il TCP co­sti­tui­sce, insieme all’UDP e all’SCTP, il gruppo dei pro­to­col­li di trasporto che, sulla base del modello OSI, vengono clas­si­fi­ca­ti nell’ar­chi­tet­tu­ra di rete al livello di trasporto. Poiché, in quasi tutti i casi, il pro­to­col­lo TCP si basa sul pro­to­col­lo Internet (IP) e questa com­bi­na­zio­ne rap­pre­sen­ta la base per la maggior parte delle reti pubbliche e locali e per i servizi di rete, spesso si parla anche di pila di pro­to­col­li TCP/IP, in­ten­den­do in senso lato la famiglia di pro­to­col­li Internet.

Il TCP permette la tra­smis­sio­ne delle in­for­ma­zio­ni in entrambe le direzioni. I sistemi in­for­ma­ti­ci che co­mu­ni­ca­no tramite TCP possono pertanto inviare e ricevere dati con­tem­po­ra­nea­men­te, proprio come avviene durante una con­ver­sa­zio­ne te­le­fo­ni­ca. Le unità di tra­smis­sio­ne fon­da­men­ta­li uti­liz­za­te dal pro­to­col­lo sono i segmenti (pacchetti) che, oltre al carico utile (ossia il messaggio effettivo), possono contenere anche in­for­ma­zio­ni di controllo e sono limitati a una di­men­sio­ne di 1.500 byte. L’in­stau­ra­zio­ne e l’in­ter­ru­zio­ne delle con­nes­sio­ni, clas­si­fi­ca­bi­li come con­nes­sio­ni punto-a-punto, nonché la tra­smis­sio­ne stessa dei dati vengono ac­qui­si­ste dal software TCP nella pila di pro­to­col­li di rete del ri­spet­ti­vo sistema operativo.

Il software TCP viene con­trol­la­to dalle varie ap­pli­ca­zio­ni rete, come browser web o server, at­tra­ver­so in­ter­fac­ce spe­ci­fi­che, laddove ciascuna con­nes­sio­ne deve essere sempre iden­ti­fi­ca­ta da due punti terminali chia­ra­men­te definiti (client e server). A questo riguardo, non ha alcuna rilevanza quale lato assuma il ruolo di client e di server – l’im­por­tan­te è che il software TCP abbia a di­spo­si­zio­ne per ciascun punto terminale una coppia ordinata e univoca formata da indirizzo IP e porta (detta anche “2-tupla” o “socket”).

I pre­sup­po­sti per in­stau­ra­re una con­nes­sio­ne TCP valida sono i seguenti: entrambi i punti terminali devono disporre già di un indirizzo IP univoco (IPv4 o IPv6) e avere di­chia­ra­to e abilitato la porta de­si­de­ra­ta per la tra­smis­sio­ne dei dati. Mentre il primo funge da ca­rat­te­ri­sti­ca iden­ti­fi­ca­ti­va, la seconda è rilevante per l’as­se­gna­zio­ne delle con­nes­sio­ni alle ap­pli­ca­zio­ni client e server concrete da parte del sistema operativo.

Poiché l’in­stau­ra­zio­ne della con­nes­sio­ne tramite il Tran­smis­sion Control Protocol prevede in totale tre passaggi, per questo processo è entrata in uso la de­no­mi­na­zio­ne “handshake a tre vie”.

Per la parte che ha inviato l’ultimo segmento ACK (nel nostro caso, il client), la con­nes­sio­ne tuttavia non è ancora chiusa. Poiché non esiste alcuna certezza che l’ultimo pacchetto inviato sia ef­fet­ti­va­men­te arrivato, il ri­spet­ti­vo par­te­ci­pan­te della co­mu­ni­ca­zio­ne si pone ini­zial­men­te in modalità di attesa (detta anche “stato time wait”), fino a quando non sono trascorsi gli in­ter­val­li di tempo massimi di un segmento ACK e di un eventuale segmento FIN reinviato (secondo la RFC 793, questi in­ter­val­li hanno una durata di 2 minuti ciascuno).

Com’è tipico per i pro­to­col­li di rete, i dati de­ter­mi­nan­ti necessari per in­stau­ra­re la con­nes­sio­ne ed eseguire la tra­smis­sio­ne dei dati con il Tran­smis­sion Control Protocol si trovano nell’header di un pacchetto TCP. Questi dati di in­te­sta­zio­ne (detti anche in­for­ma­zio­ni di controllo) sono anteposti al carico utile (payload) da tra­sfe­ri­re e hanno ge­ne­ral­men­te una di­men­sio­ne di 20 byte (160 bit); ad essi seguono le in­for­ma­zio­ni ag­giun­ti­ve, aventi una di­men­sio­ne fino a 40 byte (320 bit), che sono opzionali e non vengono uti­liz­za­te in tutti i pacchetti.

I singoli com­po­nen­ti e/o campi dell’in­te­sta­zio­ne del pro­to­col­lo TCP hanno il seguente si­gni­fi­ca­to:

Porta di origine (16 bit): indica il numero di porta del mittente.

Porta di de­sti­na­zio­ne (16 bit): indica il numero di porta del de­sti­na­ta­rio.

Numero se­quen­zia­le (32 bit): il numero se­quen­zia­le indica il primo byte del carico utile allegato oppure viene inviato durante l’in­stau­ra­zio­ne e/o l’ab­bat­ti­men­to della con­nes­sio­ne. Serve al tempo stesso a con­va­li­da­re e a ordinare (dopo il tra­sfe­ri­men­to) i segmenti.

Numero di conferma (32 bit): in questo campo viene indicato il numero di conferma che il mittente attende suc­ces­si­va­men­te. Affinché il numero sia valido, deve essere preceduto da un flag ACK (nel campo “Flags”).

Offset (4 bit): il campo “Offset” indica la lunghezza dell’header TCP in blocchi da 32 bit per evi­den­zia­re il punto di inizio del carico utile. Poiché questo campo opzionale è variabile, il punto di inizio è diverso da segmento a segmento.

Riservato (6 bit): riservato per usi futuri secondo la RFC 793, fino ad oggi non uti­liz­za­to. Questo campo deve sempre avere il valore “0”.

Flags (6 bit): at­tra­ver­so i sei possibili bit singoli nel campo Flags è possibile attivare diverse azioni TCP per or­ga­niz­za­re la co­mu­ni­ca­zio­ne e l’ela­bo­ra­zio­ne dei dati. I Flag che vengono attivati o non attivati a questo scopo sono i seguenti:

• URG: il flag “Urgent” (urgente) segnala all’ap­pli­ca­zio­ne TCP che il carico utile deve essere elaborato im­me­dia­ta­men­te fino all’Urgent Pointer definito.
• ACK: in com­bi­na­zio­ne con il numero di conferma, il flag ACK ha la funzione di con­fer­ma­re la ricezione dei pacchetti TCP. Se il flag non è attivato, anche il numero di conferma è au­to­ma­ti­ca­men­te non valido.
• PSH: il flag “Push” fa sì che un segmento TCP venga inviato im­me­dia­ta­men­te, senza dapprima essere ac­cu­mu­la­to nel buffer interno del mittente e del de­sti­na­ta­rio.
• RST: se si è ve­ri­fi­ca­to un errore durante la tra­smis­sio­ne, un pacchetto TCP con flag RST (“Reset”) attivato permette il ri­pri­sti­no della con­nes­sio­ne.
• SYN: i messaggi con flag SYN attivato rap­pre­sen­ta­no il primo passaggio dell’handshake a tre vie, vale a dire che danno inizio all’in­stau­ra­zio­ne della con­nes­sio­ne.
• FIN: il flag “Finish” segnala alla con­tro­par­te che un par­te­ci­pan­te alla co­mu­ni­ca­zio­ne termina la tra­smis­sio­ne.

Di­men­sio­ne della finestra (16 bit): in questo campo, al partner della co­mu­ni­ca­zio­ne viene trasmesso il numero di byte che il de­sti­na­ta­rio è in grado di ricevere.

Checksum (16 bit): il Tran­smis­sion Control Protocol è in grado di in­di­vi­dua­re gli errori di tra­smis­sio­ne in modo af­fi­da­bi­le. A questo scopo viene fatto ricorso alla checksum, calcolata in base all’header, al carico utile e al co­sid­det­to pseudo header.

Urgent Pointer (16 bit): l’Urgent Pointer (puntatore di “urgenza”) indica la posizione del primo byte dopo il carico utile da elaborare con urgenza. Di con­se­guen­za, questo campo è valido e rilevante solo se il flag URG è attivato.

Opzioni (0–320 bit): se è ne­ces­sa­rio attivare funzioni TCP non comprese nell’header generale, è possibile farlo at­tra­ver­so il campo delle opzioni. Questo può essere utile ad esempio qualora sia ne­ces­sa­rio definire la di­men­sio­ne massima dei segmenti. Le opzioni devono sempre avere una lunghezza pari a un multiplo di 32 bit; in caso contrario è ne­ces­sa­rio eseguire una com­pi­la­zio­ne con una serie di bit zero (padding).

Ancora prima che vengano tra­sfe­ri­ti i primi dati, ge­ne­ral­men­te il mittente e il de­sti­na­ta­rio si accordano riguardo alla di­men­sio­ne massima dei segmenti TCP da inviare (Maximum Segment Size – MSS). Di norma sono possibili fino a 1500 byte per segmento; di questi, almeno 20 byte devono essere previsti per l’header TCP e altri 20 byte per l’header IP, in modo tale che rimangano 1.460 byte. Se si desidera una di­men­sio­ne per­so­na­liz­za­ta, questa deve essere spe­ci­fi­ca­ta (come indicato sopra) tramite il campo delle opzioni, eseguendo le dovute sot­tra­zio­ni per la parte del carico utile.

Prendendo in con­si­de­ra­zio­ne la di­men­sio­ne massima del segmento meno l’header, significa dunque che un pacchetto TCP può tra­sfe­ri­re soltanto dati con una di­men­sio­ne di 1,46 kilobyte o 0,00146 megabyte. Ciò detto, affinché sia possibile scambiare tramite il pro­to­col­lo TCP contenuti web come immagini, le cui di­men­sio­ni possono arrivare a varie centinaia di kilobyte, viene uti­liz­za­ta la seg­men­ta­zio­ne, grazie alla quale, prima del trasporto, i dati ap­pli­ca­ti­vi vengono suddivisi in vari blocchi di dati, numerati e in seguito inviati in ordine casuale. Poiché il de­sti­na­ta­rio deve con­fer­ma­re la ricezione di ogni singolo segmento e poiché l’ordine effettivo può essere ri­co­strui­to sulla base dei numeri se­quen­zia­li, in seguito alla tra­smis­sio­ne TCP il de­sti­na­ta­rio può ri­com­por­re il carico utile ricevuto senza problemi e in modo completo.

Da circa mezzo secolo, il pro­to­col­lo TCP è uno dei prin­ci­pa­li pro­ta­go­ni­sti della storia e dello sviluppo delle reti in­for­ma­ti­che. Questo, da una parte, è dovuto all’ottima com­pa­ti­bi­li­tà con il pro­to­col­lo Internet (IP), altro grande pro­ta­go­ni­sta della storia delle reti in­for­ma­ti­che, dall’altra alle ca­rat­te­ri­sti­che perlopiù van­tag­gio­se grazie alle quali il TCP si eleva rispetto ad al­ter­na­ti­ve quali l’UDP e l’SCTP. Le ca­rat­te­ri­sti­che prin­ci­pa­li del TCP possono essere riassunte come segue:

• Il TCP è orientato alla con­nes­sio­ne e permette una co­mu­ni­ca­zio­ne alternata tra due punti terminali in base al co­sid­det­to handshake a tre vie.
• Il TCP è af­fi­da­bi­le, in quanto assicura che tutti i dati vengono trasmessi in modo completo e possano essere ri­com­po­sti dal de­sti­na­ta­rio nell’ordine corretto.
• Il TCP prevede l’invio dei dati in singoli segmenti che possono avere una di­men­sio­ne massima di 1.500 bytes (compreso header).
• Nel modello OSI, il TCP viene clas­si­fi­ca­to al livello di trasporto (layer 4).
• Nella maggior parte dei casi, il TCP si basa sul pro­to­col­lo Internet (IP), pertanto spesso si parla anche di pila di pro­to­col­li TCP/IP.
• L’header TCP ha una di­men­sio­ne standard di 20 byte – a cui possono ag­giun­ger­si fino a 40 byte di opzioni ag­giun­ti­ve.