Il world wild web

Materie:	Appunti
Categoria:	Informatica
Download:	121
Data:	23.10.2001
Numero di pagine:	15
Formato di file:	.doc (Microsoft Word)

1) Il World Wide Web
Il World Wide Web (detto anche Web, WWW o W3) è 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.
Figura 1-1: Uso della CPU in un browser multithreaded
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 è:
http://somewhere.net/products/index.html
nella quale:
http://
è il metodo di accesso
somewhere.net
è il nome dell'host
/products/index.html
è l'identità della risorsa
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:
http
protocollo nativo del Web
ftp
file transfer protocol
news
protocollo per l'accesso ai gruppi di discussione
gopher
vecchio protocollo per il reperimento di informazioni; concettualmente simile al Web, gestisce solo testo
mailto
usato per spedire posta
telnet
protocollo di terminale virtuale, per effettuare login remoti
file
accesso a documenti locali
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:
http://somewhere.net:8000/products/index.html
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:
http://somewhere.net/products/toasters/index.html
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:
http://somewhere.net/~username/
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:
...questo è grassetto e questo no...
indica che la parola grassetto deve essere visualizzata in grassetto (bold). Quindi il testo in questione dovrà apparire come segue:
...questo è grassetto e questo no...
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:

...
...
...
...
Il ruolo di questi marcatori è il seguente:
HTML
Inizio e fine del documento
HEAD
Questa parte non viene mostrata e contiene metainformazioni sul documento (creatore, data di "scadenza", e se c'è, il titolo)
TITLE
Il titolo del documento: appare come titolo della finestra che lo contiene
BODY
Il suo contenuto viene visualizzato nella finestra
Tag per la formattazione
Alcuni dei tag esistenti per la formattazione del testo sono i seguenti:
...
Grassetto (bold)
...
Corsivo (italic)
...
Intestazione (heading) di livello x (da 1 a 6)
...
Testo visualizzato esattamente come è scritto (preformatted), con spazi multipli, caratteri di fine linea, ecc.
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 ();
• divisori (,
,);
• colore di sfondo della pagina;
• suddivisione della finestra fra più pagine (, ).
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:
oppure
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 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 è:
...testo visibile...
Nella pagina la stringa testo visibile appare sottolineata e, di norma, di colore blu:
...testo visibile...
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:
GET
Richiesta di ricevere un oggetto dal server
HEAD
Richiesta di ricevere la sola parte head di una pagina html
PUT
Richiesta di mandare un oggetto al server
POST
Richiesta di appendere sul server un oggetto a un altro (vedremo che si usa molto)
DELETE
Richiesta di cancellare sul server un oggetto
LINK e UNLINK
Richieste di stabilire o eliminare collegamenti fra oggetti del server
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:
Esito
Codice numerico
Specifica testuale
Tutto ok
200
OK
Documento spostato
301
Moved permanently
Richiesta di autenticazione
401
Unauthorized
Richiesta di pagamento
402
Payment required
Accesso vietato
403
Forbidden
Documento non esistente
404
Not found
Errore nel server
500
Server error
Dunque, ad esempio, si potrà avere
HTTP/1.0 200 OK
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:
Server: ...
Identifica il tipo di server
Date: ...
Data e ora della risposta
Content-type: ...
Tipo dell'oggetto inviato
Content-length: ...
Numero di byte dell'oggetto inviato
Content-language: ...
Linguaggio delle informazioni
Last-modified: ...
Data e ora di ultima modifica
Content-encoding: ...
Tipo di decodifica per ottenere il content
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
MIME type/MIME subtype
Vari tipi MIME sono definiti, e molti altri continuano ad aggiungersi. I più comuni sono:
Type/Subtype
Estensione
Tipologia delle informazioni
text/plain
.txt, .java
testo
text/html
.html, .htm
pagine html
image/gif
.gif
immagini gif
image/jpeg
.jpeg, .jpg
immagini jpeg
audio/basic
.au
suoni
video/mpeg
.mpeg
filmati
application/octet-stream
.class, .cla, .exe
programmi eseguibili
application/postscript
.ps
documenti Postscript
x-world/x-vrml
.vrml, .wrl
scenari 3D
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