HTTP / 3 è la prossima generazione del protocollo HTTP. È alimentato da QUIC, che sostituisce TCP a livello di trasporto e riduce il numero di round trip che un client deve effettuare per stabilire una connessione.
Cosa lo rende migliore?
Se non si riesce a capire dall’acronimo “QUIC”, HTTP / 3 è molto più veloce.
HTTP è solo una parte di Modello OSI, che alimenta Internet come lo conosciamo. Ogni livello del modello ha uno scopo diverso, con API di alto livello come HTTP che si trovano in cima (il livello dell’applicazione), fino ai cavi fisici e alle connessioni che si collegano ai router:
Ma c’è un collo di bottiglia in questo modello e, nonostante il nuovo nome, lo standard HTTP stesso non è il problema.
TCP (il livello di trasporto) è il colpevole qui; è stato progettato negli anni ’70 e come tale non è stato costruito per gestire molto bene la comunicazione in tempo reale. HTTP-over-TCP ha raggiunto il limite. Google e il resto dello spazio tecnologico hanno lavorato su un sostituto per TCP.
Nel 2012, Google ha creato SPDY, un protocollo che si basa su TCP e risolve molti problemi comuni. SPDY stesso è deprecato, ma parti di esso si sono fatte strada in HTTP / 2, che è attualmente utilizzato da 40% del web.
QUIC è un nuovo standard, molto simile a SPDY, ma è costruito su UDP piuttosto che su TCP. UDP è molto più veloce di TCP, ma è generalmente meno affidabile in quanto non ha lo stesso controllo degli errori e prevenzione delle perdite di TCP. Viene comunemente utilizzato nelle applicazioni che non richiedono la presenza di pacchetti in esatto ordine corretto, ma attenzione alla latenza (come le videochiamate in diretta).
QUIC è ancora affidabile, ma implementa il controllo degli errori e l’affidabilità oltre a UDP, quindi ottiene il meglio da entrambi i protocolli. La prima volta che un utente si connette a un sito abilitato QUIC, lo farà tramite TCP.
Il problema principale con TCP che QUIC risolve è il blocco dell’head-of-line. Una volta stabilita una connessione tra server e client, il server invia pacchetti di dati al client. Se la connessione è difettosa e un pacchetto viene perso, il client trattiene tutti i pacchetti ricevuti successivamente fino a quando il server non ritrasmette il pacchetto perso. HTTP / 2 risolve in qualche modo questo problema, consentendo più trasferimenti sulla stessa connessione TCP, ma non è perfetto e può effettivamente essere più lento di HTTP / 1 con connessioni ad alta perdita.
QUIC risolve questo problema e gestisce molto meglio le connessioni ad alta perdita. I primi test di Google hanno mostrato miglioramenti di circa il 15% in scenari ad alta latenza e fino al 30% di miglioramenti nel buffering video sulle connessioni mobili. Poiché QUIC riduce il numero di strette di mano che devono essere fatte, ci saranno miglioramenti della latenza su tutta la linea.
È difficile da implementare?
Sebbene QUIC sia un nuovo standard, è costruito su UDP, che è già supportato quasi ovunque. Non richiederà nuovi aggiornamenti del kernel, il che può essere problematico per i server. QUIC dovrebbe funzionare immediatamente su qualsiasi sistema che supporti UDP
HTTP-over-QUIC dovrebbe essere un sostituto immediato per HTTP-over-TCP una volta che è prontamente disponibile. Al momento della scrittura, Chrome supporta QUIC, ma è disabilitato per impostazione predefinita. Puoi abilitarlo per il test andando su:
chrome://flags
e attivando il flag “Protocollo sperimentale QUIC”. Firefox aggiungerà il supporto più avanti in autunno e, con il passaggio di Edge a Chromium, anche loro riceveranno presto il supporto.
Sul lato server, se stai utilizzando CloudFlare come CDN, sarai in grado di abilitare l’opzione già nella tua dashboard, anche se non avrai molti client che la utilizzano effettivamente fino a quando i browser mobili non lo hanno attivato per impostazione predefinita. Fastly è lavorando attivamente sul supporto. Se vuoi abilitarlo sul tuo server web, dovrai aspettare un po ‘: il supporto anticipato per QUIC dovrebbe arrivare durante il ciclo di sviluppo di nginx 1.17, ma il supporto per Apache non è ancora in vista.
Una volta che nginx e Apache sono stati aggiornati per supportarlo, aggiungere QUIC alla tua pagina web o app web sarà semplice come aggiornare il tuo server web e abilitare l’opzione. Non dovrai apportare alcuna modifica alla tua app o al tuo codice, poiché tutto viene gestito a livello di infrastruttura. Non è ancora qui, ma arriverà molto presto e vorrai sicuramente abilitarlo una volta supportato per impostazione predefinita.