Reti dei calcolatori - Sintesi

PROTOCOLLI A LIVELLO DI APPLICAZIONE

Un protocollo a livello di applicazione definisce come i processi di un’applicazione, in esecuzione

su sistemi terminali diversi, si scambiano i messaggi. In particolare, un protocollo a livello di

applicazione definisce:

- I tipi di messaggi scambiati (per esempio, di richiesta o di risposta);

- La sintassi dei vari tipi di messaggio (per esempio, quali sono i campi nel messaggio e come

vengono descritti);

- La semantica dei campi, ossia il significato delle informazioni che contengono;

- Le regole per determinare quando e come un processo invia e risponde ai messaggi.

Esistono fondamentalmente due tipi di protocollo:

- Protocolli di pubblico dominio: destinati nelle RFC (); e consente l’interoperabilità (HTTP,

SMTP, ecc);

- Protocolli proprietari: KaZaA.

WEB E HTTP

Il World Wide Web è un’applicazione nata agli inizi degli anni ’90 da parte di Tim Berners Lee, che

ha scritto il primo server per il Web e il primo programma client. La cosa più attraente per gli utenti

consiste nel fatto che il Web opera su richiesta (on demand): gli utenti possono avere ciò che

vogliono, quando vogliono.

L’idea: - Una pagina web è costituita da oggetti;

- Un oggetto può essere un file HTML, un’immagine JPEG, un’applet Java, un file audio;

- Una pagina web è formata da un file base HTML che include diversi oggetti referenziati;

- Ogni oggetto è referenziato da un Uniform Resource Locator o URL.

PROTOCOLLO HTTP

HTTP (hypertext transfer protocol), protocollo a livello di applicazione del web, definito in [RFC

1945  HTTP 1.0] e [RFC 2068  HTTP 1.1] costituisce il cuore del Web. Questo protocollo è

implementato in due programmi, client e server, in esecuzione su sistemi terminali diversi, che

comunicano tra loro scambiandosi messaggi HTTP. Il protocollo definisce la struttura di questi

messaggi e come client e server si scambino i messaggi. Il client infatti è il browser che richiede,

riceve e “visualizza” gli oggetti del Web; il server web invia oggetti in risposta a una richiesta.

Il protocollo HTTP utilizza TCP (anziché UDP) come protocollo di trasporto. Il client per prima

cosa inizia una connessione TCP (crea un socket) con il server usando la porta 80. Il server accetta

la connessione TCP dal client. A questo punto, il client HTTP (browser) ed il server HTTP (server

web) si scambiano messaggi HTTP. Al termine la connessione TCP è chiusa.

HTTP è un protocollo senza stato (stateless protocol), infatti il server non mantiene informazioni

sulle richieste fatte dal client.

In molte applicazioni Internet, client e server comunicano per un ampio periodo di tempo. Gli

sviluppatori dell’applicazione devono prendere una decisione importante: ciascuna coppia

richiesta/risposta deve essere inviata su una connessione TCP separata o devono essere inviate tutte

sulla stessa connessione TCP ? Nel primo approccio si dice che l’applicazione usa connessioni non

persistenti, mentre nel secondo, usa connessioni persistenti.

Per le connessioni non persistenti viene trasmesso un solo oggetto sulla stessa connessione TCP

(HTTP 1.0 usa connessioni persistenti), mentre per le connessioni persistenti più oggetti possono

essere trasmetti su una singola connessione TCP tra client e server (HTTP 1.1 usa connessioni

persistenti nella modalità di default).

Definiamo il round trip time (RTT), che rappresenta il tempo impiegato da un piccolo pacchetto

per viaggiare dal client al server e poi ritornare al client. Il tempo di risposta totale comprende:

- Un RTT per inizializzare la connessione TCP;

- Un RTT perché ritorni la richiesta HTTP di connessione e i primi byte della risposta HTTP;

- Tempo di trasmissione del file;

Quindi in totale, il tempo sarà = 2RTT + tempo di

trasmissione.

Pertanto, per le connessioni non persistenti, ogni

trasferimento richiede 2 RTT per oggetto, si avrà

overhead del sistema operativo per ogni

connessione TCP in quanto dovrà svolgere sempre

operazioni standard ripetute quali: inizializzazione

delle strutture dati, allocazione del buffer ecc.

Nelle connessioni persistenti il server lascia aperta

la connessione TCP dopo l’invio di una risposta,

pertanto i successivi messaggi vengono spediti sulla

stessa connessione. È importante fare a questo

punto una distinzione, infatti le connessioni persistenti possono essere di due tipi:

- Una di seguito all’altra (back-to-back): in

questo caso il client invia una nuova

richiesta solo quando ha ricevuto la

risposta precedente, ed è necessario un

RTT per ogni oggetto referenziato;

- Senza aspettare le risposte pendenti

(pipelining): in questo caso il client invia

una richiesta non appena incontra un

oggetto referenziato, si ha un solo RTT per ogni oggetto referenziato, tale tecnica è di default in

HTTP 1.1;

FORMATO DEI MESSAGGI HTTP

I tipi di messaggi HTTP possono essere suddivisi in:

- Messaggi di richiesta;

- Messaggi di risposta;

MESSAGGIO DI RICHIESTA HTTP

Un messaggio di richiesta HTTP è scritto in testo ASCII: I tipi di metodi presenti in HTTP

1.0 sono GET, POST ed HEAD

(in quest’ultimo l’oggetto non è

incluso nella risposta del

server), mentre in HTTP 1.1

sono stati aggiunti due metodi,

quali PUT (che include un file

nel corpo dell’entità e lo invia al

percorso specificato nel campo

URL) e DELETE (che cancella

il file specificato nel campo

URL).

FORMATO MESSAGGIO DI

RISPOSTA

Il messaggio di risposta è di tipo

testuale ed è composta da 3

parti:

- Riga di stato (status-line);

- Sezione header;

- Body (contenuto della risposta); RIGA DI STATO: la riga di stato riporta un

codice a tre cifre catalogato nel seguente modo:

- 1xx: Informational (messaggi

informativi)

- 2xx: Successfull (la richiesta è stata

soddisfatta)

- 3xx: Redirection (non c’è risposta

immediata, ma la richiesta è sensata e

viene detto come ottenere la risposta)

- 4xx: Client error (la richiesta non può

essere soddisfatta perché sbagliata)

- 5xx: Server error (la richiesta non può essere soddisfatta per un problema interno del server)

Alcuni codici di risposta “famosi”:

- 200 OK. Il server ha fornito correttamente il contenuto nella sezione body;

- 301 Moved Permanently. La risorsa che abbiamo richiesto non è raggiungibile perché è stata

spostata in modo permanente;

- 302 Found. La risorsa è raggiungibile con un altro URI indicato nel header Location. Di norma i

browser eseguono la richiesta all’URI indicato in modo automatico senza interazione dell’utente;

- 400 Bad Request. La risorsa richiesta non è comprensibile al server;

- 404 Not Found. La risorsa richiesta non è stata trovata e non se ne conosce l’ubicazione. Di

solito avviene quando l’URI è stato indicato in modo incorretto, oppure è stato rimosso il

contenuto dal server;

- 500 Internal Server Error. Il server non è in grado di rispondere alla richiesta per un suo

problema interno;

- 505 HTTP Version not supported. La versione di HTTP non è supportata.

NOTA: la sezione server indica il tipo e la versione del server; e il content-type indica il tipo di

contenuto restituito.

Il comando telnet ci consente di collegarci ad un server

web e scaricare la home page mediante HTTP.

INTERAZIONE UTENTE-SERVER: I COOKIE

I cookie permettono di rimediare parzialmente alla mancanza di stato del protocollo HTTP. Questi

consentono ai siti di tener traccia degli utenti. Per poter usare i cookie abbiamo bisogno di:

- Una riga di intestazione nel messaggio di risposta HTTP;

- Una riga di intestazione nel messaggio di richiesta HTTP;

- Un file cookie mantenuto sul sistema terminale dell’utente e gestito dal browser dell’utente;

- Un database sul sito. Facciamo un esempio: Un utente

accede sempre a Internet dallo stesso

PC. Visita per la prima volta un

particolare sito di commercio

elettronico. Quando la richiesta

HTTP iniziale giunge al sito, il sito

crea un identificativo unico (ID) e

una entry nel database ID.

Cosa possono contenere i cookie ?

- Autorizzazione;

- Numero di carta di credito;

- Raccomandazioni;

- Stato della sessione dell’utente (email).

I cookie sono spesso criticati per via della privacy perché:

- Permettono ai siti di tracciare le abitudini degli utenti;

- I motori di ricerca usano il reindirizzamento e i cookie per saperne ancora di più;

- Le agenzie pubblicitarie ottengono informazioni dai siti;

CACHING WEB

Una cache web, nota anche come server proxy, è

un’entità di rete che soddisfa richieste HTTP per

conto di un server web d’origine. La cache web

ha una propria memoria su disco in cui conserva

copie di oggetti recentemente richiesti. Il browser

di un utente può essere configurato in modo che

tutte le richieste HTTP dell’utente vengano

innanzitutto dirette alla cache web. Una volta

configurato il browser, ogni richiesta di oggetto

da parte del browser viene inizialmente diretta

alla cache. A questo punto, se l’oggetto è presente

nella cache, la cache fornisce l’oggetto, altrimenti la cache richiede l’oggetto al server d’origine e

poi lo inoltra al client.

Si noti che la cache è contemporaneamente server e client. Tipicamente la cache è istallata da un

ISP (ovvero un’università, un’azienda o un ISP residenziale).

La caching produce alcuni vantaggi:

- Riduce i tempi di risposta alle richieste dei client;

- Riduce il traffico sul collegamento di accesso a Internet;

- Internet arricchita di cache consente ai provider “scadenti” di fornire dati con efficacia.

GET CONDIZIONALE

Sebbene il caching riduca i tempi di risposta percepiti dall’utente, introduce un nuovo problema: la

copia di un oggetto che risiede in cache potrebbe essere stata aggiornata sul server web originale.

Fortunatamente, HTTP presenta un meccanismo che permette alla cache di verificare se i suoi

oggetti sono aggiornati. Questo meccanismo è chiamato GET condizionale. Un messaggio di

richiesta HTTP viene detto messaggio di GET condizionale se:

- Usa il metodo GET;

- Include una riga di intestazione If-Modified-Since: <data>.

La cache specifica la data della copia dell’oggetto nella richiesta HTTP. La risposta del server non

contiene l’oggetto se la copia presente nella cache è già aggiornata.

TRASFERIMENTO DI FILE: FTP

Il File Transfer Protocol (FTP) è utilizzato per il trasferimento file a/da un host remoto. Questo

protocollo si basa sul modello client/server, infatti il client può essere identificato co