Internet compie 25 anni e la lingua che i browser usano per comunicare con i siti web, ovvero il protocollo HTTP (HyperText Transfer Protocol), non ha subito grandi cambiamenti da allora. Tuttavia ciò che è cambiato è il nostro uso del web, di conseguenza i limiti dell’HTTP/1 iniziano a rivelarsi. Caricare una pagina è un processo più lento di quanto dovrebbe essere in realtà e la rete non viene sfruttata così come dovrebbe. Questo perché l’HTTP/1 effettivamente permette ad una richiesta di essere collegata solamente a una singola connessione TCP per volta.
Dal momento che i siti web moderni necessitano spesso di fare più di un centinaio di richieste per caricare JavaScript, CSS e immagini, la situazione diventa alquanto problematica. Al giorno d’oggi i browser devono fare uso di più connessioni per ogni sito web per riuscire a scaricare tutti gli elementi, ma non possono usarne in quantità troppo elevata perché altrimenti causerebbe un sovraccarico della rete che porterebbe a un ulteriore congestione. Ecco perché il numero di connessioni usate dai browser si aggira attorno alle quattro e le otto: per ognuna di queste deve poi indovinare quale richiesta inviare, ma talvolta capita che non sia quella corretta.
Il grande numero di richieste su un sito web moderno causa un’ulteriore complicazione: ogni richiesta ha infatti una serie di header HTTP che sono aumentati nel tempo (tra gli altri motivi anche grazie ai cookie) e che possono accumulare una grande quantità di dati da inviare. Sulle reti mobili con un grado alto di latenza questo ha un impatto notevole sulla prestazione. Tutto ciò ha reso l’HTTP/1 lento e complicato da usare. Molti siti web tentano di affrontare questi problemi aggirandoli, facendo uso di tecniche per il CSS come l’attributo “media print”, la funzione “inline”, e la concatenazione. Per quanto siano un ausilio, questi stratagemmi sono al contempo degli indicatori che segnalano l’urgenza di un miglioramento.
Per questo nel 2012 si è incominciato a lavorare sull’HTTP/2. Il nuovo protocollo, basato sul progetto SPDY, permette di usare una connessione per tutte le comunicazioni tra il browser e il sito web. Riesce a fare questo dividendo i messaggi di richiesta da quelli di risposta in piccoli segmenti chiamati “frames” e etichettandoli così che possano essere riuniti una volta giunti al destinatario. Questo processo è conosciuto come “multiplexing” e permette alla rete di essere sfruttata in maniera molto più efficiente perché, a differenza dell’HTTP/1, c’è la possibilità di inviare più messaggi contemporaneamente. Inoltre l’HTTP/2 consente di comprimere gli header, il che significa che la dimensione della banda larga non viene sprecata ripetendo informazioni ridondanti. Ciò rende possibile caricare le pagine molto più rapidamente nonostante servano un alto numero di richieste, come fanno in molti, poiché le richieste richiedono meno tempo per attraversare la rete. Un’ulteriore ottimizzazione è data dalla funzione di “server-push”, la quale fa sì che un sito web invii risposte al browser prima che questo ne abbia bisogno: in conclusione, si tratta di un ennesimo esempio di miglioramento della prestazione.
I primi risultati indicano che utilizzando l’HTTP/2 si ottiene spesso (ma non sempre) un miglioramento del 5-15 % della performance. Con qualche messa a punto potrebbe aumentare ancora. È importante sapere che il nuovo protocollo non cambia elementi come i metodi HTTP, ad esempio gli header o gli stati del codice usati dagli API dell’HTTP rimangono pressappoco gli stessi. Il nuovo protocollo può essere utilizzato anche su una base di routing hop-by-hop, evitando così di aggiornare l’intera infrastruttura in una volta.
L’HTTP/2 è quasi completo e presto sarà supportato dai più popolari browser come Firefox, Internet Explorer e Google Chrome. Anche Akamai supporterà l’HTTPS/2, estendendo il nuovo protocollo a buona parte del web.