tecnologie Web ed evoluzioni

Transcript

tecnologie Web ed evoluzioni
Primo passo (gopher)
Strumenti trasparenti
Internet presenta tutta una serie di strumenti di
lavoro sincroni
terminale remoto telnet e
file transfer ftp
e asincroni
invio messaggi mail
diffusione informazioni news
che si sono diffusi rapidamente
strumenti di visualizzazione a caratteri di informazioni
Creazione di un unico direttorio che nasconde
informazioni di allocazione
UNICO indice di informazioni per argomento
le
Allargamento della fascia di utenza
Secondo passo (WWW)
Unico insieme di informazioni accessibile a
tutti i possibili utenti
trasparenza allocazione (strutturazione ipertestuale)
gestione informazioni eterogenee (multimediali)
WWW (Mosaic, Netscape)
strumenti e protocolli con informazioni multimediali
strutturazione ipertestuale delle informazioni (trasparenza
della allocazione delle informazioni) e uso di interfacce
grafiche (semplicità di utilizzo)
•
•
•
evoluzione della mail e altri tool tradizionali
informazioni trasparenti e multimediali
protocolli eterogenei
ELABORAZIONE
FORM
INPUT UTENTE
OUTPUT
elemento
abcdef
VISIONE LOCALE
PROBLEMI
La diffusione velocissima del WEB ha ampliato
ulteriormente la fascia di utenza (in modo esponenziale)
ma introdotto problemi
di banda di occupazione di risorse
di sicurezza delle informazioni
di standardizzazione delle informazioni
di visualizzazione rapida delle informazioni
NODI REMOTI
RETE
Architetture Distribuite e Servizi di Rete - 1
Architetture Distribuite e Servizi di Rete - 2
World Wide Web (WWW)
CERN (1989)
Progetti di integrazione in forma ipertestuale delle
risorse esistenti in INTERNET
Scopi
• Trasparenza accesso e allocazione
• Presentazione multimediale
• Interfaccia unica per protocolli diversi
(integrazione con gli altri protocolli)
• Modificabilità e condivisione delle informazioni
Ampia scelta di interfacce testuali e grafiche
Possibilità di estensioni sperimentali del sistema
World Wide Web (Web)
Dal punto di vista tecnologico
Considerare un sistema o uno scenario
vuole dire considerare una serie di componenti con
funzionalità diverse
e una suite di protocolli con diverse motivazioni e
sviluppi differenziati
Componenti
•
•
•
•
Browser (presentazione e gestione richieste)
Server (accesso e invio informazioni)
Helper applications (particolari presentazioni)
Applicazioni CGI (esecuzione remota)
Specifiche standard
•
Ragioni del suo successo
• Diffusione a livello mondiale di Internet
• Uguale interfaccia utente indipendente dal tipo di
server, di client o di macchina
(=> facilità d'uso)
• Sistema modulare (=> scalabilità)
• Facilità di navigazione (browser come Netscape, Internet
Explorer, Lynx, Mozilla, Opera)
Architetture Distribuite e Servizi di Rete - 3
•
•
•
Sistema di nomi universale URI e URL
(Uniform Resource Identifier/Location)
Protocollo HTTP (HyperText Transfer Protocol)
Linguaggio HTML (HyperText Markup Language)
Interfaccia CGI (Common Gateway Interface)
W3C come comitato che cura tutti
gli sviluppi correnti
http://www.w3.org/
il comitato controlla lo sviluppo dei Web
Architetture Distribuite e Servizi di Rete - 4
SISTEMA WWW
URL Uniform Resource Locators
Cliente e sua interazione
applicazioni di supporto
nomi unici per le risorse del sistema
specificati dal cliente per determinare il servitore
• URN (Uniform Resource Names) e servizio di name
• Uniform Resource Locators (URL):
HTTP
client
utente
•
•
•
•
•
nodo contenente la risorsa (documento o dati)
protocollo di accesso alla risorsa (e.g. http, gopher)
numero di porta TCP (porta di default del servizio)
localizzazione della risorsa nel server
specifiche ulteriori sulla operazione nel server
sistema locale
Il Cliente HTTP usa un modo cliente/servitore nei confronti
di un server per volta e può anche interagire con risorse
locali
applicazioni esterne
applicazioni di supporto
HTTP
client
Sono riconosciuti i servizi internet e relativi protocolli =>
http, gopher, ftp, wais, telnet, news, nntp, e mail
http://www.address.edu:1234/path/subdir/file.ext
richiesta HTTP
risposta server
CGI
sistema locale
TCP / IP
<protocollo>[://<host>][:<porta>][<percorso>]
<protocollo>[://<host>][:<porta>][<percorso> ?[query]]
servizio
host
porta
percorso
sistema remoto
TCP / IP
rete
Le interazioni cliente/servitore usano il protocollo TCP
creando una connessione per ogni informazione da
ritrovare (tipica porta fissa 80)
Architetture Distribuite e Servizi di Rete - 5
ftp://username:[email protected]/path/file.ext
file:///drive/path/subdir/file.ext
Uso di default per localizzare risorse
Il ? per dare specifiche sulla richiesta
Un URL può anche determinare un insieme di risorse:
ad esempio versioni multilingue tra cui scegliere
Architetture Distribuite e Servizi di Rete - 6
HTTP request/response
HTTP HyperText Transfer Protocol
protocollo di interfaccia tra cliente e servitore
Uso di TCP e di connessione (porta 80 default)
Formato del messaggio di richiesta:
indirizzo del
server
metodo di
richiesta
campi
opzionali
path+ nome file
(in generale, i dati)
Caratteristiche HTTP:
•
•
•
request/response
one-shot connection
stateless
Request/response:
richiesta e ricezione di dati.
One-shot connection: la connessione TCP è mantenuta per il
tempo necessario a trasmettere i dati
Stateless:
non mantiene nessuna informazione tra
una richiesta e la successiva
in genere:
• richiesta del cliente con informazioni per il server
• risposta con informazioni dal server
il cliente può determinare una forma di scelta
(negoziazione) sulle informazioni ed i servizi
HTTP-message =
/ Simple-Request
/ Simple-Response
/ Full-Request
/ Full-Response
Metodo di richiesta
• GET
richiesta di leggere una pagina web
• HEAD
richiesta di leggere l’header di una pagina
web (es. contiene data ultima revisione del
documento)
• PUT
• POST
• DELETE
(usato nelle tecniche di caching nei client)
richiesta di pubblicare una pagina web
append di dati (di solito HTML form)
rimuove una pagina web
Campi opzionali:
• from:
identità dell'utente richiedente (debole forma di
autenticazione degli accessi)
• referer:
il documento contenente il link che ha portato
al documento corrente
GET URL
protocol vers.
; HTTP/0.9
headers
Browser
tipi accettati
; HTTP/1.0
delimitatori
CRLF
( dati opzionali)
Dati Utente
Formato del messaggio di risposta (CRLF)
progetto semplificato del server
NON c'è stato del server
•
•
Architetture Distribuite e Servizi di Rete - 7
status
informazioni
code
sull'oggetto
dati
status code: successo o fallimento (es. file not found)
informazioni sull'oggetto: data di modifica, tipo di
oggetto. Ogni tipo di oggetto (immagine, HTML, audio)
attiva una gestione specifica da parte del client
Architetture Distribuite e Servizi di Rete - 8
HTTP One-shot connection
solite 3 cifre in chiaro
applicazioni di supporto
HTTP
client
applicazioni estern
richiesta HTTP
risposta server
sistema locale
1xx: Informational
risposta di successo parziale temporanea
•
2xx: Success
Il server accetta la richiesta
200 OK (Get)
201 Created
206 Partial Content
•
CGI
sistema remoto
porta 80
TCP / IP
Codice di stato di risposta
TCP / IP
rete
3xx: Redirection
altre informazioni richieste
301 la informazione mossa definitivamente
302 la informazione mossa temporaneamente
304 la informazione non modificata
•
1. Il browser (http client) riceve un URL dall’utente
2. Il browser richiede al DNS di risolvere il nome della
macchina specificata nell’URL
3. Il DNS risponde con l’indirizzo IP
4. Il browser stabilisce una connessione TCP sulla porta
80 dell’indirizzo IP
5. Il browser manda una richiesta con il metodo:
GET nome_pagina _web
6. Il server risponde mandando la pagina web richiesta
Attenzione: la presenza in una pagina web di altri oggetti
(immagini, applets, ecc.) costringe il client ad aprire una
differente connessione per ognuno degli oggetti
necessari.
Il cliente http può eseguire richieste seguendo protocolli
differenti (es. ftp) ⇒ porte differenti
Architetture Distribuite e Servizi di Rete - 9
4xx: Client error
richiesta non soddisfatta per errore del cliente
(errore sintattico o richiesta non autorizzata)
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
•
5xx: Server error
richiesta corretta, ma il server non può soddisfarla
(problema del server o di applicazioni CGI)
500 Internal Error
501 Extension Header
•
Architetture Distribuite e Servizi di Rete - 10
Interazione HTTP
EVOLUZIONI DI HTTP
Request
GET /beta.html HTTP/1.0
Referer: http://www.alpha.com/alpha.html
Connection: Keep-Alive
User-Agent: Mozilla/4.61
Host: www.alpha.com:80
Cookie: name=value
Accept: image/gif, image/jpeg, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Expires: ...
If-modified-since: ...
Reply
HTTP/1.1 200 OK
Date: Fri, 12 Nov 2001 11:46:53 GMT
Server: Apache/1.3.3 (Unix)
Last-Modified: Mon, 12 Jul 2000 22:55:23 GMT
Accept-Ranges: bytes
Content-Length: 34
Content-Type: text/html
Si noti che le cose cominciano ad evolvere per facilitare le
operazioni
Keep-alive la connessione viene mantenuta
condizioni richieste condizionali
proxy
agenti intermedi che fanno cache
cookie
la possibilità di avere stato della interazione è
delegata al cliente che mantiene associazioni nome=valore
(cookie)
HTTP 1.1 introduce il concetto di “connessioni persistenti”
in cui una singola connessione TCP è utilizzata per
trasferimenti multipli (molte GET).
HTTP-NG è una proposta del W3C che usa una codifica
binaria dell’header al posto di quella ASCII di HTTP
HTTPS fornisce un trasferimento sicuro delle informazioni,
garantendo la riservatezza dei dati scambiati in una
sessione HTTP
WAP (Wireless Access Protocol) è uno stack di protocolli
per fornire l’accesso Web a dispositivi portatili, palmari,
telefoni cellulari, etc.
Non è solo un protocollo, ma tutta una suite per
affrontare diversi aspetti. Contiene un linguaggio di
markup (WML), un protocollo di trasporto, un protocollo
di sicurezza, etc.
Dei WAP proxy sono incaricati di trasformare le esistenti
pagine HTML in pagine WML per la visualizzazione sui
dispositivi mobili
HTTP1.1 RFC2616 (1999), state management RFC2109
HTML
Architetture Distribuite e Servizi di Rete - 11
HyperText Markup Language
Architetture Distribuite e Servizi di Rete - 12
HTML è un linguaggio di specifica delle informazioni che
deriva da SGML (Standard Generalized Markup Language).
E' un markup language (TeX, RTF)
I linguaggi markup usano dei tag definiti
funzionalmente per caratterizzare il testo incluso e
non definiti visualmente
Pagine HTML
Tag di Apertura <H1>
Testo da formattare
</H1> Tag di Chiusura
Tag
<APPLET
coppia Attributo e Valore dell’attributo
tag HTML
testo di tipo header 1:
<H1>testo</H1>
testo in grassetto: <STRONG>testo</STRONG> oppure
<B>testo</B>
link:
<A HREF = "destinazione"> descrizione </A>
immagini:
<IMG SRC = "myimage.gif">
applet Java:
<APPLET CODE="Hello.class" WIDTH=100 HEIGHT=80>
HTML molto semplice per non complicare il cliente
Visualizzazione dipendente dal browser
versione
1.0
2.0
2.1
3.2
browser
storico
Mosaic
Netscape/Microsoft
Netscape/Microsoft
proprietà
header, liste, enfasi
Inline Image, form
tabelle, allineamento
frame, ...
CODE="Hello.class"
WIDTH=100
HEIGHT=80
>
<html>
<head>
<title>
<meta name=Autore contenuto =pippo>
……… parte descrittiva opzionale della pagina
</head>
<body>
……… parte di contenuto informativo
</body>
</html>
Il body ha attributi tipo
background (sfondo),
bgcolor (colore sfondo),
text (colore testo),
per produrre una facile visualizzazione
Architetture Distribuite e Servizi di Rete - 13
Architetture Distribuite e Servizi di Rete - 14
Esempio pagina HTML (codice)
Esempio pagina HTML (visualizzazione)
<head> <title>Getting Started</title>
</head>
<body>
<h1> Getting Started <img src=../images/Start.gif
height=40 width=40 align=top>
</h1>
<p>
<h3><em>by Kathy Walrath and Mary Campione</em></h3>
<p>
The lessons in this trail show you the simplest possible
Java programs and tell you how to compile and run them.
They then go on to explain the programs, giving you the
background knowledge you need to understand how they
work.
<p>
...........
<p align=center>
<center>
<applet code=Animator.class codebase="../example"
width=55 height=68>
<param name=endimage value=10>
<param name=pauses value="2500|100">
</applet>
</center>
</p>
<hr>
<strong>Before you go on:</strong> If you don't own a
Java development environment, you might want to download
the
<a href="http://java.sun.com/products/jdk"> Java
Development Kit (JDK)</a>. The JDK provides a compiler
you can use to compile all kinds of Java programs. It
also provides an interpreter you can use to run Java
applications. To run Java applets, you can .............
Architetture Distribuite e Servizi di Rete - 15
Architetture Distribuite e Servizi di Rete - 16
Dynamic Web
Le prime pagine apparse sul Web erano scritte in HTML ed
erano statiche e immutabili
Evoluzione del Web verso una maggiore dinamicità
Dynamic Web: Vantaggi e Svantaggi
Pagine
statiche
Tipi di documenti:
Vantaggi
Svantaggi
Semplicità
Poco flessibili (modificate a
ogni cambiamento)
Affidabilità
Performance (e
caching)
Pagine statiche
Documenti Web il cui contenuto è definito al momento
della creazione e non cambia più.
Qualunque richiesta di pagina statica fornisce la stessa
risposta
Per informazioni con
Pagine
dinamiche elevata frequenza di
Pagine attive
Un documento attivo ha un contenuto NON
completamente specificato dal Server. È, ad esempio, un
pezzo di programma che viene mandato dal Server al
browser, dove viene eseguito localmente.
Un documento attivo può interagire con l’utente (con
altre risorse ed entità dalla parte dell’utente).
Il contenuto di un documento attivo non è mai fisso, ed è
diverso per utenti diversi
Architetture Distribuite e Servizi di Rete - 17
(Server
più
cambiamento
Per il browser sono
come delle pagine
statiche
Pagine dinamiche
Documenti Web che vengono creati dal Web Server solo
quando un browser li richiede. In tale caso il Server Web
attiva un’applicazione che crea il documento dinamico
che viene inviato al browser.
ll contenuto di un documento dinamico varia di
richiesta in richiesta
Costose
potenti)
Prestazioni
più
basse
(tempo di elaborazione, no
cache)
Richiedono capacità
programmazione
Pagine
attive
di
Massima dinamicità
(possono cambiare di
continuo)
Riversano costi sui Client
(browser più sofisticati e
macchine più potenti)
Caching possibile
Richiedono capacità
programmazione
Minore carico sul
Server
di
Problemi di portabilità
Problemi
di
sicurezza
(eseguono sui Client)
Architetture Distribuite e Servizi di Rete - 18
Programmazione client/server in WWW
Dynamic Web: Implementazione
Il supporto alla dinamicità (pagine dinamiche e
attive) richiede delle estensioni all’architettura
Client/Server del Web
HTTP
client
richiesta HTTP
risposta server
sistema locale
Nuovi componenti sul lato Client e/o sul lato Server
per supportare pagine dinamiche e attive.
sistema remoto
Possibilità di avere risposta con informazioni dinamiche
Tecnologie di supporto per pagine dinamiche:
Applicazioni CGI
Server side scripting technologies
(JSP, ASP, PHP,…)
Tecnologie di supporto per pagine attive:
Java (applet) codice Java scaricato dal server
sul client e che esegue sul client
Javascript linguaggio che permette di scaricare
codice che vine interpretato dal client
Architetture Distribuite e Servizi di Rete - 19
Che tipo di elaborazione delle informazioni e
dove viene eseguita
richiesta
Documento
HTML
risposta
statica
(la pagina è un file, non
modificabile)
CGI
dinamica
Java applet
pagina attiva
Java
dinamica con un
applicazione programma esterno
tipo di elaborazione
semplice trasferimento
file dal server
qualunque elaborazione
sul nodo server
Applet codice dal server
non modificabile,
esecuzione sul client
Javascript interpretato
sul client
server elabora
dinamicamente il codice
(in base alla richiesta),
esecuzione dinamica sul
client
Architetture Distribuite e Servizi di Rete - 20
Common Gateway Interface (CGI)
CGI --> standard per la interazione con le
risorse del server aldifuori del Web
Architettura WEB
Si estende la architettura del server Web con la possibilità
di andare al di fuori delle pagine HTML
applicazioni
esterne
HTTP
client
richiesta HTTP
risposta server
sistema locale
CGI
sistema remoto
CGI è uno standard per la interfaccia con applicazioni
esterne (residenti sulla macchina server)
CGI fornisce all’utente la capacità di eseguire una
applicazione sulla macchina server remota
Uso di un direttorio specifico per contenere i programmi
/cgi-bin/
URL da eseguire del programma
http://host/cgi-bin/program
La visione comincia a essere quella del Web
come sistema legacy di interazione
Strumento tipicamente non interattivo
Collo di bottiglia
richiesta
CGI
risposta
dinamica
tipo di elaborazione
qualunque, sul nodo server
Architetture Distribuite e Servizi di Rete - 21
Architetture Distribuite e Servizi di Rete - 22
Programmazione CGI
Una applicazione CGI permette agli utenti di eseguire una
applicazione sul nodo dove risiede il server www.
Applicazioni CGI possono essere scritte in:
·
·
·
·
·
·
·
C/C++
Fortran
PERL
TCL
Any Unix shell
Visual Basic
AppleScript
Hyper Text Transfer Protocol (HTTP)
Metodi di Request
•
GET: richiedo una specifica risorsa attraverso un
singolo URL. La richiesta contiene anche diversi
parametri, con lunghezza massima di un URL è 256
caratteri
POST: richiedo una specifica risorsa evidenziando
che seguirà un altro messaggio che contiene i
dettagli per la identificazione della risorsa stessa:
non ci sono limiti di lunghezza nei parametri di una
richiesta
e anche altri metodi che permettono di verificare la
•
normale attivazione di programma Unix, modello filtro con
variabili di ambiente predefinite
Devono rispettare l’interfaccia CGI con il server
Interfaccia tra server Web e la applicazione CGI
·
·
·
·
Client HTTP → server HTTP → CGI
variabili di ambiente
linea di comando
standard input
standard output
versione di una risorsa, la compatibilità del server, le
caratteristiche delle risorse ...
Il metodi GET e POST vengono gestiti trasparentemente
dal server HTTP
lo sviluppatore nono vede se la richiesta è avvenuta tramite
un metodo o l’altro
il metodo POST che non pone limiti di lunghezza massima
dei parametri
FORM pagine personalizzabili
Un FORM prevede una possibilità di intervento da
parte dell’utente
e usa GET o POST per passare informazioni al
server e ottenere effetti diversi
Architetture Distribuite e Servizi di Rete - 23
Architetture Distribuite e Servizi di Rete - 24
Client HTTP → server HTTP → CGI
Client HTTP → server HTTP → CGI
Attributi del form tag
Tipicamente, uso di form
<TITLE>Esempio di Form </TITLE>
<H1>Esempio di Form </H1>
<FORM METHOD="POST" ACTION="http://wwwlia.deis.unibo.it/cgi-bin/post-query">
Inserisci del testo: <INPUT NAME="entry">
e premi per invio: <INPUT TYPE="submit"
VALUE="Invio">
</FORM>
<TITLE>Esempio di Form </TITLE>
<H1>Esempio di Form </H1>
<FORM METHOD="POST" ACTION="http://wwwlia.deis.unibo.it/cgi-bin/post-query">
Inserisci del testo: <INPUT NAME="entry">
e premi per invio: <INPUT TYPE="submit"
VALUE="Invio">
</FORM>
Dove:
ACTION
URL di chi processa la query
METHOD
metodo usato per sottomettere il form:
POST il form con i dati è spedito come data body (metodo
Visualizzazione form
consigliato)
GET
il form con i dati è spedito attaccato all’URL
(action?name=value&name=value)
caso GET
http://www-lia.deis.unibo.it
/cgi-bin/get-query?entry=testo
caso POST
http://www-lia.deis.unibo.it
/cgi-bin/post-query
e come data body:
entry=testo
Architetture Distribuite e Servizi di Rete - 25
Architetture Distribuite e Servizi di Rete - 26
server HTTP → CGI
la CGI deve decodificare i dati in arrivo
arrivati con POST o GET
•
•
•
•
gli spazi ("") sono rimpiazzati da "+"
gli elementi del form sono coppie chiave - valore
tipo nome=antonio
ogni coppia è separata da &
caratteri non numerici sono introdotti o da un carattere
di escape "!"-> %21
caso GET
leggiamo i dati come stringhe dall'environment
var -> QUERY_STRING
I passi della CGI
decodificare i parametri
•
eseguire il programma
Applicazione CGI usa standard output per mandare al
server i dati
I dati devono essere preceduti da un header
Tipi di dati forniti:
· full document con il corrispondente MIME type (text/html,
text/plain per testo ASCII, etc.)
Esempio: per spedire una pagina HTML
Content-type: text/html
<HTML><HEAD>
<TITLE>output di HTML da script CGI</TITLE>
</HEAD><BODY>
<H1>titolo</H1>
semplice <STRONG>prova</STRONG>
</BODY></HTML>
caso POST
leggiamo i dati dallo standard input
•
Applicazione CGI → server HTTP
· reference a un altro documento
Esempio: riferisco un documento gopher
Content-type: text/html
Location: gopher://httprules.foobar.org/0
riportare il risultato al Web server
usando lo standard output
(pagina HTML o statica o dinamicamente costruita)
•
Architetture Distribuite e Servizi di Rete - 27
<HTML><HEAD>
<TITLE > Sorry ... it moved </TITLE>
</HEAD><BODY>
<H1>go to gopher </H1>
Now available at
<A HREF="gopher://httprules.foobar.org/0">
new location</A> of gopher server.
</BODY></HTML>
Architetture Distribuite e Servizi di Rete - 28
Applicazione CGI
Esempio:
generazione della pagina di risposta
(caso full document)
#include <stdio.h>
...............
Ambiente Complessivo di Esecuzione
I sistemi Web cominciano a delineare un nuovo
modello di operazione
cliente
intermedi (proxy, cache)
servitore
con accesso alle risorse del servitore
main(int argc, char *argv[]) {
int cl;
generazione di un full document in risposta
applicazioni
esterne
printf("Content-type: text/html");
cl = atoi(getenv("CONTENT_LENGTH"));
for(x=0;cl && (!feof(stdin));x++) {
...
elaborazione dell’input (stdin)
HTTP
client
sistema locale
richiesta
risposta
Proxy
CACHE
richiesta HTTP
risposta server
CGI
server WEB
...
Integrazione con risorse di calcolo accedute via server
}
printf("<H1>Query Results</H1>");
printf("You submitted ...");
for(x=0; x <= m; x++)
printf("...........", ... , ....);
}
Sistemi a diversi livelli (multitier)
in cui la elaborazione risultante viene fornita
in modo legacy (Web compatibile) ma
ottenuta tramite la interazione di molte entità in gioco
Il sistema comincia ad avere stato e a diventare il
punto di accesso ad una infrastruttura
Architetture Distribuite e Servizi di Rete - 29
Architetture Distribuite e Servizi di Rete - 30
Architetture evolute WEB
PROBLEMI Web
• Proxy: Programma applicativo in grado di agire sia
I limiti più sentiti sono:
limiti di operazione e alle opzioni
mancanza di stato nel protocollo
mancanza di sicurezza
come Client che come Server al fine di effettuare
richieste per conto di altri Clienti. Le Request vengono
processate internamente oppure vengono ridirezionate al
Server
Un proxy deve interpretare e, se necessario, riscrivere le
Request prima di inoltrarle
Web server e le evoluzioni del protocollo tendono a fare
permanere la connessione per consentire di usare il canale
per trasferimenti multipli
• Gateway: Server che agisce da intermediario per altri
Server
Al contrario dei proxy, il gateway riceve le request come
se fosse il server originale ed il Client non è in grado di
identificare che la Response proviene da un gateway
• Tunnel: Programma applicativo che agisce come “blind
relay” tra due connessioni
Una volta attivo (in gergo “salito”) non partecipa alla
comunicazione http
• Cache: Repository locale di messaggi di Response,
compreso il sottosistema che controlla la consistenza dei
dati. Qualsiasi Client o Server (tranne i tunnel) può
includere una cache per motivi di performance
Un Response si dice Cacheable se il contenuto è
memorizzabile senza perdita di consistenza
Architetture Distribuite e Servizi di Rete - 31
Server Web (Apache)
canali che vengono mantenuti per una serie di trasferimenti
di informazioni coordinate
Si bilancia il costo del canale con una sequenza di
operazioni sullo stesso
i browser tendono a memorizzare localmente una serie di
attributi che forniscono automaticamente ai server da cui li
hanno ottenuti
per simulare lo stato della interazione
Un dominio mantiene una storia delle visite precedenti
dalla parte del cliente
dalla parte del server
Architetture Distribuite e Servizi di Rete - 32
Sistemi con stato
STATO
Accesso a risorse del server
cookies (sul cliente)
attraverso la interazione con il sistema locale al server
un cliente può memorizzare (con scadenza) attributi (stato)
da usare per successive interazioni
cookies anche per specificare preferenze utente
spesso uno stesso server ha molti cookies per pagina che
vengono ripresentati solo al servitore corretto
formato nome = valore
mantenuti sul disco permanente del cliente
cookies con scadenza e anche cifrati
log attività (sul server)
un server può tenere (con scadenza) la storia delle
interazioni da usare successivamente
si possono memorizzare molti eventi
Pagina richiesta, Host remoto, Tipo del Browser, Pagina
Riferita, Data eTempo
Necessità di applicazioni di esplorazione dei dati
Lo stato viene accumulato fuori dal Web
che rappresenta il vincolo di funzionamento
Architetture Distribuite e Servizi di Rete - 33
Architetture Distribuite e Servizi di Rete - 34
COOKIES
Web computing
sono coppie di attributo e valore
Il primo passo è la possibilità di superare i vincoli del
protocollo HTTP e delle interazioni consentendo di
integrare i diversi componenti e di ottenere nuove forme di
accesso
Se si vogliono variare le suddivisioni tra le due parti
interagenti
sono in realtà una tupla di stringhe:
•
Key: identifica univocamente un cookie all’interno di un
dominio:path
•
Value: valore associato al cookie (è una stringa di max
255 caratteri)
•
Path: posizione nell’albero di un sito al quale è associato
(di default /)
•
Domain: dominio dove è stato generato
•
Max-age: (opzionale) numero di secondi di vita
(permette la scadenza di una sessione)
•
Secure: (opzionale) non molto usato prevede una
verifica di correttezza da parte del server
•
Version: identifica la versione del protocollo di gestione
dei cookie
Elaborazione sul client via applet
Elaborazione sul server via CGI
Sono presentati in ogni richiesta dal cliente al
servitore
Possono essere anche cifrati (in modo da non
dischiudere informazioni private)
Applet scaricate da una richiesta dal server
CGI per accesso alle risorse del server
Automatismi nella invocazione
Trasparenza per l'utilizzatore
Architetture Distribuite e Servizi di Rete - 35
Architetture Distribuite e Servizi di Rete - 36
CGI: problemi, limiti e costi
Ad ogni richiesta, viene attivato un processo che specifica
la CGI (overhead della generazione)
Tempo di attesa per eventuali altre richieste
contemporanee (o problemi di mutua esclusione)
Primi passi evolutivi
FAST CGI prevedono un processo già attivo per
ogni servizio CGI specificato
Sono state proposte API per funzioni standard
ISAPI Microsoft, NISAPI Netscape
Problemi di portabilità:
browser diversi non tutti compatibili
Architetture Distribuite e Servizi di Rete - 37
Architetture Distribuite e Servizi di Rete - 38
INTERNET: PRINCIPALI PROBLEMI
Problema del traffico
alcuni formati di informazioni possono richiedere un
eccesso di banda
necessità di adeguare le infrastrutture
Problema della sicurezza
la trasparenza richiede la integrazione con i sistemi locali di
esecuzione/visualizzazione: intrusioni o virus da controllare
riservatezza delle transazioni e autenticazione clienti
Problema della visualizzazione
alcuni formati richiedono una lunga visualizzazione: tempi
di accesso molto rallentati
sfruttare la possibile concorrenza/asincronismo
Uso di clienti con strategie adatte a
abbreviare il tempo di risposta
favorire il browsing delle informazioni
(web navigation e ricerche mediante robot,
spider, worm, ecc.)
evoluzione dei protocolli
La ricerca di informazioni sul WEB
Web come ipertesto (grafo) con milioni di nodi → problema
di reperire le informazioni attraverso i link
Esistono indici del web (detti anche cataloghi o
directories), realizzati per facilitare la ricerca di informazioni
su Internet
Organizzazione indici:
·
·
·
·
alfabetica
per argomento (gerarchici)
per area geografica (gerarchici)
con possibilità di ricerca (parole chiave)
Gli indici sono costruiti utilizzando dei programmi che
esplorano i site web presenti in rete.
Programmi più diffusi:
· search engine
· spider
· crawler
· worm
· knowbots (knowledge robots)
per garantire una apertura alle esigenze man mano
determinate
Architetture Distribuite e Servizi di Rete - 39
Architetture Distribuite e Servizi di Rete - 40
Le dimensioni del sistema
Come viene processata una query
AltaVista (http://altavista.digital.com) Web index:
· 30 milioni pagine da 275,600 servers
· 4 milioni articoli da 14,000 Usenet news groups
E’ acceduto più di 21 milioni di volte al giorno
(dati di Ottobre 96)
Google (www.google.com), dati 2001.
Dati memorizzati:
· indicizza 3 miliardi di pagine web
· 700 milioni di messaggi usenet
Statistiche di accesso:
· 150 milioni di ricerche al giorno
Architettura:
· Cluster Linux di più 10.000 macchine
Continua evoluzione:
nuovi motori o nuove aggregazione dei risultati
mamma.com
teoma.com
vivisimo.com
Architetture Distribuite e Servizi di Rete - 41
Architetture Distribuite e Servizi di Rete - 42
I motori di ricerca
I motori di ricerca
Struttura di supporto tipica:
Puntatori Puntatori
a URL
a pagine
Codice
hash
URL
Pagina
URL
Pagina
Tabella URL
2
4
5
0
1
2
3
..
..
..
n
Fase di indicizzazione
URL
11
Tabella hash
Heap
Due fasi: ricerca e indicizzazione
Passi della ricerca (algoritmi breadth-first, depth-first):
· prelevare un URL
· eseguire hash URL
· Se hash URL è in Tabella hash allora STOP
altrimenti
· aggiungere hash URL in Tabella hash
· aggiungere Puntatori a URL e a pagina in Tabella
· aggiungere URL e Pagina (o titolo) in Heap
· ripetere tutti i passi per ogni link della pagina
Problemi:
· dimensioni del grafo web
· punto di partenza della ricerca
· peso dei link (anche autorità e centralità)
· tipo di ricerca: depth-first → stack overflow
breadth-first → dimensioni heap
· come trattare i link presenti nelle active map (CGI)
·
URL obsoleti e macchine non raggiungibili
Architetture Distribuite e Servizi di Rete - 43
La procedura di indexing estrae le parole chiave da ogni
pagina (o titolo) web memorizzati nell’heap nella fase di
ricerca (sintesi delle pagine)
Per trovare le parole chiave:
· si scartano le parole poco significative (articoli, etc.)
· si scelgono parole che nella pagina hanno la frequenza
maggiore (es. Lycos)
Per ogni parola ottenuta si memorizza in una tabella la
parola e l’URL che la contiene
Alla fine della indicizzazione si ordina la tabella sulle parole
e si salva su file che verrà consultato per le ricerche da
parte degli utenti
problemi:
· titoli pagine spesso poco significativi
· analisi intere pagine costosa
· pagine solo video o audio, oppure active map
Ricerche e indicizzazioni cooperative
Harvest è un motore di ricerca che richiede a tutti i server
www di eseguire una applicazione per indicizzare
localmente la macchina
Un motore centrale raccoglie tutti i risultati
Problema della sicurezza
Architetture Distribuite e Servizi di Rete - 44
I meta-searcher
Dati recenti su Web
Crescita di Internet
Effettuano la ricerca delle informazioni su più indici del web
contemporanemente.
Un meta-searcher invia la stessa query
contemporaneamente a più indici del web
e NON contiene un database
180.000.000
160.000.000
140.000.000
120.000.000
100.000.000
80.000.000
60.000.000
40.000.000
20.000.000
Query
Motore di ricerca
(Yahoo!)
Query
Query
0
81
Motore di ricerca
(Lycos)
Motore di ricerca
(Altavista)
83
85
87
89
90
91
92
93
94
95
96
97
98
99
00
01
02
numero di macchine collegate a Internet
1.000.000.000
100.000.000
10.000.000
1.000.000
Query
100.000
10.000
Servizio di Meta Search
1.000
100
10
Motore di ricerca
(Yahoo!)
Motore di ricerca
(Lycos)
Motore di ricerca
(Altavista)
1
81
83
85
87
89
90
91
92
93
94
95
96
97
98
99
00
01
02
numero di macchine collegate a Internet
(scala logaritmica)
Architetture Distribuite e Servizi di Rete - 45
Architetture Distribuite e Servizi di Rete - 46
La crescita di Internet
Architettura WEB
1.400.000
Si estende la architettura del server Web con la possibilità
di andare al di fuori delle pagine HTML
Numero di domini .
1.200.000
1.000.000
800.000
600.000
400.000
200.000
0
88
90
92
94
96
98
Anno
numero di domini Internet
La visione comincia a essere quella del Web
come sistema legacy di interazione
Architetture Distribuite e Servizi di Rete - 47
Architetture Distribuite e Servizi di Rete - 48