Il protocollo TCP/IP Transmission Control Protocol
Internet Protocol
Il TCP/IP Internet Protocol Suite è il nome dato ad un set di protocolli sviluppato in seno al DoD degli Stati Uniti (Department of Defense) dal DARPA (Defense Advanced Research Project Agency). All'epoca esisteva una sola rete, ARPA-net, che connetteva solo pochi computer a livello universitario.
Tutto nacque dall'esigenza di connettere insieme più reti possibili già esistenti, ma la comunicazione tra due utenti posti in posizione reciprocamente remota era ostacolata dal dover utilizzare una serie di reti diverse sia dal punto di vista dei protocolli che dai mezzi di trasporto fisico. L'idea era quindi di realizzare una comunicazione dati, in una rete composta di reti, perpetuata in modo da mascherare i dettagli hardware con cui erano realizzate le singole reti. Stabilire quindi una sorta di circuito virtuale tra due utenti che comunichino tra loro convinti di essere connessi direttamente, senza preoccuparsi delle particolari realizzazioni hardware che stiano sfruttando per fare ciò. Da tutto ciò nacque la rete delle reti (Internet).
Il nome TCP/IP proviene dai protocolli basilari sui quali si impernia tutta la suite: un servizio di trasporto orientato alla connessione (TCP) e un servizio a livello di rete senza connessione (IP). Nato dunque in ambito militare agli inizi degli anni Ottanta il TCP/IP raggiunge la piena maturità con il suo ingresso all'università, quando il DARPA ne promosse la diffusione tra i laboratori di ricerca universitaria grazie ad una implementazione a basso costo per il Berkeley UNIX.
TCP/IP è un modello a quattro strati: fisico, rete (IP), trasporto (TCP) ed applicativo. L'architettura somiglia fino a un certo punto al famoso modello a sette strati OSI.
Lo schema seguente classifica secondo la stratificazione OSI le principali applicazioni (per Application Layer) e i principali protocolli (per gli altri layer) di TCP/IP che saranno discussi in maggiore dettaglio nel seguito del capitolo.
Principali moduli e protocolli del TCP/IP (classificati secondo la stratificazione OSI)
I protocolli della suite TCP/IP sfruttano una tecnica nota come "encapsulation" cioè, quando i protocolli lavorano a strati sovrapposti (TCP-> IP-> NAL), ogni strato successivo aggiunge informazioni (header) in testa al pacchetto generato dal precedente, creando un nuovo pacchetto che lo incapsula.
L'incapsulamento progressivo continua fino a quando si giunge a livello della rete fisica e le informazioni vengono trasmesse. All'altro estremo, la stazione ricevente esegue l'operazione inversa, sbucciando il pacchetto come se fosse una cipolla a mano a mano che questo sale i vari strati del protocollo, fino a che restano unicamente i dati originali che dovevano essere consegnati all'applicazione.
Il livello fisico NAL (Network Access Layer)
In TCP/IP il livello fisico corrisponde ai primi due livelli dello stack OSI. Lo standard parte da un presupposto fondamentale: implementazione del livello fisico indipendente dai livelli superiori. La conseguenza è porre il gestore della rete nella possibilità di decidere quale mezzo fisico usare per la trasmissione, svincolandolo dal protocollo, rendendo il TCP/IP indipendente dal mezzo di trasmissione utilizzato: Ethernet, Token-Ring, ISDN, X.25, satellite, etc..
Qui di seguito viene riportato il formato standard di una trama Ethernet per fornire un esempio di formato di un protocollo NAL.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet destinati address (first 32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet dest (last 16 bits) |Ethernet source (first 16 bits)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet source address (last 32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP header, then TCP header, then data | | ..... | | | | end of data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethernet Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Formato semplificato di una trama Ethernet
Il livello di rete (Internet Protocol)
IP Address
Ogni standard di rete locale prevede un suo metodo specifico per indirizzare una propria macchina. Per superare questa incompatibilità si è pensato di fornire un identificativo univoco ad ogni macchina della rete, o meglio, ad ogni connessione rete macchina (per capirci: una macchina con due schede Ethernet avrà due IP number distinti, uno per scheda). Questo identificativo è il cosiddetto Indirizzo Internet (IP Number), si tratta di un sistema di indirizzamento a 32 bit che comprende un identificativo per l'host e uno per la rete.
Ci sono cinque forme, classi di indirizzi Internet, contraddistinti da una specifica sequenza di bit iniziale, ve ne sono tre primarie: A, B, C e due di servizio per utilizzi particolari: D, E (si veda la tabella seguente). La classe A è caratterizzata da un numero di rete a 7 bit e un numero di host a 24 bit, la classe B rispettivamente 14 e 16 mentre la classe C 21 e 8 bit.
Chiaramente la classe viene scelta in base al numero di host da collegare alla rete, rispettivamente 224,216 e 28.
Le classi A e B avendo spazio per moltissimi host (224 e 216) si prestano facilmente ad essere ulteriormente suddivise virtualmente in sottoreti. Per gli indirizzi di classe B e pratica comune usare il terzo ottetto per identificare la sottorete e il quarto per identificare l'host nella sottorete stessa. Ad esempio, una università potrebbe dotarsi di un indirizzo di classe B (la parte ID rete identificherebbe l'università nel suo complesso). Quindi potrebbe suddividere la propria rete per facoltà e dipartimenti a cui assegnare uno specifico indirizzo nei termini del terzo ottetto dell'IP address (i primi due sono già usati per identificare l'università stessa). Da notare che necessariamente se si usano 8 bit, non si possono avere più di 254 sottoreti. Ogni macchina di un dipartimento sarà poi contraddistinta da un indirizzo come quarto ottetto dell'IP address.
Con un IP address in classe C si possono avere al massimo 254 (28) host ed è quindi abbastanza limitata e scomoda la sua suddivisione in sottoreti, è quindi adatto a sistemi che non dispongono di molti host da collegare.
Gli indirizzi IP sono comunemente scritti, secondo la cosiddetta notazione dotted decimal, con i quattro ottetti convertiti in decimale e separati dal carattere punto. I primi tre bit di un indirizzo sono usati per riconoscere la sua classe, ma in pratica si possono distinguere anche così: gli indirizzi di classe A sono quelli in cui il primo ottetto e' compreso tra 0 e 127, quello di classe B tra 128 e 192, mentre quelli in classe C hanno il primo ottetto compreso tra 192 e 223.
C'è inoltre da sottolineare che è solo la parte rete dell'indirizzo che viene usata per instradare il traffico dati: essa permette ad una stazione di determinare se il pacchetto sia destinato alla stessa rete o ad una rete interconnessa. Per instradare i pacchetti ad una rete interconnessa il modulo IP impiega una tabella di routing contenente gli indirizzi di opportuni gateway. Per pacchetti destinati alla rete locale l'IP chiama invece l'ARP per poter mappare l'IP address nell'indirizzo hardware corrispondente (48 bit), detto anche indirizzo MAC, ma ciò sarà discusso in seguito.
Alcuni indirizzi, per ciascuna classe, sono stati riservati (cioè non assegnati a nessun host su internet) per la realizzazione di reti aziendali private (intranet), per maggiori dettagli si veda il paragrafo "Grandi reti aziendali e Internet".
Classe |
Header |
ID rete |
ID host |
Classe A |
0 |
7 bit |
24 bit |
Classe B |
10 |
14 bit |
16 bit |
Classe C |
110 |
21 bit |
8 bit |
Classe D |
1110 |
Indirizzo multicast |
|
Classe E |
11110 |
Riservato |
Le classi degli indirizzi Internet. Le prime tre sono le primarie
Il protocollo IP
Lo strato Internet fornisce agli strati superiori la trasparenza delle diverse implementazioni delle reti fisiche grazie a tre tipi di funzionalità. Un servizio di spedizione indipendente dall'hardware, un sistema di indirizzo universale, ed un metodo di instradamento dei dati attraverso le reti fisiche.
Complessivamente IP è uno strato molto povero con delle funzionalità alquanto limitate, ad esempio: non effettua nessun controllo sulla integrità dei dati ricevuti e non si preoccupa di ritrasmettere eventuali pacchetti andati smarriti. Tutto questo sarà compito del livello trasporto TCP che chiaramente dovrà essere molto sofisticato. Per quale motivo si è scelta questa opportunità di lavorare ? Semplice, lo strato IP è presente in tutti i nodi (gateway) attraversati da un pacchetto durante una comunicazione, mentre lo strato TCP è presente solo nei due host sorgente e destinazione, conviene quindi implementare solo qui le operazioni più complesse che richiedono un maggior lavoro di elaborazione e quindi un overhead per il sistema.
Il livello IP dispone solamente delle primitive Send, con la quale un processo notifica l'intenzione di trasmettere dei dati, e Deliver, con la quale IP avverte un processo dell'arrivo di un pacchetto ad esso destinato.
Riassumendo si può dire che il servizio di spedizione dei pacchetti è di tipo connectionless (comune denominatore dei protocolli Internet tranne TCP), così facendo non servono primitive per instaurare ed abbattere un circuito virtuale fra due host (come nel caso connection oriented). L'essere senza connessione rende però intrinsecamente poco affidabile la spedizione datagram, sarà compito dei protocolli superiori (TCP appunto) di assicurare l'affidabilità necessaria.
In trasmissione un programma applicativo prepara i dati e li invia al protocollo di livello trasporto (TCP, UDP o altro) che a sua volta prepara il datagram e lo consegna al protocollo di rete (IP), fornendogli con esso le seguenti informazioni:
- l'indirizzo Internet di destinazione (IP Address);
- il proprio codice identificativo, per permettere all'IP in ricezione di mandare il datagram al giusto protocollo di livello trasporto (Si veda la tabella seguente);
- alcuni attributi facoltativi (ad esempio un grado di precedenza) specificati raramente;
- il datagram-lifetime o il time-to-live, con un routing di tipo dinamico può accadere che un datagram circoli indefinitamente per la rete. Per evitarlo si assegna ad un datagram un lifetime (tempo di sopravvivenza). Quando termina questo tempo, il datagram viene scartato e si rinuncia a tentare di consegnarlo. Il lifetime è più comodamente espresso in numero di hops o salti massimi effettuabili. Ad ogni attraversamento di nodo il lifetime viene decrementato di una unità.
Il protocollo IP provvede quindi ad instradare il datagram verso il gateway di destinazione.
Si vedano in dettaglio le operazioni effettuate su un datagram, nell'attraversamento di un nodo (gateway):
- controllo sulla validità dell'header IP e del tempo di vita (lifetime). Da notare che questi sono gli unici due controlli effettuati a livello IP. Non esiste un controllo CRC effettuato sui dati trasmessi;
- operazione di routing per determinare l'indirizzamento alla rete successiva. Tutti i gateway devono avere una tabella di intradamento contenente le informazioni sulle possibili destinazioni. Per limitare le dimensioni delle tabelle si ricorre all'esame del solo indirizzo di rete e non a quello degli host;
- frammentazione del datagram se necessaria. La frammentazione avviene quando il datagram viene originato da una rete locale che supporta una misura di trame superiore a quella della stazione ricevente;
- ricostruzione dell'header IP. Decremento del time-to-live, inserimento informazioni frammentazione, ricalcolo del CRC;
- costruzione header interfaccia con la rete (Ethernet, Token-Ring, etc.);
- datagram posto in coda di trasmissione.
Quando il datagram giunge a destinazione allora IP provvede, dopo averlo eventualmente riassemblato, ad inviarlo al giusto protocollo di livello trasporto (TCP, UDP, SMTP o altro) in base al codice di protocollo specificato nell'header.
Routing Table: Destination Gateway Flags Ref Use Interface ---------------------- ---------------------- ----- ----- ------- --------- localhost localhost UH 0 3262768 lo0 leila dei2514.dei.unipd.it UGHD 0 2 147.162.96.0 manuela_hyde UG 0 101833 147.162.97.0 arianna_hyde UG 0 23321 147.162.156.0 dei-cisc.dei.unipd.it UG 0 0 147.162.9.0 dei-cisc.dei.unipd.it UG 0 0 SLC-net maya_hyde.dei.unipd.it UG 0 2720 Dei-network marina U 3 161916 le0 147.162.12.0 marina_hyde U 2 151892 le1 147.162.121.0 marina_studio U 2 71401 qe1 Classic-Net marina_q U 2 63932 qe2 BASE-ADDRESS.MCAST.NET marina U 3 0 le0 default dei-cisc.dei.unipd.it UG 0 370735Esempio di Routing. Table (prodotta con il comando netstat di Unix) che evidenzia il Gateway intermedio a cui inviare un certo datagram indirizzato a Destination attraverso la scheda di rete, montata sulla macchina locale, indicata in Interface
ID |
Protocol |
Description |
0 |
IP |
# internet protocol, pseudo protocol number |
1 |
ICMP |
# internet control message protocol |
3 |
GGP |
# gateway-gateway protocol |
6 |
TCP |
# transmission control protocol |
8 |
EGP |
# exterior gateway protocol |
12 |
PUP |
# PARC universal packet protocol |
17 |
UDP |
# user datagram protocol |
20 |
HMP |
# host monitoring protocol |
27 |
RDP |
# "reliable datagram" protocol |
Esempi di valori decimali possibili (ID) usati dallo strato IP per identificare da quale protocollo arriva e a quale protocollo passare il datagram in esame
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destinati Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TCP header, then data ...... | | |Formato semplificato della trama IP
Il protocollo ARP (Address Resolution Protocol)
Per instradare pacchetti destinati alla rete locale, IP chiama l'ARP per poter mappare un IP address nell'indirizzo hardware corrispondente.
La mappatura funziona in questa maniera: ogni stazione di rete prende una tavola e mappa in essa gli indirizzi IP sull'indirizzo Ethernet corrispondente. Quando una stazione di una rete è pronta per mandare un pacchetto IP sull'Ethernet controlla prima la sua ARP Table. Se non viene trovato l'indirizzo di destinazione viene creato un pacchetto di richiesta ARP contenente l'indirizzo IP e viene spedito a tutte le stazioni sull'Ethernet. Ovviamente questo pacchetto dovrà essere di tipo "broadcast", cioè indirizzato a tutte le stazioni connesse sulla rete locale (E' convenzione indicare l'indirizzo di destinazione 255.255.255.255 nei pacchetti "broadcast" in modo tale che ogni stazione capisca, analizzando l'indirizzo di destinazione, che non è un normale pacchetto dati).
La stazione interessata dalla richiesta è obbligata a rispondere con l'invio di un pacchetto di risposta ARP contenente il proprio indirizzo hardware MAC, pacchetto che è leggibile da ogni stazione in modo tale che queste possano all'occorrenza aggiornare la loro ARP table.
Una volta che è stata trovata l'esatta mappatura il pacchetto originale IP può essere spedito in maniera appropriata. E' anche prevista una procedura ARP inversa, RARP, che permette alle stazioni di trovare il loro indirizzo Internet (IP) conoscendo solo il proprio indirizzo hardware MAC.
Va prestata molta attenzione al fatto che ogni scheda Ethernet nasce con un proprio indirizzo fisico (o indirizzo MAC) di 48 bit già impostato dalla fabbrica, indirizzo che è assolutamente unico tanto è vero che ogni costruttore di controller Ethernet deve registrarsi presso una banca dati centrale della IEEE per essere sicuro di assegnare indirizzi fisici che non si sovrappongano a quelli di altri costruttori. Generalmente i primi 3 byte indicano il codice del costruttore e i restanti sono un numero progressivo per ciascun controller prodotto dallo stesso costruttore.
Net to Media Table Device IP Address Mask Flags Phys Addr ------ -------------------- --------------- ----- ----------------- qe1 hp5 255.255.255.255 08:00:09:3d:4e:98 le0 arianna_hyde 255.255.255.255 08:00:20:10:f8:62 le0 maya_hyde.dei.unipd.it 255.255.255.255 08:00:20:12:60:f7 le0 mango.dei.unipd.it 255.255.255.255 08:00:20:04:b1:5a le0 dei-cisc.dei.unipd.it 255.255.255.255 aa:00:04:00:3f:97 le0 dei2514.dei.unipd.it 255.255.255.255 00:00:0c:3b:e5:62 le0 marina 255.255.255.255 SP 08:00:20:1c:0c:1b le0 marisa.dei.unipd.it 255.255.255.255 00:c0:da:01:32:a0 le1 marina_hyde 255.255.255.255 SP 08:00:20:1c:0c:1b qe1 marina_studio 255.255.255.255 SP 08:00:20:1c:0c:1b qe2 marina_q 255.255.255.255 SP 08:00:20:1c:0c:1b qe1 147.162.121.18 255.255.255.255 08:00:09:3d:4e:58 qe1 147.162.121.21 255.255.255.255 08:00:09:3d:4e:f8Esempio di ARP Table (prodotta con il comando netstat di Unix) che evidenzia l'associazione tra un nome mnemonico o IP Address e il corrispettivo indirizzo fisico (Phys Addr). La colonna Device indica quale delle schede di rete installate sulla macchina (generalmente indicate come le0, le1, qe0, qe1 etc.) è connessa verso la sottorete che contiene l'indirizzo cercato
l protocollo ICMP (Internet Control and Message Protocol)
Sempre a livello di rete esiste un altro protocollo che consente la gestione degli errori ed il controllo dei messaggi, si tratta dell'ICMP. ICMP facilita l'interazione tra stazioni in rete e gateway, è capace tra l'altro di reindirizzare messaggi, notifica al mittente di un datagram problemi sul datagram stesso, richiede di ridurre il ritmo di trasmissione (per maggiori dettagli si veda il "choke packet" come mezzo anticongestione), avverte IP che un pacchetto non può raggiungere la destinazione, o che un gateway non ha sufficiente memoria per consegnare un pacchetto (cioè ha le code piene).
Il livello di trasporto TCP (Transmission Control Protocol)
Una delle prime richieste per le reti di comunicazione dati è la capacità di trasmettere e ricevere dati in maniera affidabile. Si è visto, però, che lo strato IP non fornisce alcun controllo di integrità dei dati ricevuti e non ricostruisce l'esatta sequenza cronologica dei singoli pacchetti ricevuti che compongono un datagram. Ad un protocollo di rete di tale semplicità deve corrispondere un protocollo di trasporto notevolmente sofisticato a cui demandare tutte queste funzionalità.
A questo scopo è stato sviluppato il TCP. Esso fornisce un servizio di controllo di flusso End-to-End in modo da permettere un affidabile spedizione dati. I meccanismi utilizzati includono sequenze, temporizzazioni, checksum (soltanto un semplice controllo di parità sui dati trasmessi e non un CRC), acknowledgment.
TCP stabilisce una connessione virtuale, riconosce ogni singolo byte, fornisce un servizio End-to-End full duplex, corregge gli errori di trasmissione ritrasmettendo continuamente il pacchetto fino a che non venga ricevuto correttamente e rispetta la sequenzialità dei dati. I livelli OSI superiori vedono la connessione tra due host come un flusso di byte continuo, è il TCP che si occupa di mascherare la trasmissione a pacchetti effettuata a livello IP.
La connessione tra due host viene stabilita mediante una procedura di tipo tree way handshaking, cioè l'host richiedente la connessione (SYN) manda all'host destinatario una richiesta di connessione, questo a sua volta risponde, se accetta la richiesta, con un datagram di acknowledgment (ACK) e infine l'host mittente invia una comunicazione di connessione stabilita (SYN+ACK). Quando un host invia una richiesta SYN si pone in attesa di una risposta per un certo tempo (time-out), passato il quale considera la richiesta non accettata. Può succedere però che il destinatario risponda con un certo ritardo, quando il time-out del mittente è già scaduto. In questo caso, quest'ultimo invierà un datagram di reset (RST) per informare il destinatario che la connessione non è più richiesta. Va osservato che in una procedura di tipo two way handshaking non ci sarebbe stata la trasmissione di RST, così il destinatario, convinto che la connessione fosse stabilita, sarebbe rimasto in attesa dei pacchetti inviati dall'host mittente. Pacchetti che non sarebbero mai giunti visto che quest'ultimo considerava rifiutata la connessione.
Il time-out in TCP è di tipo "adattivo", cioè l'host mittente, stimando il tempo medio di viaggio (Round Trip Time, RTP) dei pacchetti verso il destinatario nelle comunicazioni precedenti, calcola un time-out proporzionale ad esso (generalmente due volte il RTP).
Schema di trasmissione dati su TCP/IP (si noti che le reti A e B possono essere differenti ad esempio una Ethernet e una Token-Ring)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destinati Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data ... next 500 octets | | ...... |Formato semplificato della trama TCP
Controllo di flusso
TCP usa uno schema di allocazione a credito con finestra, cioè consente la trasmissione di un certo numero di pacchetti (dimensione della finestra di trasmissione) a credito, cioè senza avere la conferma di avvenuta ricezione dei precedenti. Quando un'entità (ad esempio un daemon) conferma i dati ricevuti lo fa con un messaggio nella forma:
(ACK i, CREDIT j)Ciò significa:
- Tutti i numeri di sequenza fino a i-1 si intendono confermati; il prossimo aspettato è i;
- Accordato il permesso di inviare i dati corrispondenti ai numeri di sequenza da i a i+j-1.
Controllo di congestione
Il TCP deve anche occuparsi del problema della congestione. Il protocollo IP infatti non se ne cura minimamente e, quando un nodo IP va in overflow, tutti i pacchetti in eccesso vengono persi (dropping dei pacchetti). Si parte da una assunzione: non esistono errori di trasmissione sulla linea, il dropping dei pacchetti deriva esclusivamente da congestione. Allora:
la congestione viene rilevata dalla mancanza di dati attesi in ricezione
Quando il TCP pensa che si sia verificata una congestione sulla linea (cioè è scaduto il time-out senza ricevere l'ACK dal destinatario), esso dimezza la dimensione della finestra di allocazione a credito (multiple decrease) limitando congiuntamente anche il traffico di trasmissione. Questo perché rimandare semplicemente un datagram non arrivato per congestione (e non per errore sulla linea) non fa altro che alimentare la congestione stessa. Continuando a dimezzare la finestra alla scadenza di ogni time-out si riesce nel tempo a risolvere la congestione, e dal momento che un host ricomincia a ricevere gli ACK da parte del destinatario può iniziare ad ingrandire nuovamente la propria finestra. Per evitare però di ricadere velocemente in una nuova congestione, questa non viene raddoppiata ma solo leggermente incrementata (slow start recovery).
Il protocollo UDP (User Datagram Protocol)
Con talune applicazioni che non richiedono un servizio End-to-End affidabile, è sufficiente aggiungere al servizio datagram IP il protocollo UDP. UDP opera a livello trasporto (quattro) come TCP. A differenza di questo non esegue la ritrasmissione dei pacchetti non arrivati e si limita ad effettuare un controllo di checksum per sondare la presenza di dati corrotti. Non permette neanche di capire se i datagram siano stati ricevuti nel corretto ordine di trasmissione; non esistono primitive per stabilire e abbattere una connessione (è di tipo connectionless). Anche UDP utilizza i socket, gli indirizzi di porta e i well-know socket (si veda il paragrafo omonimo).
Si può pensarlo come un protocollo IP di livello quattro, cioè datagram oriented e connectionless. Mentre IP fornisce una comunicazione tra due host (a livello tre), UDP fornisce una comunicazione tra due processi (remoti) o meglio tra due socket.
I protocolli GGP (Gateway-to-Gateway Protocol)
Appartengono a questo insieme i protocolli usati dai router per scambiarsi informazioni tra loro, generalmente si appoggiano ai protocolli TCP e UDP.
Si introduce ora il concetto di Autonomous System (AS) come una porzione di Internet in cui esistono diversi router tutti controllati da una singola organizzazione amministrativa. Il sistema può comprendere una o più reti fisiche, ma il punto nodale di controllo all'interno di quell'area ha il potere di organizzare e definire la rete a proprio piacimento. In un grande complesso universitario, ad esempio, un AS potrebbe comprendere anche una dozzina di reti locali unite da diversi router a formare un'internet locale. Tutti i sistemi autonomi sono composti da una o più reti interconnesse da una dorsale (backbone). La connessione tra singola LAN e dorsale è realizzata da border router che usano un protocollo di tipo IGP (Interior Gateway Protocol) i più noti dei quali sono il RIP (Routing Information Protocol) e il OSPF (Open Shortest Path First). La dorsale a sua volta si collega a Internet per mezzo di boundary router che usano il protocollo EGP (Exterior Gateway Protocol).
Una applicazione di questi protocolli, in particolare del RIP, si ha negli algoritmi di routing adattivi di tipo Vector Distance (Si veda il paragrafo sui routing adattivi). Questi prevedono che ogni router scambi ad intervalli costanti (ad esempio ogni 30 secondi) dei report informativi (routing update) contenenti le distanze temporali che lo separano dagli altri router interni (appartenenti cioè al medesimo AS) in modo tale che tutti possano riorganizzare le proprie tabelle di routing.
Well-know Socket
Si supponga di voler comunicare con un particolare processo in esecuzione su un computer remoto. Innanzitutto è necessario un sistema di identificazione che permetta a TCP si indirizzare correttamente i datagram verso quel processo. Dato che i processi in esecuzione, sulla macchina remota, saranno certamente più d'uno. non sarà sufficiente indicare il solo IP address del terminale destinatario. Poiché uno stesso processo potrebbe essere impegnato in più comunicazioni contemporanee non basterà nemmeno aggiungere il suo PID (Process ID) al IP address.
A tal scopo sono stati introdotti, in Unix, i concetti di socket e port. Il socket è la concatenazione di un indirizzo macchina (IP address) e un indirizzo di porta che definisce un punto di connessione verso un processo di quella macchina. Una interpretazione del socket è come indirizzo di rete di un processo. Il collegamento tra processo e socket è chiamato binding ed è effettuato tramite una chiamata ad una apposita primitiva Unix.
Per ogni comunicazione aperta su una macchina esiste un indirizzo di porta, di 16 bit, ad essa assegnato che permette a TCP di notificare ogni datagram in arrivo al corrispettivo processo che è in attesa proprio su quella porta.
Per instaurare una comunicazione un processo deve scegliere un proprio indirizzo di porta, di solito in modo casuale, ma deve obbligatoriamente conoscere anche l'indirizzo di porta della macchina remota su cui il processo remoto è in attesa della connessione. Per risolvere questo problema si è pensato di riservare una parte degli indirizzi disponibili ed assegnarli permanentemente a certe connessioni. In particolare tutti i servizi che sono offerti da TCP e Unix, ad esempio il trasferimento FTP, la gestione del mailbox, della stampante, del DNS ed altro ancora, sono gestiti da appositi processi server, detti daemon e indicati come ftpd, maild, printerd, dnsd, che vengono creati al momento del bootstrap della macchina. Questi processi effettuano inizialmente l'apertura di un socket, ognuno con un proprio caratteristico indirizzo di porta, e quindi si pongono in attesa di un tentativo di connessione proprio su quell'indirizzo da parte di un processo client remoto.
Esiste una tabella ufficiale, detta Assigned Numbers, dove sono riportati tutti gli indirizzi di porta preassegnati cosicché è facile sapere su che indirizzo di porta è in attesa un determinato processo server. Questi indirizzi costituiscono appunto i well-know socket.
Ad esempio supponiamo di voler trasferire un file, attraverso l'applicativo FTP. In questo caso è necessario specificare che si intende connettersi con l'FTP daemon del terminale remoto, cioè con quel processo che è incaricato di effettuare le operazioni di FTP per conto del terminale remoto. L'applicativo apre quindi un socket indicando il proprio ID address e un indirizzo di porta casuale per il nodo sorgente e quindi IP address della macchina remota e l'indirizzo di porta ufficiale dell'FTP daemon (il well-know socket appunto) per il lato destinatario.
Si noti che non è necessario indicare per il proprio programma un well-know socket poiché non c'è nessun processo che cerca di comunicare con lui. Lo scopo dei well-know socket è appunto questo: fornire una chiave, nota a priori, per potersi connettere con un particolare programma (daemon) di un terminale remoto. Se l'indirizzo di porta dell'FTP daemon di ogni macchina fosse casuale sarebbe necessaria una scansione preventiva di tutte le porte ad ogni tentativo di comunicazione da parte di un processo client.
Riassumendo, quindi, una comunicazione è identificata da quattro indirizzi: i due IP address degli host interessati e i due TCP port-number dei rispetti processi coinvolti. Ogni datagram contiene questi quattro campi (IP address nell'header IP e port-number nell'header TCP). Chiaramente non è possibile avere due comunicazioni con tutti i quattro numeri uguali, ma è sufficiente che almeno uno sia differente. Ad esempio si potrebbero avere due processi su uno stesso computer che effettuano l'FTP di due file da uno stesso computer remoto. Le due comunicazioni avranno gli stessi IP address e il well-know port-number dell'FTP daemon, ma si differenzieranno per i port-number dei due processi client interessati.
Il livello applicazione
I protocolli di livello applicazione basilari sono elencati di seguito:
TELNET è un protocollo di accesso ad un terminale remoto. Permette l'accesso ad un server o ad un host, ma da un host (o server) remoto. Introduce l'idea di Network Virtual Terminal.
FTP (File Transfer Protocol) è un servizio di file transfer.
SMTP (Simple Mail Transfer Protocol) è il protocollo per la gestione della posta elettronica (E-mail). Fornisce un sistema molto affidabile, infatti i messaggi vengono spediti direttamente dalla macchine ove è posto il mittente direttamente a quella del destinatario, in modo tale che il mittente può controllare se il messaggio sia stato ricevuto o meno (si veda a tal proposito il paragrafo specifico successivo).
DNS (Domain Name System) è un protocollo che permette di risolvere il problema di mappare i nomi usati dagli utenti in indirizzi IP usati dai computer. Infatti, data la scomodità intrinseca fornita dagli indirizzi di 12 cifre, si preferisce usare dei nomi mnemonici per riconoscere le macchine a cui collegarsi e a ciascuno di questi nomi viene poi abbinato il giusto indirizzo IP. Il DNS è incaricato della risoluzione del nome di dominio, cioè di convertire il nome simbolico nel corrispettivo indirizzo IP. Per ciascun dominio all'interno di Internet esiste un DNS che mantiene costantemente aggiornata una tabella di conversione per sapere come e dove ridistribuire le richieste di accesso ricevute attraverso la rete. Se il router che sta instradando un pacchetto non sa dove questo sia destinato, contatta il DNS per ricevere indicazioni che poi memorizza al proprio interno così da non doverle chiedere un'altra volta. In questo modo la struttura dei domini viene rapidamente diffusa attraverso l'intera rete e non c'è bisogno di contattare il DNS ogni volta che si vuole risolvere un indirizzo IP. I server DNS sono disposti secondo una gerarchia, così che quando non si riesce a risolvere un indirizzo si passa al livello superiore. E' necessario indicare su ogni client connesso in rete l'indirizzo IP del DNS più vicino. Il sistema è in uso dal 1983.
Dominio |
Tipo di organizzazione |
com |
Aziende private (commercial) |
edu |
Scuole e università (educational) |
gov |
Enti governativi |
int |
Organizzazioni internazionali |
mil |
Organizzazioni militari |
net |
Fornitori di accesso e di servizi in rete |
org |
Altre forme di organizzazione |
co.uk |
Società commerciali britanniche |
ac.uk |
Istituzioni accademiche britanniche |
it |
suffisso di stato per l'Italia |
fr |
suffisso di stato per la Francia |
ca |
suffisso di stato per il Canada |
uk |
suffisso di stato per il Regno Unito |
Alcuni esempio di domini. I primi sette sono i domini generici che identificano il tipo di organizzazione collegate a Internet. A questi domini generici si aggiunge quello specifico della nazione in cui si trovano. Nel caso degli Stati Uniti il suffisso .us viene spesso omesso, mentre negli altri Paesi spesso s'inserisce il suffisso nazionale e si salta quello generico
SMTP (Simple Mail Transfer Protocol)
Il messaggi viene creato da un programma a livello applicazione quindi accodato insieme ai messaggi di questo ed altri utenti nello stesso host. La coda è servita da un processo, detto SMTP sender. Questo trasmette i messaggi alle destinazioni tramite transazioni SMTP attraverso una o più connessioni sul well-know socket TCP numero 25. Ogni messaggio presente nella coda d'uscita, concettualmente consta di due parti:
- il testo del messaggio
- una lista di destinazioni
Il testo del messaggio include, un header ed il corpo del messaggio composto dall'utente. L'SMTP sender scandisce la coda di uscita ed apre delle connessioni TCP con gli host a cui recapitare i messaggi. Quando ha recapitato il messaggio a tutte le destinazioni previste, lo rimuove dalla coda.
SMTP può anche eseguire delle ottimizzazioni: se un messaggio va recapitato a più utenti di uno stesso host, viene trasmesso una sola volta. Più messaggi allo stesso host possono venire trasmessi su una singola connessione TCP.
Il SMTP sender deve anche affrontare una varietà di possibili condizioni di errore:
- l'host destinatario può non essere raggiungibile;
- la connessione TCP può cadere durante il trasferimento;
- l'indirizzo di destinazione, fornito dall'utente, può essere errato.
Il sender allora riaccoda il messaggio per trasmetterlo più tardi o rinunciare dopo un certo numero di tentativi. Quando non riesce nella consegna, deve notificare l'insuccesso all'originatore del messaggio. Non è previsto acknowledgment per l'avvenuta consegna dei messaggi.
L'SMTP receiver accetta i messaggi in arrivo e li pone nelle mailbox appropriate, inoltre, se è previsto un forwarding, li copia nella coda d'uscita. Il receiver deve affrontare diversi problemi di trasmissione.
La strategia generale, comunque, prevede che il sender sia responsabile fino a che il receiver segnali che il trasferimento è completato.
Grandi reti aziendali e Internet
Al momento di costruire una grossa intranet aziendale la vita sarebbe molto più facile se si avesse a disposizione un indirizzo di classe A, la classe degli indirizzi che supporta fino a 16 milioni di host oppure migliaia di sottoreti. Questi ultimi sono solo 128 in tutto il mondo (la parte rete è composta da soli 7 bit) per cui non si presenta come una soluzione realizzabile. Un'altra possibilità è creare la grossa intranet aziendale suddividendo in sottoreti più piccole uno speciale spazio di indirizzi di classe A (la rete 10.0.0.0 o Subnet 10).
Non solo è possibile utilizzare tutto lo spazio degli indirizzi che serve, ma la strategia della Subnet 10 permette anche di realizzate intranet protette, isolate dietro a firewall e a un server proxy, e di gestire come si vuole lo spazio di indirizzamento.
Secondo la RFC1918 (Request For Comment), tre blocchi di indirizzi IP sono stati riservati per le reti private: la rete di classe A 10.0.0.0, le reti di classe B da 172.16.0.0 a 172.31.0.0, e le reti di classe C da 192.168.0.0 a 192.168.255.0. Questi indirizzi sono stati riservati in modo che ogni amministratore di sistema che debba creare una rete privata possa essere sicuro che tutti sappiano che non si tratta di "reali" indirizzi Internet.
Il concetto chiave per la costruzione di una Subnet 10 è che, contrariamente a quando accade con gli indirizzi IP unici assegnati da un ISP (Internet Service Provider) o da Internic, tutti gli host, i router o le workstation che usano questi indirizzi speciali non devono essere visibili da Internet, e devono quindi essere nascosti dietro un firewall o un proxy server. In tal modo, sarà sempre possibile raggiungere Internet mediante il server proxy, ma si rimarrà liberi di configurare come si vuole gli indirizzi di rete interni. Ci può anche essere una seconda rete esterna, che è direttamente accessibile da Internet. Tutti gli host che devono essere pubblicamente disponibili, come i siti WWW, gli host che gestiscono servizi di FTP anonimo o di DNS dovranno far parte della rete esterna.
La principale complicazione è costituita dalla necessità di un server proxy, dato che la strategia della Subnet 10 non ne può fare a meno. Questo agisce come un meccanismo di commutazione intelligente, che traduce gli indirizzi della sottorete 10 in altri indirizzi IP "reali" prima di inoltrare il traffico in Internet. Esegue le transazioni Http, FTP, Telnet, e tutte le altre transazioni a livello di applicazione per conto degli host della Subnet, nascondendo al mondo Internet l'esistenza e la reale identità (oltre all'indirizzo IP) di questi host.
Gli host che fanno parte della rete interna protetta hanno un'unica speciale identità. I loro speciali indirizzi di rete permettono di proteggere più facilmente l'intranet dagli intrusi. Dall'esterno, infatti, sarà difficile riuscire a raggiungere un host di una rete privata mediante la manipolazione di un indirizzo della rete privata Subnet 10.
Per costruire un'intranet con la strategia della Subnet 10 si devono anzitutto organizzare tutte le sottoreti e gli host della rete interna a partire da un singolo punto, che farà da gateway nei confronti di Internet. Quindi si dovranno collocare i firewall e uno o più proxy server sul percorso fisico che collega il router al ISP. Alle loro spalle gli utenti dell'intranet potranno comunicare liberamente tra loro. Ma quando dovranno avventurarsi su Internet, dovranno connettersi al server proxy, che provvederà a stabilire la connessione per loro.
Schema di connessione Subnet 10
Lo schema tra tre elementi: la rete interna, i server proxy e la rete esterna. La rete interna, o le sue sottoreti, deve contenere tutte le workstation degli utenti, i server, gli host che gestiscono la posta elettronica e almeno un server DNS che conosca tutto delle macchine della rete interna.
Gli host che gestiscono la posta elettronica, i post office, sono solitamente nascosti rispetto ai sistemi di posta elettronica di Internet, mediante un gateway SMTP e un host per la gestione della posta elettronica posto nella rete esterna e visibile a Internet. I server proxy si trovano nella zona di confine, tra la rete esterna e quella interna. Devono essere connessi a entrambe le reti in modo da conoscerle entrambe. Ci potrebbe essere più di un server proxy. Di solito si usa un proxy per i servizi Web, uno per i protocolli FTP e Telnet, uno per le News e uno per le utilities di rete.
La rete esterna è una rete separata, che non fa parte della Subnet 10 ma di uno spazio di indirizzi pubblico. E' dotata di un indirizzo di rete assegnato da un ISP o dal GARR, che è reale, registrato e perfettamente riconosciuto e utilizzato dai router esterni. Dato l'esiguo numero di host contenuti, in genere va bene anche un indirizzo di classe C.
La rete esterna contiene gli host che i navigatori di Internet possono vedere e contattare. Questi host comprendono i siti Web dell'organizzazione, il suo FTP anonimo, il suo gateway di posta elettronica e il suo DNS esterno. Di questa rete fanno parte anche le componenti dei server proxy relative alla rete esterna. Il server DNS conosce solo le identità degli host della rete esterna e quelle dei server proxy, così come sono visti dalla rete esterna. Il server DNS della rete interna usa quello della rete esterna per risolvere i nomi degli host di Internet.
Naturalmente esiste un firewall, che si trova sulla connessione Internet con ISP, dalla parte della rete esterna (l'unico punto obbligato di passaggio per tutto il traffico). Per un livello di protezione ottimale è necessario che anche le connessioni su linea telefonica passino attraverso il firewall.