Cos’è l’HTTP?

All’inizio dell’indirizzo di un sito web c’è “http://” (o “https://”), che indica il pro­to­col­lo HTTP, uti­liz­za­to dal browser per ri­chia­ma­re un sito web. Qui di seguito vi pre­sen­tia­mo il concetto di HTTP, spie­ghia­mo le dif­fe­ren­ze tra le diverse versioni e mostriamo a quali altri concetti è correlato.

“HTTP” sta per “Hypertext Transfer Protocol” ed è stato svi­lup­pa­to da Tim Berners-Lee al CERN (Svizzera) insieme ad altri concetti che co­sti­tui­va­no le fon­da­men­ta 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 tra­sfe­ri­ta 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 in­di­riz­za­ta sul web.

Con “Ipertesto” (Hypertext), il termine che appare nelle ab­bre­via­zio­ni HTTP e HTML, si intende un concetto che noi tutti co­no­scia­mo bene: collegare i file. Su un sito web si po­si­zio­na­no i col­le­ga­men­ti iper­te­stua­li o link che conducono ad altre pagine.

Se inserite un indirizzo Internet nel browser e poco dopo viene vi­sua­liz­za­to un sito web, il browser ha co­mu­ni­ca­to con il server web at­tra­ver­so HTTP. Me­ta­fo­ri­ca­men­te parlando, l’HTTP è la lingua che utilizza il browser per parlare al server web e co­mu­ni­car­gli ciò che viene richiesto.

Ini­zial­men­te l’HTTP veniva impiegato solo per ri­chie­de­re un documento HTML da un server web. Oggi il pro­to­col­lo si utilizza in molti modi diversi:

• i browser ri­chie­do­no tramite l’HTTP tutti i tipi di media uti­liz­za­ti su siti web moderni: testo, immagini, video, codice programma ecc.
• I programmi ap­pli­ca­ti­vi uti­liz­za­no l’HTTP per caricare file e ag­gior­na­men­ti da server remoti.
• La REST API è una soluzione basata su HTTP per il controllo dei servizi web.
• Anche la WebDAV è una tec­no­lo­gia basata su HTTP.
• Nella co­mu­ni­ca­zio­ne Machine-to-Machine l’HTTP è uti­liz­za­to come pro­to­col­lo per la co­mu­ni­ca­zio­ne tra i servizi web.
• I media player uti­liz­za­no HTTP.
• Anche gli accessi a un database sul web, ovvero le ope­ra­zio­ni CRUD, possono essere ef­fet­tua­ti tramite HTTP.

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

Il server non faceva altro che inviare il file ap­pro­pria­to. Pertanto, questa versione del pro­to­col­lo era solamente in grado di gestire file HTML.

Nel 1996 l’Internet En­gi­nee­ring Task Force (IETF) ha descritto nel memo RFC1945 la versione HTTP/1, tuttavia solo come proposta non vin­co­lan­te. Re­cen­te­men­te è stato in­tro­dot­to un header che potrebbe spe­ci­fi­ca­re meglio sia la richiesta del client sia la risposta del server. Tra l’altro è stato in­tro­dot­to il campo dell’header “Content-Type”, che ha permesso di tra­smet­te­re file diversi dall’HTML. In breve, questa versione di HTTP aveva le seguenti ca­rat­te­ri­sti­che:

• Senza con­nes­sio­ne: il client sta­bi­li­sce la con­nes­sio­ne al server, invia la richiesta, il server risponde, quindi la con­nes­sio­ne viene chiusa. Per la richiesta suc­ces­si­va il client deve ri­sta­bi­li­re la con­nes­sio­ne. Si tratta di un processo com­pli­ca­to perché un sito web di solito è co­sti­tui­to da più file e ognuno di essi deve essere “re­cu­pe­ra­to” mediante una richiesta autonoma.
• Stateless: le due parti, client e server, si “di­men­ti­ca­no” im­me­dia­ta­men­te l’una dell’altra. La volta suc­ces­si­va in cui il client accede al server, questo non sa che il client lo aveva già in­ter­pel­la­to.
• In­di­pen­den­te dai media: qualsiasi tipo di file può essere trasmesso via HTTP purché entrambe le parti sappiano come gestire il ri­spet­ti­vo tipo di file.

Nel 1997 apparve la versione HTTP/1.1, descritta nel memo RFC2068. Era il primo standard “ufficiale” ed è in uso ancora oggi. Ha apportato im­por­tan­ti in­no­va­zio­ni rispetto alla versione HTTP/1:

• Keepalive: il client ha la pos­si­bi­li­tà di mantenere la con­nes­sio­ne at­tra­ver­so una richiesta (per­si­stent con­nec­tion), inviando un keepalive nell’header della sua richiesta.
• HTTP pi­pe­li­ning, in modo che il client possa inviare una richiesta suc­ces­si­va prima di ricevere la risposta alla prima.
• Nelle chat il browser può ag­gior­na­re la finestra del browser uti­liz­zan­do il MIME type multipart/replace.
• I dati possono anche essere tra­sfe­ri­ti dal client al server.
• Con il metodo TRACE, appena in­tro­dot­to, è possibile seguire il percorso dal client al server web.
• Cache: ci sono nuovi mec­ca­ni­smi per me­mo­riz­za­re il contenuto nella cache.
• Host: grazie a una specifica cor­ri­spon­den­te 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 We­b­ho­sting).

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 ri­chie­de­re diversi megabyte di dati e inviare fino a cento richieste HTTP in­di­vi­dua­li. Poiché HTTP/1.1 prevede che le richieste all’interno di una con­nes­sio­ne siano elaborate una dopo l’altra, più un sito web è complesso, maggiore è il tempo ne­ces­sa­rio per caricare la pagina.

Pertanto Google ha svi­lup­pa­to un nuovo pro­to­col­lo spe­ri­men­ta­le chiamato SPDY (pronuncia: “speedy”), che ha suscitato grande interesse da parte della comunità degli svi­lup­pa­to­ri e alla fine ha portato alla pub­bli­ca­zio­ne della versione del pro­to­col­lo HTTP/2 nel 2015. Questo nuovo standard apporta tra l’altro le seguenti in­no­va­zio­ni, tutte volte ad ac­ce­le­ra­re il ca­ri­ca­men­to dei siti web:

• Binario: il pro­to­col­lo si basa su dati binari anziché su file di testo.
• Multiplex: client e server possono inviare e pro­ces­sa­re pa­ral­le­la­men­te più richieste HTTP.
• Com­pres­sio­ne: gli header sono compressi; poiché spesso nelle molte richieste HTTP sono quasi identici, la com­pres­sio­ne elimina la ri­don­dan­za non ne­ces­sa­ria.
• Server Push: se il server è in grado di prevedere quali dati saranno ancora necessari al client, può inviarli alla cache del client, senza una pre­ce­den­te richiesta HTTP.

HTTP/2 si è affermato ra­pi­da­men­te; in par­ti­co­la­re, è stato subito adottato dai siti web con molto traffico. At­tual­men­te (ag­gior­na­to a gennaio 2020) secondo W3Techs il 42 per cento circa dei siti web usa la versione HTTP/2.

Un punto debole di tutte le pre­ce­den­ti versioni HTTP era il pro­to­col­lo di trasporto TCP sot­to­stan­te, che chiede al de­sti­na­ta­rio di ri­con­fer­ma­re ogni pacchetto dati prima di poter inviare il suc­ces­si­vo. Se un pacchetto viene perso, tutti gli altri pacchetti devono attendere la ri­tra­smis­sio­ne di quello perso. In tal caso gli esperti parlano di “Head-of-Line Blocking”.

Pertanto il nuovo HTTP/3 non dovrebbe più basarsi su TCP ma su UDP, che non richiede tali misure cor­ret­ti­ve. Sulla base di UDP è stato svi­lup­pa­to il pro­to­col­lo QUIC (Quick UDP Internet Con­nec­tions), che dovrebbe co­sti­tui­re la base per HTTP/3.

HTTP/3 non è stato ancora de­fi­ni­ti­va­men­te approvato dallo IETF. Tuttavia, secondo W3Techs già il 3 per cento circa dei siti web utilizza QUIC o HTTP/3.