La prima cosa che il browser deve fare è stabilire una connessione remota al computer dove si trova il documento. A tal fine deve prima trovare la posizione remota dell'host www.tldp.org (`host' è la forma breve di `computer host' o `host remoto'; www.tldp.org è un tipico hostname). La posizione corrispondente è in realtà un numero chiamato indirizzo IP (spiegheremo più avanti la parte `IP' di questa espressione).

A questo scopo il proprio browser interroga un programma chiamato name server. Il "name server" può trovarsi sul proprio computer, ma è più probabile che giri su un computer del fornitore col quale il proprio computer dialoga. Quando si sottoscrive un contratto con un ISP (fornitore di servizi internet) una parte della procedura di configurazione consiste quasi sicuramente nel comunicare al proprio software per internet qual ` l'indirizzo IP di un name server sulla rete dell'ISP.

I name server sui vari computer comunicano tra loro, scambiandosi e tenendo aggiornate tutte le informazioni necessarie per risolvere i nomi degli host (per tradurli in indirizzi IP). Il proprio name server può interrogare tre o quattro diversi siti sulla rete nel processo di risoluzione di www.tldp.org, ma di solito questo si verifica molto rapidamente (diciamo in meno di un secondo). Vedremo nella sezione successiva come funzionano i name server nel dettaglio

Il name server comunicherà al proprio browser che l'indirizzo IP di www.tldp.org è 152.19.254.81; conoscendo questo, la propria macchina sarà in grado di scambiare direttamente bit con www.tldp.org.

L'intera rete di programmi e database che cooperano alla traduzione degli hostname in indirizzi IP è chiamata ‘DNS’(Domain Name System). Quando si vedono riferimenti a un ‘DNS server’, questo significa solo che viene chiamato un nameserver. Ora spiegherò come funziona l'intero sistema.

Gli hostname della rete sono composti di parti separate da punti. Un dominio è una collezione di macchine che condividono un suffisso di nome comune. I domini possono esistere all'interno di altri domini. Per esempio, la macchina www.tldp.org si trova nel sottodominio .tldp.org del dominio .org.

Ogni dominio è definito da un name server autorevole che conosce gli indirizzi IP delle altre macchine nel dominio. Il name server autorevole (o ‘primario') può avere backup nel caso in cui andasse giù; se si vedono i riferimenti a un name server secondario o (‘DNS secondario') si sta parlando di uno di questi. Tipicamente questi secondari aggiornano le loro informazioni dai loro primari ogni poche ore, così un cambiamento fatto all'hostname tradotto in indirizzo IP sul primario sarà propagato automaticamente.

Ora c'è una parte importante. I nameserver per un dominio non hanno la conoscenza delle posizioni di tutte le macchine negli altri domini (includendo i loro propri sottodomini); hanno solamente la conoscenza della posizione dei nameserver. Nel nostro esempio, il name server autorevole per il dominio .org conosce l'indirizzo IP del nameserver per .tldp.org ma non gli indirizzi di tutte le altre macchine in .tldp.org.

I domini nel sistema DNS sono strutturati come un grande albero invertito. In alto ci sono i server di root. Ognuno conosce gli indirizzi IP dei server di root; sono collegati dentro al proprio software DNS. I server di root conoscono gli indirizzi IP dei nameserver per i domini di livello più alto come .com e .org, ma non gli indirizzi delle macchine all'interno di questi domini. Ogni server di dominio di alto livello conosce dove si trovano i nameserver per i domini direttamente al di sotto, e così via.

Il DNS è sviluppato con cura così che ogni macchina può andare avanti con la minima quantità di conoscenza di cui ha bisogno in relazione alla forma dell'albero, e le modifiche locali ai sottoalberi possono essere fatte semplicemente cambiando nella base dati del server autorevole le corrispondenze tra nome e indirizzo IP .

Quando si fa una richiesta per l'indirizzo IP di www.tldp.org, quel che realmente accade è questo: Prima, il proprio nameserver chiede a un server root di dirgli dove si può trovare un nameserver per .org. Una volta ottenuta la risposta, chiede poi al server .org di dirgli l'indirizzo IP di un nameserver .tldp.org. Una volta ottenuta la risposta, chiede al nameserver .tldp.org di dirgli l'indirizzo dell'host www.tldp.org.

La maggior parte delle volte, il proprio nameserver non deve realmente lavorare così tanto. I nameserver fanno molto uso della memoria cache; quando risolve un nome di host, tiene in memori aper qualche tempo l'associazione con l'indirizzo IP risultante. Questo è il motivo per cui, quando naviga in un nuovo sito, normalmente si vedrà nel browser un messaggio di ricerca dell'host solo per la prima pagina visitata. Alla fine l'associazione nome-indirizzo scade e il DNS dev'essere chiesto di nuovo. Questo è importante affinché la ricerca di informazioni non valide non debba durare in eterno quando un nome di host cambia indirizzo. L'indirizzo IP di un sito tenuto in memoria viene rifiutato anche quando l'host è irraggiungibile.

Quello che il browser vuol fare è inviare un comando al server web su www.tldp.org come il seguente:

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: indirizzo di provenienza (l'indirizzo IP del proprio computer), l'indirizzo di destinazione (152.19.254.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 proprio computer spedisce allora il pacchetto lungo il cavo (la connessione al proprio ISP o rete locale) finché arriva a un apparato specializzato chiamato router. Il router ha nella sua memoria una mappa di Internet; non sempre è una mappa completa, ma una che descrive completamente il proprio vicinato di rete e sa come raggiungere i router per altri circondari di Internet.

Il pacchetto potrebbe passare attraverso svariati router lungo il percorso per la sua destinazione. I router sono intelligenti. Guardano quanto tempo impiegano gli altri router per sapere se hanno ricevuto un pacchetto. Usano questa informazione anche 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 a ottenere prestazioni affidabili da hardware precarioin un mondo incerto. Questo deriva direttamente dal fatto che la sua intelligenza è distribuita attraverso migliaia di router piuttosto che concentrata in poche centrali enormi e vulnerabili (come la rete telefonica). Questo significa che i malfunzionamenti tendono ad essere ben localizzati e la rete può aggirarli.

Una volta che il 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 suddividerà in un certo numero di pacchetti. La dimensione dei pacchetti varierà a seconda del mezzo di trasmissione sulla rete e del tipo di servizio.

Per capire come vengono gestite le trasmissioni a pacchetti multipli, è necessario sapere che Internet in realtà usa due protocolli, uno sovrapposto all'altro.

Il livello più basso, l'IP (Internet Protocol), ha la responsabilità di etichettare singoli pacchetti con un indirizzo di provenienza e un indirizzo di destinazione di due computer che si scambiano informazioni su una rete. Per esempio, quando si accede a http://www.tldp.org, i pacchetti che si inviano avranno l'indirizzo IP del proprio computer, come 192.168.1.101, e l'indirizzo IP del computer www.tldp.org, 152.2.210.81. Questi indirizzi funzionano allo stesso modo del proprio indirizzo di casa quando qualcuno invia una lettera. L'ufficio postale può leggere gli indirizzi e determinare dove si abita e qual'è il miglior percorso perché la lettera arrivi, molto simile a quello che svolge un router per il traffico di internet.

Il livello superiore, TCP (Transmission Control Protocol), fornisce 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 ricevimento dei pacchetti che legge. Se il mittente non vede un avviso di ricevimento per un pacchetto entro un certo periodo di tempo (timeout), rispedisce quel pacchetto. Inoltre, il mittente fornisce ogni pacchetto TCP di un numero di sequenza, che il ricevente può usare per riassemblare i pacchetti nel caso che risultino in disordine. (Questo può facilmente succedere se i collegamenti della rete vanno e vengono durante una connessione.)

I pacchetti TCP/IP contengono anche una somma di controllo (checksum) per consentire l'individuazione di dati rovinati da collegamenti difettosi (la somma di controllo è calcolata dal resto del pacchetto in modo tale che se il resto del pacchetto o la somma di controllo sono difettosi, il ricalcolo e il successivo confronto indichi con molta probabilità un errore). Così, dal punto di vista di chiunque usi il TCP/IP e i name server, sembra essere un modo affidabile per passare flussi di byte tra coppie di hostname/numero di servizio. Chi scrive i protocolli di rete non deve quasi mai pensare a tutte le operazioni di pacchettizzazione, riassemblaggio dei pacchetti, controllo degli errori, calcolo della somma di controllo e ritrasmissione che stanno al di sotto di quel livello.

Torniamo ora al nostro esempio. I browser e i server web dialogano usando un protocollo applicativo che viene eseguito al disopra del 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 prima.

Quando il comando GET arriva al server www.tldp.org con numero di servizio 80, verrà notificato a un server daemon 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 la struttura 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 è leggermente inefficiente; in qualche circostanza si potrebbe ottenere una velocità maggiore usando un protocollo binario di stretta codifica. Ma l'esperienza ha dimostrato che i vantaggi di avere comandi facili da descrivere e comprendere per gli esseri umani supera qualsiasi guadagno marginale di efficienza che si possa ottenere al prezzo di rendere le cose oscure e complicate.

Di conseguenza, quello che il demone server rispedisce attraverso TCP/IP è anch'esso testo. L'inizio della risposta assomiglierà in qualche modo a questa (alcune intestazioni sono state omesse):

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

Queste intestazioni saranno seguite da una riga vuota e dal testo della pagina web (dopodich´ la connessione viene lasciata cadere). Il proprio browser si limita a visualizzare quella pagina. Le intestazioni servono a comunicargli come (in particolare, l'intestazione Content-Type gli comunica che i dati restituiti sono veramente HTML).