Bibliografia:
Computer Networking. Cap. 3. Autori: James F. Kurose (University of Massachusetts, Amherst) Keith W. Ross (Polytechnic Institute of NYU).
I protocolli Internet del livello Trasporto sono UDP e TCP.
Si supponga di voler progettare un semplice protocollo di livello Trasporto. Inizialmente, dal lato del trasmettitore, si pensa di prendere i messaggi dal processo del livello applicazione e di consegnarli al livello Rete, e al lato del ricevitore, si prendono i pacchetti provenienti dal livello Rete e si passano direttamente al processo applicativo. Ma, come si è visto, serve almeno un servizio di multiplexing/demultiplexing per scambiare i messaggi tra il corretto processo applicativo e il livello Rete.
Il protocollo UDP, oltre a questo servizio, introduce anche un controllo sugli errori. UDP prende i messaggi dal processo del livello applicazione, aggiunge i numeri porta sorgente e destinazione e passa il segmento al livello Rete. Il livello Rete incapsula il segmento in un datagramma IP e provvede a consegnare il pacchetto al destinatario con il minimo impegno. Quando il pacchetto arriva all'host destinatario, UDP usa i numeri di porta e gli indirizzi IP per consegnare i dati al processo applicativo.
UDP non sincronizza le entità del livello 4 del trasmettitore e del ricevitore per cui è detto privo di connessione.
DNS è un esempio di protocollo del livello Applicazione che usa UDP. Quando l'applicazione DNS in un host produce una interrogazione, costruisce un messaggio DNS e lo passa al socket UDP senza sincronizzare il processo dal lato trasmettitore con il processo che esegue UDP sul sistema ricevitore. UDP aggiunge i campi dell'intestazione al messaggio e passa il segmento al livello Rete. Il livello Rete incapsula il segmento UDP in un datagramma e lo invia al server di risoluzione dei nomi. L'applicazione DNS che ha generato l'interrogazione attende la risposta. Se non la riceve, perchè si è perso il pacchetto di richiesta o il pacchetto di risposta, ripete l'invio dell'interrogazione a un altro server o informa il processo applicativo che non è stata ricevuta la risposta.
Le ragioni per cui si può preferire UDP a TCP sono:
Il livello applicazione controlla quali dati inviare e quando inviarli. Nel momento in cui un processo del livello applicazione passa dei dati al livello trasporto, UDP racchiude i dati un segmento e consegna immediatamente il segmento al livello rete. Il protocollo TCP, invece, introduce un meccanismo di controllo della congestione che potrebbe portare il mittente in uno stato di sospensione della trasmissione quando si rileva la presenza di congestione su uno o più canali, tra il mittente e il destinatario. Inoltre, TCP ripete l'invio di un pacchetto fino a quando non riceve la conferma dal ricevitore che il pacchetto è giunto a destinazione. Le applicazioni real-time richiedono che sia rispettato un flusso minimo di pacchetti e, mentre esigono che sia mantenuto un ritardo costante tra i segmenti, possono tollerare la perdita di qualche segmento.
Assenza della fase di apertura connessione. TCP fa precedere alla fase di trasferimento dei dati uno scambio di pacchetti per memorizzare lo stato dei processi in comunicazione. UDP non effettua questa fase preliminare. Per questo motivo il DNS si serve dell'UDP. Il DNS dovrebbe essere più lento su una connessione TCP. HTTP usa il TCP perchè l'affidabilità è un requisito essenziale per consultare le pagine web.
Assenza dello stato della connessione. Il TCP mantiene lo stato della connessione nei sistemi terminali. Lo stato è rappresentato dai buffer di trasmissione e di ricezione, dai parametri per il controllo della congestione e dai parametri necessari per assegnare i numeri di sequenza e i numeri delle conferme. Queste informazioni servono a garantire l'affidabilità del trasferimento dati. UDP non gestisce lo stato della connessione, quindi un server dedicato a particolari applicazioni riesce a gestire più client.
Intestazione del segmento breve. Il segmento TCP ha 20 byte di intestazione, mentre UDP ne ha solo 8.
Velocità di trasmissione irregolare. Il TCP ha un meccanismo di controllo della congestione che rallenta il trasmettitore quando il traffico su uno o più canali aumenta. Questo rallentamento è indesiderato per le applicazioni real-time, che possono tollerare la perdita di un pacchetto, ma richiedono che si rispetti una minima velocità di trasferimento. La velocità con cui UDP spedisce i pacchetti dipende dalla velocità con cui l'applicazione li genera, dalle prestazioni del computer (CPU, clock rate, ecc.) e dalla larghezza di banda della linea. Una parte dei pacchetti UDP potrebbe essere perduta per varie ragioni, così la velocità di ricezione dipende dal traffico presente in rete.
La Tabella seguente elenca le principali applicazioni Internet e, per ognuna, indica il protocollo del livello Trasporto che essa usa: e-mail, terminale remoto, Web e il trasferimento dei file utilizzano il TCP - queste applicazioni hanno bisogno di un servizio affidabile. Le applicazioni che usano l'UDP sono, ad esempio, il RIP - il protocollo di tipo Distance Vector - che consente di aggiornare le tabelle di instradamento dei router. UDP è usato anche per i dati SNMP. L'UDP è preferito nei casi di intenso traffico sulla rete.
| Applicazione | Protocollo del livello Applicazione | Protocollo del livello trasporto sottostante |
| posta elettronica | SMTP | TCP |
| terminale remoto | Telnet | TCP |
| Web | HTTP | TCP |
| trasferimento file | FTP | TCP |
| file server remoto | NFS | UDP |
| streaming multimediale | proprietario | UDP |
| telefonia su Internet | proprietario | UDP |
| Network Management | SNMP | UDP |
| Protocollo di instradamento | RIP | UDP |
| Traduzione dei nomi di dominio | DNS | UDP |
Applicazioni Internet e protocolli di trasporto su cui si appoggiano
UDP è usato anche con le applicazioni multimediali, come la telefonia su Internet, la video conferenza real-time, e lo streaming di file audio e video. Ognuna di queste applicazioni può tollerare una piccola perdita di pacchetti, quindi non è necessario un protocollo affidabile. Inoltre le applicazioni interattive real-time, come telefonia e video conferenza, non migliorano le prestazioni introducendo, con il TCP, il controllo della congestione. Infine, siccome il TCP non consente il multicast, questo tipo di applicazioni usa l'UDP.
L'esecuzione di applicazioni multimediali su UDP è critica, perchè UDP è privo di qualsiasi forma di controllo della congestione. Il controllo della congestione serve per impedire che la rete si saturi di traffico. Se tutti gli utenti di una rete avviassero uno streaming video ad alta velocità, senza alcun controllo della congestione, si verificherebbe una sovrascrittura di pacchetti nei router e nessuno vedrebbe nulla. Per rendere affidabile il trasferimento tramite l'UDP se ne dovrebbe incaricare il processo applicativo.
Le principali applicazioni di streaming usano l'UDP e posseggono un meccanismo di conferma dei pacchetti allo scopo di limitarne le perdite.
Ci sono alcune critiche rivolte alla scelta di appoggiare le applicazioni multimediali sull'UDP. Come visto, UDP non introduce un controllo sulla congestione. Ma si pensi che il controllo della congestione serve per prevenire lo stato di saturazione dei canali, dove i pacchetti subiscono un ritardo illimitato. Se ogni utente iniziasse lo streaming alla massima velocità di trasferimento, senza controllare la congestione, si dovrebbe verificare una sovrascrittura di pacchetti nelle code dei router e pochissimi pacchetti riuscirebbero a compiere il percorso completo da sorgente a destinazione. Inoltre l'elevato tasso di pacchetti persi, conseguente al mancato controllo della congestione da parte delle sorgenti UDP, causerebbe la riduzione del flusso dei pacchetti inviati dalle sorgenti TCP (che invece controllano la congestione). Quindi il mancato controllo della congestione ha due effetti negativi: aumenta il tasso dei pacchetti persi e diminuisce (se non addirittura si annulla) il traffico generato dalle sorgenti TCP.
| Numero Porta Sorgente |
| Numero Porta Destinazione |
| Lunghezza Campo Dati |
| Checksum |
| … dati del livello Applicazione … |
Il messaggio generato dall'applicazione occupa il campo dati del datagramma UDP. Ad esempio il campo dati del DNS contiene la richiesta o la risposta. Il campo dati di un'applicazione di streaming audio contiene i campionamenti audio. L'intestazione dell'UDP ha solo quattro campi, ognuno di 32 bit. Il campo checksum serve per il controllo degli errori.
il campo di controllo degli errori in un segmento UDP
Il checksum fornisce un metodo per riconoscere la presenza di errori nel segmento. Cioè il campo checksum nel segmento UDP consente di verificare se il messaggio è stato alterato dal rumore, mentre viaggiava sul canale. Il messaggio del pacchetto viene considerato come una sequenza di numeri di 16 bit. L'UDP dal lato del trasmettitore somma, scartando i riporti, tutti questi numeri, esegue il complemento a uno del risultato e lo inserisce nel campo checksum.
Un semplice esempio di calcolo del checksum.
Si abbiano i seguenti 3 gruppi di 16 bit:
0110011001100000 0101010101010101 1000111100001100
La somma dei primi due gruppi di 16 bit è
0110011001100000 0101010101010101 1011101110110101
A questo risultato si aggiunge il terzo gruppo di 16 bit e si ha:
1011101110110101 1000111100001100 0100101011000010
Notare che quest'ultima addizione ha generato un riporto che è stato scartato. Il complemento dei bit 0100101011000010 del risultato è 1011010100111101, che diventa il checksum.
Il ricevitore calcola la somma dei tre gruppi di 16 bit ricevuti, aggiunge anche il checksum e si aspetta di ottenere un numero formato da tutti 1, cioè 1111111111111111. Se c'è un bit a 0 UDP segnala l'errore. La correzione del messaggio non è possibile, per cui si dovrebbe chiedere la ritrasmissione del pacchetto.
UDP introduce il controllo degli errori, anche se questo controllo avviene al livello 2. La ragione è che lungo il percorso potrebbe esserci un protocollo di livello 2 che non fornisce il controllo degli errori, quindi per sicurezza provvede il protocollo del livello Trasporto.
Un processo server aspetta su una porta aperta che un client gli chieda un servizio.
Alcune porte sono riservate altre sono usate da applicazioni di rete. Di conseguenza, se si scopre la porta aperta su un host si è in grado di conoscere l'applicazione corrispondente in esecuzione su quell'host. Questa informazione è molto utile agli amministratori di rete, che sono interessati a conoscere quali applicazioni sono in esecuzione sui computer della rete.
Ma anche gli attaccanti sono interessati a conoscere le porte aperte sui computer. Se si scopre che un host sta eseguendo un'applicazione, di cui si conosce un difetto nella sicurezzza, (ad esempio, un server SQL in ascolto sulla porta 1434 poteva essere vittima di un attacco "buffer overflow", che permetteva ad un utente della rete di eseguire qualsiasi elenco di istruzioni su quell'host), allora quell'host è vulnerabile ad un attacco.
È molto facile determinare quali applicazioni sono in ascolto sulle porte dell'host. Infatti, per questi scopi esistono dei programmi di dominio pubblico, detti "port scanners". Il più noto è nmap, che si può ottenere gratuitamente all'indirizzo: http://nmap.org ed è incluso in molte distribuzioni Linux.
Per il protocollo TCP, nmap genera in sequenza dei numeri di porta, alla scoperta di quelle che accettano connessioni.
Per il protocollo UDP, nmap genera in successione i numeri di porta e aspetta di ricevere un segmento di risposta.
In entrambi i casi, nmap restituisce lo stato (aperta, chiusa, irraggiungibile) di tutte le porte scoperte.
Un host su cui viene eseguito nmap può tentare di scansionare ogni computer collegato a Internet.