UX & Coding

QUIC e HTTP/3: il futuro delle comunicazioni web più veloci

"QUIC è il protocollo di trasporto disegnato da Google e base dell'HTTP/3 che migliora le prestazioni delle applicazioni web riducendo la latenza delle connessioni e migliorando lo scambio dati"

QUIC (Quick UDP Internet Connections) è 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.

I protocolli HTTP

L’HTTP/1.1 (rilasciato nel 1999) aveva un problema chiamato Head of Line Blocking (HOLB), un fenomeno che si verifica quando una lista di pacchetti (la sequenza finita e distinta di dati trasmessa su una rete) viene bloccata dal primo.

Head of Line Blocking

In presenza di una richiesta lenta tutte le successive sono penalizzate dovendo attendere quelle meno veloci precedenti.

L’introduzione dell’HTTP/2 nel 2015 ha aggiunto il supporto multiplexing che consente la gestione di più richieste simultaneamente in modo che non si crei una coda.

In assenza di problemi di connettività funziona bene ma dato che tutte le richieste vengono inviate su una singola connessione TCP che potrebbe non avere buone prestazioni, l’intero caricamento delle pagine può risentirne sensibilmente se sussistono problemi.

QUIC, successore dell’HTTP/2 e pilastro dell’HTTP/3, è stato inizialmente sviluppato da Google nel 2012 e distribuito sia nel suo popolare browser Chrome che nella maggior parte dei suoi servizi, inclusi YouTube e la ricerca.

QUIC Logo

Ciò ha permesso di osservare il protocollo in azione e di modificarne il design prima di sottoporlo all’esame IETF nel 2016, che ha poi istituito il QUIC Working Group (gruppo di lavoro ufficiale).

Tra i suoi obiettivi principali si è posto quello di migliorare la gestione delle connessioni per risolvere i possibili blocchi e migliorare la velocità sul web.

QUiC no Head of Line Blocking

Riduzione dei pacchetti

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.

Round trip time
Il Round Trip Time è il tempo che intercorre tra l'invio di un segnale più il tempo necessario per la ricezione della conferma

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
AttesaReazione utente (rispetto all’attesa)
< 100 msIstantanea
100 ms – 300 msRagionevole
300 ms – 1 sSeccante
> 1 sChiusura 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.

Zero Round trip time
1 Pre-connessione esistente
2 Nuova connessione

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”.

QUIC e HTTP/3

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.

Controllare 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.

HTTP/3 diventerà uno standard ufficiale alla scadenza del draft, che avverrà in prossimità di Giungo 2019.

Unisciti alla community! Rimani aggiornato, scopri le migliori guide e ricevi risorse gratuite.



Aggiungi un commento

UX & Coding

Articoli recenti

Newsletter

Inserisci la tua email per restare aggiornato sulle ultime novità.