Guida tcp/ip

Materie:Appunti
Categoria:Informatica
Download:44
Data:23.04.2001
Numero di pagine:37
Formato di file:.txt (File di testo)
Download   Anteprima
guida-tcp-ip_2.zip (Dimensione: 33.19 Kb)
readme.txt     59 Bytes
trucheck.it_guida-tcp-ip.txt     107.07 Kb


Testo

Guida TCP/IP

Miliardi di bit viaggiano ogni giorno sulla Rete. Vi siete mai chiesti come fanno ad arrivare al corretto destinatario? In questo articolo, primo di una serie vi presentiamo "la suite di protocolli TCP/IP" cioи le regole utilizzate per la trasmissione su Internet. Non и certo fondamentale sapere come funziona uno spinterogeno o un albero di trasmissione per guidare un'automobile. Analogamente, al giorno d'oggi, non serve sapere come funziona un computer per poterlo utilizzare. La tecnologia ci scherma sempre di piщ dal come una cosa funziona spostando l'attenzione sul cosa fare per utilizzarla. Cosм, quella che era una volta tecnologia per un'йlite abbastanza ristretta di studiosi, ricercatori e studenti, и oggi una realtа a disposizione di tutti. Non solo и diventato semplice navigare nella Ragnatela, ma oggi chiunque puт facilmente costruirsi le sue pagine e agganciarle a uno dei tanti siti Web che ospitano pagine private. Non c'и piщ neanche bisogno di conoscere l'HTML, grazie alla proliferazione di editor HTML commerciali e di pubblico dominio. In quanto ai risultati estetici, beh, lм non c'и programma che tenga.
Ma cosa c'и sotto a tutto ciт? Per chi и ancora e nonostante tutto interessato a capire come funzionano le cose, e se vogliamo anche per coloro ai quali la cosa non interessa per niente, ma hanno qualche minuto per leggere un paio di paginette e poi, chissа, potrebbe sempre tornare utile... insomma, per chi vuole, ecco a voi il "TCP/IP, questo sconosciuto".
Il nome completo и TCP/IP Internet Protocol Suite, ed и un insieme di protocolli di trasmissione di cui i due principali sono appunto il TCP (Transmission Control Protocol) e l'IP (Internet Protocol). Ma che cosa и esattamente un protocollo? Essenzialmente и una serie di regole per comporre dei messaggi e per far sм che essi possano essere scambiati tra due macchine. Non stiamo parlando solo di computer. Anche una centrale telefonica meccanica puт ricadere in questa definizione. Un protocollo puт contenere regole estremamente dettagliate, come quelle che identificano il significato di ogni singolo bit nella costruzione di un messaggio, oppure fornire uno scenario di alto livello, come per esempio definire come avviene il trasferimento di un file da un computer a un altro. Fondamentalmente un protocollo sta alla trasmissione dati come un linguaggio di alto livello quale il C++ sta alla programmazione. Infatti, un linguaggio di programmazione comprende sia regole estremamente dettagliate che devono essere seguite alla lettera - guai a dimenticare anche un solo punto e virgola alla fine di un'istruzione C++ - sia strutture di alto livello che vanno costruite nel modo corretto, pena errori nella struttura logica del programma.
Una generica architettura di trasmissione и formata da una torre a piщ piani, dove ogni piano rappresenta una precisa responsabilitа nella trasmissione dei messaggi. Alla base della torre sta la porta di accesso alla rete fisica, che potremmo pensare come una rete di strade. Ogni piano prende il messaggio che arriva dal piano superiore, lo mette in una busta con alcune informazioni aggiuntive, e lo passa come messaggio al piano inferiore.
Le regole di comunicazione tra i vari piani sono dette interfacce. Il messaggio risultante, formato da tante buste una dentro l'altra, viene immesso nella rete dalla porta che si trova alla base della torre. Una volta arrivato al piano terreno infatti, esso viene trasportato alla torre di destinazione e da qui risale un piano dopo l'altro fino all'ultimo piano, detto anche livello applicativo. Ogni piano della torre di destinazione apre solo la busta che gli compete e usa le informazioni aggiuntive per recapitare la busta successiva al piano superiore. Le informazioni aggiuntive rappresentano il protocollo di comunicazione. Ogni piano comunica quindi solo con il piano corrispondente.
Esempio: Il direttore della Pippo e Figli manda una lettera riservata al direttore della Pluto e Consorte. Il modo con cui i due comunicano, per esempio i riferimenti a lettere precedenti, lo stile della lettera, il modo di salutare alla fine della lettera, e cosм via, rappresenta il protocollo ad alto livello, cioи quello applicativo. Per spedire la lettera il direttore lo passa alla sua segretaria. Ciт avviene secondo le regole interne della
Pippo e figli, ed и perciт un'interfaccia. La segretaria prende la lettera, la mette in una busta aggiungendo il nome del destinatario e la scritta RISERVATO. Queste informazioni sono per la sua controparte nella Pluto e consorte, ed и quindi anch'esso un protocollo. La busta viene quindi passata all'Ufficio Posta dell'edificio secondo la procedura ordinaria (altra interfaccia), il quale aggiunge l'indirizzo completo, il CAP e altre informazioni necessarie alla spedizione, e la passa quindi al corriere, che rappresenta il meccanismo fisico di trasferimento del messaggio. Terzo protocollo. Quando la lettera arriva, questa viene gestita dall'Ufficio Posta della Pluto e consorte che, dopo aver buttato la busta esterna con l'indirizzo dell'edificio, la passa alla segreteria del direttore. Questa registra l'arrivo della missiva, la toglie dalla busta piщ interna, e poi consegna la lettera vera e propria al direttore della Pluto e consorte.
И evidente che perchй il sistema funzioni bisogna che i vari protocolli siano rispettati da entrambe le aziende. Mentre infatti le interfacce possono essere diverse (ogni azienda ha le sue procedure interne), i protocolli devono essere stati concordati prima, altrimenti alcune informazioni potrebbero andare perse, o addirittura la lettera potrebbe non essere recapitata in tempo. Pensate a una segretaria italiana che riceve una busta da una consociata asiatica con sopra scritto URGENTE in cinese! Ne nasce una considerazione importante. La base di ogni protocollo и il concetto di standardizzazione. Piщ vasta и l'accettazione dello standard, piщ forte e diffuso и il protocollo. Gli standard internazionali sono in genere i piщ importanti, ma non sempre. Un esempio и proprio il TCP/IP, nato per volontа dell'agenzia americana DARPA (Defense Advanced Research Projects Agency) e poi diventato di fatto il maggior sistema di protocolli per l'interconnessione di reti a livello mondiale.
Internet и fatta a strati Internet и basato su tre livelli concettuali: il livello applicativo (Application Services), quello del trasporto (Reliable Stream Transport Service) e quello della spedizione dei pacchetti (Connectionless Packet Delivery Service). Per capire il TCP/IP, и necessario a questo punto capire bene che cosa и Internet. Tanto per cominciare Internet non и una rete di comunicazione. Una rete di comunicazione и in genere legata alle necessitа specifiche di chi l'ha disegnata e dell'hardware utilizzato per implementarla. Costruire una rete ideale che vada bene per qualsiasi esigenza, o pensare di poter limitare a un solo tipo di hardware l'implementazione di una qualunque rete non solo non и fattibile, ma neanche auspicabile, date le limitazioni delle tecnologie attuali. A volte и necessario far correre i dati molto velocemente in un ambito molto ristretto, come per esempio all'interno di un edificio. Altre volte si ha l'esigenza di trasmettere dati a migliaia di chilometri di distanza in modo molto affidabile, anche se questo puт significare un rallentamento nella velocitа di trasmissione. Se si cercasse di utilizzare lo stesso hardware in entrambi i casi, i costi sarebbero assolutamente inaccettabili.
La soluzione и l'interconnessione delle reti, o internetworking. Grazie a ponti di collegamento (detti gateway) e la definizione di opportuni protocolli, si possono collegare fra di loro reti anche molto diverse, fornendone agli utenti una visione comune. Questa и la forza di Internet rispetto alle varie reti proprietarie, e di conseguenza del TCP/IP sui vari protocolli proprietari. Il TCP/IP и un insieme di regole pubbliche, aperte a tutti, o come si dice nell'ambiente, un sistema aperto (open system), che permette l'interconnessione di reti anche molto differenti, indipendentemente dalla tecnologia usata da ogni rete. I suoi principali vantaggi sono appunto l'indipendenza dalle tecnologie delle singole reti interconnesse, la possibilitа di far comunicare fra di loro ogni computer connesso al sistema, la possibilitа di trasmettere conferme di ricezione (acknowledgement) direttamente dal destinatario al mittente, e soprattutto una notevole quantitа di protocolli applicativi per qualunque possibile bisogno, come vedremo piщ avanti. Il TCP/IP definisce quindi una unitа di trasmissione dati chiamata datagram, e le regole da seguire per trasmettere un datagram in una particolare rete.
Il principio che sta alla base dell'interconnessione и quello di schermare le applicazioni dalle caratteristiche fisiche delle reti in modo semplice e flessibile. Questo avviene attraverso un livello intermedio che si occupa di spedire e ricevere piccoli pacchetti di dati fra due punti qualsiasi del sistema di reti. Questo meccanismo si chiama packet-switching. Esso consiste nella divisione di ogni messaggio in un certo numero di pacchetti di dati. Ogni pacchetto и formato da poche centinaia di byte, e contiene una intestazione che fornisce informazioni sul destinatario e su come raggiungerlo. Questo meccanismo ha il vantaggio di ottimizzare l'utilizzo della rete, parallelizzando la trasmissione di piщ messaggi contemporaneamente. Lo svantaggio и che ogni nuovo sistema che si aggancia alla rete per trasferire dati riduce la disponibilitа della rete per tutti gli altri sistemi giа connessi. Una rete infatti ha una certa capacitа ben definita, che dipende sostanzialmente dalla tecnologia hardware e software che utilizza. Tale capacitа viene misurata in bit per second (bps). Questa grandezza non rappresenta la velocitа dei dati in rete, come si potrebbe pensare in prima istanza, bensм dа una misura del numero massimo di bit che possono essere trasmessi nella rete in un secondo. La velocitа reale di un singolo messaggio dipende da tanti fattori, come il numero di sistemi che stanno utilizzando la rete, la qualitа delle connessioni e di conseguenza il numero di tentativi necessari per trasferire correttamente i dati, le modalitа di trasmissione e i dati aggiuntivi necessari al trasferimento degli stessi.
Ci sono altri modi per trasferire dati in una rete: per esempio, quando fate una telefonata, la rete stabilisce un collegamento diretto fra il vostro telefono e quello della persona chiamata. A questo punto il telefono incomincia a campionare il microfono della vostra cornetta in modo continuo, trasferendo il segnare al ricevitore all'altro capo. Il tutto a 64.000 bit per secondo, che и la velocitа di campionamento necessaria a digitalizzare la voce. Questo avviene comunque, indipendentemente dal fatto che stiate parlando o meno. Anche se state in silenzio la linea и saturata al massimo della sua capacitа. Questo meccanismo и detto circuit-switching. Al contrario del meccanismo usato dal TCP/IP, quello cioи a pacchetti, la linea и completamente assegnata alla comunicazione in atto, per cui il fatto che altri stiano telefonando non riduce la capacitа della connessione. D'altra parte la linea и utilizzata completamente indipendentemente dal fatto che ci siano o meno dati da trasferire. Di qui gli elevati costi di tale meccanismo. La telefonata, infatti, la pagate lo stesso sia che parliate molto velocemente, sia che stiate completamente in silenzio. Questo meccanismo и troppo costoso per una rete informatica, specialmente se si tiene conto che la disponibilitа di tecnologie hardware sempre piщ raffinate e veloci per il trasferimento dei dati bilanciano in buona parte quello che и uno dei punti deboli del sistema a pacchetti, e cioи l'impossibilitа di garantire a ogni utente e in ogni momento una certa capacitа di trasferimento ben definita.
Torniamo al sistema a pacchetti. Per trasferire dati da un sistema a un altro ogni sistema ha un nome unico ben definito. Non esistono cioи due sistemi con lo stesso nome, anche se in reti diverse, indipendentemente da quale и il nome locale di un sistema nella sua rete di appartenenza. All'interno di ciascuna rete, i vari computer usano la tecnologia hardware e software specifica di quella rete. Tuttavia, grazie a questo strato intermedio di software, le varie applicazioni hanno una visione unica e globale del sistema interconnesso di reti, detto appunto internet. Notate la "i" minuscola. Il concetto di internet и infatti quello appena descritto. Viceversa Internet con la "I" maiuscola, identifica quel sistema di reti, basato sull'architettura internet, che viene detto anche Connected Internet.
La connessione tra due reti avviene attraverso macchine opportune che sono collegate fisicamente a entrambe le reti, e hanno la responsabilitа di far passare i vari pacchetti da una rete all'altra e viceversa. Tali macchine sono dette internet gateway, o anche IP router. Sono loro il vero elemento portante di una internet. Ogni router non solo deve sapere che determinati pacchetti vanno passati da una rete a un'altra, ma deve passare dall'altra parte anche pacchetti destinati a ulteriori reti connesse attraverso altri router. Essi perт ragionano solo in termini di reti, non di destinazione finale. A un router non interessa chi и effettivamente il destinatario di un pacchetto, ma solo a quale rete appartiene. Questo semplifica molto l'implementazione di un router. Alla base del meccanismo dei router c'и l'indirizzo IP, o IP address.
Ogni cosa che conosciamo ha un nome. Cane, casa, auto, e via dicendo. Se ci interessa specificare meglio ciт di cui stiamo parlando, possiamo assegnare un nome anche a un sottogruppo di cose. Cosм abbiamo che i cani bassotti sono alquanto diversi dai San Bernardo, una catapecchia non и certo una villa, e una Ferrari costa un po' piщ di una Cinquecento. Se poi dobbiamo identificare una cosa in modo chiaro e univoco, и necessario assegnarle un nome che solo quella cosa ha. Giа un nome come Mario Rossi non va bene, perchй non и unico, e comunque, anche se scegliessimo oggi un nome veramente strano e originale, non avremmo la garanzia in futuro di non ritrovarci con un caso di omonimia. Ecco allora le targhe per le automobili, i codici fiscali per le persone, i numeri di telefono, e via dicendo. Ognuno di questi nomi ha tre caratteristiche. La prima и che esiste un organo competente centrale che li assegna, proprio per garantirne l'univocitа. La seconda, и che hanno una struttura a sottogruppi. Esistono cioи degli elementi che garantiscono l'univocitа a un certo livello, all'interno del quale esiste una certa libertа di scelta, e cosм via, livello dopo livello. Per esempio, il codice fiscale viene costruito in modo che un uomo e una donna non possano mai avere lo stesso codice, anche se fossero nati lo stesso giorno, nella stessa cittа e si chiamassero nello stesso modo. Similmente, i numeri di telefono di due cittа diverse si distinguono per il prefisso e se queste si trovano anche in stati diversi, per il prefisso internazionale.
Affinchй internet possa rappresentare un sistema universale di comunicazione, permetta cioи di far comunicare qualunque macchina connessa a una delle sue reti con una qualsivoglia altra macchina connessa alla stessa o a un'altra rete, и necessario fornire ogni macchina di un nome unico a livello globale. Internet fornisce ogni sistema di un nome, che identifica il sistema stesso, di un indirizzo, che mi dice dove si trova il sistema, e di un cammino, che mi dice come raggiungere il sistema. Ogni macchina connessa a una rete и detta host, nella terminologia internet. Lo stesso termine ha significati differenti in altri contesti informatici, come per esempio in quello client/server, o nel caso di mainframe. Attenzione a non fare confusione quindi. In internet un host puт essere anche un vecchio 8088 con 640K di RAM e 10M di disco fisso.
L'indirizzo, o IP address, и un campo composto da 32 bit. I primi bit permettono di distinguere 5 forme standard identificate da una lettera del alfabeto, e dette classi. Le prime tre classi dell'IP address contengono sia l'indirizzo di una rete (netid), sia quello di una macchina nella stessa (hostid). In realtа l'indirizzo non identifica necessariamente una macchina, ma una connessione alla rete. Per esempio, un router ha almeno due indirizzi, avendo connessioni ad almeno due reti. Questo in quanto un router appartiene a entrambe le reti, e quindi sono necessari due indirizzi dato che un IP address ha posto per un solo indirizzo di rete. Se l'indirizzo dell'host и 0, allora l'IP address si riferisce alla rete stessa. Se viceversa tutti i bit riservati all'indirizzo dell'host sono 1, allora l'indirizzo viene utilizzato per identificare tutti gli host della rete (broadcasting). Uno speciale indirizzo formato da 32 bit posti a uno и chiamato local network broadcast address e serve solo in casi molto particolari. Il concetto di broadcasting и quello della diffusione a tutto raggio, un po' come fa un'emittente radiofonica. In generale internet interpreta i campi formati da tutti uno come all, cioи "tutti", mentre quelli formati da tutti zero come this, cioи "questo", "qui". Questo per quanto riguarda le classi A, B e C. La classe D и usata per un particolare tipo di distribuzione dei dati detto multicasting. La classe E и riservata a usi futuri. Dato che specificare ogni singolo bit di un indirizzo IP sarebbe alquanto poco pratico e di scarsa leggibilitа, la convenzione и quella di leggere ogni ottetto, cioи ogni gruppo di 8 bit, come un intero, e di separare i quattro ottetti con un punto. Oltre a i casi speciali giа descritti, l'indirizzo di classe A 127.0.0.0 и riservato per un particolare processo di test che rimanda indietro i dati al mittente senza propagarli nella rete.
Uno dei vantaggi di questo schema и la possibilitа da parte dell'organismo centrale che assegna gli indirizzi (Network Information Center) di delegare ai responsabili delle singole reti l'assegnazione di una parte dell'indirizzo all'interno della rete stessa. La cosa avviene un poco come con i numeri di telefono. A livello internazionale ogni stato ha il suo prefisso internazionale. Per esempio, per l'Italia, и 39. All'interno ogni stato divide il paese in aree geografiche a cui assegna un ulteriore codice. Per esempio, Roma и identificata dal 6, Milano dal 2, Firenze da 55, e cosм via. All'interno poi della provincia o della cittа possono essere definite ulteriormente sottoaree a cui si assegnano due, tre o quattro cifre. Per esempio 529 oppure 7054. Infine ogni telefono in tali aree avrа il suo numero. Cosм, se Mr. Smith deve chiamare dagli Stati Uniti il signor Mario Rossi abitante all'EUR, a Roma, comporrа per esempio il numero 011.39.6.529.4467. In questo caso lo 011 serve per uscire dagli USA, un po' come il nostro 00.
Analogamente in internet i numeri di classe C sono assegnati alla piccole reti, quelle cioи con meno di 256 host, quelli di classe B alle reti con al massimo 65536 host, e quelli di classe A alle reti con oltre 16 milioni di host. Ogni rete decide poi come suddividere gli indirizzi che gli sono stati riservati al suo interno come meglio crede. Ovviamente, una internet privata non ha la necessitа di seguire queste regole, nй a utilizzare indirizzi assegnati dal NIC, ma il non farlo potrebbe impedire in futuro la connessione alla TCP/IP Internet.
Dato che l'indirizzo puт essere a volte abbastanza ostico da ricordare, и possibili associare a ogni host anche un nome, che puт essere utilizzato come mnemonico per un IP address, e la cui risoluzione и responsabilitа di particolari macchine chiamate name server. In realtа il name server и un programma software che puт girare in qualunque macchina connessa alla rete, e che mantiene l'associazione tra nomi e indirizzi IP, fornendo tali corrispondenze quando richiesto da un altro programma chiamato name resolver. Di fatto, si preferisce far girare il name server su una macchina dedicata, che prende anch'essa, a questo punto, il nome di name server. Potete pensare al name server come a una agenda telefonica elettronica, che contiene una lista parziale di nomi e numeri telefonici. In internet infatti, non esiste un singolo elenco telefonico, ma tanti name server che cooperano per fornire quello che и un vero e proprio elenco distribuito. In realtа il sistema funziona in modo gerarchico, un po' come se una certa agenda contenesse solo i prefissi internazionali e il puntatore alle agende di ogni singolo stato, le quali a loro volta contengono i prefissi regionali e i puntatori agli elenchi regionali, e cosм via, fino ad arrivare all'agenda che contiene solo le estensioni telefoniche di un singolo edificio.
I nomi Internet sono basati su una serie di regole dette Domain Name System (DNS), che si basa appunto su uno schema gerarchico in cui il nome и suddiviso in varie parti separate fra loro da punti. Per esempio, vnet.ibm.com. Ogni suffisso и a sua volta un dominio. Quindi, nel nostro esempio, ibm.com и un dominio di secondo livello, mentre com и un dominio di terzo livello. I domini ufficiali riconosciuti dal NIC al livello piщ elevato sono riportati in tabella 1. Una rete puт richiedere di essere registrata come categoria, oppure usando il dominio geografico. Per esempio, l'Italia ha come dominio base it. Supponiamo che il governo decida di costruire un insieme di reti cittadine interconesse fra loro e connesse a Internet. Si puт pensare di assegnare a ogni provincia un dominio xxxxxx.it. Per esempio, Firenze avrebbe come dominio firenze.it. L'universitа di Firenze potrebbe registrare la sue rete come unifi.edu, e in tal caso sarebbe direttamente il NIC a dover dare l'autorizzazione per tale nome, essendo il dominio edu sotto responsabilitа dell'organismo centrale di controllo, oppure potrebbe decidere di far parte del dominio cittadino, come unifi.firenze.it, e quindi potrebbe richiedere il permesso di registrare tale nome direttamente all'amministratore del dominio di Firenze. A questo punto, se il dipartimento di Fisica di Arcetri vuole registrare un proprio dominio, deve chiederlo solo all'Universitа stessa, ricevendo cosм, per esempio, arcetri.usf.fi.it oppure fisica.usf.fi.it.
Esiste una piccola complicazione. Ogni oggetto connesso alla rete ha un tipo. Oggetti di tipo diverso possono avere lo stesso nome. Per cui, per poter risolvere un nome e ottenere indietro l'indirizzo IP, и necessario anche specificare il tipo di oggetto: macchina, utente, casella postale, e via dicendo. Dal solo nome non и possibile evincere il tipo di oggetto.
Il DNS definisce anche come associare i nomi agli indirizzi IP, e come ottenere quest'ultimi dal nome. In realtа lo schema и ancora piщ generale di quanto puт sembrare, in quanto permette di estendere la sintassi del nome per usi specifici, sfruttando anche il concetto di tipo. Per esempio, nel caso di una casella postale (tipo MX), il nome sarа del tipo [email protected]
Per esempio [email protected]
Innanzi tutto una internet и un sistema di interconnessione fra reti differenti che utilizza sia sistemi dedicati per la connessione, detti gateway, sia uno strato (layer) di protocolli che mostrano alle applicazioni una visione omogenea di una rete virtuale e che sono basati sulla trasmissione di piccoli pacchetti di dati. Ogni pacchetto porta con sй l'indirizzo del destinatario il quale identifica univocamente sia la rete di destinazione che la connessione alla quale deve essere recapitato il pacchetto. Un sistema connesso a piщ reti della stessa internet avrа quindi piщ indirizzi IP. Un opportuno software, spesso installato su macchine dedicate, permette di associare a ogni indirizzo un nome di piщ facile utilizzo da parte degli utenti del sistema. Il formato di questo nome si basa su un insieme di regole dette DNS. Quella che и universalmente conosciuta come Internet и di fatto la principale rete interconnessa esistente, che si estende praticamente su tutto il pianeta.
Data questa premessa, vediamo di approfondire la trattazione dei protocolli TCP/IP. Innanzi tutto qualunque trasferimento di dati implica la trasmissione di bit da un sistema a un altro. Tali dati devono essere correttamente interpretati dai vari sistemi connessi alla rete. Data l'enorme varietа di hardware e di sistemi operativi questo и tutt'altro che banale. Nei protocolli di trasmissione i bit vengono convenzionalmente raggruppati per multipli di otto, detti ottetti. Una volta questo corrispondeva al bus da 8 bit, cioи un byte, tipico dei computer. Oggi la maggior parte dei computer usa parole di almeno 32 bit. Tuttavia non tutte le macchine memorizzano tali parole nello stesso modo. Esistono vari modi per memorizzare un intero rappresentato da 32 bit. In quello detto Little Endian, la posizione piщ bassa in memoria contiene il byte di ordine piщ basso dell'intero. Nei sistemi Big Endian avviene esattamente il contrario, cioи la posizione piщ bassa in memoria contiene il byte di ordine piщ elevato. In altri sistemi ancora il raggruppamento viene fatto con parole da 16 bit, in cui la parola meno significativa viene appunto prima. Il risultato и lo stesso del Little Endian ma con i byte invertiti all'interno di ogni singola parola. И evidente che non и pensabile che sia la rete a gestire tutti questi modi diversi di interpretare i dati, anche perchй di solito i protocolli di trasmissione non entrano nel merito di come ragionano i singoli sistemi, ma si occupano solamente di trasferire in modo piщ o meno affidabile i dati a loro affidati. Ne consegue la necessitа di definire un formato standard valido per tutti i dati che corrono lungo i collegamenti, lasciando a i vari sistemi il compito di effettuare le opportune conversioni locali. Lo standard internet prevede che gli interi vengano trasmessi a partire dal byte piщ significativo, secondo lo stile del Big Endian.
Cosм in un pacchetto, un intero ha il byte piщ significativo verso la testa del pacchetto e quello meno significativo verso la coda dello stesso.
A questo punto i sistemi sono in grado di scambiarsi i dati in modo non equivoco. Ma come fa a sapere la rete internet che un sistema и collegato, e soprattutto, come avviene l'associazione tra l'IP address e l'indirizzo fisico di rete? Ogni rete fisica infatti ha un suo formato per gli indirizzi fisici assegnati alle connessioni di rete. In generale esistono due modi di assegnare indirizzi fisici alle macchine connesse in rete. In una rete piccola, come puт essere una Token Ring, cioи un anello di un paio di centinaia di macchine al massimo, a ogni connessione puт essere assegnato un intero basso, per esempio compreso tra 1 e 254. Questo sistema ha il vantaggio di associare l'indirizzo fisico alla connessione piuttosto che alla scheda che permette la stessa. Per cui, se la scheda si rompe, l'utente puт cambiarla senza dover tuttavia modificare l'indirizzo fisico di rete, purchй imposti sulla nuova scheda lo stesso indirizzo di quella vecchia. Lo svantaggio и che non esiste alcun controllo che impedisca a due utenti sulla stessa rete di impostare lo stesso indirizzo fisico, creando cosм una collisione. In altri tipi di reti, come per esempio Ethernet, ogni scheda ha giа preimpostato da parte del costruttore un indirizzo fisico fisso, per cui non c'и alcun rischio di collisione, ma cambiare la scheda vuol dire dover necessariamente cambiare indirizzo fisico. Inoltre, dato che questo indirizzo и unico non solo fra le schede installate su una certa rete, ma in assoluto fra tutte le schede costruite, esso и generalmente molto lungo. Nel caso di Ethernet и di ben 48 bit.
Associare un IP address a un sistema con indirizzi formati da piccoli numeri e per giunta tali che a paritа di connessione l'indirizzo non cambia mai, come nel caso di una rete proNET-10, и molto semplice. Per esempio, per un IP address di classe C, si puт usare l'indirizzo fisico come host identifier. Cosм, se la rete ha IP address del tipo 10.214.32.x, l'host con indirizzo fisico 16 avrа IP address 10.214.32.16. Un altro paio di maniche и gestire indirizzi molto piщ lunghi dei 32 bit utilizzati per gli indirizzi internet, e per giunta che possono cambiare nel tempo a paritа di connessione. Ovviamente si potrebbe tenere da qualche parte una tabella per gli accoppiamenti, e di fatto si fa cosм, ma non и certo molto pratico pensare che qualcuno la tenga aggiornata a mano. Il problema и stato risolto efficacemente utilizzando un meccanismo di risoluzione dinamica implementato dal protocollo ARP, o Address Resolution Protocol.
ARP funziona piщ o meno cosм. Quando un host deve spedire un pacchetto a un certo destinatario, spedisce a tutti gli host nella stessa rete fisica un messaggio in cui chiede chi и l'host con quel ben preciso IP address. Nello stesso messaggio mette anche i propri indirizzi, sia quello fisico che quello IP. Si adopera cioи una tecnica di broadcasting. L'host il cui IP и quello cercato, rimanda indietro al richiedente il proprio indirizzo fisico, permettendo cosм l'associazione tra i due. Ciт и possibile in quanto esso ha comunque ricevuto anche l'indirizzo fisico del mittente. Ma allora per ogni pacchetto che va spedito a un certo IP address и necessario prima mandare un pacchetto a tutti gli host nella rete? E perchй allora non mandare direttamente il pacchetto da trasmettere a tutti, invece di chiedere prima chi и che ha un certo indirizzo IP? Ovviamente la cosa non funziona cosм, anche perchй si rischierebbe di appesantire inutilmente la rete con pacchetti che vengono recapitati ai sistemi sbagliati. Quello che si fa и di mantenere presso ogni host una tabella con tutti gli accoppiamenti giа trovati, e di aggiornarla periodicamente per evitare che diventi obsoleta. A questo punto i meccanismi di broadcasting servono ad aggiornare tali tabelle. Per esempio, se un host deve spedire un pacchetto a un certo indirizzo IP, prima controlla nella sua tabella se non ha giа l'indirizzo fisico del destinatario. Solo nel caso l'informazioni manchi, l'host spedisce a tutti gli altri host il messaggio di richiesta. Quando questo arriva a un qualunque host, sia esso il vero destinatario o no, ogni host aggiorna la sua tabella con l'indirizzo fisico e quello IP del mittente, tanto per guadagnare tempo. Il destinatario, in piщ, spedisce indietro anche il suo indirizzo fisico al mittente, cosм da potergli permettere di aggiornare la sua tabella di indirizzi. Un'ulteriore tecnica che si usa per assicurarsi che tali tabelle siano sempre aggiornate, и quella di far distribuire la propria
coppia di indirizzi, fisico ed IP, ogni qual volta un sistema si connette alla rete, per esempio al reboot.
ARP non viene considerato propriamente un protocollo internet, quanto un meccanismo della rete fisica. Su ARP si basa il protocollo IP per far comunicare fra loro le varie macchine quando non и possibile risolvere in altro modo gli indirizzi IP in indirizzi fisici. Un protocollo analogo и il RARP, o Reverse Address Resolution Protocol, con il quale una macchina senza disco fisso (diskless) и in grado di conoscere il proprio indirizzo IP a partire da quello fisico. Per far ciт la rete deve avere uno o piщ RARP Server, i quali contengono una tabella di associazione fra gli indirizzi IP e quelli fisici di tutte le macchine diskless. Anche questo protocollo si basa su un messaggio mandato in broadcasting. L'esistenza di questo protocollo и legata al fatto che una macchina diskless non puт memorizzare il proprio indirizzo IP in alcun posto, non avendo memoria secondaria.
E veniamo ora al TCP/IP vero e proprio. Come detto prima l'architettura internet и basata su tre livelli. L'Application Services и il livello piщ alto, cioи quello delle applicazioni. I programmi che utilizzate quando usate internet ricadono in questo livello. Il Reliable Stream Transport Service и il livello intermedio. Esso si occupa dell'affidabilitа della comunicazione, gestendo gli errori di trasmissione e la perdita di eventuali dati. Esso inoltre fornisce una visione della comunicazione ad alto livello, in cui esiste una connessione tra i due host che si trasmettono grandi volumi di dati. Il livello piщ basso, chiamato Connectionless Packet Delivery Service и quello che effettua la spedizione vera e propria dei singoli pacchetti, senza garantire l'affidabilitа sulla singola trasmissione, nella modalitа detta connectionless.
Il protocollo su cui si basa il livello piщ basso della torre internet и appunto l'Internet Protocol, o IP. Tale protocollo si basa su alcuni concetti fondamentali. Innanzi tutto il servizio che fornisce и detto unreliable, cioи inaffidabile, in quanto non dа alcun garanzia che il singolo pacchetto arrivi effettivamente a destinazione. In secondo luogo и detto connectionless, cioи senza connessione diretta, in quanto la trasmissione non avviene direttamente verso il destinatario, ma il messaggio и lanciato nella rete lasciando poi a questa il compito di portarlo a destinazione utilizzando l'indirizzo IP dell'host destinatario. Infine si parla di best-effort delivery, cioи spedizione al meglio delle possibilitа, in quanto la rete fa tutto il possibile per portare comunque a destinazione il pacchetto. In pratica l'IP si comporta come un naufrago su un'isola deserta che lancia nella corrente un messaggio in una bottiglia per un tizio che si trova su di un'altra isola dello stesso arcipelago, contando sul fatto che se la bottiglia arriva sull'isola sbagliata qualcuno ributterа a mare il messaggio fintanto che non arriverа a destinazione. Detta cosм c'и quasi da stupirsi che internet funzioni cosм bene. Anzi, che funzioni del tutto! In realtа non dimentichiamoci che sopra al livello piщ basso ce n'и un altro che garantisce appunto l'affidabilitа della comunicazione. Torniamo comunque all'IP. Esso и formato da tre regole base: come и fatto il pacchetto da trasmettere, detto IP datagram, come avviene la scelta del cammino che il pacchetto segue per raggiungere il destinatario, come gli host e i gateway devono trattare i pacchetti e in particolare le modalitа per l'emissione dei messaggi di errore e quelle per la soppressione dei pacchetti.
Prima perт di entrare nel dettaglio dei singoli campi, vediamo come si comporta l'IP nella gestione dei pacchetti di dati. Questo ci permetterа piщ avanti di comprendere meglio il significato di alcuni campi dell'IP datagram.
Innanzi tutto va ricordato che l'IP и un protocollo unreliable, non dа cioи alcuna garanzia che il singolo pacchetto arrivi effettivamente a destinazione, ed и connectionless, ovverosia il messaggio non viene spedito direttamente al destinatario ma viene immesso nella rete lasciando poi a questa il compito di portarlo a destinazione. Esso inoltre и di tipo best-effort delivery, in quanto la rete fa tutto il possibile per portare comunque a destinazione il pacchetto.
Detto questo, vediamo come avviene la trasmissione vera e propria dei dati. L'unitа fisica di trasferimento dei dati in una rete и la frame. Questa и composta di due parti: l'intestazione (header) e l'area dati (data area). L'unitа di misura и invece l'ottetto, formato da otto bit, cioи un byte. Ogni rete fisica ha un limite massimo di capacitа di trasferimento per un singolo frame, detto Maximum Transfer Unit (MTU). L'MTU и cioи il massimo numero di ottetti di dati che puт essere trasferito in un singolo frame. Per esempio, Ethernet ha generalmente una MTU di 1.500 ottetti (1492 secondo lo standard IEEE 802.3). Questo vuol dire che se si devono spedire 2.000 byte di dati via Ethernet, и necessario spezzarli in due blocchi tali che ogni blocco sia minore o uguale a 1.500. A ogni blocco si aggiunge poi l'intestazione del frame. Dal punto di vista della rete fisica l'IP datagram и un blocco di dati. La rete fisica ignora cioи come tali dati vengano utilizzati dall'IP. Quindi, il primo compito di IP и quello di decidere come costruire il datagram affinchй possa essere trasmesso in un frame fisico. L'ideale sarebbe di poter mettere un singolo datagram in ogni frame, ottimizzando cosм la trasmissione e semplificando la logica. Ma quale frame? Quello della rete di partenza? Quello della rete di arrivo? E se durante la trasmissione il datagram deve passare attraverso piщ reti con MTU differenti? Il punto и che non c'и modo di fare una scelta che assicuri di avere un datagram per frame. D'altra parte internet ha come obiettivo quello di svincolarsi dalle caratteristiche fisiche delle varie reti interconnesse fra loro. E allora? La soluzione adottata и molto semplice. Le dimensioni del datagram sono scelte convenzionalmente secondo una logica del tutto indipendente dalle MTU delle singole reti fisiche, dopodichй, a seconda della rete in
cui il datagram deve passare, questo и spezzato in piщ pezzi di dimensioni inferiori alla MTU della rete fisica, detti frammenti (fragment).
Il datagram и anch'esso un frame, che potremmo chiamare logico per distinguerla da quello usata da una specifica rete fisica per trasmettere i dati. Come tale anch'esso и formato da una intestazione e da un'area dati. All'atto della frammentazione, ogni frammento viene costruito replicando l'header del datagram, modificandone alcuni campi che vedremo in seguito, e aggiungendo a questo un pezzo dell'area dati originaria. L'aspetto piщ importante di questo meccanismo и che il riassemblaggio dei frammenti non viene effettuato quando i vari frammenti rientrano in una rete fisica ad alto MTU, ma sempre e comunque presso l'host di destinazione. Cosм, se due reti con MTU uguale a 1.500 ottetti sono separate da una rete con MTU piщ bassa, per esempio 500 ottetti, i frammenti che arriveranno a destinazione saranno di soli 500 ottetti. In questo caso la frammentazione avviene nel primo gateway mentre il riassemblaggio avviene solo nell'host di destinazione. Il protocollo IP richiede che sia gli host che i gateway siano capaci di gestire datagram di almeno 576 ottetti. In aggiunta, questi ultimi devono essere capaci anche di gestire datagram grandi quanto l'MTU piщ grande tra quelle delle reti a cui sono connessi. Ricordiamo che un gateway, per definizione, ha almeno due connessioni e quindi almeno due indirizzi IP.
Il punto debole di questo meccanismo и che la perdita di anche un solo frammento comporta la perdita dell'intero datagram. Dato che ogni frammento и trasmesso indipendentemente, passare attraverso reti a bassa MTU comporta un'elevata frammentazione anche nelle reti a maggiore MTU e comunque aumenta i rischi di perdita dei dati. Quando un frammento arriva a destinazione, e non и detto che il primo arrivi per primo, l'host fa partire un timer. Se questo scade prima che tutti i frammenti siano arrivati, il sistema cancella tutti i frammenti e considera perduto il datagram. Il concetto di timer e di tempi и estremamente importante per l'IP ed и spesso usato per ottimizzare la rete. Per esempio, ogni datagram ha una scadenza. Se il datagram и ancora all'interno della rete quando il suo tempo и scaduto, esso viene cancellato definitivamente. Lo scopo и quello di evitare che un pacchetto possa restare all'infinito in internet a causa di un errore in una routing table. Queste tabelle infatti servono a gestire il processo di instradamento del pacchetto nella rete. Se una o piщ tabelle sono sbagliate, si potrebbero creare cammini chiusi in cui i datagram potrebbero rimanere intrappolati. Veniamo finalmente al formato del datagram. Come si и giа detto esso и composto di un'intestazione e di un'area dati. L'area dati contiene semplicemente una parte dei dati da trasmettere. Questo in quanto il datagram и piccolo mentre l'oggetto da trasmettere puт essere anche molte centinaia di Kilobyte, se non addirittura migliaia, come per esempio un'immagine o un file compresso. L'intestazione и invece alquanto piщ complessa. Vediamola in dettaglio.
I primi 4 bit contengono la versione del protocollo IP che и stato utilizzato per creare il datagram. Infatti, come spiegato nella prima parte di questo corso, il tutto funziona se e solo se tutti seguono le stesse regole alla lettera. D'altra parte le convenzioni, e di conseguenza i protocolli, seguono un processo di evoluzione, per cui un datagram creato con una versione piщ recente potrebbe creare problemi a un protocollo piщ vecchio se questi non avesse modo di accorgersene in tempo. I 4 bit successivi danno la lunghezza dell'intestazione misurata in parole da 32 bit. Questa и necessaria agli algoritmi usati per leggere il datagram (parsing algorithms). Dato che i campi dell'intestazione potrebbere non risultare un multiplo intero di 32, и necessario porre alla fine dell'intestazione un campo di riempimento. Inoltre il programma di ricezione ha bisogno di conoscere anche la lunghezza totale del datagram, cioи la lunghezza dell'intestazione piщ quella dell'area dati. Questa и memorizzata nei bit dal 16 al 31 inclusi, e il suo valore и espresso in ottetti, al contrario del precedente. Poichи il campo и lungo 16 bit, il datagram non puт essere piщ grande di 216 ottetti, cioи 65.535 byte.
Il campo tra la lunghezza dell'intestazione e quella totale del datagram identifica il tipo di servizio che va offerto al pacchetto, ed и formato da un campo di 3 bit che specifica l'importanza che va data al datagram, e da tre campi da 1 bit ciascuno che identificano il tipo di trasporto desiderato per questo pacchetto. Purtroppo questo campo non puт essere sempre preso in considerazione da tutte le reti, in quanto non sempre la rete fisica и in grado di soddisfare le richieste di prioritа e trasporto memorizzate in questo campo. Per cui esso viene considerato una sorta di raccomandazione alla rete, piuttosto che un vero obbligo. In ogni caso il campo di prioritа puт contenere valori da 0 a 7. Lo zero и il valore di base di un normale pacchetto, mentre il 7 rappresenta la richiesta di precedenza piщ elevata, e va usato per i datagram che contengono dati per il controllo della rete stessa. I tre bit relativi al tipo di trasporto servono a definire il livello di qualitа relativo al trasferimento del pacchetto. Se impostati a uno, essi richiedono rispettivamente: di evitare al massimo ritardi nel recapitare il pacchetto al destinatario, di fornire la massima capacitа di trasferimento, e di garantire un'elevata affidabilitа durante il trasporto. Ovviamente и estremamente difficile poter fornire tutti e tre questi servizi contemporaneamente. Spesso la rete non riesce a garantirne neanche uno solo.
I tre campi successivi vengono utilizzati nel meccanismo di frammentazione spiegato poco fa, e in particolare sono quelli che permettono all'host che riceve i vari frammenti di riassemblare il tutto per ottenere il datagram originario. Essi sono assolutamente necessari in quanto non и prevista alcuna comunicazione tra il mittente e il destinatario su come ricomporre il datagram, tanto piщ che la frammentazione finale puт essere il risultato di piщ frammentazioni successive. Inoltre i vari frammenti possono arrivare in qualunque ordine, dato che possono avere seguito cammini differenti. Dulcis in fundo, anche se l'intestazione di ogni frammento и ottenuta da quella del datagram originale, il quarto campo dell'intestazione di un frammento contiene la sua lunghezza totale, e non quella di tutto il datagram. Quest'ultima informazione deve essere calcolata dal destinatario in qualche modo. Ed ecco il perchй di questi tre campi.
Il primo campo serve a identificare univocamente il datagram ed и lungo 16 bit. Tutti i frammenti che appartengono a uno stesso datagram hanno lo stesso identificativo. Il secondo campo и una maschera di 2 bit che controlla il meccanismo di frammentazione. Il primo bit specifica se il datagram puт essere frammentato: se impostato a uno, la frammentazione non и permessa. Il secondo bit serve a marcare l'ultimo frammento. Vedremo tra un attimo a cosa serve. Il terzo campo contiene la posizione dei dati del frammento nel blocco originale di dati misurato in parole da 64 bit. Questo campo si chiama fragment offset. Per esempio, se un frammento ha un offset 7, vuol dire che il primo bit dei suoi dati corrisponde al quattrocentoquarantanovesimo bit dei dati del frammento originale, dato che 7 * 64 + 1 fa appunto 449. A questo punto и chiaro come si puт ottenere la lunghezza totale del datagram originario. Basta sommare l'offset e la lunghezza totale dell'ultimo frammento, riconoscibile grazie al secondo bit del campo di controllo.
Il campo successivo, posto a partire dal 64° bit dell'ntestazione, и lungo un byte e serve a stabilire quanto a lungo un datagram puт rimanere nella rete. И cioи il campo che specifica la scadenza di un datagram di cui avevamo accennato in precedenza. L'idea originaria era che tale campo contenesse il numero massimo di secondi che il pacchetto potesse restare nella rete. Tuttavia, data l'evidente difficoltа di sincronizzare gli orologi di tutti gli hosts e i gateway della rete, si и deciso di semplificare il meccanismo come segue: ogni gateway che processa il pacchetto decrementa il campo di uno quando questo arriva e memorizza il tempo di arrivo. Se il pacchetto non riparte subito ma rimane in attesa nel gateway, il valore di questo campo viene ulteriormente decrementato di una unitа per ogni secondo di attesa. Come il campo arriva a zero, il datagram viene cancellato dalla rete e un messaggio di errore viene rispedito al mittente.
Il campo seguente, lungo 8 bit, identifica il protocollo di alto livello utilizzato che ha generato i dati contenuti nel datagram, e definisce di fatto il loro formato. Ne riparleremo in seguito, quando vedremo i protocolli applicativi.
Abbiamo quindi un campo di controllo di 16 bit che serve a verificare l'integritа dell'intestazione, e che utilizza il meccanismo di checksum ben conosciuto nel mondo del software. In suo valore и la somma complementata a uno delle parole da 16 bit che compongono l'intestazione, addizionate con il metodo del complemento a uno.
Quindi vengono gli indirizzi IP del mittente e del destinatario, ognuno lungo 32 bit. Di tali indirizzi e del loro scopo abbiamo parlato esaustivamente nella seconda e terza parte di questo corso.
Per finire abbiamo un campo di lunghezza variabile che puт contenere varie opzioni, e quindi il campo di riempimento di cui abbiamo giа parlato. Queste opzioni non sono presenti in tutti i datagram e vengono usate prevalentemente nelle verifiche e nella identificazione dei problemi della rete.
Parliamo ora di due aspetti fin qui solo accennati: i meccanismi di instradamento dei pacchetti (routing) e la gestione degli errori. Iincominceremo 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.
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. 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, 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.
Se l’IP rappresenta il braccio del TCP/IP, il TCP ne rappresenta la mente. Il primo si limita a spedire rapidamente i dati che gli arrivano senza preoccuparsi troppo se qualcosa va male. Il secondo si occupa invece di controllare che l’informazione passatagli dai livelli superiori arrivi correttamente a destinazione. Insieme sono sicuramente una coppia molto affiatata.
In questo articolo useremo il termine applicazioni per indicare tanto i protocolli applicativi come FTP o SMTP, quanto i programmi applicativi veri e propri, salvo indicazione contraria. Indicheremo inoltre con il termine utente di un servizio colui che utilizza tale servizio, sia esso direttamente una persona, un’applicazione, o un protocollo. Per esempio, il TCP и un utente dell’IP.
C’и subito da dire due cose importanti sul TCP. La prima и che lo standard del TCP non definisce nй l’implementazione dello stesso, nй le modalitа con cui un’applicazione accede a i servizi di questo protocollo. Esso definisce solamente le caratteristiche di tali servizi, per cui si possono trovare molte differenti implementazioni del TCP, ognuna con la propria interfaccia applicativa. Per chi non programma ricordo che un’interfaccia applicativa o API (Application Programming Interface) non и altro che l’insieme delle funzioni, delle istruzioni, dei parametri e dei blocchi di controllo che vengono utilizzati dai programmatori per accedere ai servizi di un sistema. Per esempio, se ho un sistema di posta elettronica potrei definire un’API basata su due funzioni, una chiamata spedisci, e una chiamata ricevi . Per ogni funzione sarebbero poi da definire quali informazioni sono da passare al momento dell’utilizzo (parametri in ingresso), quali si ottengono una volta espletato il servizio (parametri di ritorno), eventuali codici di errore, e le regole di utilizzo delle singole funzioni. Il motivo che sta alla base della scelta di non standardizzare l’interfaccia con il TCP и che in molti casi questo protocollo и direttamente definito nel sistema operativo, o comunque fa parte del cosiddetto corredo di base di un sistema, per cui si и voluto evitare di forzare una sintassi che potesse essere in contrasto con quella nativa del sistema ospite. Il secondo punto fondamentale и che il TCP и stato definito per funzionare su un qualsiasi sistema di trasmissione dati a pacchetto, e non necessariamente solo sull’IP. Di fatto esso puт essere poggiato, per esempio, direttamente sopra una rete Ethernet senza bisogno di un livello Internet intermedio.
Ma qual и lo scopo del TCP nell’architettura internet? Il protocollo non fornisce le garanzie di affidabilitа e robustezza necessarie per implementare un sistema di trasmissione dati sicuro e di facile gestione. L’IP и inaffidabile e benchй schermi lo sviluppatore dalla conoscenza della rete fisica, fornisce ancora una visione di livello troppo basso del sistema di reti interconnesse. Questo vuol dire che l’IP и troppo complesso per essere utilizzato direttamente dalle applicazioni. Per avere un protocollo di trasmissione affidabile abbiamo bisogno di gestire tutte le possibili situazioni di errore, la duplicazione o la perdita dei pacchetti, la caduta delle connessioni o di un router, e via dicendo. Se le
applicazioni utilizzassero direttamente i servizi dell’IP, ognuna di esse dovrebbe implementare una serie alquanto complessa di algoritmi e servizi per tenere conto di tutto ciт. A parte il fatto che esistono relativamente pochi programmatori in grado di far questo fra gli svariati milioni di sviluppatori di applicazioni, nella maggior parte dei casi si tratterebbe di reinventare ogni volta la ruota. In generale questi problemi, seppure complessi, sono abbastanza standard, per cui si и pensato di poggiare sui sistemi di trasmissione a pacchetti un protocollo affidabile che potesse essere implementano da sviluppatori altamente specializzati, lasciando cosм agli altri la possibilitа di concentrarsi sulla logica applicativa piuttosto che sugli aspetti specifici della trasmissione dei dati a basso livello.
Vediamo allora quali sono le caratteristiche principali del TCP, eventualmente comparate a quelle dell’IP.
Innanzi tutto il TCP fornisce una visione dei dati di tipo a flusso (data stream), cioи i dati sono ricevuti in sequenza e nello stesso ordine con il quale sono stati trasmessi. A questo livello cioи, l’utente del TCP spedisce i dati come un singolo flusso di byte e nello stesso modo li riceve. Nell’IP avevamo invece la divisione dei dati i

Esempio