Appunti del corso di Reti di calcolatori

HTTP

Il protocollo HTTP è un protocollo a livello di applicazione del Web. È tipico dell’architettura client/server ed è “senza

stato” (stateless), ovvero non mantiene memoria dello stato della connessione e delle richieste effettuate verso il

server. Il client è rappresentato dal browser web, che richiede, riceve, visualizza gli oggetti delle pagine web. Il server

web invia oggetti in risposta a una richiesta. Esistono diverse evoluzioni del protocollo HTTP: HTTP 1.0, HTTP 1.1.

HTTP usa TCP. Il client inizializza la connessione TCP (crea una socket) con il server, sulla porta 80. Il server, in attivo e

in ascolto sulla porta specificata, accetta la connessione TCP dal client. Successivamente, vengono scambiati messaggi

HTTP fra browser (client HTTP) e server web (server HTTP) di richiesta e di risposta. Infine, la connessione TCP viene

chiusa.

Roundtrip Time

Per RTT si intende il tempo impiegato da un piccolo pacchetto per andare dal client al server e ritornare al client.

Occorre un RTT per inizializzare la connessione TCP, un RTT affinché ritornino la richiesta HTTP e i primi byte della

risposta HTTP, più il tempo di trasmissione del file. Il tempo totale è, dunque, pari a 2RTT + tempo di trasmissione.

Connessioni persistenti e non persistenti

Le connessioni HTTP possono essere:

• Non persistenti: ogni oggetto viene trasmesso su una connessione TCP separata. HTTP/1.0 usa connessioni non

persistenti. Tale approccio ha diversi svantaggi. In particolate richiedono 2 RTT per oggetto, risulta overhead del

sistema operativo per ogni connessione TCP e i browser aprono connessioni TCP parallele per caricare gli oggetti

referenziati;

• Persistenti: più oggetti possono essere trasmessi su una singola connessione TCP tra client e server. HTTP/1.1 usa

connessioni persistenti nella modalità di default. Il server lascia la connessione TCP aperta dopo l’invio di una

risposta. I successivi messaggi tra gli stessi client/server vengono trasmessi sulla connessione aperta e richiedono

in solo RTT per tutti gli oggetti referenziati. Le connessioni persistenti si dividono in:

o Connessioni persistenti senza pipelining: il client invia una nuova richiesta solo quando ha ricevuto la

risposta precedente;

o Connessione persistente con pipelining: Il client invia più richieste, senza aspettare la risposta dell’ultima

richiesta effettuata. Le risposte vengono ricevute in sequenza.

Anche le connessioni non persistenti possono essere con pipelining.

17

Messaggi HTTP

Nel protocollo HTTP sono presenti due tipi di messaggi:

• Messaggi di richiesta: in formato ASCII, sono composti da una riga di richiesta in cui è specificato il metodo della

richiesta (GET, POST, HEAD, PUT, DELETE), dalle righe di intestazione della richiesta e da una riga vuota (carriage

return + line feed \r\n), l’eventuale corpo della richiesta che indica la fine del messaggio;

• Messaggi di risposta: composti da una riga di stato (codice che identifica lo stato della richiesta), righe di

intestazione della richiesta e dai dati che compongono l’effettiva risposta (es. file HTML).

Metodi HTTP

Il corpo della richiesta può arrivare al server mediante due metodi diversi, il metodo POST e il metodo GET.

• Metodo POST: la pagina web predispone un form per l’input dell’utente. L’input arriva al server nel corpo

dell’entità;

• Metodo URL: usa il metodo GET. L’input arriva al server nel campo URL della riga di richiesta:

Esempio di richiesta: http://www.somesite.com/animalsearch?monkeys&banana

HTTP 1.0 ammette i metodi GET, POST ed HEAD (chiede al server di escludere l’oggetto richiesto dalla risposta).

HTTP/1.1 ammette i metodi GET, POST, HEAD, PUT (include il file nel corpo dell’entità e lo invia al percorso specificato

nel campo URL) e DELETE (cancella il file specificato nel campo URL).

Codici di stato

Nella prima riga nel messaggio di risposta è presente un codice di stato tra i seguenti:

• 200 OK: la richiesta ha avuto successo. L’oggetto richiesto viene inviato nella risposta;

• 301 Moved Permanently: l’oggetto richiesto è stato trasferito. La nuova posizione è specificata nell’intestazione

Location della risposta;

• 400 Bad Request: il messaggio di richiesta non è stato compreso dal server;

• 404 Not Found: il documento richiesto non si trova su questo server;

• 505 HTTP Version Not Supported: il server non ha la versione di protocollo HTTP.

Proxy server

Un proxy server è un programma che si interpone tra le richieste di client e i server. Esso è un server che funge da

cache. Il browser client trasmette tutte le richieste HTTP alla cache, che fornisce l’oggetto, altrimenti il server proxy

richiede l’oggetto al server d’origine e poi lo inoltra al client. L’obiettivo è di soddisfare la richiesta del client senza

coinvolgere il server d’origine, se è presente una copia dell’oggetto richiesto nella cache del server proxy, riducendo i

18

tempi di risposta e riducendo il traffico sul collegamento di accesso a Internet e, in generale, sulla rete globale.

Consente, inoltre, ai provider “scadenti” di fornire dati con efficacia.

GET condizionale

Il metodo GET condizionale permette di non inviare un oggetto se la cache ha una copia aggiornata dell’oggetto

stesso. Nella richiesta HTTP è specificata la data della copia dell’oggetto. La risposta non contiene l’oggetto se la copia

nella cache è aggiornata. È utilizzato il campo “If-modified-since: <data>” e viene restituito il codice di stato 304 Not

Modified, se la copia dell’oggetto sul client è già aggiornata.

Capitolo 8: Livello di trasporto

Il livello di trasporto mette a disposizione meccanismi per aumentare la qualità della connessione. I protocolli, a tale

livello, si occupano di instaurare e gestire la connessione logica tra processi in un’applicazione distribuita.

I protocolli del livello di trasporto:

• Forniscono la comunicazione logica tra processi applicativi di host differenti;

• I protocolli di trasporto vengono eseguiti nei sistemi terminali;

• Lato invio: suddivide i messaggi in segmenti e li passa al livello di rete;

• Lato ricezione: riassembla i segmenti in messaggi e li passa al livello di applicazione;

• Più protocolli di trasporto sono a disposizione delle applicazioni (UDP e TCP);

A differenza del livello di rete, che mette a disposizione una comunicazione logica tra host, il livello di trasporto mette

a disposizione una comunicazione logica tra processi (si basa sui servizi del livello di rete).

Il livello di rete non offre nessuna garanzia e affidabilità sulla trasmissione dei pacchetti dalla sorgente alla destinazione.

A livello di trasporto, ci sono sia protocolli più affidabili e meno affidabili.

TCP è affidabile:

• Consegna nell’ordine originario;

• Controllo di congestione;

• Controllo di flusso;

• Setup della connessione (three-way handshake).

UDP, invece, è inaffidabile:

• Consegne senz’ordine;

• Servizio di consegna a massimo sforzo (best effort, senza garanzie);

• Non c’è garanzia su ritardi o ampiezza di banda.

TCP e UDP, però, forniscono entrambi multiplexing/demultiplexing e controllo dell’errore.

Multiplexing e demultiplexing

Nell’host mittente avviene il multiplexing, ovvero vengono raccolti i dati da varie socket e incapsulati con l’intestazione

(utilizzati poi per il demultiplexing).

Nell’host ricevente avviene il demultiplexing, ovvero la consegna dei segmenti ricevuti alla socket appropriata.

19

Ogni datagramma ha un indirizzo IP di origine e un indirizzo IP di destinazione e trasporta un segmento a livello di

trasporto. Inoltre, ha un numero di porta di origine e un numero di porta di destinazione. L’host usa l’indirizzo IP di

destinazione e il numero di porta per inviare il segmento alla socket appropriata.

Demultiplexing senza connessione

Crea le socket con i numeri di porta. La socket UDP è identificata da 2 parametri: indirizzo IP di destinazione, numero

di porta di destinazione. Quando l’host riceve il segmento UDP controlla il numero della porta di destinazione nel

segmento e invia il segmento UDP alla socket con quel numero di porta. I datagrammi IP con indirizzi IP di origine e

numeri di porta di origine differenti vengono inviati alla stessa socket.

Demultiplexing orientato alla connessione

La socket TCP è identificata da una quaterna di parametri: indirizzo IP di origine, numero di porta di origine, indirizzo

IP di destinazione, numero di porta di destinazione. L’host ricevente usa i quattro parametri per inviare il segmento alla

socket appropriata. Un host server può supportare più socket TCP contemporanee. I server web hanno socket differenti

per ogni connessione client (con HTTP non-persistente si avrà una socket differente per ogni richiesta).

UDP (User Datagram Protocol)

Il protocollo UDP è un protocollo di trasporto “senza fronzoli” con servizio di consegna “a massimo sforzo”, poiché i

segmenti UDP possono essere:

• Perduti; 20

• Consegnati fuori sequenza all’applicazione;

• Senza connessione: no handshaking tra mittente e destinatario UDP;

• Ogni segmento UDP è gestito indipendentemente.

UDP è un protocollo piuttosto veloce, dato che non viene stabilita nessuna connessione, che potrebbe aggiungere un

ritardo, e semplice, per l’assenza di connessione tra mittente e destinatario. Pertanto, ha intestazioni di segmento corte

e non fornisce servizi di controllo di congestione (può sparare dati a raffica). Viene implementato soprattutto per

applicazioni multimediali, poiché tollera piccole perdite ed è sensibile alla frequenza. UDP aggiunge affidabilità al livello

applicativo, per il recupero degli errori delle applicazioni.

Checksum UDP

Il checksum UDP è necessario per rilevare gli errori (bit alterati) nel segmento trasmesso. Il mittente tratta il contenuto

del segmento come una sequenza di interi da 16 bit. Successivamente effettua la checksum, ovvero la somma in

complemento a 1 (inverte gli 0 e gli 1) dei contenuti del segmento. Dopodiché, pone il valore della checksum nel campo

checksum del segmento (prestando attenzione al bit di riporto, XOR).

Il ricevente ricalcola il cheksum del segmento e lo confronta con il valore presente nel campo checksum del segmento

stesso (ovviamente escludendo il campo checksum dal ricalcolo). Se i due checksum coincidono, allora non sono

presenti errori.

Affidabilità del trasferimento

Le caratteristiche di un canale inaffidabile determinano la complessità del protocollo RDT (Reliable Data Transfer).

Quando due processi comunicano a livello applicativo,