TCP/IP
Application Layer
Stefano Clemente
[email protected]
© 2005 Stefano Clemente
Livelli nello stack TCP/IP
• C’è qualche problema nel mappare il modello
TCP/IP nel modello OSI in quanto non c’è una
perfetta corrispondenza
Application
HTTP, SMTP, SNMP, FTP,
Telnet, Ssh, NFS
Presentation
SMB, AFP
Session
TLS, SSH,
RPC, NetBIOS
Transport
TCP, UDP, SPX
Network
Data Link
IP, ICMP, IGMP, X.25, CLNP, ARP,
RARP, BGP, OSPF, RIP, IPX, DDP
Ethernet, Token ring, PPP, HDLC,
Frame relay, ISDN, ATM
Physical
4 Ottobre 2005
elettricità, radio, laser
Stefano Clemente
2
Livelli nello stack TCP/IP
• Application, Presentation e Session del
modello OSI sono considerati un unico livello
Application nel TCP/IP
− TCP/IP non ha un unico livello Session sul quale i
livelli superiori poggiano e le funzioni del livello
Session sono scorporate dallo stesso o ignorate
Application
HTTP, FTP, DNS
Transport
TCP, UDP, RTP, SCTP
Network
IP
Data Link
Physical
4 Ottobre 2005
Ethernet, Token ring, PPP, HDLC,
Frame relay, ISDN, ATM
elettricità, radio, laser
tecniche di codifica
Stefano Clemente
3
Application Layer
• L’application layer è la
parte dello stack IP in
cui risiede il lavoro degli
utenti (applicazioni).
• Verranno illustrati i
protocolli:
− HTTP, HTTPS
4 Ottobre 2005
Stefano Clemente
4
Application Layer: Obiettivi
•Aspetti concettuali
dell’implementazione
dei protocolli di rete
•In particolare
−http e https
−Architettura clientserver
−Modelli dei servizi
•Apprendere i concetti
legati ai protocolli
attraverso l’esame a
livello applicativo di
quelli più popolari
4 Ottobre 2005
Stefano Clemente
5
Applicazioni e protocolli a
livello applicazione
•Applicazioni: comunicazione application
transport
network
tra processi distribuiti
data link
− eseguite nello spazio utente
degli “host” della rete
− implementate attraverso lo
scambio di messaggi
− esempi:e-mail, ftp, Web
physical
•Protocolli a livello
applicazione
− parte di un’applicazione
− definiscono i messaggi
scambiati tra le applicazioni e
le azioni intraprese
− usano i servizi di
comunicazione forniti dai livelli
inferiori (TCP, UDP)
4 Ottobre 2005
Stefano Clemente
application
transport
network
data link
physical
application
transport
network
data link
physical
6
Applicazioni di rete
• Processo: programma
eseguito su un host
− Sullo stesso host i processi
comunicano tra di essi
attraverso meccanismi di
interprocess communication
definiti dal sistema
operativo
− Processi in esecuzione su
host differenti comunicano
attraverso i protocolli a
livello applicazione
4 Ottobre 2005
•user agent:
processo software che
si interfaccia verso
l’alto con l’utente e
verso il basso con la
rete
− Mette in atto i protocolli a
livello applicazione
− Web: browser
− E-mail: client mail
− streaming audio/video:
media player
Stefano Clemente
7
Architettura Client-Server
• Una tipica rete si compone
di client e di server
• Client
application
transport
network
data link
physical
− È il primo a parlare aprendo una
comunicazione con il server
− Solitamente richiede servizi
• Web: il client è il browser
• e-mail: il client è il mail reader
• Server
− Soddisfa la richiesta di servizi dei
client
• Web server inviano le pagine
Web richieste
• i mail server spediscono le e-mail
4 Ottobre 2005
Stefano Clemente
richiesta
risposta
application
transport
network
data link
physical
8
I protocolli a livello applicazione
• API: Application
Programming
Interface
− Interfaccia le
applicazioni con il livello
di trasporto
• Come fa un processo
a identificare il
processo remoto con
il quale deve
comunicare?
− Socket: Internet API
− Indirizzo IP dell’host
remoto sul quale è in
esecuzione l’altro processo
− Due processi
comunicano inviando
dati al socket e leggendo
dati dal socket
− “port number” – permette
all’host remoto di
identificare il processo tra
quelli che sta eseguendo
4 Ottobre 2005
Stefano Clemente
9
Parametri dei servizi di trasporto
valutabili per le applicazioni
• Data loss
− Alcune applicazioni (es.
streaming audio)
possono tollerare alcune
perdite
− altre (es. file transfer,
telnet) richiedono una
affidabilità del 100% nel
trasferimento dei dati
• Bandwidth
− Alcune applicazioni (es.
multimedia) richiedono
poca banda per funzionare
− altre (dette “elastic apps”)
usano tutta la banda della
quale possono disporre
• Timing
− Alcune applicazioni (es.
VOIP) richiedono bassi
ritardi per essere efficaci
4 Ottobre 2005
Stefano Clemente
10
Requisiti dei servizi di trasporto
per le applicazioni più comuni
Applicazione
Data loss
Bandwidth
Timing
File transfer
Nessuna
Elastica
No
E-mail
Nessuna
Elastica
No
Web
Tollerata
Elastica
No
Tollerata
audio: 5Kb-1Mb
video:10Kb5Mb
Si, 100 msec
audio/video
differiti
Tollerata
audio: 5Kb-1Mb
video:10Kb5Mb
Si, pochi
secondi
Applicazioni
Finanziarie
Nessuna
Elastica
Si/No
audio/video
real-time
4 Ottobre 2005
Stefano Clemente
11
Servizi dei protocolli di trasporto
Internet
• TCP (Trasmission Control
Protocol)
− connection-oriented: setup
richiesto tra client e server
− Trasporto affidabile tra
processi trasmittenti e
riceventi
− Flow control: il trasmittente
non può sommergere il
ricevente
− congestion control: rallenta
il trasmittente quando la
rete è sovraccarica
− Non fornisce
• UDP (User Datagram
Protocol)
− Trasmissioni dati tra
trasmittente e ricevente
non affidabile
− Non fornisce:
• Timing
• Banda minima garantita
4 Ottobre 2005
Stefano Clemente
•
•
•
•
•
•
connection setup
reliability
flow control
congestion control
Timing
Garanzie di banda
12
Programmazione dei Socket
Come avviene la comunicazione
client/server per mezzo dei socket
• Socket API
• Introdotta nella versione
BSD 4.1 UNIX nel 1981
• Creata esplicitamente,
usata e rilasciata dalle
applicazioni
• Modello client/server
• Due tipi di servizio di
trasporto attraverso le
socket API:
− unreliable datagram
− reliable, byte streamoriented
4 Ottobre 2005
Stefano Clemente
socket
interfaccia locale all’host
(una “porta”), creata
dall’applicazione e di sua
proprietà,
controllata dal sistema
operativo, attraverso la
quale i processi
applicativi possono sia
inviare sia ricevere
messaggi a/da un altro
processo applicativo
(remoto o locale)
13
Programmazione dei Socket
usando il TCP
• Socket: porta tra processi applicazione e la
parte terminale del protocollo di trasporto
• Servizio TCP: trasferimento affidabile di byte
tra due processi
controllato dallo
sviluppatore
dell’applicazione
controllato dal
sistema
operativo
processo
processo
socket
TCP con
buffer e
variabili
internet
controllato dal
sistema
operativo
host o
server
host o
server
4 Ottobre 2005
socket
TCP con
buffer e
variabili
controllato dallo
sviluppatore
dell’applicazione
Stefano Clemente
14
Programmazione dei Socket
usando il TCP
• Il client deve
contattare il server
− Il processo server deve già
essere in esecuzione
− Il server deve aver creato il
socket (porta) che accoglie
il tentativo di contatto del
client
− Quando il client crea un
socket: il TCP del client si
connette al TCP del server
− Una volta contattato dal
client, il TCP del server crea
un nuovo socket con il quale
il processo server comunica
con il client
• Il client contatta il
server
− creando un socket TCP
locale al client
− specificando l’indirizzo IP e
il numero della porta del
processo server
4 Ottobre 2005
Stefano Clemente
• Un server può parlare con
più client
Dal punto di vista
dell’applicazione
Il TCP fornisce un trasferimento di
byte affidabile e ordinato (“pipe”)
tra client e server
15
Programmazione dei Socket
usando il TCP
trastiera
Processo
Client
stream di input:
sequenza di byte
inviata al
processo
socket TCP
del client
alla rete
4 Ottobre 2005
Stefano Clemente
inFromServer
stream di output:
sequenza di byte
inviata dal processo
outToServer
− Il client legge una riga da
standard input (inFromUser
stream)e la invia al server
via socket (outToServer
stream)
− Il server legge una riga dal
socket
− Il server converte la riga in
maiuscolo e la rimanda al
client
− Il client legge dal socket
(inFromServer stream) e
stampa la riga modificata
inFromUser
• Esempio di applicazione
client/server:
monitor
TCP
socket
dalla rete
16
Interazione tra i socket client e
server: TCP
Server (su hostid)
Client
Crea il socket sulla
porta x per le richieste
in ingresso:
welcomeSocket = ServerSocket()
attende l’arrivo delle
richieste di connessione
TCP
connection setup
crea il socket connettendosi
all’hostid sulla porta x
clientSocket = Socket()
connectionSocket = welcomeSocket.accept()
Invia una richiesta usando
clientSocket
legge le richieste da
connectionSocket
legge la risposta da
clientSocket
scrive le risposte a
connectionSocket
chiude clientSocket
4 Ottobre 2005
Stefano Clemente
17
Programmazione dei Socket
usando UDP
• nessuna “connessione” tra
client e server
− non c’è handshaking
− chi invia attacca al pacchetto
in modo esplicito l’indirizzo IP
e la porta del destinatario
− il server si fa carico
dell’estrazione dell’indirizzo IP
e della porta del mittente dal
datagram ricevuto
• i dati trasmessi possono
essere ricevuti in qualsiasi
ordine o smarriti
Dal punto di vista
dell’applicazione
UDP trasferisce gruppi di byte
(“datagram”) tra client e
server in modo non affidabile
4 Ottobre 2005
Stefano Clemente
18
Interazione tra i socket client e
server: UDP
Server (su hostid)
Client
Crea il socket sulla
porta x per le richieste
in ingresso:
ServerSocket =DatagramSocket()
crea il socket
clientSocket = DatagramSocket()
Crea la coppia indirizzo (hostid, porta=x)
e invia la richiesta di datagram con
clientSocket
legge le richieste da
ServerSocket
scrive le risposte a
ServerSocket
specificando l’indirizzo del client
e la porta
legge la risposta da
clientSocket
chiude clientSocket
4 Ottobre 2005
Stefano Clemente
19
tastiera
stream
di Input
Processo
Client
monitor
inFromUser
Input: riceve
pacchetti (il TCP
riceve “byte
stream”)
pacchetto
UDP
sendPacket
Output: invia
pacchetti (il TCP
invia “byte
stream”)
receivePacket
Client (UDP)
pacchetto
UDP
Socket del Client
socket
UDP
alla rete
4 Ottobre 2005
dalla rete
Stefano Clemente
20
Il Protocollo HTTP: Hypertext
Transfer Protocol 1.1
Stefano Clemente
[email protected]
© 2005 Stefano Clemente
Riferimenti bibliografici
• Internet Official Protocol Standards
(STD 1)
− Request For Comments (RFC):
• 2616 (HTTP)
− Cercare con Google “RFC 2616”
4 Ottobre 2005
Stefano Clemente
22
Introduzione
• Hypertext Transfer Protocol (HTTP) è un protocollo a
livello applicazione per sistemi informativi
− distribuiti
− collaborativi
− hypermedia
• Storia del protocollo
− HTTP/0.9 – Trasferimento di righe di dati su internet
− HTTP/1.0 – Messaggi MIME-like contenenti metainformazioni
sui dati trasferiti e modificatori sulla semantica delle richieste
o risposte
• non prendeva in considerazione le cache, i proxy gerarchici, le
connessioni persistenti, gli host virtuali
− HTTP/1.1 – …
4 Ottobre 2005
Stefano Clemente
23
MIME: Multipurpose Internet Mail
Extensions
• RFC 2045, 2046
• Delle righe addizionali nell’intestazione del
messaggio definiscono il tipo dei contenuti del
MIME
versione MIME
metodo utilizzato per
la codifica
tipo del contenuto
tipo/sottotipo
dichiarazione dei parametri
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
dati codificati
4 Ottobre 2005
Stefano Clemente
24
MIME: Multipurpose Internet Mail
Extensions
Tipi del MIME
Content-Type: type/subtype; parameters
• Text
• Video
− sottotipi di esempio
− sottotipi di esempio
• mpeg
• quicktime
• plain
• html
• Image
• Application
− sottotipi di esempio
− dati non interpretati che
sono riservati
all’elaborazione da parte di
un’applicazione
− sottotipi di esempio
• jpeg
• gif
• Audio
− sottotipi di esempio
• basic (8-bit mu-law
encoded),
• 32kadpcm (32 kbps coding)
4 Ottobre 2005
• msword
− octet-stream
Stefano Clemente
25
MIME: Multipurpose Internet Mail
Extensions
Multipart Type
From: [email protected]
To: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=98766789
--98766789
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain
Dear Bob,
Please find a picture of a crepe.
--98766789
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
.........................
......base64 encoded data
--98766789--
4 Ottobre 2005
Stefano Clemente
26
Il modello HTTP
• È un protocollo richiesta-risposta
− Il client invia una richiesta nella forma di
• metodo di richiesta – URI (Uniform Resource Identifier) –
versione del protocollo
• messaggio tipo MIME contente modificatori della richiesta,
informazioni sul client e un probabile corpo del messaggio
− Il server risponde con
• una riga di stato contenente un codice e la versione del
protocollo
• messaggio tipo MIME contente informazioni sul server,
metainformazioni sull’entità (entity – l’oggetto della
richiesta) e, se possibile, l’oggetto della risposta
4 Ottobre 2005
Stefano Clemente
27
Il modello HTTP
• La maggior parte delle comunicazioni
HTTP vengono avviate da uno User
Agent (UA) e consistono in una richiesta
indirizzata a un Origin Server (OS)
UA
OS
• CASO 1 – connessione singola
4 Ottobre 2005
Stefano Clemente
28
Il modello HTTP
• CASO 2 – Connessione attraverso intermediari
A
UA
B
C
OS
− intermediari – ognuno può gestire più richieste/risposte
contemporaneamente
• PROXY – Agente di inoltro
− riceve richieste per un URI
− riscrive una parte o l’intero messaggio
− inoltra la richiesta riformattata verso il server identificato
dall’URI
• GATEWAY – Agente di ricezione
− agisce come uno strato al di sopra dei server e, se necessario,
traduce la richiesta nel protocollo del server sottostante
• TUNNEL
− agisce come un punto di passaggio tra due connessioni e non
cambia in alcun modo il messaggio (es. firewall)
4 Ottobre 2005
Stefano Clemente
29
Il modello HTTP
• CASO2 – Connessione attraverso intermediari (2)
UA
A
B
C
OS
− Gli intermediari che non agiscono da tunnel possono avvalersi
di una cache interna con l’effetto di accorciare la catena
richieste/risposte verso un OS se esiste in cache una copia
della risposta applicabile alla particolare richiesta
• in questo modo si ottimizza l’uso della banda, si velocizza la
risposta in modo da tutelare i dispositivi con più difficoltà di
connessione (es. PDA)
• HTTP è solitamente utilizzato su TCP/IP e per default
usa la porta 80
4 Ottobre 2005
Stefano Clemente
30
I messaggi HTTP
• Tipi di messaggio
− I messaggi HTTP consistono in
• richieste dal client al server
• risposte dal server al client
− Entrambi sono formati da
•
•
•
•
4 Ottobre 2005
una riga iniziale
zero o più header field (intestazioni)
una riga vuota per indicare la fine delle intestazioni
il corpo del messaggio (opzionale)
Stefano Clemente
31
I messaggi HTTP
Richiesta
Risposta
4 Ottobre 2005
riga di stato
HTTP/1.0 200 OK
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html
righe header
DATI ...
dati (es. file html)
Stefano Clemente
32
I messaggi HTTP
• Header
− Le intestazioni sono suddivise in più righe ognuna
della forma
• nome-header: valore
• nome-header è case insensitive
− L’ordine in cui appaiono non ha nessuna importanza
• è comunque buona pratica disporle nel seguente ordine
− intestazioni generali
− intestazioni relative alla richiesta/risposta
− intestazioni relative all’entità
− POSSONO comparire più righe con lo stesso nomeheader se e solo se per quell’intestazione è
possibile fornire valori in un elenco separato da
virgole
nome-header: valore1
nome-header: valoren
4 Ottobre 2005
nome-header: valore1, …, valoren
Stefano Clemente
33
I messaggi HTTP
• Corpo
− è opzionale
− contiene l’entità oggetto della richiesta/risposta
− <corpo_messaggio>  <corpo_entità> solo quando è
stato applicato un meccanismo di codifica
(specificato con header “Transfer-Encoding”)
• la codifica è applicata da un’applicazione per garantire il
trasporto sicuro e esatto del messaggio per cui è una
proprietà dell’intero messaggio e non dell’entità
− nel caso di richieste
• la presenza di un corpo è segnalata dagli header
“Content-Length” o “Transfer-Encoding”
• NON DEVE essere incluso nelle richieste il cui metodo non
lo consente (es. HEAD)
4 Ottobre 2005
Stefano Clemente
34
I messaggi HTTP
− nel caso di risposte
• la presenza di un corpo dipende sia dal metodo
della richiesta, sia dal codice di stato della
risposta
• NON DEVE essere incluso un messaggio
− nelle risposte alle richieste con metodo HEAD
− nei codici di stato 1xx (informational), 204 (no
content), 304 (not modified)
• tutte le altre risposte includono un corpo anche
se POTREBBE essere di lunghezza zero
4 Ottobre 2005
Stefano Clemente
35
I messaggi HTTP
• Lunghezza del messaggio
− È la lunghezza di trasferimento del messaggio, cioè
la lunghezza del corpo così come appare nel
messaggio (es. codifica inclusa)
− Header Content-Lenght
− Quando in un messaggio che ammette un corpo è
fornita anche la lunghezza, il valore di questa
DEVE corrispondere esattamente al numero di
ottetti del messaggio
• gli UA HTTP/1.1 DEVONO notificare all’utente quando
questa condizione non è verificata
4 Ottobre 2005
Stefano Clemente
36
I messaggi HTTP
• Header generali
− Sono intestazioni applicabili sia alle richieste
che alle risposte, ma non alle entità
• Cache-Control, Connection, Date, Pragma,
Trailer, Transfer-Encoding, Upgrade, Via, Warning
• Header non riconosciuti sono considerati header
dell’entità
4 Ottobre 2005
Stefano Clemente
37
Richieste
• Un messaggio di richiesta riporta nella prima riga (detta Request-Line) il
metodo da applicare alla risorsa, l’identificatore della risorsa e la
versione di HTTP utilizzata
<metodo> <URI> HTTP/<major>.<minor>
• Metodo
− indica l’azione da eseguire sulla risorsa identificata dallo URI
− è case-sensitive
• OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT
− si possono specificare i metodi ammessi da una risorsa attraverso l’header
“Allow”
− la risposta notifica sempre se è consentito l’uso del metodo sulla risorsa
indicata
• il server
DOVREBBE restituire i codici
− 405 (Method Not Allowed) se il metodo è implementato, ma non utilizzabile sulla risorsa
− 501 (Not Implemented) se il metodo non è riconosciuto
− i metodi
DEVONO essere supportati
gli altri sono opzionali, ma DEVONO rispettare sempre la semantica imposta dal
• GET e HEAD
•
4 Ottobre 2005
protocollo HTTP
Stefano Clemente
38
Richieste
• URI della richiesta
− identifica la risorsa alla quale si applica il metodo
− può essere
• *
− indica che la richiesta non va applicata ad una risorsa, ma al server
OPTIONS * HTTP/1.1
• URI assoluta
− è OBBLIGATORIA quando la richiesta viene fatta a un Proxy
GET http://www.ei.unibo.it/ HTTP/1.1
− DEVE essere accettata da tutti i server HTTP/1.1 per le future versioni di
HTTP anche se attualmente generata solo dai client che si collegano ai Proxy
• path assoluto
− è la forma più comune e prevede la trasmissione nella Request-Line del path
assoluto e la trasmissione di un header “Host” contenente l’indirizzo
GET / HTTP/1.1
Host: www.ei.unibo.it
• authority
− utilizzata solo dal metodo CONNECT
4 Ottobre 2005
Stefano Clemente
39
Richieste
• La risorsa identificata dalla richiesta
− è determinata dal path assoluto e dall’header
“Host”
• se un host non permette la differenziazione delle richieste
in base all’host, POTREBBE ignorare l’header “Host”
• se un host permette la differenziazione delle richieste in
base all’host, DEVE determinare la risorsa secondo le
regole seguenti
− se c’è un URI assoluto, DEVE ignorare gli header “Host”
− se non c’è un URI assoluto, l’host è ricavato dall’header
“Host”
− se le prime due non regole non sono applicabili DEVE
rispondere
400 (Bad Request)
4 Ottobre 2005
Stefano Clemente
40
Richieste
• Header
− permettono al client di fornire ulteriori
informazioni circa la richiesta (sono una sorta di
modificatori della richiesta)
•
•
•
•
•
•
•
•
•
4 Ottobre 2005
Accept
Accept-Charset
Accept-Encoding
Authorization
Expect
From
Host
If-Match
If-Modified-Since
•
•
•
•
•
•
•
•
•
Stefano Clemente
If-None-Match
If-Range
If-Unmodified-Since
Max-Forwards
Proxy-Authorization
Range
Referer
TE
User-Agent
41
Metodi delle richieste HTTP
• OPTIONS
− Rappresenta una richiesta di informazioni riguardanti le
opzioni di comunicazione disponibili sulla catena di
richieste/risposte identificata dalla URI
− Permette al client di
• determinare le opzioni e/o I requisiti associati ad una risorsa
• le capacità di un server
senza azioni su risorse o ricerca di risorse
− Le risposte non sono soggette a cache
− Se la URI richiesta
• è un asterisco ("*"), la richiesta si intende applicata al server
piuttosto che a una risorsa specifica
− la comunicazione con il server dipende tipicamente dalla risorsa per
cui in genere serve come no-op; in pratica no fa altro che restituire
le caratteristiche del server (es. il client testa se il proxy è HTTP 1.1)
• non è un asterisco, la richiesta OPTIONS applica le opzioni
disponibili nella comunicazione con la risorsa
4 Ottobre 2005
Stefano Clemente
42
Metodi delle richieste HTTP
• GET
− Recupera le informazioni specificate dalla URI di richiesta.
• Se la URI di richiesta si riferisce a un processo di creazione dati
(es. pagine dinamiche), è il risultato di detto processo che deve
essere restituito come risposta e non la sorgente del processo
− La risposta può essere memorizzata in cache
• HEAD
− Identico al GET tranne per il fatto che il server non deve
restituire il corpo del messaggio nella risposta, mentre le
metainformazioni devono essere identiche a quelle che
restituirebbe il GET
• per il fatto che non restituisce il corpo è utile per verificare link,
accesibilità e modifiche alle pagine
− La risposta può essere messa in cache
4 Ottobre 2005
Stefano Clemente
43
Metodi delle richieste HTTP
• POST
− È usato per richiedere che il server accetti l’entità inclusa nella richiesta come
subordinata alla risorsa identificata dalla URI
− POST è concepito per fornire un metodo uniforme per le seguenti funzioni:
•
•
•
•
Prendere nota delle risorse esistenti
Inserire un messaggio in un bollettino, newsgroup, ecc.
Fornire dati a un processo per la gestione dei dati
Estendere un database attraverso una append
il modo in cui la funzione è eseguita dipende dal server
− L’azione eseguita dalla POST potrebbe non restituire una risorsa identificata
da una URI e in questo caso lo stato della risposta deve essere 200 (OK)
oppure 204 (No Content), a seconda del fatto che la risposta includa o meno
un’entità che descriva il risultato
− Se è stata creata una risorsa sul server di origine la risposta dovrebbe
essere 201 (Created) e contenere un’entità che descriva lo stato della
richiesta e il riferimento alla nuova risorsa
− Le risposte non sono soggette a cache a meno che esse non includano
appropriati Cache-Control o intestazioni Expires. In quest’ultimo caso la
risposta 303 (See Other) può essere usata per indirizzare lo user agent a
reperire la risposta in cache
4 Ottobre 2005
Stefano Clemente
44
Metodi delle richieste HTTP
•
PUT
−
Richiede che l’entità enclusa sia memorizzata sotto l’URI di richiesta fornita.
−
La differenza con la POST sta nel diverso significato della URI di richiesta
−
HTTP/1.1 non specifica in che modo la PUT incide sullo stato del server
−
A meno di atre specifiche, le intestazioni dell’entità nella richiesta dovrebbero essere
applicate alla risorsa creata o modificata dalla PUT
• Se l’URI di richiesta fa riferimento a una risorsa già esistente, l’entità inclusa dovrebbe essere
considerata come una versione modificata di quella esistente sul server di origine. In questo caso
dovrebbe essere risposto 200 (OK) o 204 (No Content) per indicare il completamento con
successo
• Se la URI di richiesta non punta a una risorsa esistente e quindi può essere definita come una
nuova risorsa dall’utente richiedente, il server di origine può creare la risorsa con quella URI. In
questo caso il server di origine deve informare lo user agent attraverso la risposta 201 (Created).
• Nel caso in cui la risorsa non possa essere nè creata nè modificata il server di origine dovrebbe
rispondere con un messaggio appropriato che indichi la natura del problema
• Il recipiente dell’entità non deve ignorare nessuna intestazione di tipo Content che non capisca o
implementi e deve rispondere con 501 (Not Implemented)
• Lo user agent conosce l’URI e il server non deve applicare la stessa URI ad altre risorse; se il
server desidera che la richiesta venga applicata a un altra URI, deve inviare una risposta 301
(Moved Permanently), e lo user agent può sceglierese rinviare o meno la richiesta
• nel caso di POST la URI identifica la risorsa che gestirà l’entità inclusa
• la URI nella richiesta PUT identifica l’entità inclusa con la richiesta stessa
4 Ottobre 2005
Stefano Clemente
45
Metodi delle richieste HTTP
• DELETE
− Richiede la cancellazione dal server di origine della risorsa
identificata dalla URI di richiesta. Questo metodo può essere
modificato dall’intervento umano o da altro e il client non ha
alcuna garanzia che l’operazione sia stata portata a termine,
anche se il codice della risposta restituita dal server afferma
che l’operazione è andata a buon fine. Il server non
dovrebbe fornire risposte di successo a meno che nel
momento in cui fornisce una tale risposta non intende
effettivamente eliminare o rendere comunque inaccessibile la
risorsa
− La risposta di successo dovrebbe essere
• 200 (OK) se include un’entità che descrive lo stato
• 202 (Accepted) se l’azione non è stata ancora attivata
• 204 (No Content) se l’azione è stata attivata, ma non c’è
un’entità inclusa nella risposta
− Le risposte a DELETE non sono soggette a cache
4 Ottobre 2005
Stefano Clemente
46
Metodi delle richieste HTTP
• TRACE
− Attraverso questo metodo un client può vedere cosa viene
ricevuto dall’altra parte della catena delle richieste in modo
tale da eseguire delle diagnosi
− La richiesta TRACE non deve includere un corpo
− Se la richiesta è valida la risposta dovrebbe contenere una
risposta 200 (OK) e l’intero messaggio di richiesta nel corpo
dell’entità con Content-Type "message/http“
− Le risposte non dovrebbero essere soggette a cache.
• CONNECT
− Usata con i proxy per tunnel (es. SSL)
4 Ottobre 2005
Stefano Clemente
47
Metodi delle richieste HTTP
• Metodi di richiesta HTTP
− GET
• richiesta di un documento al Web Server
− POST
• invio dei dati che l’utente del client ha immesso nella form
• GET può inviare contenuti di una form come parte della URL per
recuperare una particolare risorsa dal server web
− http://www.google.it/advanced_search?hl=it
in cui la parte seguente il punto interrogativo (nella forma
<query>=<query_utente>) rappresenta la query dell’utente
− In una GET la lunghezza massima di <query_utente> è di 1024
caratteri; se eccede questo limite si usa il metodo POST
• POST è usata anche per modificare i contenuti del web server
(es. forum)
• I browser solitamente fanno cache delle pagine web per
velocizzare l’accesso a queste in caso debbano essere ricaricate
− non vengono messe in cache le pagine relative a richieste POST
− vengono messe in cache le pagine relative a richieste GET
4 Ottobre 2005
Stefano Clemente
48
Risposte
• Dopo avere ricevuto e interpretato un
messaggio il server risponde con un
messaggio formato da una riga di stato
(Status-Line), degli header e un
eventuale corpo del messaggio
4 Ottobre 2005
Stefano Clemente
49
Risposte
• Status-Line
− è la prima riga del messaggio di risposta ed è formata dalla versione del
protocollo, codice numerico dello stato e descrizione dello stato, tutti separati
da uno spazio, e con un <CRLF> alla fine
<versione_HTTP> <xyz> <descrizione>
− il codice di stato è un codice di tre cifre che codifica il risultato del tentativo di
soddisfare la richiesta, mentre la descrizione dà una breve spiegazione circa il
codice
• il codice è destinato alle procedure automatiche
• la descrizione all’utente la prima cifra del codice definisce la classe della risposta,
mentre le altre due non hanno un ruolo ben codificato
• 1xx – Informational, è stata ricevuta la richiesta e l’elaborazione prosegue
• 2xx – Success, l’azione è stata completata con successo
• 3xx – Redirection, per completare la richiesta sono necessarie ulteriori azioni
• 4xx – Client Error, la richiesta non è ben formulata
• 5xx – Server Error, il server non riesce a soddisfare una richiesta apparentemente
valida
− le applicazioni non sono obbligate a riconoscere tutti i codici, ma devono
comprendere almeno la classe codificata dalla prima cifra
• ogni risposta non codificata dall’applicazione deve essere ricondotta a x00
4 Ottobre 2005
Stefano Clemente
50
Risposte
• Header della risposta
− sono utilizzati dal server per fornire informazioni
addizionali riguardanti la risposta e che non
possono essere passati con la Status-Line
•
•
•
•
•
•
•
•
•
4 Ottobre 2005
Accept-Ranges
Age
ETag
Location
Proxy-Authenticate
Retry-After
Server
Vary
WWW-Authenticate
Stefano Clemente
51
Entity
• Le richieste e le risposte possono trasmettere un’entità
− entity header field
− entity body
• Entity Header Field
− definiscono meta-informazioni sul corpo dell’entità oppure, se non
c’è un’entità, sulla risorsa
•
•
•
•
•
•
•
•
•
•
•
4 Ottobre 2005
Allow
Content-Encoding
Content-Language
Content-Length
Content-Location
Content-MD5
Content-Range
Content-Type
Expires
Last-Modified
extension-header  informazioni addizionali
Stefano Clemente
52
Entity
• Corpo
− è nel formato di codifica definito dall’header dell’entità
− è ottenuto dalla decodifica del messaggio
• Tipo
− il tipo dei dati dell’entità è definito dagli header Content-Type
e Content-Encoding
• Content-Type specifica il formato dei dati
− Content-Type: image/gif
• Content-Encoding serve per indicare delle codifiche ulteriori sui
dati, per esempio per compressione, e che sono una proprietà
della risorsa richiesta
− Content-Encoding: gzip
• Lunghezza
− lunghezza del corpo del messaggio prima dell’applicazione
delle codifiche per il trasferimento
4 Ottobre 2005
Stefano Clemente
53
Le connessioni
• Connessioni persistenti
− prima che venissero implementate occorreva una connessione per
ogni richiesta/risposta con problemi di crescita del carico per i server
HTTP e aumento del traffico su rete
− ci sono applicazioni che fanno richieste multiple allo stesso server in
brevi tempi
− vantaggi
• l’apertura di poche connessioni permette ai router e agli stessi host di
risparmiare memoria e tempo di CPU
• le richieste e le risposte possono essere sovrapposte sulla stessa
connessione per cui un client può fare delle richieste multiple senza
preoccuparsi di attendere per ognuna di esse la relativa risposta
• il traffico sulla rete viene ridotto eliminando i numerosi pacchetti
provocati dall’apertura delle connessioni
• si riducono i tempi di latenza in seguito alle richieste, dovuti
principalmente agli handshake conseguenti all’apertura delle connessioni
− Le implementazioni HTTP DOVREBBERO disporre di connessioni
persistenti
4 Ottobre 2005
Stefano Clemente
54
Le connessioni:
Visione generale
• Le connessioni persistenti sono il
comportamento di default nelle connessioni:
il client DOVREBBE assumere che il server
resterà connesso anche in caso di errori
• La chiusura della connessione viene
segnalata attraverso l’header
− Connection: close
dopodiché il client NON DEVE inviare più
richieste
4 Ottobre 2005
Stefano Clemente
55
Le connessioni:
Visione generale
Negoziazione
− Un server HTTP/1.1 POTREBBE assumere che il client
HTTP/1.1 vuole mantenere una connessione persistente fino a
quando non invia l’header “Connection: close” in una
richiesta, in questo caso se il server decide di chiudere subito
dopo l’invio della risposta deve inserire lo stesso header nella
risposta
− Un client HTTP/1.1 POTREBBE aspettarsi che la connessione
rimanga aperta, ma decide il da farsi in base alla presenza o
meno di un header “Connection: close” nella risposta del
server. Se però decidesse di non mantenere aperta la
connessione DOVREBBE inviare lo stesso header in una
richiesta
− La richiesta o la risposta con l’header di chiusura è l’ultima
azione sulla connessione
− Per le versioni precedenti di HTTP i client e i server NON
DOVREBBERO assumere la persistenza della connessione
4 Ottobre 2005
Stefano Clemente
56
Le connessioni:
Visione generale
Pipelining
− Pipeline = meccanismo delle richieste multiple
− Un client che supporta la persistenza della connessione
POTREBBE inviare richieste multiple senza attendere per
ognuna la relativa risposta
− Il server DEVE rispondere secondo l’ordine di ricezione delle
richieste
− I client che suppongono di poter disporre di connessioni
persistenti e che cominciano l’invio delle richieste multiple
subito dopo la connessione, DOVREBBERO essere pronti a
dover riprovare la connessione se il primo tentativo fallisse
• Se un client riprova, NON DEVE ricominciare il pipeline prima di
essersi accertato della persistenza della connessione
• Il client DEVE essere pronto a ripetere le richieste se il server
chiude la connessione prima di aver inviato tutte le risposte
4 Ottobre 2005
Stefano Clemente
57
HTTP è stateless
• Stateful e stateless sono aggettivi che
descrivono la capacità o l’incapacità di un
computer o di un programma di annotare e
ricordare uno o più eventi in una sequenza di
interazioni con un utente, un altro computer,
un programma, un dispositivo o qualunque
altro elemento estraneo
− Stateful significa che il computer o il programma
tiene traccia dello stato delle interazioni in genere
mantenendo dei valori in porzioni di memoria
dedicate
− Stateless significa che non viene tenuta nessuna
traccia e ogni interazione viene eseguita soltanto in
base alle informazioni che arrivano con la richiesta
4 Ottobre 2005
Stefano Clemente
58
HTTP è stateless
• Stateful e stateless provengono dall’uso del
termine state per descrivere l‘insieme delle
condizioni a un dato istante
− i computer sono intrinsecamente stateful nelle
loro operazioni per cui questi termini sono riferiti
non alla loro normale operatività, ma a particolari
interazioni
• L’Internet Protocol (IP), è esempio di
interazione stateless
− Ogni pacchetto viaggia per conto proprio senza
riferimento agli altri pacchetti. Per Esempio quando
viene richiesta una pagina web, questa arriva
spezzata in più pacchetti, successivamente
ricomposti dal TCP solo con le informazioni
contenute negli stessi.
4 Ottobre 2005
Stefano Clemente
59
HTTP è stateless
• HTTP è stateless. A ogni richiesta segue la relativa
risposta del server, ma il server non ricorda le
richieste ricevute. Ogni comunicazione è fine a sé
stessa e senza relazioni con quelle precedenti o
successive
• Per rendere HTTP stateful, lo sviluppatore del sito
deve dotare il server di un programma che consenta
la registrazione e il recupero delle informazioni di
stato
• I browser sfruttano una zona su disco per
memorizzare e recuperare le informazioni di stato
− COOKIE
• I server usano le variabili di sessione
4 Ottobre 2005
Stefano Clemente
60
Il Protocollo HTTPS:
HTTP Over TLS
Stefano Clemente
[email protected]
© 2005 Stefano Clemente
Riferimenti bibliografici
• Internet Official Protocol Standards
(STD 1)
− Request For Comments (RFC):
• 2818 (HTTPS)
• 2246 (TLS)
− Cercare con Google “RFC 2818”, “RFC
2246”,
4 Ottobre 2005
Stefano Clemente
62
Introduzione
• HTTP trasmette dati non criptati, quindi
potenzialmente visibili
• L’uso di HTTP per applicazioni contenenti
dati sensibili (es. e-commerce) ha
portato all’adozione di misure di
sicurezza
4 Ottobre 2005
Stefano Clemente
63
Introduzione
• Prima SSL (Secure Socket Layer) e poi il
successore TLS (Transport Layer
Security ) sono stati disegnati
appositamente per fornire sicurezza sul
canale di comunicazione
• HTTPS è un’idea molto semplice basata
sull’uso di HTTP sul TLS, allo stesso
modo in cui HTTP usa TCP
4 Ottobre 2005
Stefano Clemente
64
Brevi cenni su TLS (Transport
Layer Security)
• Lo scopo principale del TLS è fornire
protezione e integrità dei dati sui canali
di comunicazione
• Il protocollo è composto da due strati
− TLS Record Protocol
− TLS HandshakeProtocol
4 Ottobre 2005
Stefano Clemente
65
Brevi cenni su TLS (Transport
Layer Security)
• Al livello più basso, sopra il livello del
protocollo di trasporto (es TCP) si pone il TLS
Record Protocol, che fornisce la sicurezza della
connessione con le seguenti proprietà
− Privatezza della connessione
• Dati crittografati con crittografia simmetrica – le chiavi
sono generate unicamente per ogni singola connessione e
la loro negoziazione avviene per opera del protocollo TLS
Handshake Protocol (il Record Protocol può essere usato
anche senza crittografia)
− Affidabilità della connessione
• Il trasporto dei messaggi include il controllo dell’integrità
attraverso la codifica di un MAC (Message Authentication
Code) calcolato attraverso funzioni di hash sicure quali
SHA, MDA, ecc.
4 Ottobre 2005
Stefano Clemente
66
Brevi cenni su TLS (Transport
Layer Security)
• Il TLS Record Protocol viene usato per
incapsulare i protocolli di livello più alto,
tra i quali il TLS Handshake Protocol
• Il TLS Handshake Protocol permette a
client e server di autenticarsi a vicenda
e di negoziare l’algoritmo di crittografia
e le chiavi prima di iniziare la
trasmissione dei dati
4 Ottobre 2005
Stefano Clemente
67
Brevi cenni su TLS (Transport
Layer Security)
• IL TLS Handshake Protocol fornisce la
sicurezza durante lo stabilimento della
connessione attraverso le seguenti proprietà
− L’identità del partner può essere stabilita mediante
l’uso della crittografia a chiavi asimmetriche(questa
autenticazione può essere opzionale ma è
generalmente richiesta per almeno un partner
− La negoziazione del segreto è sicura e nessuno può
ottenere il segreto
− La negoziazione è affidabile e nessuno può
interferire senza che le parti se ne accorgano
• Vantaggio
− L’applicazione è indipendente dal protocollo
4 Ottobre 2005
Stefano Clemente
68
La connessione HTTPS
• L’agente che si comporta come il client
HTTP deve essere anche un client TLS
iniziando la connessione su una porta
specifica del server ed inviando un
messaggio di saluto ClientHello per
avviare l’handshake TLS
• Quando la fase di handshake è conclusa
il client può inviare la prima richiesta
HTTP
4 Ottobre 2005
Stefano Clemente
69
La connessione HTTPS
• Tutto il traffico HTTP deve avvenire nella
forma di dati dell’applicazione TLS
• Il comportamento del protocollo HTTP
deve essere garantito (incluse le
connessioni persistenti)
4 Ottobre 2005
Stefano Clemente
70
La chiusura della connessione
HTTPS
• La connessione deve essere chiusa in
modo sicuro, vale a dire dopo la
richiesta di chiusura, nessun dato deve
transitare sul canale
• Tra i partner DEVE esserci uno scambio
di avvertimenti di chiusura prima di
chiudere la connessione
4 Ottobre 2005
Stefano Clemente
71
La chiusura della connessione
HTTPS
• Dopo aver inviato un segnale di chiusura
un’implementazione TLS PUO’ chiudere
la connessione senza attendere il
segnale dell’altro partner = Incomplete
Close
• Un partner TLS che vede chiudere la
connessione senza aver ricevuto un
segnale di chiusura (= Premature Close)
NON DEVE riutilizzare la sessione
4 Ottobre 2005
Stefano Clemente
72
La chiusura della connessione
HTTPS - il client
• La chiusura deve avvenire dopo lo scambio dei segnali e quindi il
client DEVE considerare un errore la chiusura prematura e i
dati ricevuti come potenzialmente incompleti
− HTTP permette al client di verificare l’incompletezza dei dati
− un client che agisca secondo il principio “preciso quando invia,
tollerante quando riceve” può tollerare la ricezione di dati incompleti
− due casi meritano attenzione
• Nel caso di risposte senza header Content-Length, normalmente è la
chiusura della connessione a indicare la lunghezza del messaggio e la
chiusura prematura non è distinguibile dalla chiusura dovuta ad un
attacco
• Nel caso di risposte contenenti header Content-Length chiuse prima della
lettura di tutti i dati, a causa del fatto che TLS non fornisce metodi di
protezione orientati ai documenti, non si può stabilire se il server ha
sbagliato l’header Content-Length o se la connessione è stata troncata da
un attacco
• Nel caso di chiusura prematura il client DOVREBBE
considerare buoni solo le risposte i cui dati corrispondono al
Content-Length
4 Ottobre 2005
Stefano Clemente
73
La chiusura della connessione
HTTPS - il client
• Nel caso di chiusura incompleta il client
DOVREBBE recuperare con attenzione e
POTREBBE riaprire la sessione chiusa
• Il client DEVE inviare un segnale di chiusura
prima di chiudere la connessione
• Se il client non è più capace di ricevere dati
POTREBBE non attendere il segnale del server
e chiudere la connessione provocando una
chiusura incompleta al server
4 Ottobre 2005
Stefano Clemente
74
La chiusura della connessione
HTTPS - il server
• Un client HTTP può chiudere la connessione quando
crede e il server si gestisce questa situazione
• Un server DOVREBBE essere pronto alla gestione di
una chiusura incompleta
• Nelle implementazioni HTTP che non usano le
connessioni persistenti il server segnala la fine dei
dati chiudendo la connessione. Se si usa il ContentLength il client potrebbe aver già inviato il segnale di
chiusura e aver chiuso la connessione
• I server DEVONO tentare sempre lo scambio di
segnali di chiusura prima di chiudere effettivamente la
connessione
− i server POTREBBERO chiudere la connessione
immediatamente dopo aver segnalato la chiusura, generando
la chiusura incompleta lato client
4 Ottobre 2005
Stefano Clemente
75
La porta HTTPS
• All’inizio della connessione HTTP il server
si aspetta che il client invii una richiesta,
mentre il TLS (e quindi HTTPS) aspetta
di ricevere il segnale ClientHello
• HTTPS deve quindi ascoltare su una
porta diversa dalla 80 di HTTP
• Per default HTTPS usa la porta 443
4 Ottobre 2005
Stefano Clemente
76
URI per HTTPS
• Sono diverse da quelle HTTP
semplicemente per la parte di
identificazione del protocollo, nella quale
“https” rimpiazza “http”
• Esempio
https://www.ei.unibo.it
4 Ottobre 2005
Stefano Clemente
77
Identificazione dei partner:
identità del server
• Una richiesta HTTPS è generata in base a un URI, per
cui il client che la invia conosce il server
• Se l’host specificato in URI è disponibile, il client
DEVE ancora verificare la sua identità dal certificato
che il server invia alla connessione
• Il certificato è rilasciato da una Certification Authority
• Il controllo dell’identità dell’host POTREBBE essere
omesso solo nel caso in cui il client ha già le
informazioni circa la sua identità (es. ha già il
certificato)
4 Ottobre 2005
Stefano Clemente
78
Identificazione dei partner:
identità del server
• Se il certificato non corrisponde all’host in URI
− i client utilizzati da persone DEVONO eseguire una delle
seguenti azioni
• notificare il fatto all’utente
• chiudere la connessione
− le procedure automatiche DEVONO scrivere in appositi file
di log l’evento e DOVREBBERO chiudere la connessione
• Questi tipi di client POSSONO disporre di particolari settaggi
che disabilitano questo comportamento, ma DEVONO
disporre dei settaggi per l’abilitazione
4 Ottobre 2005
Stefano Clemente
79
Identificazione dei partner:
identità del client
• Il server HTTPS non ha nessuna
conoscenza del client coinvolto con la
comunicazione per cui non ha possibilità
di eseguire controlli
− problema insito nel protocollo HTTP
• Se il server ha possibilità di conoscere il
client attraverso altre fonti esterne al
protocollo DOVREBBE eseguire il
controllo dell’identità
4 Ottobre 2005
Stefano Clemente
80