Reti dei calcolatori - Appunti

2.1.4 SERVIZIO DI TRASPORTO OFFERTI DA INTERNET

Internet (come ogni TCP/IP) mette a disposizione delle applicazioni due protocolli di

trasporto: UDP e TCP.Ovvero due protocolli che offrono un modello di servizio diverso.

TCP prevede un servizio orientato alla connessione e il trasporto affidabile dei dati.

Quando un’applicazione invoca TCP come protocollo di trasporto, riceve i seguenti

servizi.

Servizio orientato alla connessione: TCP fa in modo che client e server si

scambino informazioni di controllo a livello di trasporto prima che i messaggi a

livello di applicazione comincino a fluire. Questa procedura detta di

handshaking, mette in allerta client e server preparandoli alla partenza dei

pacchetti. Dopo tale fase, si dice che esiste una connessione TCP tra le socket

dei due processi e tale connessione è full-duplex, nel senso che i due processi

possono scambiarsi contemporaneamente messaggi sulla connessione.

Servizio di trasporto affidabile: i processi comunicanti possono contare su

TCP per trasportare i dati senza errori e nell’ordine opportuno.

Controllo della congestione: servizio che riguarda il benessere generale di

Internet e non quello diretto dei processi comunicanti. Il meccanismo di

controllo della congestione esegue una strozzatura del processo di invio quando

il traffico di rete appare eccessivo. Il controllo di congestione di TCP cerca anche

di confinare le connessioni TCP all’interno della loro porzione di ampiezza di

banda.

Controllo di flusso: il mittente può sovraccaricare il destinatario;

Non vengono garantiti temporizzazione e ampiezza di banda e gli sviluppatori di

applicazioni in tempo reale solitamente scelgono UDP anziché TCP.

UDP: è un protocollo di trasporto leggero e senza fronzoli, dotato di un modello di

servizi minimalista. UDP è senza connessione, non necessita quindi di handshaking, e

fornisce un servizio di trasferimento dati inaffidabile. Così, quando un processo invia

un messaggio tramite la socket UDP, il protocollo non garantisce che questo raggiunga

il processo di destinazione. UDP non include un meccanismo di controllo della

congestione, pertanto un processo d’invio UDP può spingere i dati al livello sottostante

di rete a qualsiasi frequenza. UDP non offre:

- Setup della connessione affidabilità;

- Controllo di flusso;

- Controllo della congestione;

- Temporizzazione;

- Ampiezza di banda minima;

indirizzamento: un processo su di un host per poter inviare un messaggio ad un

processo su un altro host deve identificare il processo destinatario. Gli indirizzi degli

host nelle applicazioni internet vengono identificati attraverso i loro indirizzi IP. Un

indirizzo IP è una stringa di 32 bit che identifica univocamente l’host. Oltre a conosere

l’indirizzo dell’host cui è destinato il messaggio, il mittente deve anche identificare il

processo destinatario. Questa informazione è necessaria in quanto, in generale,

sull’host potrebbero essere in esecuzione molte applicazioni di rete. Il numero di

porta destinazione risponde a questo compito (i server web sono identificati con la

porta 80, mentre i server posta sono identificati dalla porta 25). L’identificatore

comprende sia l’indirizzo Ip che i numeri di porta associati al processo in esecuzione

su un host.

2.1.5 PROTOCOLLI A LIVELLO DI APPLICAZIONE

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

in esecuzio 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 terminare quando e come un processo invia e risponde ai

messaggi;

Alcuni protocolli a livello di applicazione vengono specificati dalle RRFC e sono

pertanto di pubblico dominio(http,SMTP). Altri protocolli a livello di applicazione

sono privati e volutamente non disponibili al pubblico (per esempio in molti sistemi di

condivisione dei file P2P e KAzaA).

E’ importante distinguere tra applicazioni di rete e protocolli a livello di applicazione.

Un protocollo a livello di applicazione è solo una parte di un’applicazione di rete,

ad esempio http è un protocollo a livello di applicazione del Web, che definisce il

formato e la sequenza dei messaggi che vengono scambiati tra browser e server web.

E’ pertanto solo una parte dell’applicazione web.

2.2 WEB e http

Nei primi anni ’90, comparve sulla scena una nuova importante applicazione: il World

Wide Web. Il Web è l’applicazione Internet che ha catturato l’attenzione del pubbico,

cambiando profondamente il modo di interagire all’interno e all’esterno degli ambienti

di lavoro. Venne ideato da Berners Lee nel 1994 e fu il primo programma client. Inoltre

Bernes Lee scrisse la prima versione di formattazione http..

Il Web opera su richiesta, ovvero gli utenti possono avere ciò che vogliono, quando

vogliono. Inoltre è facilissimo per tutti rendere disponibili informazioni sul Web.

HTTP (Hypertext transfer protocol), protocollo a livello di applicazione web,

definito in [RFC 1945] e [RFC 2616], e costituisce il cuore del Web. Questo protocollo è

implementato in due programmi, client e server, in eseczione su sistemi terminali

diversi, che comunicano tra loro scambiandosi messaggi http.

Una pagina web , detta anche documento, è costituita da oggetti. Un oggetto è

semplicemente un file indirizzabile tramite un solo URL. La maggioranza delle pagine

web consiste di file base HTML e diversi oggetti referenziati. Il file base HTML

referenzia gli altri oggetti nella pagina tramite il loro URL. Ogni URL ha due

componenti: il nome dell’host del server che ospita l’oggetto e il percorso

dell’oggetto.

Un browser web implementa il lato client di http. Un server web, che implementa il

lato server di http, ospita oggetti web, indirizzabili tramite URL. Dunque l’http utilizza

un modello client/server, dove il client è rappresentato dal browser che richiede,

riceve e visualizza gli oggetti del Web e il server web invia oggetti in risposta a una

richiesta.

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

cosa inizia una connessione TCP con il server usando la porta 80. Il server accetta la

connessione TCP dal client e il client http (browser) e il server http (server web) si

scambiano messaggi http. Al termine la connessione TCP è chiusa.

HTTP è un protocollo senza stato, ovvero il server non mantiene informazioni sulle

richieste fatte dal client.

NB: un server web è sempre attivo,ha indirizzo IP fisso e risponde potenzialmente alle

richieste da milioni di diversi browser.

2.2.2 Connessioni persistenti e non persistenti

Le connessioni non persistenti si definiscono in quanto almeno un oggetto viene

trasmesso su una stessa connessione TCP (http 1.0 usa connessioni persistenti),

mentre le connessioni persistenti prevedono che più oggetti possono essere

trasmessi su una singola connessione TCP tra client e server (http 1.1 usa connessioni

persistenti nella modalità di default).

Supponiamo che l’utente immetta l’URL:

www.someSchool.edu/someDepartment/home.index

che contiene testo e riferimenti ad immagini per un totale di 10 oggetti jpeg. Ecco

cosa avviene:

1. Il processo client http inizializza una connessione TCP con il server

www.someSchool.edu sulla porta 80, che è la porta di default per http.

Associate alla connessione TCP ci saranno anche una socket al client e una al

server.

2. Il client http, tramite la porta socket, invia al server un messaggio di richiesta

http che include il percorso /someDepartment/home.index;

3. Il processo server http riceve il messaggio di richiesta attraverso la propria

socket associata alla connessione, recupera l’oggetto

/someDepartment/home.index dalla memoria centrale, lo incapsula in un

messaggio di risposta http che vinee inviato al client attraverso la socket.

4. Il processo http comunica a TCP di chiudere la connessione. Questi in realtà non

termina la connessione fino a quando non è certo che il client abbia ricevuto

integro il messaggio di risposta;

5. Il client http riceve il messaggio di risposta. La connessione TCP termina Il

messaggio indica che l’oggetto incapsulato è un file HTML. Il client estrae il file

dal messaggio di risposta, esamina il file HTML e trova i riferimenti ai 10 oggeti

JPEG.

6. Vengono quindi ripetuti i primi 4 passi per ciascuno degli oggetti JPEG

referenziati.

Schema del tempo di risposta: è il tempo impiegato da un piccolo pacchetto per

andare dal client al server e ritornare al client. Il tempo di risposta totale include i

ritardi di propagazione, di accodamento nei router e nei commutatori intermedi e di

elaborazione del pacchetto. Dunque 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.

- Il tempo di trasmissione del file.

Dunque in totale saranno 2RTT + il tempo di trasmissione. Dunque vi sono numerosi

svantaggi per le connessioni non persistenti, ovvero richiede 2RTT per oggetto e si

verifica un OVerhead del sistema operativo ogni connessione TCP (inizializzazione

strutture dati, allocazione buffer). I browser spesso aprono connessioni TCP parallele

per caricare gi oggetti referenziati.

Nelle connessioni persistenti il server lascia aperta la connessione TCP dopo l’invio

di una risposta e i successivi messaggi vengono spediti sulla stessa connessione. Le

connessioni persistenti possono essere di due tipi:

- Una di seguito all’altra (back-to-back): il client invia una richiesta non

appena incontra un oggetto referenziato. Un solo RTT per ogni oggetto

referenziato. Modalità di default in http /1.1

- Senza aspettare le risposte pendenti (pipeling): il client invia una nuova

richiesta solo quando ha ricevuto la risposta precedente. E’ necessario un RTT

per ogni oggetto referenziato;

Formato dei messaggi HTTP: le specifiche http [RFC 2616] includono la definizione

dei due formati dei messaggi http, di richiesta e di risposta.

- Messaggio di richiesta HTTP: un esempio tipico è

-

Osservandolo, accuratamente, inanzittutto notiamo che il messaggio è scritto in

ASCII normale, in modo che l’utente sia in grado di leggerlo. Inoltre notiamo che

consiste di cinque riche, ciascuna seguita da un comando d’invio e di nuova linea.

L’ultima riga è seguita da un comando d’invio e di nuova linea aggiuntivo. In

genere, i messaggi di ri