TCP/IP in pillole - Parte quinta
Continua la trattazione dei protocolli utilizzati per le trasmissioni dei dati sulla Rete. In questa puntata: l'instradamento, la gestione degli errori e UDP
Dario de Judicibus
Ci siamo lasciati nella scorsa puntata con una descrizione abbastanza dettagliata dell'IP datagram, cioΦ del blocco di dati che costituisce l'elemento base trasmesso tramite il protocollo IP. Terminiamo con questa puntata la trattazione dell'IP parlando di due aspetti fin qui solo accennati: i meccanismi di instradamento dei pacchetti (routing) e la gestione degli errori. Sempre in questa puntata incominceremo a salire nella torre dei protocolli internet, introducendo il primo protocollo che si poggia sull'IP, e precisamente lo User Datagram Protocol (UDP). Come vedremo si tratta ancora di un protocollo molto legato all'IP, ma comunque considerato al di sopra di questo.
Come abbiamo giα detto in precedenza, IP Φ un protocollo connectionless. Questo vuol dire che non esiste un collegamento diretto tra i due host che si scambiano dati, bens∞ una rete di connessioni attraverso la quale si possono identificare vari potenziali cammini da un host all'altro. Il cammino attraverso il quale i dati giungono all'host destinatario Φ scelto dinamicamente e pu≥ variare per ogni singolo pacchetto di dati.
Tale scelta non avviene quando il pacchetto parte, ma Φ il risultato di numerose decisioni prese a ogni singolo gateway. Per questo motivo i gateway sono detti anche router. Tali scelte possono dover tenere conto di molti elementi, quali la prioritα del messaggio, il carico di rete, la capacitα delle reti intermedie, e via dicendo. La base tuttavia del meccanismo sono le tabelle di instradamento (routing table). Vediamo di che si tratta.
Consideriamo prima una singola rete fisica. Se un host vuole spedire un messaggio a un altro host nella stessa rete, non deve far altro che incapsulare il messaggio in un datagramma IP fornendo quindi l'indirizzo IP del destinatario, e passare il tutto al livello inferiore. Questi provvederα a ricavare dall'indirizzo IP l'identificativo del destinatario nella rete fisica, a incapsulare il datagramma in un frame, e a spedire direttamente il tutto all'host finale . Questa tecnica si chiama instradamento diretto (direct routing).
Vediamo adesso quello che succede quando abbiamo due reti interconnesse tramite un gateway. L'host mittente si accorge che il destinatario non Φ nella sua rete fisica, dato che il network id del suo indirizzo IP Φ diverso da quello a cui deve spedire il datagramma. Spedisce allora il messaggio al gateway passando sia il datagramma che l'indirizzo IP del gateway al livello inferiore. Il messaggio arriva quindi direttamente al gateway che estrae l'indirizzo IP del destinatario, si accorge che fa parte della seconda rete a cui Φ connesso, e spedisce quindi il tutto all'host finale attraverso la rete fisica. Questa tecnica si chiama di instradamento indiretto (indirect routing).
In questo secondo caso la tabella di instradamento Φ semplice, dato che il gateway ritrasmette sempre i messaggi che devono andare da una rete all'altra attraverso la rete fisica. Se invece abbiamo pi∙ gateway tra i due host, ogni gateway, tranne l'ultimo, dovrα spedire il messaggio a un altro gateway.
Per far questo userα appunto la tabella di instradamento che fornisce per ogni possibile rete destinataria finale l'indirizzo IP del gateway successivo. ╚ da notare che queste tabelle non contengono di solito gli indirizzi IP di tutti i possibili host destinatari, cosa che sarebbe fisicamente impossibile, bens∞ gli indirizzi delle reti raggiungibili a partire da quel gateway. Esiste poi la possibilitα di specificare un gateway di default e cammini specifici per host speciali. La prima cosa Φ molto comune, mentre la seconda Φ usata solo in casi eccezionali. La logica di instradamento Φ quindi quella riportata nel diagramma (vedi rivista)
La gestione dei messaggi di errore
Come si pu≥ facilmente capire dal meccanismo di instradamento appena spiegato, non Φ possibile sapere se il destinatario effettivamente esiste fintanto che il datagramma non arriva all'ultimo gateway. In generale l'IP non contiene grossi meccanismi di verifica, ed Φ per questo che Φ detto ½inaffidabile╗. Esso richiede quindi un protocollo ausiliaro per l'emissione di messaggi di errore in rete, che permettano ai protocolli di livello superiore di implementare una logica pi∙ affidabile e robusta. Tale protocollo Φ chiamato Internet Control Message Protocol (ICMP).
L'ICMP Φ considerato parte integrante dell'IP ed Φ sostanzialmente un protocollo per la segnalazioni di errori il cui utente principale Φ l'IP stesso.
Solo in casi particolari l'ICMP arriva a informare dell'errore eventuali livelli superiori all'IP. In ogni caso cosa fare quando avviene un errore non spetta all'ICMP, ma ai processi che se ne avvalgono. L'ICMP informa sempre l'IP mittente, non i vari gateway intermedi. Questo in quanto del cammino percorso da un datagramma non rimane traccia, per cui l'unico possibile destinatario di un messaggio di errore Φ solo chi ha generato il datagramma. Inoltre, dato che i datagrammi ICMP viaggiano incapsulati in datagrammi IP, come un qualunque messaggio di livello superiore, essi sono soggetti alle stesse limitazioni in termini di affidabilitα di qualunque altro messaggio spedito via TCP/IP. Non analizzeremo in dettaglio tutti i datagrammi ICMP, anche perchΘ ognuno pu≥ avere una struttura differente. Diremo solamente che l'intestazione di un datagramma ICMP contiene sempre almeno tre campi: il tipo di messaggio, un codice di errore, e una somma di controllo.
Il livello di Trasporto
Come sicuramente ricorderete, la torre Internet si pu≥ schematizzare pi∙ o meno su quattro livelli.
Alla base della torre sta l'hardware che rappresenta la rete vera e propria. Sopra a questo sta il primo livello, quello cioΦ di interfaccia alla rete fisica, detto appunto Network Interface o anche Data Link. I protocolli a questo livello si scambiano blocchi di dati chiamati frame, la cui struttura Φ strettamente legata alle caratteristiche hardware della rete stessa. Al di sopra di questo livello c'Φ il livello di interconnessione fra reti, ovverosia il livello dell'IP la cui unitα di scambio dati Φ appunto il datagramma IP, mentre il terzo livello Φ quello detto di Trasporto. Concettualmente Φ a questo livello che si pongono sia il TCP che appunto l'UDP, di cui parleremo in questa puntata. L'unitα di scambio dati al terzo livello si chiama pacchetto (transport packet). Il quarto livello Φ infine quello Applicativo, al quale vengono scambiati i messaggi applicativi (message e data stream).
Abbiamo visto come l'IP permette di scambiare datagrammi fra host, cioΦ a livello di macchine. Tuttavia non Φ certo la macchina il destinatario finale dei dati che fluiscono nella rete, bens∞ le applicazioni e i programmi che girano su di essa. I moderni sistemi operativi permettono di far girare pi∙ processi contemporaneamente, e comunque questi non hanno le caratteristiche di permanenza che ha invece un host. Un programma infatti Φ un componente dinamico e temporaneo in un sistema. Non Φ quindi pensabile di poter associare a un processo un identificativo fisso come si fa con gli host e gli indirizzi IP. Un processo infatti non ha un identificativo univoco in un sistema, dato che ogni volta che viene lanciato esso pu≥ assumere un identificativo diverso. Inoltre non Φ detto che gli stessi dati siano sempre processati dalla stessa applicazione. Per esempio, oggi potrei voler usare un certo programma per gestire la mia posta elettronica, domani potrei decidere di usarne un altro, e non Φ sicuramente pensabile che si debba informare tutta la rete ogni volta che si decide di cambiare l'applicazione che gestisce un certo tipo di dati. Quindi, pi∙ che il processo, quello che Φ importante identificare Φ la funzione, come per esempio, trasferire file oppure spedire posta elettronica. Lo scopo dell'UDP Φ appunto quello di permettere di distinguere in un singolo host pi∙ destinatari per i dati che arrivano dalla rete. Ma come?
Facciamo un attimo una digressione. Se io devo stampare un file cosa faccio? Collego al mio computer una stampante, attivo il driver corrispondente, e uso una applicazione o un comando del sistema operativo per lanciare l'ordine di stampa. Se ora stacco la stampante e ne attacco un'altra alla stessa porta non devo far altro che cambiare il driver per continuare a lavorare senza che il sistema si sia accorto di niente. Se poi le due stampanti usano lo stesso driver generico devo solo staccare e riattaccare fisicamente le stampanti senza modificare il sistema. In generale, tutto lo scambio di dati da e verso un computer avviene attraverso porte di I/O. Ogni applicazione accede la porta che gli serve in modo dinamico. La periferica di I/O non ha bisogno di sapere con quale applicazione sta parlando: la porta fa da schermo fra i due.
L'UDP fa una cosa analoga. Esso permette di associare a un indirizzo IP pi∙ punti di ingresso e di uscita virtuali, detti protocol port. Queste porte si comportano un po' come quelle di I/O di un computer. Ogni porta Φ identificata da un numero intero positivo e i processi possono chiedere al sistema l'accesso a tali porte. Quando un processo accede una porta, esso si mette in attesa dei dati sulla stessa. Il meccanismo Φ cioΦ sincrono. Inoltre, se dei dati arrivano a una porta alla quale non si Φ agganciato ancora un processo, questi vengono mantenuti in memoria nell'ordine di arrivo. Si dice cioΦ che le porte hanno un buffer. A questo punto, sia il processo mittente che quello destinatario sono univocamente identificati dall'indirizzo IP dell'host su cui girano e dal numero di porta che utilizzano per la trasmissione in rete. Tale associazione Φ tuttavia dinamica, e cos∞ come pi∙ applicazioni possono stampare sulla stessa stampante purchΘ non contemporaneamente, cos∞ pi∙ processi possono attaccarsi uno alla volta alla stessa porta ed essere visti come lo stesso destinatario dalla controparte mittente. Questo permette di spedire un file di testo con un word processor, e subito dopo spedire un file binario, per esempio un file ZIP, con un comando di sistema. Il tutto sempre attraverso la stessa porta e con lo stesso destinatario in termini di host e di processo.
Come abbiamo visto nel caso dell'IP e dei vari protocolli di rete nelle prime puntate di questa serie, anche il datagramma UDP Φ formato da una intestazione (header) e da una parte dati. Esso Φ inoltre incapsulato in un datagramma IP il quale a sua volta Φ contenuto in un frame della rete fisica.
Al contrario tuttavia di quello IP, l'header UDP Φ molto pi∙ semplice. Esso Φ formato dal numero di porta del mittente, da quello del destinatario, dalla lunghezza del messaggio UDP, sia dei dati che dell'intestazione, e da una somma di controllo (checksum) per la verifica dell'integritα dei dati.
Infatti, anche l'UDP, come l'IP, Φ un protocollo cosiddetto ½inaffidabile╗. Questo vuol dire che un messaggio UDP pu≥ andare perso, essere duplicato, o arrivare nell'ordine sbagliato. L'UDP non fa alcun controllo al riguardo. L'affidabilitα della comunicazione Φ infatti affidata a i protocolli di livello pi∙ elevato. Tutti i campi dell'intestazione sono lunghi 16 bit.
BenchΘ il formato del datagramma UDP sia alquanto semplice, la sua gestione pu≥ essere un po' pi∙ complessa. Il punto riguarda la somma di controllo. Questo valore Φ opzionale e, al contrario di quello che succedeva con la somma di controllo nel datagramma IP, esso non Φ relativo solo all'intestazione ma a tutto il datagramma, compresa la parte dati. Questo vuol dire che tale campo rappresenta l'unico elemento di controllo a livello IP e UDP dell'integritα dei dati arrivati. Se esso non viene utilizzato, il campo va posto a zero. Questo in quanto la somma di controllo segue la logica a complemento uno. Il che vuol dire che se la somma calcolata Φ zero, essa pu≥ essere memorizzata come 16 bit impostati a uno, dato che in tale logica un valore con tutti i bit a uno e uno con tutti i bit a zero rappresentano lo stesso numero. Quindi: se il campo Φ a zero, vuol dire che non Φ stato utilizzato; se viceversa ha tutti i bit ad 1, vuol dire che la somma era zero.
La somma di controllo, tuttavia, per ragioni pratiche, non riguarda solo il datagramma UDP, ma viene calcolata anche utilizzando alcune informazioni addizionali. Queste formano il cosiddetto pseudo-header.
In pratica, quando si deve calcolare il checksum UDP si mette davanti al datagramma UDP un altro blocco di dati che contiene l'indirizzo IP del mittente e del destinatario, il codice del protocollo UDP (17), e la lunghezza del datagramma UDP. Il motivo di questa tecnica risiede nel fatto che, per verificare se un messaggio UDP Φ arrivato al giusto destinatario, non basta verificare il numero di porta, ma anche l'indirizzo IP dell'host in cui gira il processo che Φ collegato a quella porta. Il datagramma UDP contiene tuttavia solo il numero di porta, per cui il controllo fornito da una somma sul solo datagramma non potrebbe realmente verificare che il destinatario dei dati Φ quello giusto.
Questa tecnica ha tuttavia un prezzo: gli indirizzi IP fanno parte appunto del livello internet, non di quello di trasporto. PerchΘ l'UDP conosca tali informazioni Φ necessario violare una legge fondamentale dei protocolli di comunicazione, e cioΦ che ogni livello della torre deve gestire i suoi dati senza esportarli agli altri livelli a cui offre, o da cui riceve, servizi. Questo vuol dire che la separazione tra UDP ed IP non Φ cos∞ pulita come dovrebbe essere, ma che i due protocolli sono in qualche modo legati tra loro. D'altra parte i vantaggi in termini di controllo e semplicitα di implementazione sono tali che si Φ deciso di fare un'eccezione ai principi dell'architettura. Da notare che la pseudo-intestazione serve solo a calcolare la somma di controllo. Essa non viene fisicamente trasmessa con il datagramma UDP, dato che le informazioni che contiene fanno giα parte dell'intestazione del datagramma IP in cui quello UDP sarα incapsulato.
Nella prossima puntata inizieremo a parlare di TCP, l'altro protocollo base del TCP/IP.
Arrivederci.