LIVELLO APPLICAZIONE IL PROTOCOLLO HTTP

IL PROTOCOLLO HTTP

“HTTP” sta per “Hypertext Transfer Protocol” ed è stato sviluppato da Tim Berners-Lee al CERN (Svizzera) insieme ad altri concetti che costituivano le fondamenta per il World Wide Web: HTML e URI. Mentre l’HTML (Hypertext Markup Language) definisce la struttura di un sito web, l’HTTP regola il modo in cui questa pagina viene trasferita dal server al client. Il terzo concetto, URL (Uniform Resource Locator), definisce il modo in cui la risorsa (ad esempio un sito web) debba essere indirizzata sul web. Con “Ipertesto” (Hypertext), il termine che appare nelle abbreviazioni HTTP e HTML, si intende un concetto che noi tutti conosciamo bene: collegare i file. Su un sito web si posizionano i collegamenti ipertestuali o link che conducono ad altre pagine. Se inserite un indirizzo Internet nel browser e poco dopo viene visualizzato un sito web, il browser ha comunicato con il server web attraverso HTTP. Metaforicamente parlando, l’HTTP è la lingua che utilizza il browser per parlare al server web e comunicargli ciò che viene richiesto.

COME FUNZIONA HTTP

Il modo più semplice per spiegare come funziona l’HTTP è aprire un sito web:

1. Apriamo “http://www.rifugioalbasini.it/contatti.html/” digitando rifugioalbasini.it nella barra di ricerca Google e aprire il sito non sicuro in quanto non usa HTTPS.
2. Il browser invia una richiesta corrispondente, la richiesta HTTP, al server web competente, il quale gestisce il dominio rifugioalbasini.it. Di solito la richiesta è “Per favore inviami il file”. In alternativa il client può semplicemente chiedere “Hai questo file?”.
3. Il server web riceve la richiesta HTTP, cerca il file desiderato (nell’esempio: la homepage di rifugioalbasini.it, ovvero il file contatti.html) e invia prima l’header, che utilizza un codice di stato per informare il client richiedente del risultato della sua ricerca.
4. Se il file viene trovato e il client desidera effettivamente che venga inviato (e non voleva solo sapere se esiste), dopo l’header il server invia il corpo del messaggio, ovvero il contenuto effettivo. Nel nostro esempio è il file contatti.html.
5. Il browser riceve il file e lo visualizza come sito web.

VERSIONI DI HTTP

La versione originale: HTTP/1

La storia dell’HTTP è iniziata nel 1989, quando Tim Berners-Lee e il suo team hanno iniziato a sviluppare il World Wide Web presso il CERN di Ginevra. La versione originale dell’HTTP era la versione 0.9 ed era chiamata “protocollo a una riga”. Tutto quello che poteva fare era ottenere un file HTML da un server.

GET /dummy.html

Il server non faceva altro che inviare il file appropriato. Pertanto, questa versione del protocollo era solamente in grado di gestire file HTML. Nel 1996 l’Internet Engineering Task Force (IETF) ha descritto nel memo RFC1945 la versione HTTP/1, tuttavia solo come proposta non vincolante. Recentemente è stato introdotto un header che potrebbe specificare meglio sia la richiesta del client sia la risposta del server. Tra l’altro è stato introdotto il campo dell’header “Content-Type”, che ha permesso di trasmettere file diversi dall’HTML. In breve, questa versione di HTTP aveva le seguenti caratteristiche:

• Senza connessione: il client stabilisce la connessione al server, invia la richiesta, il server risponde, quindi la connessione viene chiusa. Per la richiesta successiva il client deve ristabilire la connessione. Si tratta di un processo complicato perché un sito web di solito è costituito da più file e ognuno di essi deve essere “recuperato” mediante una richiesta autonoma.
• Stateless: le due parti, client e server, si “dimenticano” immediatamente l’una dell’altra. La volta successiva in cui il client accede al server, questo non sa che il client lo aveva già interpellato.
• Indipendente dai media: qualsiasi tipo di file può essere trasmesso via HTTP purché entrambe le parti sappiano come gestire il rispettivo tipo di file.

Il primo standard ufficiale: HTTP/1.1

Nel 1997 apparve la versione HTTP/1.1, descritta nel memo RFC2068. Era il primo standard “ufficiale” ed è in uso ancora oggi. Ha apportato importanti innovazioni rispetto alla versione HTTP/1:

• Keepalive: il client ha la possibilità di mantenere la connessione attraverso una richiesta (persistent connection), inviando un keepalive nell’header della sua richiesta.
• HTTP pipelining, in modo che il client possa inviare una richiesta successiva prima di ricevere la risposta alla prima.
• Nelle chat il browser può aggiornare la finestra del browser utilizzando il MIME type multipart/replace.
• I dati possono anche essere trasferiti dal client al server.
• Con il metodo TRACE, appena introdotto, è possibile seguire il percorso dal client al server web.
• Cache: ci sono nuovi meccanismi per memorizzare il contenuto nella cache.
• Host: grazie a una specifica corrispondente nell’header (host), una richiesta HTTP funziona anche se più domini diversi sono ospitati sotto un unico indirizzo IP, come accade oggi con la maggior parte dei siti web (Shared Webhosting).

Un rinnovo urgentemente necessario: HTTP/2

Nel corso degli anni i siti web sono diventati sempre più grandi e complessi. Per caricare un sito web moderno nel browser, il browser deve richiedere diversi megabyte di dati e inviare fino a cento richieste HTTP individuali. Poiché HTTP/1.1 prevede che le richieste all’interno di una connessione siano elaborate una dopo l’altra, più un sito web è complesso, maggiore è il tempo necessario per caricare la pagina. Pertanto Google ha sviluppato un nuovo protocollo sperimentale chiamato SPDY (pronuncia: “speedy”), che ha suscitato grande interesse da parte della comunità degli sviluppatori e alla fine ha portato alla pubblicazione della versione del protocollo HTTP/2 nel 2015. Questo nuovo standard apporta tra l’altro le seguenti innovazioni, tutte volte ad accelerare il caricamento dei siti web:

• Binario: il protocollo si basa su dati binari anziché su file di testo.
• Multiplex: client e server possono inviare e processare parallelamente più richieste HTTP.
• Compressione: gli header sono compressi; poiché spesso nelle molte richieste HTTP sono quasi identici, la compressione elimina la ridondanza non necessaria.
• Server Push: se il server è in grado di prevedere quali dati saranno ancora necessari al client, può inviarli alla cache del client, senza una precedente richiesta HTTP.

HTTP/2 si è affermato rapidamente; in particolare, è stato subito adottato dai siti web con molto traffico. Attualmente (aggiornato a gennaio 2020) secondo W3Techs il 42 per cento circa dei siti web usa la versione HTTP/2.

APPROFONDIMENTO FUNZIONAMENTO HTTP/1.1

L’HTTP è un protocollo che lavora con un’architettura di tipo client/server: il client esegue una richiesta e il server restituisce la risposta mandata da un altro host. Nell’uso comune il client corrisponde al browser ed il server la macchina su cui risiede il sito web. Vi sono quindi due tipi di messaggi HTTP: messaggi richiesta e messaggi risposta. HTTP differisce da altri protocolli di livello 7 come FTP, per il fatto che le connessioni vengono generalmente chiuse una volta che una particolare richiesta (o una serie di richieste correlate) è stata soddisfatta. Questo comportamento rende il protocollo HTTP ideale per il World Wide Web, in cui le pagine molto spesso contengono dei collegamenti (link) a pagine ospitate da altri server diminuendo così il numero di connessioni attive limitandole a quelle effettivamente necessarie con aumento quindi di efficienza (minor carico e occupazione) sia sul client che sul server. Talvolta però pone problemi agli sviluppatori di contenuti web, perché la natura senza stato (stateless) della sessione di navigazione costringe ad utilizzare dei metodi alternativi – tipicamente basati sui cookie – per conservare lo stato dell’utente.

MESSAGGIO DI RICHIESTA

Il messaggio di richiesta è composto di quattro parti:

1. riga di richiesta (request line);
2. sezione header (informazioni aggiuntive);
3. riga vuota (CRLF: i 2 caratteri carriage return e line feed);
4. body (corpo del messaggio).

RIGA DI RICHIESTA

La riga di richiesta è composta da metodo, URI e versione del protocollo. Il metodo di richiesta, per la versione 1.1, può essere uno dei seguenti:

GET

POST

HEAD

PUT

DELETE

PATCH

TRACE

OPTIONS

CONNECT

l’URI, Uniform Resource Identifier (identificatore univoco di risorsa), indica l’oggetto della richiesta (ad esempio la pagina web che si intende ottenere). I metodi http più comuni sono GET, HEAD e POST. Il metodo GET è usato per ottenere il contenuto della risorsa indicata come URI (come può essere il contenuto di una pagina HTML). HEAD è analogo a GET, ma restituisce solo i campi dell’header, ad esempio per verificare la data di modifica del file. Una richiesta con metodo HEAD non prevede l’uso del body. Il metodo POST è usato di norma per inviare informazioni al server (ad esempio i dati di un form). In questo caso l’URI indica che cosa si sta inviando e il body ne indica il contenuto.

GLI HEADER DELLA RICHIESTA

Gli header di richiesta più comuni sono:

1. Host: nome del server a cui si riferisce l’URL. È obbligatorio nelle richieste conformi HTTP/1.1 perché permette l’uso dei virtual host basati sui nomi.
2. User-Agent: identificazione del tipo di client: tipo browser, produttore, versione…
3. Cookie: utilizzati dalle applicazioni web per archiviare e recuperare informazioni a lungo termine sul lato client. Spesso usati per memorizzare un token di autenticazione o per tracciare le attività dell’utente.

MESSAGGIO DI RISPOSTA

Il messaggio di risposta è di tipo testuale ed è composto da quattro parti:

• riga di stato (status-line);
• sezione header;
• riga vuota (CRLF: i 2 caratteri carriage return e line feed);
• body (contenuto della risposta).

La riga di stato riporta un codice a tre cifre catalogato nel seguente modo:

• 1xx: Informational (messaggi informativi)
• 2xx: Successful (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)

I codici di risposta più comuni sono:

• 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.
• 502 Bad Gateway. Il server web che agisce come reverse proxy non ha ottenuto una risposta valida dal server di upstream.
• 505 HTTP Version Not Supported. La versione di http non è supportata.

GLI HEADER DELLA RISPOSTA

Gli header della risposta più comuni sono:

• Server: Indica il tipo e la versione del server. Può essere visto come l’equivalente dell’header di richiesta User-Agent
• Content-Type: Indica il tipo di contenuto restituito. La codifica di tali tipi (detti Media type) è registrata presso lo IANA (Internet Assigned Number Authority); essi sono detti tipi MIME (Multimedia Internet Mail Extensions), la cui codifica è descritta nel documento RFC 1521. Alcuni usuali tipi MIME incontrati in una risposta HTTP sono:

1. 1. text/html Documento HTML
   2. text/plain Documento di testo non formattato
   3. text/xml Documento XML
   4. image/jpeg Immagine di formato JPEG

TIPO DI CONNESSSIONE

Il client può chiedere al server, nel messaggio di richiesta, di utilizzare due tipi di comunicazione.

Non persistente

Per ogni richiesta e relativa risposta, viene stabilita una connessione TCP dedicata.

Persistente

Ogni richiesta e relativa risposta è trasferita utilizzando la stessa connessione TCP. È il comportamento predefinito di HTTP 1.1.

Da un lato, le connessioni non persistenti introducono una latenza aggiuntiva rispetto a quelle persistenti di almeno 3 Round Trip Time (RTT). Infatti, al termine di ogni risposta da parte del server si rendono necessari

1.5 o 2 RTT per la chiusura della connessione corrente, con la sua stretta di mano conclusiva a tre o quattro passaggi di FIN ed ACK (three- o four-way handshake).

1.5 RTT per l’apertura della nuova connessione, per i tre passaggi di SYN e ACK.

D’altro canto, le connessioni persistenti precludono il parallelismo nelle comunicazioni, giacché il client che abbia diverse richieste da inviare allo stesso server è costretto ad evaderle sequenzialmente, una dopo l’altra. Per queste ragioni, i browser solitamente sfruttano le complementarità prestazionali delle due politiche di comunicazione per massimizzare la loro efficienza: solitamente aprono con ogni server diverse connessioni TCP in parallelo, su cui comunicano con strategia persistente.

ESEMPI DI MESSAGGI HTTP

1. Navigare su una pagina web.
2. Aprire gli strumenti del browser facendo click su ispeziona.
3. Nella scheda Network si possono vedere i vari messaggi scambiati tra client e server.

APPROFONDIMENTO HTTP/2

HTTP/2 (originariamente chiamato HTTP/2.0) è la nuova versione del protocollo di rete HTTP usato dal World Wide Web. È basato su SPDY. HTTP/2 è stato sviluppato dal Working Group Hypertext Transfer Protocol (http bis) dell’Internet Engineering Task Force. HTTP/2 sarebbe la prima nuova versione del protocollo HTTP dalla nascita di HTTP 1.1, il quale è standard RFC 2616 nel 1999. Il Working Group ha presentato HTTP/2 allo IESG proponendolo come standard nel dicembre 2014. Gli sforzi effettuati per la standardizzazione sono una risposta allo SPDY, un protocollo HTTP-compatibile sviluppato da Google e supportato in Chrome, Opera, Firefox, Internet Explorer 11, Safari, e Amazon Sil.

DIFFERENZE CON HTTP 1.1

I cambiamenti proposti non richiedono nessuna modifica al modo di lavorare delle applicazioni web esistenti, ma le nuove applicazioni possono avvantaggiarsi delle novità introdotte per incrementare la velocità. HTTP/2 mantiene ad alto livello la maggior parte della sintassi di HTTP 1.1 come metodi, codici di stato, campi degli header, URI. La differenza sta nel modo in cui è strutturato e trasportato il flusso dei dati tra il client e il server. I siti web efficienti minimizzano il numero di richieste necessarie per restituire una pagina con la tecnica del “minifying” o minimizzazione (riducendo le dimensioni del codice e impacchettando piccoli pezzi di codice in unità più grandi, senza intaccarne la funzionalità) applicata su risorse come immagini e script. Ad ogni modo la minimizzazione non è necessariamente conveniente né efficiente e può ancora richiedere connessioni HTTP distinte per ottenere la pagina e le risorse minimizzate. HTTP/2 permette al server di inviare (“push”) più dati di quelli richiesti dal client. Questo consente al server di fornire dati che sa essere necessari ad un web browser per completare la pagina, senza attendere che il browser esamini la prima risposta e senza l’overhead di un ciclo di richiesta addizionale.

SUCCESSIVE DIFFERENZE CON SPDY

SPDY (si pronuncia “spidi”) è un progetto di ricerca portato avanti da Google. Il protocollo derivato dal progetto SPDY, che porta lo stesso nome, è inteso per il trasporto di informazioni e altro contenuto sul web, con obiettivo principale la riduzione della latenza. SPDY si appoggia sempre sulla stessa pipe TCP, ma utilizza differenti protocolli per ottenere questa riduzione. Le modifiche di base apportate a HTTP/1.1 per creare SPDY includono: “vero pipelining delle richieste senza restrizioni FIFO, un meccanismo di framing dei messaggi per semplificare lo sviluppo di client e server, compressione obbligatoria (compresi gli header), gestione delle priorità e anche comunicazioni bi-direzionali.” Il gruppo di lavoro httpbis prese in considerazione il protocollo SPDY di Google, l’HTTP Speed+Mobility proposal (basato su SPDY) di Microsoft e il Network-Friendly HTTP Upgrade. Nel luglio 2012 Facebook fornì un feedback su ciascuna delle proposte e raccomandò che HTTP/2 fosse basato su SPDY.[12] La bozza iniziale di HTTP/2 fu pubblicata a novembre 2012 ed era basata direttamente su una copia di SPDY. La maggior differenza tra HTTP/1.1 e SPDY è che ad ogni azione di un utente in SPDY viene assegnato uno “stream ID”, il che significa che un singolo canale TCP connette l’utente al server. SPDY suddivide le richieste in controllo o dati, che è un “semplice eseguire il parsing del protocollo binario con due tipi di frame”. SPDY ha mostrato un evidente miglioramento rispetto HTTP, con incrementi della velocità di caricamento di una pagina dall’11.81% fino al 47.7%. HTTP/2 usa SPDY come punto di partenza. In HTTP/2, comunque, viene utilizzato un algoritmo di compressione Huffman, di tipo code-based, anziché la compressione dinamica stream-based usata in SPDY. Questo aiuta a ridurre potenziali rischi di attacchi sul protocollo. Il 9 febbraio 2015 Google ha annunciato di prevedere la rimozione del supporto per SPDY in Chrome entro i primi mesi del 2016, in favore del supporto a HTTP/2, iniziando da Chrome 40. Nonostante HTTP/2 sia stato progettato per supportare sia HTTP che HTTPS, di fatto tutte le implementazioni all’interno dei principali browser (Firefox, Chrome, Safari, Opera, IE, Edge) hanno deciso di supportare esclusivamente HTTP/2 attraverso TLS, rendendolo di fatto un requisito.

APPROFONDIMENTO AI

1. HTTP: HyperText Transfer Protocol

L’HTTP (HyperText Transfer Protocol) è il protocollo di comunicazione utilizzato per il trasferimento di informazioni su Internet, in particolare tra un client (solitamente un browser web) e un server web. È il protocollo su cui si basa il World Wide Web e permette la visualizzazione delle pagine web.

1.1 Funzionamento di HTTP

HTTP è un protocollo stateless (senza stato), il che significa che ogni richiesta tra il client e il server è indipendente e non mantiene informazioni sullo stato delle comunicazioni precedenti. Ogni volta che un utente richiede una pagina web, il browser invia una richiesta al server, il quale risponde con le risorse richieste (come pagine HTML, immagini, video, ecc.).

Il processo di comunicazione HTTP avviene tramite un meccanismo di richieste e risposte:

•Client: il browser invia una richiesta HTTP al server.

•Server: il server elabora la richiesta e restituisce una risposta (contenuto web o un messaggio di errore).

1.2 Metodi HTTP

Esistono vari metodi HTTP, che indicano al server quale azione eseguire in relazione alla risorsa. I metodi principali sono:

•GET: Richiede dati dal server. È utilizzato per ottenere informazioni o caricare una pagina web.

•POST: Invia dati al server, ad esempio un modulo di contatto o di registrazione.

•PUT: Carica una risorsa sul server o ne modifica una esistente.

•DELETE: Rimuove una risorsa dal server.

•HEAD: Simile a GET, ma non restituisce il corpo del documento, solo le informazioni dell’intestazione (headers).

•OPTIONS: Richiede al server quali metodi di richiesta sono supportati su una risorsa specifica.

1.3 Porta e Sicurezza di HTTP

HTTP utilizza la porta 80 per la comunicazione. Uno degli svantaggi principali di HTTP è la mancanza di crittografia: i dati inviati tra il client e il server sono in chiaro e possono essere intercettati e letti da terze parti malintenzionate.

2. HTTPS: HyperText Transfer Protocol Secure

L’HTTPS (HyperText Transfer Protocol Secure) è la versione sicura di HTTP. Utilizza una combinazione di HTTP e SSL/TLS (Secure Sockets Layer/Transport Layer Security) per crittografare la comunicazione tra il client e il server, garantendo che i dati trasmessi non possano essere intercettati o alterati da terzi.

2.1 Funzionamento di HTTPS

L’HTTPS aggiunge un livello di sicurezza tramite la crittografia SSL/TLS. Quando un utente accede a un sito HTTPS:

1. Handshaking: Il browser e il server stabiliscono una connessione sicura attraverso un processo chiamato handshake. In questo processo, vengono negoziati chiavi crittografiche che verranno utilizzate per proteggere la comunicazione.

2. Crittografia: Una volta stabilita la connessione sicura, tutte le informazioni scambiate tra il browser e il server sono crittografate.

3. Autenticazione: Il server HTTPS utilizza un certificato digitale (rilasciato da un’autorità di certificazione, ad esempio Let’s Encrypt o Symantec) per dimostrare la propria identità e autenticità.

2.2 Vantaggi di HTTPS

•Crittografia: HTTPS garantisce che i dati trasmessi tra il client e il server siano crittografati, rendendoli illeggibili per terze parti.

•Integrità dei dati: HTTPS assicura che i dati non vengano alterati durante la trasmissione.

•Autenticazione: HTTPS autentica il server, garantendo all’utente che sta comunicando con il server legittimo e non con un’entità fraudolenta.

•SEO: I motori di ricerca come Google danno priorità ai siti HTTPS rispetto ai siti HTTP, migliorando il loro posizionamento nelle ricerche.

2.3 Porta e Sicurezza di HTTPS

HTTPS utilizza la porta 443 per la comunicazione. Grazie all’implementazione di SSL/TLS, HTTPS protegge i dati sensibili, come numeri di carta di credito, credenziali di accesso, e informazioni personali. 

3. Come Avviene la Transizione da HTTP a HTTPS

La transizione da HTTP a HTTPS è diventata essenziale per la sicurezza delle comunicazioni online. Il processo di transizione include:

•Acquisto di un certificato SSL/TLS: Gli amministratori di siti web devono acquistare (o ottenere gratuitamente) un certificato SSL/TLS da un’autorità di certificazione (CA).

•Configurazione del server: Il certificato deve essere installato e configurato correttamente sul server.

•Redirezione da HTTP a HTTPS: Una volta configurato HTTPS, tutte le richieste HTTP devono essere redirette verso la versione HTTPS del sito.

•Aggiornamento dei link interni: Ogni collegamento interno che punta a una risorsa HTTP dovrebbe essere aggiornato per utilizzare HTTPS.

4. Conclusione

HTTP e HTTPS sono entrambi protocolli utilizzati per la comunicazione tra client e server, ma differiscono notevolmente in termini di sicurezza. HTTPS rappresenta il nuovo standard, indispensabile per garantire la sicurezza e la fiducia nelle comunicazioni online. L’utilizzo di HTTPS è particolarmente importante per i siti che gestiscono informazioni sensibili come password e dati finanziari, mentre HTTP è ormai considerato obsoleto per la maggior parte delle applicazioni moderne.

LINK AI POST PRECEDENTI

RETI DI CALCOLATORI

HTTPS