I Protocolli di Rete
Leo Liberti - Marzo 1999
Abstract
Quel che segue è una spiegazione ``informale'' del significato e
del funzionamento dei protocolli di rete appartenenti alla famiglia TCP/IP.
In teoria per capire quanto segue non ci dovrebbe essere bisogno di nessuna
conoscenza del concetto di rete, ma si dovrebbe avere qualche fondamento
(anche approssimativo) nel campo dei sistemi operativi e dei computer in
genere.
1. Introduzione
Per spedire dati da un computer all'altro, si usano vari protocolli di
rete, cioè vari ``intendimenti" tra colui che spedisce e colui che
riceve. La cosa più importante da capire è che ci sono diversi
livelli gerarchici di protocolli e su uno stesso livello gerarchico, protocolli
diversi.
Regola 1:
I dati vengono spediti in ``pacchetti" e non come un flusso unico
Questo per far sì che su un unico cavo possano dialogare più
computer senza interferenze.
Regola 2:
Ci sono 4 gerarchie fondamentali di protocolli
Ogni protocollo agisce sul pacchetto aggiungendo un ``header" e un ``trailer",
cioè dei dati all'inizio e alla fine del pacchetto. Il pacchetto
viene ``incapsulato" dal protocollo. I dati vengono incapsulati prima dal
livello più alto (di solito il quarto livello, in alcuni casi il
terzo), poi da quello immediatamente inferiore, fino al primo livello.
Questa gerarchizzazione dei protocolli serve ad astrarre i livelli di difficoltà
tecnica della comunicazione di rete. Se mando una e-mail non voglio sapere
se la riceve un Pentium con Win95, una AlphaStation con Linux, un Cray,
un telefonino cellulare o chissà quale altra diavoleria. E` necessario
perciò che il protocollo che si occupa della posta elettronica usi
un substrato di comunicazione ``capito" da tutti per spedire i messaggi.
Se supponiamo che "x" denoti il pacchetto da spedire, i dati
che vengono effettivamente messi sui cavi sono di questo tipo:
<H1><H2><H3><H4>"x"<T4><T3><T2><T1>
Dove Hn denota l'header dell'n-esimo livello gerarchico
di protocollo, e Tn ne denota il trailer.
2. Il primo livello: il livello fisico
Il primo livello è detto ``livello fisico". Queste regole servono
a gestire la trasmissione a livello di cavo. Immaginiamo un pacchetto di
dati che dev'essere spedito su un cavo. Diciamo una stringa di 30 bytes,
come ``Al mio babbo Internet non piace". I protocolli del livello fisico
si assicurano basilarmente che il pacchetto venga ricevuto dal computer
a cui era destinato, e che il pacchetto non venga spedito quando il cavo
è occupato da un altro pacchetto. Sappiamo che il protocollo fisico
è l'ultimo protocollo a gestire il pacchetto prima che esso venga
messo sui cavi. Dunque la stringa di cui sopra, quando giunge al livello
fisico, appare così :
<H2><H3><H4>
"Al mio babbo Internet non piace"
<T4><T3><T2>
Dopo l'azione del protocollo fisico esso appare così :
<Header del protocollo fisico>
<H2><H3><H4>
"Al mio babbo Internet non piace"
<T4><T3><T2>
<Trailer del protocollo fisico>
Due fra i più famosi protocolli del livello fisico sono: Ethernet
e PPP.
2.1 Ethernet
Il protocollo Ethernet viene spessissimo usato sulle reti di molti computer
(per esempio la Brent usa una rete Ethernet). In questo tipo di rete il
guaio che può succedere è che due computer tentino di spedire
un pacchetto allo stesso istante. Quando questo succede, l'interferenza
generata sul cavo viene intercettata da tutte le schede di rete (che funzionano
come prescritto dal protocollo Ethernet) che si bloccano immediatamente,
e ognuna aspetta un tempo casuale prima di riprendere a funzionare. La
probabilità di un blocco perpetuo esiste, ma è trascurabile.
Quando il pacchetto ``Al mio babbo Internet non piace", già incapsulato
dal 4o, 3o e 2o livello, arriva alla scheda di rete mittente, l'incapsulamento
aggiunge un header con su l'indirizzo della scheda di rete ricevente (e
un trailer con altri dati ``di servizio") e lo mette sul cavo. Tutte le
schede di rete sul cavo ``vedono" il pacchetto, ma solo quella con il numero
giusto lo legge. Va detto che c'è un authority centrale che regola
la produzione di schede di rete Ethernet e che assegna a ogni scheda di
rete fabbricata nel mondo un unico numero Ethernet.
2.2 PPP
PPP sta per ``Point to Point Protocol" e disciplina la trasmissione di
pacchetti su una linea telefonica (analogica o digitale). La differenza
fondamentale tra il PPP e l'Ethernet è che le linee telefoniche
vengono usate per connettere due computer soltanto. E` ovvio, per ogni
pacchetto spedito, chi sia il mittente e chi il ricevente, quindi il PPP
si occupa soltanto di assicurarsi che i due computer non spediscano pacchetti
nello stesso istante. Questo, by the way, è il protocollo che usi
tu per collegarti a Internet. All'altro capo del filo telefonico c'è
un modem e un computer (che capisce il PPP) attaccato a sua volta a una
rete Ethernet attaccata a sua volta al resto di internet, tramite un altro
cavo telefonico su cui ``si parla" PPP.
3. Il secondo livello: il livello IP
``IP" è un acronimo di ``Internet Protocol" ed è il protocollo
che ``unisce" tutte le reti fisiche, ignorandone le proprietà intrinseche,
e fa in modo che ogni interfaccia di rete su Internet (sia questa interfaccia
una scheda di rete, un modem, una porta seriale, parallela, un ponte radio
o altre cose ancora) abbia un unico numero IP. In questo modo ogni computer
può raggiungere ogni altro: basta che ci sia fra i due una connessione
di qualunque tipo e che i due computer ``parlino" l'IP. Nota bene: il
numero IP non viene assegnato al computer, bensì all'interfaccia
di rete. Questo è un punto importante: significa che ad un solo
computer possono essere associati diversi numeri IP. Se un computer è
collegato a due reti diverse, esso avrà due interfacce di rete e
quindi due numeri IP. I computer che collegano due (o più) reti
diverse sono alla base del funzionamento del protocollo IP e vengono chiamati
router o gateway.
Il protocollo IP, come tutti i protocolli (eccettuati alcuni protocolli
di comunicazione a livello fisico), è implementato a livello di
software. Ciò significa che in ogni sistema operativo capace di
gestire comunicazioni di rete ci sono dei ``filtri" IP che ricevono i pacchetti
di dati dai protocolli superiori e incapsulano il pacchetto con il numero
IP dell'interfaccia mittente e il numero IP dell'interfaccia ricevente
prima di passare il pacchetto al protocollo fisico. Così , il nostro
pacchetto ``Al mio babbo Internet non piace", viene trasformato da
<H3><H4>"Al mio babbo Internet non piace"<T4><T3>
a
<IP_mittente IP_ricevente Parametri_di_servizio>
<H3><H4>"Al mio babbo Internet non piace"<T4><T3>
<Trailer IP>
Un numero IP è composto da quattro numeri compresi tra 0 e 255 separati
da punti (also known as ``dotted quad notation"), per esempio 130.192.238.143,
18.124.38.1, 42.0.13.0, eccetera. Generalmente, a ogni numero IP corrisponde
un'interfaccia di rete. A questa regola fanno eccezione:
-
i numeri 0.x.x.x (cioè 0. seguito da qualsiasi numero)
-
i numeri 127.x.x.x
-
i numeri 255.x.x.x
-
alcuni altri numeri riservati
Di queste eccezioni, la più interessante è la 127.x.x.x che
si riferisce sempre al proprio computer. Più in particolare, 127.0.0.1
è un'interfaccia di rete presente in tutti i sistemi operativi atti
a gestire il protocollo IP e indica il ``loopback", cioè il proprio
computer (spesso chiamato localhost).
3.1 Significato del numero IP
Alcuni numeri non indicano un'interfaccia di rete bensì il ``segmento
di rete" con cui si vuole raggruppare un insieme di interfacce di rete.
Solitamente viene comodo riunire un'unica rete fisica (come i computer
collegati ad un unico segmento di cavo Ethernet) in un'unica ``sottorete"
IP. Il numero di interfacce di rete presenti sulla sottorete viene specificato
per mezzo del numero di ``netmask": supponendo che il numero di netmask
sia a.b.c.d, il numero di numeri IP facenti parte della sottorete è
dato da
(255.255.255.256 - a.b.c.d) |
|
dove l'operazione di sottrazione è effettuata componente per componente.
Per una rete con 16 numeri IP il netmask sarà di 255.255.255.240,
perché 256-240=16. Attenzione: questa rete non potrà ospitare
che 14 interfacce di rete, perché dei 16 numeri IP uno indica la
rete, ed è sempre il più basso, ed uno l'indirizzo di broadcast
(cioè un indirizzo IP a cui tutte le interfacce dovrebbero rispondere),
che è il più alto.
Facciamo un esempio. Le reti più comuni hanno 256 numeri IP (e
hanno quindi netmask=255.255.255.0) di cui il più basso (quello
che termina per .0) è riservato alla rete e quello più alto
(quello che termina per .255) è riservato al broadcast. Gli altri
254 indirizzi sono assegnabili. Si potrà quindi avere 204.135.66.0
(numero di rete), 204.135.66.1 fino a 204.135.66.254 (assegnabili) e 204.135.66.255
(broadcast). Un esempio un pò più complicato potrebbe essere
una rete con 24 numeri IP, con numero di rete 200.200.200.16, netmask 255.255.255.232,
numeri assegnabili 200.200.200.17-200.200.200.38 e broadcast 200.200.200.39
.
3.2 Funzionamento del protocollo IP
Come fa il protocollo IP a ``recapitare" un pacchetto ad un'interfaccia
di rete che magari si trova dall'altra parte del globo a molti reti fisiche
di distanza? Il segreto sta in particolari macchine che uniscono due o
più reti e quindi passano il pacchetto nella direzione giusta. Ogni
interfaccia di rete conosce ``personalmente" i computer presenti sulla
sua sottorete (nel senso che può recapitare i pacchetti direttamente)
e spedisce ogni altro pacchetto al gateway della sottorete (si capisce
che ogni sottorete deve avere almeno un gateway. Se sono presenti due o
più gateway ognuno di questi deve conoscere la topologia delle reti
vicine, per sapere dove inoltrare i pacchetti), che lo passa al gateway
della rete vicina e così via, finché il pacchetto arriva
a destinazione. Vi sono ovviamente dei casi in cui la scelta del gateway
non è obbligata, e in quei casi si implementano degli algoritmi
di routing che scelgono il gateway più appropriato a seconda dell'indirizzo
IP di destinazione scritto sul pacchetto.
Una delle proprietà del protocollo IP è che quasi nessun
gateway è cruciale alla rete, perché in genere c'è
più di una strada da ogni punto a ogni altro: questo fa sì
che le reti IP siano quasi immuni alle rotture dei singoli computer. Può
succedere che si creino delle strade circolari, che terminano in un gateway
già percorso. Gli algoritmi di routing più efficienti ne
tengono conto e respingono il pacchetto che hanno già visto. C'è
comunque un modo sicuro per evitare che un pacchetto giri indefinitamente:
il TTL (time to live). Ogni pacchetto IP, quando viene spedito, viene dotato
di un contatore detto TTL che viene decrementato ogni volta che il pacchetto
passa da un gateway. Se il TTL raggiunge zero significa che probabilmente
il pacchetto è finito in un circolo, o il computer che doveva raggiungere
non è operativo, o altri errori non reparabili. Il gateway a cui
giunge un pacchetto con un TTL=0 non lo inoltra ma lo distrugge, inviando
al mittente un pacchetto di notifica dell'errore.
3.3 Possibili errori
Il sintomo più tipico di un errore al livello del protocollo IP
è dato da una connessione che improvvisamente cade o che addirittura
non si verifica. Spesso la causa è dovuta a un gateway tra i due
computer comunicanti che funziona in modo difettoso. Abbiamo visto che
se il gateway non funziona del tutto spesso il protocollo IP riesce a trovare
un'altra strada. Ma quando il gateway funziona male allora il protocollo
IP fallisce. Solitamente un gateway funziona male per colpa dei suoi amministratori
(tipico caso di errore umano). Recentemente mi è capitato di vedere
un pacchetto bloccato per sempre fra due gateway che se lo palleggiavano.
Se succede questo vuol dire che l'amministratore è un idiota completo.
4. Il terzo livello: Il livello di connessione
In pratica il protocollo IP garantisce un modo per arrivare da un punto
all'altro di Internet. I protocolli del livello di connessione garantiscono
un ``flusso virtuale" continuo di dati, simulando una connessione diretta
da un computer all'altro. Essi si occupano perciò, soprattutto,
di correggere gli errori e di mantenere un contatto con il computer remoto.
I protocolli di questo livello più usati su Internet sono il TCP
(transmission control protocol), UDP (user datagram protocol) e ICMP (Internet
control message protocol). Di questi, solo il primo è in realtà
orientato alla connessione, nel senso che simula un flusso continuo di
dati. Il secondo garantisce solo la correzione degli errori e il fatto
che l'ordine dei pacchetti spediti venga mantenuto fino alla ricezione
(si noti che proprio perché il protocollo IP non garantisce nulla,
se non l'instradamento del pacchetto, una successione di pacchetti 1 2
3 4 può venire ricevuta come 4 1 3 2) e il terzo è un protocollo
``di servizio", usato per esempio nella notifica della distruzione di un
pacchetto per TTL=0, e messaggi simili. In questa sede ci occuperemo solo
del protocollo TCP perché è di gran lunga il più usato.
Il nostro pacchetto di esempio, ``Al mio babbo Internet non piace",
viene così trasformato. Da:
<H4>"Al mio babbo Internet non piace"<T4>
a
<Header TCP/UDP/ICMP>
<H4>"Al mio babbo Internet non piace"<T4>
<Trailer TCP/UDP/ICMP>
4.1 Possibili errori
Vi è una notevole discrepanza di principi tra il protocollo IP (che
deve mettere in comunicazione due computer, anche a costo di fare errori
nella trasmissione) e il protocollo TCP, che deve simulare una connessione
senza errori nè interruzioni. Per questo, su linee particolarmente
disturbate possono avvenire comunicazioni lentissime, o, frequentemente,
mancate chiusure di comunicazione. Su un protocollo non orientato alla
connessione, come l'IP, la chiusura è semplice: quando non si ricevono
più pacchetti la comunicazione si chiude. Su un protocollo come
il TCP, invece, entrambi i comunicanti devono venire notificati della chiusura,
il che vuol dire che il computer che propone la chiusura deve mandare un
pacchetto CLOSE e l'altro computer, prima di chiudere, deve notificare
un ACK (acknowledgement) di avvenuta ricezione del CLOSE. Se viene perso
il pacchetto CLOSE, poco male: dopo un tempo di timeout, non avendo ricevuto
la risposta ACK, il computer che vuole proporre la chiusura rispedisce
il pacchetto CLOSE. Ma se viene perso l'ACK che succede? Il computer che
ha mandato l'ACK ha già chiuso la connessione, e il computer che
aveva mandato il CLOSE, non ricevendo l'ACK, rispedisce il CLOSE, ma trova
la connessione già chiusa e quindi non riceve mai l'ACK e non riesce
mai a chiudere. Questo viene spesso chiamato ``il problema dei due eserciti",
per analogia al seguente problema. Un esercito, i Neri, si trova in una
valle, e sulle cime opposte si trovano i Rossi, divisi dalla vallata. Le
due falangi Rosse, unite, vincerebbero, ma separate no. Inoltre la loro
unica possibilità di comunicare è di mandare un corriere
attraverso la valle, che però potrebbe essere catturato dai Neri.
Ora, come fanno i due comandanti delle falangi Rosse a mettersi d'accordo
per attaccare in contemporanea? La falange Rossa di destra spedisce un
messaggio via corriere che dice ``Attacco martedì alle dieci", e
attende ovviamente una risposta, perché se il corriere venisse preso
la battaglia sarebbe persa. La falange Rossa di sinistra, se riceve il
messaggio, risponde ``OK" via corriere, ma attende una risposta, perché
se l'''OK" non giungesse a destinazione la battaglia sarebbe persa. La
destra manda un ``ricevuto" e ovviamente attende una risposta, e così
via. In realtà, senza avere la sicurezza totale del messaggio, la
connessione non può mai essere chiusa senza potenziali errori.
La mancata chiusura di una connessione può essere molto fastidiosa,
perché chi chiude non sa se la chiusura è avvenuta, e quindi
si trova in situazione di stallo e non sa (ad esempio) quando può
spegnere il modem, perché ignora se la mancata chiusura derivi da
una comunicazione ancora in corso o da un errore del tipo descritto sopra.
5. Il quarto livello: I protocolli utente
Eccoci arrivati all'ultimo livello di astrazione della gerarchia delle
comunicazioni di rete: i protocolli utente. Ormai abbiamo un substrato
che, sebbene non perfetto, ci permette di comunicare con qualsiasi computer
su Internet come se fosse davanti a noi. Possiamo tranquillamente ignorare
dove si trovi la nostra controparte, e possiamo anche fingere di avere
un filo diretto che la collega a noi. Tutto quello che rimane da fare,
ora, è di spedire i dati. E proprio di questo si occupano i protocolli
utente. L'utilità di un quarto livello di astrazione è che
si può ottimizzare il tempo e la qualità della connessione
conoscendo a priori quale tipo di dati si intende spedire: posta elettronica,
newsgroups, WWW... e quindi per ogni tipo di dato si può creare
un protocollo utente. Cito qui solo i più diffusi:
-
SMTP (Simple Mail Transfer Protocol) serve a inoltrare la posta elettronica.
Quando si spedisce una e-mail il protocollo SMTP aggiunge un header con
l'indirizzo del mittente e del ricevente, e passa i pacchetti al protocollo
TCP, che crea una connessione usando il protocollo IP che a sua volta si
basa sui protocolli fisici delle varie reti attraversate.
-
POP (Post Office Protocol) serve a recuperare la posta da un server di
posta elettronica. Questo protocollo serve più che altro quando
il computer che deve recuperare la posta non è costantemente in
rete (come nel caso di un collegamento temporaneo con un Internet Service
Provider (ISP). Un computer costantemente in rete è tranquillamente
raggiungibile con l'SMTP.
-
HTTP (HyperText Transfer Protocol) è il protocollo più recente
e più usato di Internet, quello che serve a ``navigare" in Internet.
E` un protocollo specializzato nel trasferire file di (iper-)testo in modo
che l'utente possa cominciare a leggerne i contenuti anche se la connessione
non è ancora stata chiusa. Inoltre, poiché chi naviga frequentemente
cambia pagina, le connessioni sono numerose e molto brevi, in modo da poter
interrompere più facilmente. Poiché le connessioni sono effimere,
il problema dei due eserciti viene minimizzato richiedendo che non si attenda
l'ACK dopo il CLOSE ogni volta che una connessione viene interrotta manualmente
dall'utente.
-
FTP (File Transfer Protocol) serve a trasferire files di qualsiasi tipo.
Distingue tra files di testo e files ASCII. Qui la connessione è
molto importante.
-
NNTP (Network News Transfer Protocol) molto simile all'SMTP, serve a trasferire
le lettere dei newsgroups, ma dispone di funzioni per recuperare i campi
``Subject:" delle e-mail per compilare la lista dei messaggi disponibili
nel newsgroup.
-
TELNET serve ad aprire una console remota virtuale interattiva (tipo una
finestra DOS) sul computer remoto. La interattività richiede che
ogni tasto premuto (cioè ogni byte) venga spedito in un pacchetto
separato, e quindi su connessioni lente o difficoltose il collegamento
diventa molto farraginoso.
-
DNS serve, dato un nome di un computer, a recuperarne il numero IP. E`
notorio che noi umani ci riferiamo ai computer con nomi tipo lx05.dm.unito.it
o brumaio.csea.torino.it o www.lwn.net. Questi si chiamano nomi di dominio
(DNS sta per Domain Name System), ma vanno tradotti in numeri IP prima
di intraprendere una connessione. Il protocollo DNS serve per l'appunto
a ``risolvere" i nomi in numeri. Il DNS è un grosso database distribuito.
Dovendo risolvere il nome ``lx05.dm.unito.it", prima di tutto ci rivolgiamo
ai ``root-servers", gestori del dominio ``root" (che sta sopra a tutti
i dominii), di cui sappiamo i numeri IP (sono pubblici) e gli chiediamo
``qual è il nameserver del dominio it?", ricevendo un numero IP
come risposta. Ora ci rivolgiamo a questo numero chiedendo ``qual è
il nameserver del dominio unito?", ricevendo un secondo numero IP, a cui
chiediamo ``qual è il nameserver del dominio dm?", ricevendo un
terzo numero IP, a cui chiediamo ``qual è il numero IP del computer
lx02?", e voila!, abbiamo il numero.
6. Conclusione
Seguiamo ora, passo passo, cosa succede quando spedisco da liberti@dm.unito.it
a liberti@login.it il messaggio ``Al mio babbo Internet non piace". Verosimilmente
userò un mail composer per scrivere la stringa ``Al mio babbo Internet
non piace". Poi invierò il messaggio. Il primo filtro usato è
il protocollo utente SMTP, che attacca l'header
<
>From diliberti@dm.unito.it Wed Mar 10 18:50:24 1999 +0100
Status:
X-Status:
X-Keywords:
Date: Wed, 10 Mar 1999 18:49:43 +0100 (CET)
From: Leo Liberti <diliberti@dm.unito.it>
X-Sender: diliberti@triton.leo.it
To: gianfranco.diliberti@login.it
cc: diliberti@login.it
Subject: prova
Message-ID: <Pine.LNX.4.04.9903101849270.1026-100000@triton.leo.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
>
poi viene il corpo del messaggio, cioè la stringa
"Al mio babbo Internet non piace"
e poi il trailer, che in questo caso è un punto su una linea vuota
<
.
>
Successivamente il messaggio
>From diliberti@dm.unito.it Wed Mar 10 18:50:24 1999 +0100
Status:
X-Status:
X-Keywords:
Date: Wed, 10 Mar 1999 18:49:43 +0100 (CET)
From: Leo Liberti <diliberti@dm.unito.it>
X-Sender: diliberti@triton.leo.it
To: gianfranco.diliberti@login.it
cc: diliberti@login.it
Subject: prova
Message-ID: <Pine.LNX.4.04.9903101849270.1026-100000@triton.leo.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Al mio babbo Internet non piace
.
viene passato al protocollo TCP, che lo spezzetta in pacchetti, li numera,
li ordina, li dota del codice necessario al riconoscimento e alla correzione
degli errori, trova il nome del computer sulla rete a cui va fatta la connessione
e lo immagazzina su ogni pacchetto. I pacchetti passano poi alla gestione
del protocollo IP, che li dota dei numeri IP del mittente e del ricevente,
nonché del primo gateway da contattare e dei parametri di servizio
tipo il TTL, e da ultimo passano al protocollo fisico, sia esso Ethernet,
PPP, o altro.
All'arrivo, i pacchetti incapsulati nei protocolli vengono ``decapsulati",
prima dal protocollo fisico, poi dall'IP, poi dal TCP (che li ordina e
richiede nuovamente gli eventuali pacchetti erronei) e infine dall'SMTP,
cosicché l'utente finale legge sul monitor il messaggio ``sgusciato"
"Al mio babbo Internet non piace"
File translated from TEX by TTH,
version 1.1.