LIVELLO TRASPORTO

retiIl livello di trasporto, in telecomunicazioni, informatica e nell’ambito delle reti di calcolatori, è il quarto dei livelli nel modello ISO/OSI. Il suo compito è di fornire servizi al soprastante livello Applicazione del modello TCP/IP e per raggiungere tale scopo sfrutta i servizi offerti dal sottostante livello 3 (livello rete). Lo scopo del livello di trasporto è fornire un canale logico di comunicazione end-to-end per pacchetti, in sostanza fornisce la comunicazione logica tra processi applicativi di host differenti.

Transport Layer

FUNZIONALITA’

Di seguito vengono riportati i servizi che vengono, in genere, offerti dal livello di trasporto; è bene ricordare che nessuno di tali servizi è obbligatorio. Di conseguenza, per ciascuna applicazione è possibile scegliere il protocollo più adatto allo scopo.

  • Servizio orientato alla connessione. In genere il livello rete non stabilisce una connessione persistente verso l’host di destinazione. Il livello di trasporto si incarica, quindi, di realizzare una connessione persistente che viene poi chiusa quando non è più necessaria.
  • Corretto ordine di consegna. Poiché i pacchetti possono seguire percorsi diversi all’interno della rete, non c’è alcuna garanzia che i dati vengano recapitati nello stesso ordine in cui sono stati inviati. Il livello di trasporto verifica che i pacchetti vengano riordinati nella giusta sequenza in ricezione prima di passarli al livello superiore.
  • Trasferimento affidabile. Il protocollo si occupa di garantire che tutti i dati inviati vengano ricevuti; nel caso il servizio di rete utilizzato perda pacchetti, il protocollo di trasporto si occupa di ritrasmetterli al mittente sotto forma di file corrotti.
  • Controllo di flusso. Se gli host coinvolti nella comunicazione hanno prestazioni molto differenti può capitare che un pc più veloce “inondi” di dati uno più lento portando alla perdita di pacchetti. Mediante il controllo di flusso, un host in “difficoltà” può chiedere di abbassare il tasso di trasmissione in modo da poter gestire le informazioni in ingresso.
  • Controllo di Congestione: il protocollo riconosce uno stato di congestione della rete e adatta di conseguenza la velocità di trasmissione.
  • Orientamento al Byte. Invece che gestire i dati in base ai pacchetti, viene fornita la possibilità di vedere la comunicazione come uno stream di byte, in modo da semplificarne l’utilizzo.
  • Il protocollo permette di stabilire diverse connessioni contemporanee tra gli stessi due host, tipicamente utilizzando l’astrazione delle porte. Nell’uso comune diversi servizi utilizzano porte logiche di comunicazione diverse.

Il nome trasporto per tale livello può quindi trarre in inganno in quanto non implementa alcun meccanismo di trasferimento logico e fisico dei dati sul canale (multiplazione/accesso multiplo, indirizzamento e commutazione) cui ovviano i livelli architetturali inferiori attraverso i meccanismi propri del particolare modo di trasferimento adottato, bensì al contrario si occupa di supplire alle mancanze delle funzionalità del trasferimento in termini di affidabilità implementando le suddette funzioni come garanzie sul trasporto stesso cioè chiudendo il cerchio su tutto ciò che il trasporto in toto dovrebbe fare e garantire.

Servizio di trasporto

LIVELLO DI TRASPORTO IN INTERNET

Nello stack protocollare Internet, i protocolli di trasporto più utilizzati sono TCP e UDP. TCP è il più complicato fra i due e fornisce un servizio end-to-end orientato alla connessione e al byte, con verifica del corretto ordine di consegna, controllo di errore e di flusso. Il nome è un acronimo per Transmission Control Protocol. UDP, invece, è un protocollo più snello e fornisce un servizio a datagrammi, senza connessione, con un meccanismo di riduzione degli errori e con porte multiple. Il nome è un acronimo per User Datagram Protocol. La relazione tra livello di trasporto e livello di rete è la seguente:

  • Livello di rete
    • Comunicazione logica tra host
  • Livello di trasporto
    • Comunicazione logica tra processi che girano su host diversi

IL LIVELLO SOTTOSTANTE

  • Il livello di rete usa IP che, come modello di servizio, è “Best-Effort” ovvero non affidabile
  1. Non assicura la consegna
  2. Non assicura l’ordine
  3. Non assicura l’integrità
  • Il livello trasporto ha il compito di estendere i servizi di consegna di IP “tra terminali” a uno di consegna “tra processi in esecuzione sui sistemi terminali”.
  • Questo passaggio da consegna host-to-host a consegna process-to-process viene detto multiplexing e demultiplexing a livello di trasporto.
  • TCP converte il sistema inaffidabile, IP, a livello di rete in un sistema affidabile a livello trasporto.
  • UDP, invece, estende l’inaffidabilità di IP a livello trasporto.

INDIRIZZAMENTO DEL TRASPORTO

  • Le applicazioni che utilizzano il TCP/IP si registrano sullo strato di trasporto ad un indirizzo specifico, detto porta
    • Questo meccanismo permette ad una applicazione di identificare l’applicazione remota a cui inviare i dati.
  • La porta è un numero di 16 bit (da 1 a 65535; la porta 0 non è utilizzata).
  • TCP/IP permette alle applicazioni di registrarsi su una porta definita dalla applicazione (come nel caso dei server) o su una qualunque porta libera scelta dal livello di trasporto (spesso è il caso dei client).
  • Per rendere funzionali i servizi di utilizzo diffuso, TCP/IP prevede che determinati servizi utilizzino dal lato server delle porte ben definite.
  • Esiste una autorità centrale, lo IANA (Internet Assigned Numbers Authority), che pubblica la raccolta dei numeri di porta assegnati alle applicazioni negli RFC (http://www.iana.org).

SOCKET

Un socket, in informatica, indica un’astrazione software progettata per utilizzare delle API standard del sistema operativo e condivise per la trasmissione e la ricezione di dati attraverso una rete. È il punto in cui il codice applicativo di un processo accede al canale di comunicazione per mezzo di una porta, ottenendo una comunicazione tra processi che lavorano su due macchine fisicamente separate. Dal punto di vista di un programmatore un socket è un particolare oggetto sul quale leggere e scrivere i dati da trasmettere o ricevere. Essi sono composti principalmente da due parti:

  • Indirizzo IP: codice univoco della macchina interessata, con una grandezza di 32 bit.
  • Numero di porta: numero, con una grandezza di 16 bit, usato dal singolo processo per richiedere il protocollo all’interno della macchina stessa.

Questa combinazione permette di distinguere in maniera univoca le singole richieste all’interno della rete.

Indirizzi ip e indirizzi di porta
Porte IANA

IL PROTOCOLLO TCP

In telecomunicazioni e informatica il Transmission Control Protocol (TCP) è un protocollo di rete a pacchetto di livello di trasporto, appartenente alla suite di protocolli Internet, che si occupa di controllo della trasmissione ovvero rendere affidabile la comunicazione dati in rete tra mittente e destinatario. Su di esso si appoggia 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 sistema operativo di un host, e il terminale in trasmissione o in ricezione vi accede attraverso l’uso di opportune chiamate di sistema definite nelle API di sistema. Il TCP può essere classificato al livello trasporto (level 4) del modello di riferimento OSI, e di solito è usato in combinazione con il protocollo di livello rete (OSI level 3) IP. Nel modello TCP/IP il protocollo TCP occupa il livello 4, trasporto. 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’interconnessione 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 affidabile canale di comunicazione tra due processi applicativi di rete. Il canale di comunicazione così costruito è composto 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 protocollo di rete che si occupa di costruire connessioni e garantire affidabilità su una rete IP sottostante che è sostanzialmente di tipo best-effort.

 

CARATTERISTICHE PRINCIPALI

  • 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 una connessione.
  • TCP è un protocollo affidabile: garantisce la consegna dei segmenti a destinazione attraverso il meccanismo degli acknowledgements.
  • 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 prodotto dall’applicazione (o applicativo, o protocollo applicativo) sull’host mittente, viene preso in carico da TCP per la trasmissione, viene quindi frazionato in blocchi, detti segmenti, e consegnato al TCP sull’host destinatario che lo passerà all’applicativo indicato dal numero di porta del destinatario nell’header del segmento (es.: applicativo HTTP, porta 80).
  • 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. Una Protocol Data Unit (PDU) è l’unità d’informazione o pacchetto scambiata tra due peer entities in un protocollo di comunicazione di un’architettura di rete a strati.
  • 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 dei buffer di ricezione/invio sui due end devices (controllo di flusso) e di diminuire il numero di segmenti inviati in caso di congestione della rete.
  • TCP fornisce un servizio di multiplazione delle connessioni su un host, attraverso il meccanismo dei numeri di porta del mittente.
  • Una connessione TCP è punto-punto, un mittente, un destinatario

il Multicast non è possibile con TCP.

  • flusso di byte affidabile, in sequenza:
    • nessun “confine ai messaggi”
  • pipeline:
    • il controllo di flusso e di congestione TCP definiscono
      la dimensione della finestra.
  • buffer d’invio e di ricezione
    • Una connessione TCP consiste di buffers, variabili e di 2 sockets verso i due end-systems.
  • flusso controllato:
    • il mittente non sovraccarica il destinatario
Flusso di dati

CONFRONTO CON UDP

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

  • TCP è un protocollo orientato alla connessione. Pertanto, per stabilire, mantenere e chiudere una connessione, è necessario inviare segmenti di servizio i quali aumentano l’overhead di comunicazione. Al contrario, UDP è senza connessione ed invia solo i datagrammi richiesti dal livello applicativo; (nota: i pacchetti prendono nomi diversi a seconda delle circostanze a cui si riferiscono: segmenti (TCP) o datagrammi (UDP));
  • UDP non offre nessuna garanzia sull’affidabilità della comunicazione, ovvero sull’effettivo arrivo dei segmenti, né 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); TCP riesce altresì a riordinare i segmenti in arrivo presso il destinatario attraverso un campo del suo header: il sequence number;
  • l’oggetto della comunicazione di TCP è un flusso di byte, mentre quello di UDP sono singoli datagrammi.

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. streaming in tempo reale, videogiochi multiplayer).

 

SEGMENTO TCP

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 i dati provenienti dal livello applicativo (es.: HTTP). I dati contenuti nell’intestazione costituiscono un canale di comunicazione tra TCP mittente e TCP destinatario, che viene utilizzato per realizzare le funzionalità dello strato di trasporto e non è accessibile agli strati dei livelli superiori.

Un segmento TCP è così strutturato:

segmento tcp
  • 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), deciso 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 dword da 32 bit) dell’header del segmento TCP; tale lunghezza può variare da 5 dword (20 byte) a 15 dword (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 impostati a zero.
  • Flags [8 bit] – Bit utilizzati per il controllo del protocollo:
  • CWR (Congestion Window Reduced) – se impostato a 1 indica che l’host sorgente ha ricevuto un segmento TCP con il flag ECE impostato a 1 (aggiunto all’header in RFC 3168).
  • ECE [ECN (Explicit Congestion Notification) -Echo] – se impostato a 1 indica che l’host supporta ECN durante il 3-way handshake (aggiunto all’header in RFC 3168).
  • URG – se impostato 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 impostato a 1 indica che il campo Acknowledgment number è valido;
  • PSH – se impostato a 1 indica che i dati in arrivo non devono essere bufferizzati ma passati subito ai livelli superiori dell’applicazione;
  • RST – se impostato 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 impostato 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 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.
  • Data – rappresenta il carico utile o Payload da trasmettere cioè la PDU proveniente dal livello superiore.

CONNESSIONE

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. 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.

APERTURA DI UNA CONNESSIONE – THREE-WAY HANDSHAKE

Tcp-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 (numero casuale);
  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 ad 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 – DOPPIO TWO-WAY HANDSHAKE

Dopo che è stata stabilita, una connessione TCP non è considerata una singola connessione bidirezionale, ma piuttosto come l’interazione di due connessioni monodirezionali; pertanto, ognuna delle parti dovrebbe terminare la propria connessione. Possono esistere anche connessioni chiuse a metà, in cui solo uno dei due host ha chiuso la connessione poiché non ha più nulla da trasmettere, ma può (e deve) ancora ricevere i dati dall’altro host. 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 (o meglio 2 separati handshake), in cui le due connessioni vengono chiuse in tempi diversi. L’handshake a 3 vie per la chiusura della connessione è omologo a quello usato per l’apertura della connessione, con la differenza che il flag utilizzato è il FIN invece del SYN. Un host invia un segmento con la richiesta FIN, l’altro risponde con un FIN + ACK, infine il primo manda l’ultimo ACK, e l’intera connessione viene terminata.

FIN a tre vie

Il doppio handshake a 2 vie invece viene utilizzato quando la disconnessione non è contemporanea tra i due host in comunicazione. In questo caso uno dei due host invia la richiesta di FIN, e attende l’ACK di risposta; l’altro terminale farà poi altrettanto, generando quindi un totale di 4 segmenti. È possibile anche una modalità più aggressiva di chiusura della connessione, settando il flag di RESET nel segmento interrompendo la connessione in entrambe le direzioni. Il TCP che riceve un RESET chiude la connessione interrompendo ogni invio di dati.

TCP-Chiusura-a-4-vie

MULTIPLAZIONE E PORTE

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.

AFFIDABILITA’ DELLA COMUNICAZIONE

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 il 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 (memoria tampone) 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

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 (Ricevente) a B è pari al numero di sequenza atteso da A e, quindi, riguarda il flusso di dati da B ad A, una sorta di report su ciò che è stato ricevuto. 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 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).

Maximum segment size
Controllo Errore
Controllo Errore nell'acknoweledge
Controllo Errore nei dati

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), variabile dinamica (ossia dipendente dallo spazio disponibile) che specifica il numero massimo di segmenti ricevibili dal destinatario. Definito:

LastByteRead: numero dell’ultimo byte nel flusso di dati che il processo applicativo in B ha letto dal buffer

LastByteRcvd: numero dell’ultimo byte nel flusso di dati proveniente dalla rete che è stato copiato nel buffer di ricezione RcvBuffer precedentemente allocato

allora necessariamente, dovendo TCP evitare l’overflow del proprio buffer, si avrà:

RCV_WND = RcvBuffer – [LastByteRcvd – LastByteRead]

dove ovviamente per negare l’overflow:

RcvBuffer ≥ [LastByteRcvd – LastByteRead]

A sua volta il mittente terrà traccia dell’ultimo byte mandato e dell’ultimo byte per cui si è ricevuto l’ACK affinché esso non mandi in overflow il buffer del destinatario. Si noti come, qualora la finestra di ricezione fosse vuota (RCV_WND == 0), il mittente continuerà ad inviare segmenti di un byte, in modo tale da garantire la sincronizzazione tra sender e receiver. Esistono alcuni problemi nel controllo di flusso in TCP che si verificano sia lato trasmettitore che lato ricevitore. Tali problemi vanno sotto il nome di Silly Window syndrome ed hanno effetti e cause diverse a seconda del lato.

Silly Window lato ricevitore: se il ricevitore svuota molto lentamente il buffer di ricezione, solo quando il ricevitore estrae informazioni dal buffer di ricezione si libera un piccolo spazio (Receive Window molto piccola) e tale valore di Receive Window viene comunicato indietro al trasmettitore. il problema è che ora, il trasmettitore usa una finestra di trasmissione molto stretta e quindi può succedere che esso sia costretto ad inviare dei segmenti molto corti rispetto all’header canonico di 20 byte, con conseguente abbassamento dell’efficienza della trasmissione. Per mitigare questo problema il TCP fa in modo che il ricevitore “menta” al trasmettitore indicando una finestra nulla sino a che il suo buffer di ricezione non si è svuotato per metà o per una porzione almeno pari al MSS (Maximun Segment Size), evitando così che il trasmettitore invii segmenti molto corti che limitino l’efficienza della trasmissione. Tale algoritmo risolutivo viene chiamato algoritmo di Clark.

Silly Window lato trasmettitore: si verifica quando l’applicazione genera dati molto lentamente. Dal momento che il TCP legge i dati che sono presenti nel buffer di trasmissione creando dei segmenti che invia dall’altra parte, nel caso in cui l’applicazione generi i dati molto lentamente l’entità TCP potrebbe essere forzata a creare segmenti molto corti (e con tanto overhead). La soluzione si chiama algoritmo di Nagle, per cui il TCP sorgente invia la prima porzione di dati anche se corta, e quando è il momento di creare nuovi segmenti, tali segmenti, vengono creati solamente se il buffer d’uscita contiene dati sufficienti per riempire un MSS oppure anche quando riceve un riscontro valido.

Controllo di flusso
Controllo di flusso
Controllo di flusso

CONTROLLO DI CONGESTIONE

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.

Controllo di congestione
Controllo di congestione

IL PROTOCOLLO UDP

Lo User Datagram Protocol (UDP), nelle telecomunicazioni, è uno dei principali protocolli di rete della suite di protocolli Internet. È un protocollo di livello di trasporto a pacchetto, usato di solito in combinazione con il protocollo di livello di rete IP.

FUNZIONAMENTO

A differenza del TCP, l’UDP è un protocollo di tipo connectionless, inoltre non gestisce il riordinamento dei pacchetti né la ritrasmissione di quelli persi, ed è perciò generalmente considerato di minore affidabilità. In compenso è molto rapido (non c’è latenza per riordino e ritrasmissione) ed efficiente per le applicazioni “leggere” o time-sensitive. In genere è utilizzato per le applicazioni per le quali un pacchetto in ritardo ha validità nulla, per esempio la trasmissione audio-video in tempo reale (streaming o VoIP sono gli usi più comuni), oppure la trasmissione di altre informazioni sullo stato di un sistema, per esempio i giochi multiplayer online. Infatti, visto che le applicazioni in tempo reale richiedono spesso un bit-rate minimo di trasmissione, non vogliono ritardare eccessivamente la trasmissione dei pacchetti e possono tollerare qualche perdita di dati, il modello di servizio TCP può non essere particolarmente adatto alle loro caratteristiche. Nel caso della telefonia via Internet (VoIP), un pacchetto riordinato è inutile perché risale a un tempo passato, mentre un pacchetto non ricevuto causa lo stallo del sistema fino al suo arrivo, per cui si sentirebbe un lungo silenzio seguito da tutti i pacchetti non arrivati in tempo.

L’UDP fornisce soltanto i servizi basilari del livello di trasporto, ovvero:

  • multiplazione delle connessioni, ottenuta attraverso il meccanismo di assegnazione delle porte;
  • verifica degli errori (integrità dei dati) mediante una checksum, inserita in un campo dell’intestazione (header) del pacchetto, mentre TCP garantisce anche il trasferimento affidabile dei dati, il controllo di flusso e il controllo della congestione.

L’UDP è un protocollo stateless, ovvero non tiene nota dello stato della connessione dunque ha, rispetto al TCP, meno informazioni da memorizzare: un server dedicato ad una particolare applicazione che scelga UDP come protocollo di trasporto può supportare quindi molti più client attivi.

STRUTTURA DI UN DATAGRAMMA UDP

Datagramma UDP

Header:

  • Source port [16 bit] – identifica il numero di porta sull’host del mittente del datagramma;
  • Destination port [16 bit] – identifica il numero di porta sull’host del destinatario del datagramma;
  • Length [16 bit] – contiene la lunghezza totale in bytes del datagramma UDP (header+dati);
  • Checksum [16 bit] – contiene il codice di controllo del datagramma (header+dati+pseudo-header, quest’ultimo comprendente gli indirizzi IP di sorgente e destinazione). L’algoritmo di calcolo è definito nell’RFC del protocollo;

Payload:

  • Data – contiene i dati del messaggio

APPLICAZIONI CHE UTILIZZANO UDP E TCP

Le applicazioni di rete che hanno la necessità di un trasferimento affidabile dei loro dati non si affidano ovviamente a UDP, mentre le applicazioni più elastiche riguardo alla perdita dei dati e strettamente dipendenti dal tempo si affidano invece a UDP. Inoltre si utilizza UDP per comunicazioni in broadcast (invio a tutti i terminali in una rete locale) e multicast (invio a tutti i terminali iscritti ad un servizio).

Di seguito è proposto un elenco dei principali servizi Internet e dei protocolli che essi adottano:

Applicazioni che usano UDP e TCP

APPROFONDIMENTO AI

Il livello di trasporto è uno dei livelli del modello OSI (Open Systems Interconnection) e del modello TCP/IP che si occupa di gestire la comunicazione end-to-end tra due dispositivi in rete. Il suo ruolo principale è fornire un servizio affidabile per la trasmissione di dati tra applicazioni che si trovano su dispositivi diversi, assicurandosi che i dati arrivino correttamente, in ordine e senza errori. Il livello di trasporto si trova sopra il livello di rete e sotto il livello di sessione nel modello OSI, mentre nel modello TCP/IP è al di sopra del livello Internet.

Funzioni principali del livello di trasporto:

1. Segmentazione dei dati: I dati che provengono dal livello superiore (livello di sessione o applicazione) vengono suddivisi in segmenti più piccoli. Questo è importante perché le reti spesso limitano la dimensione massima dei pacchetti di dati che possono essere trasmessi. Il livello di trasporto frammenta i dati in segmenti che possono essere gestiti dalla rete sottostante.

2. Affidabilità della trasmissione: Una delle responsabilità chiave del livello di trasporto è garantire che i dati arrivino correttamente. Il protocollo può fornire vari meccanismi di controllo degli errori, come il checksum, per verificare l’integrità dei dati e assicurarsi che non siano corrotti durante il trasferimento.

3. Controllo di flusso: Questo meccanismo permette al livello di trasporto di gestire la quantità di dati che il mittente può inviare prima di ricevere un feedback dal ricevente, evitando così di sovraccaricare il destinatario con troppi dati in una sola volta.

4. Controllo della congestione: Il livello di trasporto monitora la rete per evitare la congestione. In caso di congestione, riduce la velocità di trasmissione dei dati per prevenire ulteriori perdite di pacchetti.

5. Multiplexing/demultiplexing: Il livello di trasporto consente a più applicazioni di utilizzare contemporaneamente la rete, identificando ciascuna connessione attraverso porte logiche. Questo processo è chiamato multiplexing quando dati provenienti da più applicazioni vengono combinati in un unico flusso di dati. Il demultiplexing, invece, separa questi flussi quando arrivano a destinazione.

6. Gestione delle connessioni: I protocolli del livello di trasporto possono essere connection-oriented o connectionless.

•Nei protocolli connection-oriented (es. TCP), il livello di trasporto stabilisce una connessione logica tra il mittente e il destinatario prima di iniziare a trasmettere i dati. Questo implica che i pacchetti vengano numerati e riordinati correttamente nel caso vengano ricevuti fuori sequenza.

•Nei protocolli connectionless (es. UDP), non viene stabilita una connessione formale e i dati vengono inviati in modo indipendente senza verificare se sono stati ricevuti correttamente.

Protocolli principali del livello di trasporto:

1. TCP (Transmission Control Protocol):

Connessione orientata: Stabilisce una connessione prima di trasmettere i dati (tramite il processo chiamato three-way handshake).

Affidabilità: Garantisce che i pacchetti vengano consegnati, siano corretti e in ordine.

Controllo di congestione e di flusso: Monitora la rete e regola la trasmissione di dati per evitare il sovraccarico.

Utilizzo: Viene usato in applicazioni dove l’affidabilità è essenziale, come il web browsing (HTTP/HTTPS), trasferimenti di file (FTP) e posta elettronica (SMTP).

2. UDP (User Datagram Protocol):

Connessione non orientata: Non stabilisce una connessione. I pacchetti, chiamati datagrammi, vengono inviati senza verificare se sono stati ricevuti.

Bassa latenza: Poiché non vi è il sovraccarico dovuto al controllo di errori o alla gestione della connessione, è molto veloce e adatto per applicazioni in tempo reale.

Utilizzo: Viene usato in applicazioni che richiedono velocità e bassa latenza piuttosto che affidabilità, come streaming video/audio (es. VoIP), gaming online e DNS (Domain Name System).

Processi coinvolti nel livello di trasporto:

Three-Way Handshake (solo in TCP): È il processo attraverso il quale viene stabilita una connessione tra due host:

1. Il client invia un pacchetto SYN al server per iniziare la connessione.

2.Il server risponde con un pacchetto SYN-ACK.

3. Il client risponde con un pacchetto ACK. A questo punto, la connessione è stabilita.

Finishing the connection (solo in TCP): Per terminare una connessione TCP, si utilizza il processo a quattro fasi, detto Four-Way Handshake, che permette a entrambi i lati di chiudere la comunicazione in modo ordinato.

Importanza del livello di trasporto:

Il livello di trasporto è cruciale per garantire che i dati vengano trasferiti in modo affidabile tra due punti della rete, indipendentemente dalle differenze fisiche tra le reti che connettono questi punti. Senza un livello di trasporto affidabile, le applicazioni che richiedono un’alta precisione e integrità dei dati, come i servizi bancari online o la trasmissione di file importanti, non potrebbero funzionare correttamente.

In sintesi, il livello di trasporto fornisce le fondamenta per le comunicazioni tra applicazioni in una rete, assicurando che la trasmissione di dati sia gestita in modo efficace, sicuro e coerente.

APPROFONDIMENTO

LIVELLO TRASPORTO