Protocollo di applicazione

Strato applicazione

Un protocollo di applicazione definisce:

• I tipi di messaggi scambiati
• La sintassi
• La semantica dei campi
• Le regole che determinano quando e come un processo invia/risponde ai messaggi

Convenzionalmente il terminale che inizia la sessione viene considerato come client. Due processi in due diversi host comunicano scambiandosi messaggi attraverso il proprio socket, che si può immaginare come una porta reale. Perché un processo possa inviare messaggi ad un processo su un altro host, il mittente deve specificare l'IP della macchina host (32 bit che identificano univocamente l'interfaccia che la connette alla rete) ed un ID che specifichi il processo ricevente: a quest'ultima mansione assolve il numero di porta.

Protocolli dello strato applicazione

Ai più diffusi protocolli dello strato applicazione sono stati assegnati numeri di porta standard di default:

• Processo Web (HTTP): 80
• Server di posta (SMTP): 25
• Server di posta (POP3): 110

HTTP

È un protocollo testuale con messaggi costituiti da sequenze di byte, ognuno di questi è un carattere. L'HyperText Transfer Protocol è il cuore del Web.

Pagina web

Consiste di oggetti, file indirizzabili mediante singoli rispettivi URL. La maggior parte consiste di uno scheletro HTML e da più oggetti referenziati: il file base HTML rinvia agli altri oggetti attraverso i rispettivi URL.

URL: http://host[:port]/path[#fragment][?query]

Server usato per passare info risorsa sul server dal client al server. Default:80 punto interno alla risorsa.

Browser

È un user agent per il Web, implementa anche il lato client dell'HTTP, per questo useremo indifferentemente “browser” e “client” in questo contesto.

Server web

Memorizza gli oggetti ed implementa anche il lato server dell'HTTP. HTTP definisce come i client Web richiedono le pagine Web dai server, e come questi trasferiscono le pagine Web ai client. Fino al 1997 tutti i browser ed i server implementavano la versione HTTP/1.0, che usa la connessione non persistente:

Squall – http://www.quellidiinformatica.org – La community di Ingegneria Informatica a Napoli

• Il client apre una socket verso il porto 80
• Il server accetta la connessione
• Il client manda ACK e richiesta
• Il server risponde e chiude la connessione
• Il client effettua il parsing dello stream HTML e rileva link ad altri N oggetti: per scaricare ognuno si ripetono i passi da 1 a 4 (genero N+1 connessioni TCP)

La versione HTTP/1.1 consente la connessione persistente: il server lascia aperta la connessione TCP e permette quindi il trasferimento di un'intera pagina su una singola connessione. Una sintesi in termini di prestazioni:

Formato generico dei messaggi HTTP

HTTP Request

HTTP Response

• METHOD URL VERSION
• VERSION STATUS-CODE MSG

Host: www.site.edu

Server: Apache/1.3 (Unix)

Connection: keep-alive

Connection: close

User-agent: Mozilla/4.0

Last-Modified: Mon, 22 Jun 2003

Accept-language: it

Content-Length: 6820 (byte)

Content-Type: text/html

PAYLOAD

Lo STATUS-CODE si compone di 3 cifre: la prima indica la classe della risposta:

• 1xx Informational
• 2xx Successful 200 OK
• 3xx Redirection 301 Moved Permanently
• 4xx Client error 404 Not Found
• 5xx Server error 505 HTTP version not supported

Vediamo qualche METHOD: serve per richiedere una risorsa ad un server e può essere:

• GET
• Assoluto: senza specificazioni
• Condizionale: richiede la risorsa se è soddisfatto un criterio indicato negli header (es. if-modified-since)
• Parziale: richiede una sottoparte di una risorsa memorizzata

Generalmente non usa PAYLOAD. Simula il GET evitando però il traffico PAYLOAD: serve per il Debugging! HEAD usa il PAYLOAD per trasmettere info dal client al server. POST come POST, creando o sostituendo la risorsa.

Cookies

Essendo HTTP stateless, il server non è tenuto a mantenere info relative a connessioni precedenti: un Cookie è una breve informazione scambiata tra server e client tramite la quale mantiene lo stato di precedenti connessioni e lo manda al server ogni volta che richiede un documento.

• Client Server Request genera il Cookie
• Reply + Set-Cookie
• Request + Cookie analizza il Cookie
• Reply

Squall – http://www.quellidiinformatica.org – La community di Ingegneria Informatica a Napoli

Web caching

Le richieste non raggiungono direttamente il server, ma vengono intercettate da un proxy. Tipicamente un certo numero di client di una stessa rete condivide un proxy: se l'oggetto richiesto non è in cache questa lo richiede.