Per aiutarvi a capire come funziona Internet daremo un'occhiata alle cose che succedono quando fate una tipica operazione di Internet: indirizzate un browser alla prima pagina di questo documento, sul sito Web del Linux Documentation Project. L'indirizzo di questo documento è
http://metalab.unc.edu/LDP/HOWTO/Fundamentals.html
che significa che si trova nel file LDP/HOWTO/Fundamentals.html sotto la web directory dell'host sunsite.unc.edu.
La prima cosa che il vostro browser deve fare è stabilire una connessione remota al computer dove si trova il documento. A tal fine deve prima trovare la locazione remota dell'host sunsite.unc.edu (`host' è la forma breve di `computer host' o `host remoto'; sunsite.unc.edu è un tipico hostname). La locazione corrispondente è in realtà un numero chiamato indirizzo IP (spiegheremo più avanti la parte `IP' di questa espressione).
A questo scopo il vostro browser interroga un programma chiamato name server. Il name server può trovarsi sul vostro computer, ma è più probabile che giri su un computer del fornitore col quale il vostro computer dialoga. Quando vi collegate ad un ISP una parte della procedura consiste quasi sicuramente nel dire al vostro software per Internet qual è l'indirizzo IP di un name server sulla rete dell'ISP.
I name server sui vari computer si parlano tra loro, scambiandosi e tenendo aggiornate tutte le informazioni necessarie per risolvere i nomi degli host (per mapparli agli indirizzi IP). Il vostro name server può interrogare tre o quattro diversi siti sulla rete nel processo di risoluzione di sunsite.unc.edu, ma di solito questo si verifica molto rapidamente (tipo in meno di un secondo).
Il name server dirà al vostro browser che l'indirizzo IP di Sunsite è 152.2.22.81; a questo punto il vostro computer sarà in grado di scambiare direttamente bit con sunsite.
Quello che il browser vuole è mandare al Web server su Sunsite un comando come questo:
GET /LDP/HOWTO/Fundamentals.html HTTP/1.0
Ecco cosa succede. Dal comando si costruisce un pacchetto, cioè un blocco di bit come un telegramma che è `impacchettato' con tre cose importanti: l'indirizzo di provenienza (l'indirizzo IP del vostro computer), l'indirizzo di destinazione (152.2.22.81) e un numero di servizio o numero di porta (in questo caso 80) che indica che si tratta di una richiesta World Wide Web.
Il vostro computer spedisce allora il pacchetto lungo il cavo (la connessione modem al vostro ISP o rete locale) finché arriva ad un computer specializzato chiamato router. Il router ha nella sua memoria una mappa di Internet, non sempre una completa, ma una che descrive completamente il vostro vicinato di rete e sa come raggiungere i router per altri circondari di Internet.
Il vostro pacchetto potrebbe passare attraverso svariati router lungo la strada per la sua destinazione. I router sono intelligenti. Guardano quanto tempo impiegano gli altri router per avvertire che hanno ricevuto un pacchetto. Usano questa informazione per dirigere il traffico verso i collegamenti veloci. La usano per accorgersi se un altro router (o un cavo) sono fuori servizio o irraggiungibili e quindi, se possibile, ovviare al problema trovando un'altra strada.
C'è una leggenda metropolitana secondo la quale Internet è stata progettata per sopravvivere alla guerra nucleare. Questo non è vero, ma la struttura di Internet è estremamente adatta ad ottenere prestazioni affidabili anche con l'hardware precario che caratterizza questo mondo incerto. Questo deriva direttamente dal fatto che la sua intelligenza è distribuita tra migliaia di router piuttosto che riunita in poche enormi centrali (come la rete telefonica). Questo significa che i malfunzionamenti tendono a essere ben localizzati e la rete può aggirarli.
Una volta che il vostro pacchetto è giunto al computer di destinazione quest'ultimo usa il numero di servizio per inviare il pacchetto al server web. Il server web può capire a chi rispondere guardando l'indirizzo IP di provenienza del pacchetto con il comando. Quando il server web restituisce questo documento lo suddivide in un certo numero di pacchetti. La dimensione dei pacchetti varia a seconda del mezzo di trasmissione sulla rete e del tipo di servizio.
Per capire come vengono gestite le trasmissioni a pacchetti multipli, dovete sapere che Internet in realtà usa due protocolli, uno sovrapposto all'altro.
Il livello più basso, l'IP (Internet Protocol), sa come prendere singoli pacchetti da un indirizzo di provenienza a un indirizzo di destinazione (è per questo che si chiamano indirizzi IP). Tuttavia l'IP non è affidabile: se un pacchetto si perde o cade i computer di origine e di destinazione possono non venirne mai a conoscenza. Nel gergo delle reti, l'IP è un protocollo senza connessione; il mittente si limita a far partire un pacchetto per il destinatario e non si aspetta un avviso di ricevuta.
L'IP è veloce ed economico, comunque. A volte veloce, economico e inaffidabile va bene. Quando giocate in rete a Doom o Quake, ogni pallottola è rappresentata da un pacchetto IP. Se alcune vengono perse, pazienza.
Il livello superiore, TCP (Transmission Control Protocol), vi dà affidabilità. Questi due computer negoziano una connessione TCP (cosa che fanno usando l'IP); il ricevente sa che deve spedire al mittente un avviso di ricevuta dei pacchetti che legge. Se il mittente non vede un avviso di ricevuta per un pacchetto entro un certo periodo di tempo (timeout) allora rispedisce quel pacchetto. Inoltre, il mittente attribuisce ad ogni pacchetto TCP un numero di sequenza, che il ricevente può usare per riassemblare i pacchetti nel caso che risultino in disordine. (Cosa che si verifica se un collegamento della rete viene attivato o cade durante una connessione.)
I pacchetti TCP/IP contengono anche un checksum per consentire l'individuazione di dati rovinati da collegamenti difettosi. Così, dal punto di vista di chiunque usi il TCP/IP e i name server, sembra affidabile passare flussi di byte in coppie hostname/numero di servizio. Chi scrive i protocolli di rete non deve quasi mai pensare agli aspetti di basso livello relativi alla pacchettizzazione, al riassemblaggio dei pacchetti, al controllo degli errori, al checksum e alla ritrasmissione.
Torniamo ora al nostro esempio. I browser ed i server web dialogano usando un protocollo applicativo che si appoggia al TCP/IP, usandolo semplicemente come un modo per passare stringhe di byte avanti e indietro. Questo protocollo è chiamato HTTP (Hyper-Text Trasfer Protocol, protocollo per il trasferimento di ipertesti) e abbiamo già visto un suo comando: il GET mostrato sopra.
Quando il comando GET arriva al server web sunsite.unc.edu con numero di servizio 80 verrà notificato al demone server che è in attesa sulla porta 80. La maggior parte dei servizi Internet sono implementati da demoni server che si limitano ad ascoltare sulle porte, attendono ed eseguono i comandi in arrivo.
Se il disegno di Internet ha una regola generale, questa è che tutte le parti dovrebbero essere il più possibile semplici e accessibili per gli esseri umani. L'HTTP e i suoi simili (come il Simple Mail Transfer Protocol, SMTP, che viene usato per trasferire la posta elettronica tra gli host) tende a usare comandi in semplice testo stampabile che terminano con un codice di carriage return/line feed.
Questo è marginalmente inefficiente: in qualche circostanza potreste ottenere una velocità maggiore usando un protocollo binario di stretta codifica. Ma l'esperienza ha dimostrato che i benefici di avere comandi facili da descrivere e comprendere per gli esseri umani supera qualsiasi marginale guadagno di efficienza che si possa ottenere al prezzo di rendere le cose oscure e complicate.
Di conseguenza, quello che il demone server vi rispedisce via TCP/IP è anch'esso testo. L'inizio della risposta assomiglierà in qualche modo a questa (alcuni header sono stati omessi):
HTTP/1.1 200 OK Date: Sat, 10 Oct 1998 18:43:35 GMT Server: Apache/1.2.6 Red Hat Last-Modified: Thu, 27 Aug 1998 17:55:15 GMT Content-Length: 2982 Content-Type: text/html
Questi header saranno seguiti da una linea vuota e dal testo della pagina web (dopodiché la connessione viene lasciata cadere). Il vostro browser si limita a visualizzare quella pagina. Gli header servono a spiegargli come (in particolare, l'header Content-Type gli dice che i dati restituiti sono veramente HTML).