Questi appunti sono basati sui libri "Computer Networks" di A. Tanenbaum, terza edizione, ed. Prentice-Hall, e "Java Network Programming" di Merlin Hughes et al., Mannig Publications Co, Greenwich CT, adottati quali libri di testo del corso.

Essi rispecchiano piuttosto fedelmente il livello di dettaglio che viene seguito durante le lezioni, e costituiscono un ausilio didattico allo studio.

Tuttavia, è importante chiarire che gli appunti non vanno intesi come sostitutivi né dei libri di testo né della frequenza alle lezioni, che rimangono fattori importanti per una buona preparazione dell'esame.

La realizzazione di questi appunti è stata resa possibile dalla collaborazione di alcuni studenti, che hanno avuto la pazienza di convertire in forma elettronica il contenuto testuale dei manoscritti da me preparati per il corso. La realizzazione delle figure, la formattazione e la rifinitura del testo sono opera mia.

1) Il World Wide Web

Il World Wide Web (detto anche Web, WWW o W³⁾ è nato al Cern nel 1989 per consentire una agevole cooperazione fra i gruppi di ricerca di fisica sparsi nel mondo.

E' un'architettura software volta a fornire l'accesso e la navigazione a un enorme insieme di documenti collegati fra loro e sparsi su milioni di elaboratori.

Tale insieme di documenti forma un ipertesto (hypertext), cioè un testo che viene percorso in modo non lineare. Il concetto di ipertesto risale alla fine degli anni '40, e si deve a vari scienziati:

• Vannevar Bush (sistema Memex, basato su microfilm);
• Douglas Engelbart (sistema NLS/Augment, basato su elaboratori interconnessi);
• Ted Nelson (sistema Xanadu, con enfasi sulla tutela dei diritti d'autore: un documento poteva contenere un riferimento ad altri documenti, che venivano inclusi "al volo" in quello referente e mantenevano così la loro unicità e originalità).

Il Web ha diverse caratteristiche che hanno contribuito al suo enorme successo:

• architettura di tipo client-server:
  • ampia scalabilità;
  • adatta ad ambienti di rete;
• architettura distribuita:
  • perfettamente in linea con le esigenze di gestione di un ipertesto;
• architettura basata su standard di pubblico dominio:
  • possibilità per chiunque di proporre una implementazione;
  • uguali possibilità di accesso per tutte le piattaforme di calcolo;
• capacità di gestire informazioni di diverso tipo (testo, immagini, suoni, filmati, realtà virtuale, ecc.):
  • grande interesse da parte di tutti gli utenti.

I documenti che costituiscono l'ipertesto gestito dal Web sono detti pagine web, e possono contenere, oltre a normale testo formattato, anche:

• rimandi (detti link o hyperlink) ad altre pagine web;
• immagini fisse o in movimento;
• suoni;
• scenari tridimensionali interattivi;
• codice eseguibile localmente.

L'utilizzo del Web è semplicissimo:

• un utente legge il testo della pagina, vede le immagini, ascolta la musica, ecc.;
• se seleziona col mouse un link (che di solito appare come una parola sottolineata e di diverso colore) la pagina di partenza viene sostituita sullo schermo da quella relativa al link selezionato.

Si noti che la nuova pagina può provenire da qualunque parte del pianeta.

1.1) Architettura client-server del Web

Il Web è una architettura software di tipo client-server, nella quale sono previste due tipologie di componenti software: il client e il server, ciascuno avente compiti ben definiti.

1.1.1) Client

Il client (o user agent) è lo strumento a disposizione dell'utente che gli permette l'accesso e la navigazione nell'ipertesto del Web.

Esso ha varie competenze:

• trasmettere all'opportuno server le richieste di reperimento dati che derivano dalle azioni dell'utente;
• ricevere dal server le informazioni richieste;
• visualizzare il contenuto della pagina Web richiesta dall'utente, gestendo in modo appropriato tutte le tipologie di informazioni in esse contenute;
• consentire operazioni locali sulle informazioni ricevute (ad esempio salvarle su disco, stamparle).

I client vengono comunemente chiamati browser (sfogliatori). Gli esempi più noti sono:

• NCSA Mosaic (il primo);
• Netscape Navigator;
• Microsoft Internet Explorer.

In generale è troppo complicato e costoso (sarebbero necessari aggiornamenti troppo frequenti) sviluppare un browser che sappia gestire direttamente tutti i tipi di informazioni presenti sul Web, poiché essi sono in continuo e rapido aumento.

Per questa ragione, di norma i browser gestiscono direttamente solo alcune tipologie di informazioni, quali:

• testo formattato;
• immagini fisse;
• codice eseguibile.

Viceversa, di norma gli altri tipi di informazioni vengono gestiti in uno (o entrambi) dei seguenti modi:

• consegnandoli a un programma esterno (helper) che provvederà alla corretta gestione (ad esempio, un file contenente un filmato verrà consegnato a un programma per il playback di filmati);
• se il browser ha un'architettura modulare le sue funzionalità possono essere estese per mezzo di plug-in, ossia librerie di codice eseguibile specializzato che possono essere caricate in memoria secondo le necessità. In questa situazione, se il necessario plug-in è installato, il browser provvede a caricarlo e gli affida la gestione delle informazioni da trattare.

Una importante caratteristica di tutti i browser moderni è di essere multithreaded, cioè di consentire che, quando la cpu è sotto il loro controllo, si alternino fra loro multipli thread di controllo, cioè flussi di elaborazione concorrenti. Spesso si usa come sinonimo di thread il termine lightweight process.

Ad esempio, nel caso di un sistema operativo (S.O.) che offre il multitasking, si può avere una situazione come quella seguente.

Un thread, a differenza di un vero processo, è un contesto di esecuzione il cui spazio di indirizzamento viene ricavato all'interno di quello del processo che lo ha generato.

1.1.2) Server

Il server è tipicamente un processo in esecuzione su un elaboratore. Esso, di norma, è sempre in esecuzione (tranne che in situazioni eccezionali) ed ha delle incombenze molto semplici, almeno in linea di principio. Infatti deve:

• rimanere in ascolto di richieste da parte dei client;
• fare del suo meglio per soddisfare ogni richiesta che arriva:
  • se possibile, consegnare il documento richiesto;
  • altrimenti, spedire un messaggio di notifica di errore (documento non esistente, documento protetto, ecc.).

Nonostante la apparente semplicità di tale compito, la realizzazione di un server non è banale, perché:

• deve fare il suo lavoro nel modo più efficiente possibile, dunque deve essere implementato con un occhio di riguardo alle prestazioni;
• deve essere in grado di gestire molte richieste contemporaneamente, e mentre fa questo deve continuare a rimanere in ascolto di nuove richieste.

Il secondo requisito in particolare implica una qualche forma di concorrenza nel lavoro del server. Essa si può ottenere in vari modi, anche in funzione delle caratteristiche del sistema operativo sottostante. Le due tecniche più diffuse sono descritte nel seguito.

Clonazione del server

L'idea è semplice:

• per ogni nuova richiesta che arriva, il server (che è sempre in ascolto):
  • crea una nuova copia di se stesso alla quale affida la gestione della richiesta;
  • si mette subito in attesa di nuove richieste;
• la copia clonata si occupa di soddisfare la richiesta e poi termina.

Le varie copie del server vivono in spazi di indirizzamento separati, e il loro avvicendamento nell'uso della CPU è governato dal sistema operativo.

Questo è un metodo tipico di S.O. multitasking quali UNIX, e si ottiene con l'uso della fork().

Vantaggi:

• il codice del server rimane semplice, poiché la clonazione è demandata in toto al S.O.

Svantaggi

• poiché in genere la gestione di una richiesta è piuttosto rapida, il tempo di generazione del clone può non essere trascurabile rispetto al tempo di gestione della richiesta, introducendo così un overhead che può penalizzare l'efficienza del sistema.

Server multithreaded

Esiste una sola copia del server, che però è progettato per essere in grado di generare thread multipli:

• il thread principale (quello iniziale) rimane sempre in ascolto delle richieste;
• quando ne arriva una, esso genera un nuovo thread che prima la gestisce e poi termina.

Questo metodo richiede che il S.O. offra librerie di supporto al multithreading, che ormai sono presenti in tutti i S.O. moderni (UNIX, Windows 95 e NT, MacOS, Linux) per cui di fatto è universalmente applicabile.

Vantaggi:

• la creazione di un thread è molto più veloce di una fork() (anche 30 volte sotto UNIX), quindi in generale è più efficiente per gestire operazioni veloci come l'esaudire la richiesta del client.

Svantaggi:

• il codice del server diviene un pò più complesso, perché al suo interno si dovranno gestire la creazione dei thread ed il loro avanzamento, anche in termini di sincronizzazione.

1.2) Standard utilizzati nel Web

Ci sono tre standard principali che, nel loro insieme, costituiscono l'architettura software del Web:

• sistema di indirizzamento basato su Uniform Resource Locator (URL): è un meccanismo standard per fare riferimento alle entità indirizzabili (risorse) nel Web, che possono essere:
  • documenti (testo, immagini, suoni, ecc.);
  • programmi eseguibili (vedremo poi);
• linguaggio HTML (HyperText Markup Language): è il linguaggio per la definizione delle pagine Web;
• protocollo HTTP (HyperText Transfer Protocol): è il protocollo che i client e i server utilizzano per comunicare.

1.2.1) URL

Una URL costituisce un riferimento a una qualunque risorsa accessibile nel Web.

Tale risorsa ovviamente risiede da qualche parte, ed è in generale possibile accedervi in vari modi.

Dunque, una URL deve essere in grado di indicare:

• come si vuole accedere alla risorsa;
• dove è fisicamente localizzata la risorsa;
• come è identificata la risorsa.

Per queste ragioni, una URL è fatta di 3 parti, che specificano:

• il metodo di accesso;
• l'host che detiene la risorsa;
• l'identità della risorsa.

Un tipico esempio di una URL è:

nella quale:

Metodo di accesso

Indica il modo di accedere alla risorsa, cioè che tipo di protocollo bisogna usare per colloquiare col server che controlla la risorsa.

I metodi di accesso più comuni sono:

Il Web nasce con l'idea di inglobare gli altri protocolli di accesso alle informazioni, per costituire un ambiente unificato che soddisfa tutte le esigenze.

Quando il client effettua la richiesta di una risorsa, usa nel dialogo col server il protocollo specificato dal metodo d'accesso. Se non è in grado di farlo, affida il compito a una applicazione helper esterna (questo è tipicamente il caso del protocollo telnet: il client lancia un emulatore di terminale passandogli il nome dell'host).

Dall'altra parte risponde il server di competenza, che può essere:

• un server Web in grado di gestire anche altri protocolli;
• un server preesistente per lo specifico protocollo (ftp, gopher, ecc.).

Nome dell'host

Può essere l'indirizzo IP numerico o, più comunemente, il nome DNS dell'host a cui si vuole chiedere la risorsa.

Dopo il nome dell'host può essere incluso anche un numero di port. Se non c'è, si intende il port 80 (che è il default). Ad esempio:

In questo modo si possono avere, sullo stesso host, diversi server Web in ascolto su diverse porte.

Identità della risorsa

Consiste, nella sua forma più completa, della specifica del nome di un file e del cammino che porta al direttorio in cui si trova.

Ad esempio, la URL:

specifica il file index.html contenuto nel direttorio toasters, a sua volta contenuto nel direttorio products il quale si trova nel direttorio radice dell'host somewhere.net.

Si noti che:

• la sintassi è quella di Unix;
• il direttorio radice è relativo all'albero dei documenti Web, e non è necessariamente la radice dell'intero file system dell'elaboratore;
• ciò fa sì che sia di fatto impossibile accedere per mezzo del Web al di fuori di tale parte del file system: il server, di norma, non consente di accedere a nulla che non sia nell'albero dei documenti Web.

Esistono alcune regole per il completamento di URL non interamente specificate:

• se manca il nome del direttorio, si assume quello della pagina precedente;
• se manca il nome del file (ma c'è quello del direttorio), a seconda del server:
  • si restituisce un file prefissato del direttorio specificato (index.html, default.html oppure welcome.html);
  • se tale file non esiste, talvolta si restituisce un elenco dei file nel direttorio.

Infine, una convenzione usata spesso è la seguente. A fronte di una URL del tipo:

il server restituisce il file welcome.html situato nel direttorio public_html situato nel direttorio principale (home directory) dell'utente username.

Questo meccanismo consente agli utenti, che di norma hanno libero accesso al proprio home directory, di mantenere facilmente proprie pagine Web.

1.2.2) Linguaggio HTML

Il linguaggio per la formattazione di testo HTML è una specializzazione del linguaggio SGML (Standard Generalized Markup Language) definito nello standard ISO 8879.

HTML è specializzato nel senso che è stato progettato appositamente per un utilizzo nell'ambito del Web.

Un markup language si chiama così perché i comandi (tag) per la formattazione sono inseriti in modo esplicito nel testo, a differenza di quanto avviene in un word processor WYSIWYG (What You See Is What You Get), nel quale il testo appare visivamente dotato dei suoi formati, come fosse stampato. TROFF e TeX sono altri markup language, mentre ad esempio Microsoft Word è WYSIWYG.

Per esempio in HTML il testo:

indica che la parola grassetto deve essere visualizzata in grassetto (bold). Quindi il testo in questione dovrà apparire come segue:

Il ruolo di HTML è quindi quello di definire il modo in cui deve essere visualizzata una pagina Web (detta anche pagina HTML), che tipicamente è un documento di tipo testuale contenente opportuni tag di HTML.

Il client, quando riceve una pagina compie le seguenti operazioni:

• interpreta i tag presenti nella pagina;
• formatta la pagina di conseguenza, provvedendo automaticamente ad adattarla alle condizioni locali (risoluzione dello schermo, dimensione della finestra, profondità di colore, ecc.);
• mostra la pagina formattata sullo schermo.

Nella formattazione si ignorano:

• sequenze multiple di spazi;
• caratteri di fine riga, tabulazioni, ecc.

I tag HTML possono essere divisi in due categorie:

• tag per la formattazione di testo;
• tag per altre finalità (inclusione di immagini, interazione con l'utente, elaborazione locale, ecc.).

Il linguaggio HTML è in costante evoluzione, si è passati dalla versione 1.0 alla 2.0 (rfc 1866), poi alla 3.0 e ora alla 3.2.

E' in corso una attività di standardizzazione della versione 3, che cerca di mediare le proposte, spesso incompatibili, che sono portate avanti da diverse organizzazioni (quali Netscape e Microsoft) le quali spingono perché proprie estensioni (ad esempio i frame di Netscape e gli style sheet di Microsoft) divengano parte dello standard.

In genere i tag hanno la forma:

e possono contenere parametri:

Struttura di un documento HTML

Una pagina HTML ha questa struttura:

<HTML> <HEAD> ... <TITLE>...</TITLE> ... </HEAD > <BODY> ... </BODY> </HTML>

Il ruolo di questi marcatori è il seguente:

Tag per la formattazione

Alcuni dei tag esistenti per la formattazione del testo sono i seguenti:

Ci sono moltissimi altri tag per la formattazione, coi quali si possono specificare:

• dimensione, colore, tipo dei caratteri;
• centratura del testo;
• liste di elementi;
• tabelle di testo in forma grafica (<TABLE>);
• divisori (<HR>,<BR>,<P>);
• colore di sfondo della pagina;
• suddivisione della finestra fra più pagine (<FRAMESET>, <FRAME>).

Tag per altre finalità

Questi sono i tag che forniscono al Web la sua grande versatilità. Anch'essi sono in continua evoluzione, permettendo di includere sempre nuove funzionalità.

I tag di questo tipo più usati sono quelli per la inclusione di immagini in-line (visualizzate direttamente all'interno della pagina) e per la gestione degli hyperlink.

Il tag per la inclusione di immagini ha la seguente forma:

Questo tag fa apparire l'immagine di cui alla URL. L'immagine (se il client è configurato per farlo) viene richiesta automaticamente e quando è disponibile viene mostrata. Altrimenti, al suo posto appare una piccola icona, sulla quale bisogna fare click se si vuole vedere la relativa immagine (che solo allora verrà richiesta), seguita dal testo specificato nel parametro ALT.

Altri parametri del tag <IMG> servono a:

• specificare le dimensioni dell'immagine (WIDTH, HEIGHT);
• specificare l'allineamento dell'immagine e del testo circostante (ALIGN);
• specificare le aree dell'immagine sensibili ai click del mouse (ISMAP).

Tag per la gestione degli hyperlink

Costituiscono il fondamento funzionale su cui è basato il Web, perché è per mezzo di questi che si realizzano le funzioni ipertestuali.

Il tag è uno solo (con alcune varianti) e viene chiamato anchor:

La sua forma standard è:

Nella pagina la stringa testo visibile appare sottolineata e, di norma, di colore blu:

Quando l'utente fa click su un'ancora (ossia sul testo visibile della stessa) il client provvede a richiedere il documento di cui alla URL, lo riceve, lo formatta e lo mostra nella finestra al posto di quello precedente.

1.2.3) Il protocollo HTTP

Il protocollo HTTP sovraintende al dialogo fra un client e un server web, ed è il linguaggio nativo del Web.

HTTP non è ancora uno standard ufficiale. Infatti, HTTP 1.0 (rfc 1945) è informational, mentre HTTP 1.1 (rfc 2068) è ancora in fase di proposta; parleremo di quest'ultimo più avanti.

HTTP è un protocollo ASCII, cioè i messaggi scambiati fra client e server sono costituiti da sequenze di caratteri ASCII (e questo, come vedremo, è un problema se è necessaria la riservatezza delle comunicazioni).

In questo contesto per messaggio si intende la richiesta del cliente oppure la risposta del server, intesa come informazione di controllo; viceversa, i dati della URL richiesta che vengono restituiti dal server non sono necessariamente ASCII (esempi di dati binari: immagini, filmati, suoni, codice eseguibile).

Il protocollo prevede che ogni singola interazione fra client e server si svolga secondo il seguente schema:

• apertura di una connessione di livello transport fra client e server (TCP è lo standard di fatto, ma qualunque altro può essere usato);
• invio di una singola richiesta da parte del client, che specifica la URL desiderata;
• invio di una risposta da parte del server e dei dati di cui alla URL richiesta;
• chiusura della connessione di livello transport.

Dunque, il protocollo è di tipo stateless, cioè non è previsto il concetto di sessione all'interno della quale ci si ricorda dello stato dell'interazione fra client e server. Ogni singola interazione è storia a se ed è del tutto indipendente dalle altre.

La richiesta del client

Quando un client effettua una richiesta invia diverse informazioni:

• il metodo (cioè il comando) che si chiede al server di eseguire;
• il numero di versione del protocollo HTTP in uso;
• l'indicazione dell'oggetto al quale applicare il comando;
• varie altre informazioni, fra cui:
  • il tipo di client;
  • i tipi di dati che il client può accettare.

I metodi definiti in HTTP sono:

In proposito, si noti che:

• il metodo che si usa quasi sempre è GET;
• POST ha il suo più significativo utilizzo in relazione all'invio di dati tramite form, come vedremo in seguito;
• HEAD si usa quando il client vuole avere delle informazioni per decidere se richiedere o no la pagina;
• PUT, DELETE, LINK, UNLINK non sono di norma disponibili per un client, tranne che in quei casi in cui l'utente sia abilitato alla configurazione remota (via Web) del server Web.

Ad esempio, supponiamo che nel file HTML visualizzato sul client vi sia un'ancora:

e che l'utente attivi tale link. A tal punto il client:

• chiede al DNS l'indirizzo IP di somewhere.net;
• apre una connessione TCP con somewhere.net, port 80;
• invia la sua richiesta.

Essa è costituita da un insieme di comandi (uno per ogni linea di testo) terminati con una linea vuota:

GET /products/toasters/index.html HTTP/1.0	Metodo, URL e versione protocollo
User-agent: Mozilla/3.0	Tipo del client
Host: 160.10.5.43	Indirizzo IP del client
Accept: text/html	Client accetta pagine HTML
Accept: image/gif	Client accetta immagini
Accept: application/octet-stream	Client accetta file binari qualunque
If-modified-since: data e ora	Inviare il documento solo se è più recente della data specificata

La risposta del server

La risposta del server è articolata in più parti, perché c'è un problema di fondo: come farà il client a sapere in che modo dovrà gestire le informazioni che gli arriveranno?

Ovviamente, non si può mostrare sotto forma di testo un'immagine o un file sonoro! Dunque, si deve informare il client sulla natura dei dati che gli arriveranno prima di iniziare a spedirglieli.

Per questo motivo la risposta consiste di 3 parti:

• una riga di stato, che indica quale esito ha avuto la richiesta (tutto ok, errore, ecc.);
• delle metainformazioni che descrivono la natura delle informazioni che seguono;
• le informazioni vere e proprie (ossia, l'oggetto richiesto).

La riga di stato, a sua volta, consiste di tre parti:

• Versione del protocollo http;
• Codice numerico di stato;
• Specifica testuale dello stato.

Tipici codici di stato sono:

Dunque, ad esempio, si potrà avere

Le metainformazioni dicono al client ciò che deve sapere per poter gestire correttamente i dati che riceverà.

Sono elencate in linee di testo successive alla riga di stato e terminano con una linea vuota.

Tipiche metainformazioni sono:

Il Content-type si specifica usando lo standard MIME (Multipurpose Internet Mail Exchange), nato originariamente per estendere la funzionalità della posta elettronica.

Un tipo MIME è specificato da una coppia

Vari tipi MIME sono definiti, e molti altri continuano ad aggiungersi. I più comuni sono:

Il server viene configurato associando alle varie estensioni i corrispondenti tipi MIME. Quando gli viene chiesto un file, deduce dall'estensione e dalla propria configurazione il tipo MIME che deve comunicare al client.

Se la corrispondenza non è nota, si usa quella di default (tipicamente text/html), il che può causare errori in fase di visualizzazione.

Anche la configurazione del client (in merito alle applicazioni helper) si fa sulla base dei tipi MIME.

Tornando al nostro esempio, una richiesta del client quale:

GET /products/toasters/index.html HTTP/1.0

User-agent: Mozilla/3.0

ecc.


riceverà come risposta dal server (supponendo che non ci siano errori) le metainformazioni, poi una riga vuota e quindi il contenuto del documento (in questo caso una pagina HTML costituita di 6528 byte):

HTTP/1.0 200 OK
Server: NCSA/1.4
Date: Tue, july 4, 1996 19:17:05 GMT
Content-type: text/html
Content-length: 6528
Content-language: en
Last-modified: Mon, july 3, 1996 15:05:35 GMT
                                                    <----- notare la riga vuota
<HTML>
<HEAD>
...
<TITLE>...</TITLE>
...
</HEAD >
<BODY>
...
</BODY>
</HTML>