Ormai ci siamo Http 3 sta arrivando ufficialmente.

Vediamo di capire cos’è e cosa significa, ma prima dobbiamo capire come ci siamo arrivati..

HTTP è un acronimo per “HyperText Transfer Protocol” (protocollo di trasferimento di un ipertesto) ovvero un protocollo a livello applicativo utilizzato come sistema per la trasmissione di informazioni sul web.

La prima versione dell’HTTP, è stata la 0.9 e risale alla fine degli anni ’80.

L’HTTP/1.1 arriva, nel 1999, presentando però un problema detto HOLB: Head of Line Blocking: sostanzialmente un fenomeno che aveva luogo quando una lista di pacchetti, costituita dalla sequenza di dati finita e distinta tramessa su una rete, veniva bloccata dal primo.

Se era presente una richiesta lenta allora di conseguenza tutte quelle successive erano penalizzate e il sito web risultava lento.

Da allora sono stati introdotti numerosi miglioramenti e si sono susseguiti in quest’ordine: HTTP/2, QUIC (Quick UDP Internet Connections) inizialmente sviluppato da Google e, infine, HTTP/3, conosciuto anche come HTTP-over-QUIC.

La Versione Http/2 ha portato in dono il supporto multiplexing, questo ha fatto si che fosse possibile gestire più richieste contemporaneamente, così che non si formasse la coda. Le pagine quindi sono state liberate dal vincolo della progressione lineare dei download.

In questo modo una risorsa javascript di grandi dimensioni non rappresenta per forza un punto di strozzatura per tutte le risorse statiche in attesa di essere scaricate. Se si considera anche la compressione HPACK dell’header HTTP/2 e il formato binario predefinito per trasferire i dati non si può non convenire sul fatto che HTTP/2 sia un protocollo efficiente.

Tendenzialmente HTTP/2 se non sono presenti problemi di connettività funziona bene, però è altrettanto vero che siccome tutte le richieste vengono inviate su una singola connessione TCP e quest’ ultima non sempre gode di ottime prestazioni, l’intero caricamento delle pagine potrebbe risentirne se le condizioni non fossero ottimali.

Ma naturalmente Http/2 presentava pure degli svantaggi ovvero:

le principali implementazioni dei browser, per sfruttare i vantaggi di HTTP/2, hanno obbligato i siti web a implementare la crittografia SSL e questo ha causato un sovraccarico di calcolo che non ha fatto percepire i vantaggi legati alla velocità.

Inoltre, non è presente la funzione server-push per l’implementazione NGINX. Questo è uno svantaggio perché i moduli NGINX non sono come i moduli drop-in di Apache e quindi non si possono copiare, occorre ricompilare NGINX con tali moduli.

I problemi citati sono stati risolti e, osservando l’intero stack del protocollo, si nota come il vincolo principale sia ad un livello inferiore rispetto a HTTP/2.

Cosa cambia con l’avvento dell’Http/3?

Il protocollo http/3 non usa più come base portante il Tcp ma si appoggia mediante Quic sul protocollo Udp, è un protocollo di trasporto che si pone come obiettivo quello di ridurre i tempi di latenza rispetto a quelli offerti da TCP.

Il vantaggio principale di QUIC è che garantisce migliori prestazioni per le reti lente o con latenza elevata dato che gestisce le richieste in modo diverso rispetto ai precedenti protocolli.

L’efficientamento, la limitazione e la prevenzione degli errori legata all’invio dei pacchetti sono tra gli obiettivi principali di QUIC dato che sono parametri strettamente legati alla velocità di risposta.

Quando si ha a disposizione una connessione internet veloce, la latenza tra client e un server remoto “vicino” è solitamente compresa tra 10-50 ms: ogni pacchetto inviato attraverso la rete impiegherà questo tempo per essere ricevuto.

Se il server che viene contattato risiede in un altro continente o la navigazione viene effettuata tramite un operatore di telefonia mobile utilizzando connessioni più lente si ottiene immediatamente una penalità sulla latenza uguale o superiore ai 100 ms semplicemente a causa della distanza che deve essere percorsa.

Le reti mobili hanno inoltre un’ulteriore possibile ritardo compreso normalmente tra 100-150 ms (più vicino a 50 ms sulle connessioni 4G/LTE) tra il telefono e il server a causa delle frequenze radio e delle reti intermedie.

Poche centinaia di millisecondi possono sembrare un tempo trascurabile ma da svariati anni Google sostiene e ha dimostrato quanto la velocità e la reattività della risposta in un sito siano fondamentali per offrire una User Experience di qualità e per limitare il tasso di uscita.

Fonte, QUIC: Next generation multiplexed transport over UDP

Attesa	Reazione utente (rispetto all’attesa)
< 100 ms	Istantanea
100 ms – 300 ms	Ragionevole
300 ms – 1 s	Seccante
> 1 s	Chiusura pagina

Sui dispositivi mobili e per comunicazioni su grande distanza, la differenza tra l’invio e la ricezione unificata che offre QUIC può consentire un risparmio di diverse centinaia di millisecondi.

Il Round Trip Time

Per i servizi molto sensibili alla latenza come la ricerche sul Web, i maggiori guadagni derivano proprio da una connessione zero-round-trip.

Tipicamente per accedere ad una pagina HTTPS è prevista una comunicazione che richiede da 2 a 3 cicli (andata e ritorno) con il server per stabilire una connessione sicura prima che il browser possa scaricare la pagina.

QUIC è progettato in modo tale che se un client ha già dialogato con un server può iniziare a inviare dati senza tempi di attesa, il che rende la risposta client-server-client molto più veloce.

Anche su un sito molto ottimizzato come lo stesso Google, dove le connessioni sono spesso prestabilite, è comunque possibile ottenere un miglioramento del 3% nel tempo medio di caricamento delle pagine con QUIC.

Vantaggi di QUIC

L’approccio migliorativo di QUIC è molto simile a TCP+TLS+ HTTP/2 ma implementato sul protocollo di rete UDP.

Essendo TCP parte integrante nel kernel del sistema operativo è molto difficile apportare modifiche significative dato che bisogna lavorare su rilasci che hanno un impatto a livello di sistema e in genere vengono distribuite con cautela e lentezza sui server.

QUIC riduce le limitazione evitando la necessità di aggiornare i kernel dei sistemi dato che sposta il suo funzionamento nello “spazio utente”.

Dato che si basa su UDP, non presenta tali limiti ed offre alte prestazioni per gli utenti connessi a reti lente o con latenza elevata gestendo le richieste in modo diverso rispetto ai più datati protocolli.

Connessione più veloce

Il protocollo QUIC migliora la comunicazione tra client e server gestendo connessioni separate e indipendenti per ogni richiesta: in questo modo, anche se una chiamata non viene gestita in tempi brevi, essa non influisce sul rallentamento delle altre.

Avvia una connessione con un singolo pacchetto e comunica tutti i parametri TLS o HTTPS necessari direttamente al server senza dover dipendere da una risposta a differenza del TCP che ha bisogno per prima cosa ottenere ed elaborare una conferma del server.

Supporto al Multiplexing

Le connessioni QUIC sono identificate da un ID a 64 bit, generato casualmente dal client al contrario delle connessioni TCP composte da una combinazione di indirizzo sorgente, porta sorgente, indirizzo di destinazione e porta di destinazione.

Questo significa che se un client modifica gli indirizzi IP (ad esempio passando improvvisamente da una connessione Wi-Fi ad una in 3G) tutte le connessioni TCP attive non saranno più valide.

Nel momento in cui un client QUIC cambia gli indirizzi IP, può continuare a utilizzare il vecchio ID di connessione dal nuovo indirizzo IP senza interrompere alcuna richiesta in corso e garantendo quindi continuità.

Forward Error Correction

Attraverso un sistema di correzione degli errori, in caso di perdita di pacchetti durante la comunicazione non è necessario un ulteriore invio dei dati.

Questi possono essere ricostruiti in qualunque momento grazie ai pacchetti FEC (Forward Error Correction), ovvero una sorta di copia di sicurezza. Questo è essenzialmente il funzionamento del RAID 5 ma utilizzato a livello di rete.

Per consentire questa gestione c’è un compromesso necessario: ogni pacchetto UDP contiene più payload di quanto sia strettamente necessario (si stima circa il 10%), perché tiene conto del potenziale di pacchetti persi che possono essere ricreati più facilmente in questo modo.

Congestion control

TCP invia dati con una velocità incrementale che porta ad avere vantaggi in presenza di connessioni di dati veloci, ma che contribuisce ad aumentare il tasso di perdita dei pacchetti.

Se un pacchetto non viene inviato correttamente l’operazione riparte immediatamente riducendo la finestra di coda temporanea e causando una trasmissione dati a intervalli. QUIC ha una efficiente gestione del sovraccarico e fornisce informazioni più complete rispetto a TCP.

Grazie al Packet Pacing il tasso di invio è automaticamente gestito ed in questo modo si evita un sovraccarico anche in caso di connessioni poco reattive.

Autenticazione e crittografia

Uno dei più grandi problemi relativi al protocollo TCP riguarda l’intestazione dei pacchetti inviati che viene passata sotto forma di testo in chiaro e non può essere processata senza aver prima ricevuto l’autorizzazione; questo espone più facilmente le chiamate a possibili attacchi o ad una manipolazione.

I pacchetti QUIC sono sempre autentificati e per la maggior parte crittografati: le porzioni dell’header che non sono crittografate vengono protette dalle alterazioni grazie all’autenticazione da parte del destinatario.

Maggiore compatibilità

Un altro grande vantaggio di QUIC è che il suo funzionamento non è legato al sistema come nel caso del protocollo TCP che deve essere gestito dalle varie piattaforme e dispositivi perché sia possibile una comunicazione (questo comporta un supporto sia hardware che software).

Con QUIC la gestione è direttamente a livello di applicazione e la sua disponibilità è quindi dipendente da chi sviluppa il software che può decidere o meno di integrare questa caratteristica come hanno già fatto applicazioni come Google Server o i browser Chrome e Opera.

Controllare se QUIC è attivo

Per verificare se un sito usa QUIC basta utilizzare il Chrome DevTools di Google Chrome e caricare una pagina mantenendo aperto il Network panel.

Se nella colonna Protocol è presente la stringa http/2+quic/43 allora quel dominio sta utilizzando QUIC.

Alcuni servizi di hosting come l’ottimo SiteGround hanno già attivato da tempo il supporto e quindi i siti che risiedono sui loro server beneficiano direttamente di questa ulteriore ottimizzazione.

Rilascio ufficiale di HTTP/3

Lo standard HTTP/3 è un Internet-Draft (o ID) dell’IETF, l’organismo che si occupa di sviluppare e promuovere standard Internet in stretta cooperazione con il World Wide Web Consortium.

Attualmente l’ID di HTTP/3 è nella fase finale prima che le proposte vengano promosse a Request-for-Comments che corrispondono alle definizioni ufficiali dei protocolli Internet.

Per abilitarlo su Chrome (Ver. 83 e successive):

• Scrivere nella barra indirizzi di Chrome : chrome://flags e premere invio
• Cercare QUIC troverete Experimental QUIC protocol
• Nella tendina scegliere Enabled
• Riavviare Chrome

Per abilitarlo su Edge (Ver. 83 e successive):

• Scrivere nella barra indirizzi di Edge: edge://flags e premere invio
• Cercare QUIC troverete Experimental QUIC protocol
• Nella tendina scegliere Enabled
• Riavviare Edge

Per abilitarlo su Firefox

• Aprire da Firefox la pagina di configurazione about:config
• Cliccare su Accetto il rischio e continua
• Come da copertina, filtra la preferenza network.http.http3.enabled
• Impostare il valore della preferenza a true

Non è necessario riavviare il browser