TL;DR

Nel novembre 2018, l’Internet Engineering Task Force (IETF) si è riunito a Bangkok per l’adozione di un nuovo Internet Draft. Al protocollo di trasporto QUIC, un successore di HTTP/2, è stato assegnato il nome HTTP/3. Il protocollo HTTP/3 si basa su UDP ed è già utilizzato da importanti aziende di Internet come Google e Facebook. Se utilizzate Chrome e vi connettete ad un servizio Google, probabilmente state già utilizzando QUIC.

La nuova versione del protocollo HTTP sfrutta il protocollo UDP di basso livello e definisce molte delle nuove funzionalità presenti nelle versioni precedenti di HTTP a livello di TCP. Questo fornisce un modo per risolvere i vincoli all’interno dell’infrastruttura internet esistente.

I primi risultati sono promettenti, e quando l’Internet Draft dell’IETF scadrà nel giugno 2019, potremo aspettarci che HTTP/3 sia promosso a nuovo standard HTTP di terza generazione.

HTTP/3 si baserà nuovamente sui risultati di HTTP/2 per velocizzare il web. 🚀 Click to Tweet

HTTP/3 È in Arrivo

Alcuni sostengono che nell’industria del web la fame di maggiore velocità e minore latenza è pari solo alla fame di RAM di Google Chrome.

Nel 2016 abbiamo pubblicato un articolo su HTTP/2, uno standard che, secondo W3Techs, ha attualmente un tasso di adozione mondiale intorno al 34%. E secondo Can I use, è anche supportato da tutti i moderni browser web. Ed eccoci qui, a scrivere un articolo sulla prossima versione del protocollo, HTTP/3.

Utilizzo HTTP/2

Utilizzo HTTP/2

Al momento in cui scriviamo, HTTP/3 è un Internet-Draft (o ID) dell’IETF, il che significa che è allo studio un imminente standard Internet da parte della Internet Engineering Task Force – un organismo internazionale degli standard internet, incaricato di definire e promuovere accordi sugli standard dei protocolli internet, come TCP, IPv6, VoIP, Internet of Things, ecc.

È un organismo aperto che riunisce l’industria del web e facilita la discussione sulla direzione che seguirà Internet.

Attualmente, l’ID di HTTP/3 è nella sua ultima fase prima che le proposte vengano promosse a livello di RFC-s o Request-for-Comments, che possiamo considerare, a tutti gli effetti, le definizioni ufficiali dei protocolli Internet. A questo punto sono implementati da tutti i principali attori di internet.

Ciò significa che HTTP/3 diventerà uno standard ufficiale alla scadenza del draft, che avverrà nel corso l’anno (giugno 2019).

Un Po’ di Background – È Iniziato Con HTTP/2

Da Kinsta abbiamo l’ossessione di spremere dal nostro stack ogni millisecondo popssibile, sia con soluzioni come l’utilizzo delle ultime versioni di PHP, sia con la consegna dei dati tramite la rete premium di Google Cloud Platform, sia con il caching delle risorse del nostro CDN HTTP/2.

HTTP/2 ha apportato alcuni seri miglioramenti con download non bloccanti, pipeline e server push che ci hanno aiutato a superare alcune limitazioni del protocollo TCP sottostante. Questo ci ha permesso di ridurre al minimo il numero dei cicli richiesta-risposta e di handshake.

HTTP/2 ha reso possibile il push di più di una risorsa in una singola connessione TCP – multiplexing. Abbiamo anche ottenuto una maggiore flessibilità nell’ordinare i download statici e le nostre pagine non sono più vincolate alla progressione lineare dei download.

HTTP/2 push

HTTP/2 push

In pratica, ciò significa che ora una risorsa javascript di grandi dimensioni non è necessariamente un punto di strozzatura per tutte le altre risorse statiche rimaste in attesa del proprio turno.

No Pipelining contro pipelining

No pipelining contro pipelining (Origine immagine: Wikipedia, Autore Mwhitlock)

Aggiungete a questo la compressione HPACK dell’header HTTP/2 e il formato binario predefinito per il trasferimento dei dati, ed ecco a voi, in molti casi, un protocollo significativamente più efficiente.

Compressione HTTP/2 HPACK

Compressione HTTP/2 HPACK

Le principali implementazioni dei browser hanno reso obbligatorio per i siti web l’implementazione della crittografia – SSL – per poter sfruttare i benefici di HTTP/2 – e a volte questo ha comportato un sovraccarico di calcolo che ha reso i miglioramenti nella velocità non percepibili. Ci sono stati anche alcuni casi in cui gli utenti hanno segnalato un rallentamento con la transizione a HTTP/2.

Diciamo solo che i primi giorni di adozione di questa versione non sono stati per deboli di cuore.

Inoltre, l’implementazione di NGINX mancava della funzione server-push, basandosi solo su un modulo. E i moduli NGINX non sono i soliti moduli drop-in di Apache che potete semplicemente copiare: NGINX deve essere ricompilato con questi moduli.

Sebbene alcuni di questi problemi ora sono stati risolti, se guardiamo all’intero stack del protocollo, vediamo che il vincolo principale si trova ad un livello inferiore rispetto ad HTTP/2.

Per descriverlo meglio, analizzeremo lo stack del protocollo Internet di oggi a partire dal layer inferiore. Se volete sapere di più sul background di HTTP/2, non perdetevi la nostra guida definitiva ad HTTP/2.

Internet Protocol (IP)

L’IP (Internet Protocol) definisce la parte inferiore dell’intera topologia di Internet. È la parte dello stack di Internet che possiamo dire tranquillamente che non è negoziabile senza dover cambiare tutto, compresa la sostituzione dell’intera infrastruttura hardware, dai router ai server e persino alle macchine degli utenti finali.

Quindi, sebbene la revisione del protocollo possa essere una cosa necessaria, uno sforzo di tale portata non è prevedibile in questo momento, soprattutto perché non abbiamo trovato un’alternativa valida, innovativa ma compatibile con le versioni precedenti.

Al di sotto c’è il Livello di accesso alla rete – la parte del protocollo che, per così dire, è “al nocciolo”.

Nota a margine, un caso convincente di revisione completa può essere desunto dalla velocità con cui i creatori dell’IPFS (file system interplanetario) sono riusciti a chiudere un finanziamento ICO che gli ha procurato 250 milioni di USD in un mese.

Possiamo tornare a ritroso all’inizio del protocollo IP fino al 1974, ad un documento pubblicato dall’Institute of Electrical and Electronics Engineers di Vint Cerf e Bob Cahn. Il documento descriveva pacchetti inviati su una rete, instradati attraverso indirizzi IP e indirizzi numerici definiti di nodi in rete/reti. Il protocollo definiva il formato di questi pacchetti, o datagrammi, le sue intestazioni e il carico utile.

Dopo la definizione della RFC 760 del 1980, l’IETF si è fermata alla definizione ampiamente utilizzata fino ad oggi, nella sua Request For Comments 791. Si tratta della quarta versione del protocollo, ma potremmo dire che è la prima versione di produzione.

Internet Protocol (RFC791)

Internet Protocol (Origine immagine: RFC791)

Il protocollo utilizza indirizzi a 32 bit, cosa che imposta un limite al numero di indirizzi a circa 4 miliardi. Questa limitazione è la spiegazione del mistero del perché gli utenti di Internet non business ricevano dai loro ISP “indirizzi IP dinamici”, e un IP statico è considerato un “valore aggiunto” e spesso soggetto a costi addizionali.

Stanno razionando.

Dopo un po’ ci si è resi conto che gli indirizzi a 32 bit non erano sufficienti e in breve tempo si sarebbero esauriti, così sono state pubblicate molte RFC per cercare di risolvere il problema. Sebbene queste soluzioni siano oggi ampiamente utilizzate, e facciano parte della nostra vita quotidiana, continuano ad accumulare problemi.

L’Internet Protocol versione 6, o IPv6, è nato come soluzione per superare questi limiti e per essere gradualmente adottato al posto della versione precedente. È stato creato un documento Draft Standard per l’IETF nel 1998 ed è stato promosso a Internet Standard nel 2017.

Mentre lo spazio degli indirizzi IPv4 è limitato dalla lunghezza degli indirizzi a 32 bit, allo standard IPv6 sono stati assegnati 128 bit, ossia 3,4 * 10 ^ 38 possibili indirizzi. Dovrebbe essere sufficiente per un bel po’ di tempo.

Secondo quanto afferma Google sulla connettività IPv6 tra i suoi utenti, a marzo 2019 l’adozione di IPv6 è di poco superiore al 25%.

Adozione IPv6

Adozione IPv6

L’IP è uno layer rudimentale dello stack di Internet che definisce la maggior parte delle cose di base, senza garanzie di consegna, integrità dei dati o ordine dei pacchetti trasmessi. Da solo è inaffidabile. Il formato dell’intestazione dell’IPv4 fornisce il checksum dell’header, utilizzato dai nodi di trasmissione per verificare l’integrità dell’intestazione. Questo lo rende diverso dalla versione IPv6, che si basa sul sottostante Livello di accesso alla rete, che gli consente di essere più veloce.

Internet Datagram Header

Internet Datagram Header (Origine immagine: RFC791)

Capire il ruolo di TCP e UDP

È il momento di capire come HTTP/3 si integra con TCP e UDP.

TCP

Mentre IP è il layer sottostante a tutte le nostre comunicazioni online di oggi, TCP (Transmission Control Protocol) è una parte di livello superiore della suite di protocolli Internet, e garantisce l’affidabilità necessaria al web, alla posta, al trasferimento di file (FTP) – all’applicazione dei layer/protocolli di Internet.

Ciò include la creazione di connessioni a più fasi, con handshake, ordine sicuro dei pacchetti e ritrasmissione dei pacchetti persi. Fornisce feedback (Acks) di consegna al mittente e così via. C’è anche il calcolo del checksum per la rilevazione degli errori.

Tutte queste cose stanno ad indicare i molti passaggi che rendono TCP un protocollo affidabile, rendendolo una solida base dei più noti servizi Internet che usiamo oggi.

Fino ad oggi le sue specifiche risalenti al 1974 (RFC 675) e al 1981 (RFC 793) non sono cambiate sostanzialmente.

L’affidabilità fornita da TCP, tuttavia, non è senza costi. Il sovraccarico di tutti i roundtrip richiesti dagli handshake, dai feedback di consegna, dalle garanzie di ordine e dai checksum che potrebbero essere considerati deboli e ridondanti. Questo ha reso il TCP un collo di bottiglia del moderno stack di protocolli. HTTP/2 ha raggiunto un tale miglioramento della velocità che lo stesso può essere raggiunto solo al top di TCP.

Cambiare il TCP in modo sostanziale non è un’impresa semplice, perché il protocollo è parte dello stack TCP/IP che risale agli anni ’70. È profondamente integrato nei sistemi operativi, nel firmware dei dispositivi, ecc.

UDP

Anche UDP (User Datagram Protocol) è una delle parti dell’Internet Protocol Suite, con le sue specifiche risalenti al 1980 (RFC 768).

È, come suggerisce il nome, un protocollo senza connessione basato su datagramma. Il che significa che non ci sono handshake e non c’è garanzia di ordine o consegna. Questo significa che tutti i possibili passaggi per garantire la consegna, l’integrità dei dati e quant’altro è lasciato al layer dell’applicazione. Ciò significa che un’applicazione che si aggiunge a UDP può scegliere le strategie che impiegherà a seconda del caso concreto, oppure può eventualmente sfruttare elementi del livello di accesso alla rete, come i checksum, per evitare sovraccarichi.

Dato che l’UDP è diffuso proprio come il TCP, consente di ottenere miglioramenti senza richiedere un ampio cambio del firmware su tutti i dispositivi connessi a Internet o cambiamenti significativi nei sistemi operativi.

La distribuzione di nuovi protocolli è ostacolata da molti firewall, NAT, router e altre scatole nel mezzo che consentono solo la distribuzione di TCP o UDP tra gli utenti e i server che devono raggiungere. – HTTP/3 explained

Questo thread su Hacker News può aiutarci a capire il ragionamento alla base della costruzione della nuova versione di HTTP in cima allo stack di rete esistente, piuttosto che reinventarlo da zero (anche se c’è dell’altro oltre a questo).

Le specifiche del formato dei pacchetti UDP sono piuttosto ridotte, l’intestazione è composta dalla porta di origine, dalla porta di destinazione, dalla lunghezza in byte, dall’intestazione e dai dati del pacchetto e dal checksum. Il checksum può essere utilizzato per verificare l’integrità dei dati sia per l’intestazione che per i dati del pacchetto.

Il checksum è facoltativo quando il layer del protocollo sottostante è IPv4 e obbligatorio con IPv6. Finora, UDP è stato utilizzato per cose come la sincronizzazione dell’orologio dei sistemi informatici (NTP), applicazioni VoIP, streaming video, sistema DNS e protocollo DHCP.

QUIC e HTTP/3

QUIC (Quick UDP Internet Connections) è stato implementato per la prima volta da Google nel 2012. Ridefinisce i confini dei livelli di rete, basandosi sul protocollo UDP di livello inferiore, ridefinendo gli handshake, le caratteristiche di affidabilità e le funzionalità di sicurezza nello “spazio utente”, evitando la necessità di aggiornare i kernel dei sistemi su tutta la internet.

Stack HTTP/2 verso stack HTTP/3

Stack HTTP/2 verso stack HTTP/3

Proprio come è successo con HTTP/2, che è stato un avanzamento guidato da SPDY o speedy di Google, HTTP/3 si baserà nuovamente su questi risultati.

Anche se HTTP/2 ci ha fornito il multiplexing e attenuato l’head-of-line-blocking, è limitato dal TCP. È possibile utilizzare una singola connessione TCP per più flussi multiplex insieme per trasferire dati, ma quando uno di quei flussi subisce una perdita di pacchetti, l’intera connessione (e tutti i suoi flussi) sono tenuti in ostaggio, per così dire, fino a quando TCP fa le sue cose (ritrasmette il pacchetto perso).

Ciò significa che tutti i pacchetti, anche se sono già stati trasmessi e in attesa nel buffer del nodo di destinazione, vengono bloccati fino a quando il pacchetto perso viene ritrasmesso. Daniel Stenberg, nel suo libro su http/3 lo chiama “head of line block basato su TCP”. Afferma che, con una perdita di pacchetti del 2%, gli utenti faranno meglio con HTTP/1, con sei connessioni per proteggersi da questo rischio.

QUIC non subisce questo vincolo. Con QUIC in costruzione sul protocollo UDP senza connessione, il concetto di connessione non porta i limiti del TCP e gli errori di un flusso non devono necessariamente avere effetti su tutto il resto.

Come ha detto Lucas Pardue di Cloudflare:

Lucas Pardue su HTTP/3

Lucas Pardue su HTTP/3

Concentrandosi sugli stream UDP, QUIC raggiunge il multiplexing senza dover ricorrere a una connessione TCP. QUIC crea la sua connessione a un livello superiore rispetto a TCP. Nuovi flussi all’interno delle connessioni QUIC non sono costretti ad aspettare che gli altri terminino. Le connessioni QUIC beneficiano anche del superamento del sovraccarico dell’handshake TCP, il che riduce la latenza.

Quelli di Cisco hanno realizzato un video interessante che spiega l’handshake a 3 vie di TCP.

Sebbene QUIC si allontani dalle caratteristiche di affidabilità TCP, le ripropone al di sopra del livello UDP, provvedendo alla ritrasmissione di pacchetti, all’ordinamento e così via. Google Cloud Platform ha introdotto il supporto di QUIC nel 2018 per i bilanciatori di carico ed ha registrato un miglioramento del tempo medio di caricamento delle pagine dell’8% a livello globale e del 13% nelle regioni in cui la latenza è più elevata.

Tra Google Chrome, YouTube, Gmail, Google Search e altri servizi, Google è stato in grado di implementare QUIC su una bella porzione di Internet, senza attendere l’IETF. Gli ingegneri di Google sostengono che nel 2017 il 7% del traffico Internet era già stato trasmesso tramite QUIC.

La versione di Google di QUIC era centrata solo sul trasporto HTTP, con sintassi HTTP/2. Il gruppo dell’IETF (responsabili della standardizzazione di QUIC) hanno deciso che la versione IETF di QUIC dovrebbe essere in grado di trasportare più del semplice HTTP. Per il momento, tuttavia, qualsiasi lavoro su protocolli non HTTP su QUIC è sospeso.

Un’altra cosa che il gruppo di lavoro dell’IETF ha deciso è che la versione standardizzata utilizzerà la crittografia TLS 1.3 anziché la soluzione personalizzata di Google. TLS 1.3, rispetto alle versioni precedenti, contribuisce anche alla velocità del protocollo, in quanto i suoi handshake richiedono meno roundtrip. Kinsta supports TLS 1.3 on all of our servers and our Kinsta CDN.

Al momento, Google continua a utilizzare la sua versione di QUIC nel suo prodotto, dirigendo al contempo gli sforzi di sviluppo verso gli standard IETF. La maggior parte degli altri attori di Internet sta sviluppando al top della versione IETF (tra i due ci sono altre differenze oltre alla crittografia).

Se apriamo Chrome Dev Tools e cariciamo alcuni prodotti Google, come Gmail, nella colonna Protocollo della scheda Network, vedremo molte risorse caricate tramite la versione di Google del protocollo QUIC. Questo vale anche per altri prodotti Google come Analytics, Google Tag Manager, ecc.

Google service QUIC

Google service QUIC

Cloudflare ha recentemente pubblicato un aggiornamento molto esteso sui progressi della standardizzazione.

Sebbene UDP fornisca QUIC e HTTP/3 alcuni vantaggi intrinseci, porta con sé anche alcune sfide. TCP è stato il protocollo mainstream per anni, mentre UDP non lo è, quindi i sistemi operativi e lo stack software che lo riguardano, in generale, non sono ottimizzati. Di conseguenza, con QUIC c’è un carico e requisiti di CPU molto più elevati; secondo alcune stime, il doppio rispetto a HTTP/2.

Le ottimizzazioni scendono in profindità fino al kernel dei sistemi operativi e dei diversi firmware di router e periferiche. Questa guida all’ottimizzazione di Red Hat potrebbe far luce sull’argomento per coloro che sono più inclini agli aspetti tecnologici.

Potremmo dire che QUIC tenta di riprogettare le funzionalità TCP su un protocollo più minimale e flessibile.

Le connessioni QUIC, che abbiamo citato in precedenza, combinano TLS e handshake di trasporto. Una volta stabiliti, vengono identificati da CID univoci (ID di connessione). Questi ID persistono attraverso le modifiche degli IP e possono contribuire a garantire download ininterrotti su, ad esempio, un passaggio da 4G a WiFi. Ciò è rilevante, in particolare perché sempre più traffico internet viene condotto sui dispositivi mobili. Ci si potrebbe chiedere se questo elemento sia concepito da Google per facilitare un migliore tracciamento degli utenti attraverso diverse connessioni e provider internet.

Il TLS è obbligatorio ed è pensato per rendere difficile la manomissione dei dispositivi nel mezzo o per fiutare il traffico. Ecco perché non è raro vedere provider di firewall e vendors come Cisco considerare il protocollo UDP come un problema e spiegare come disabilitarlo. È più difficile per gli operatori intermedi ispezionare e supervisionare o filtrare il traffico QUIC.

I flussi QUIC vengono inviati tramite connessioni QUIC, unidirezionali o bidirezionali. Gli stream hanno ID che identificano l’iniziatore, stabiliscono se lo stream è unidirezionale o bidirezionale e servono anche il controllo del flusso in-stream.

Mentre QUIC è un protocollo a livello di trasporto, HTTP è al livello subito sopra, un protocollo a livello di applicazione, o un protocollo di applicazione.

Dato che la compatibilità con le versioni precedenti è della massima importanza, l’implementazione di HTTP/3 promossa da IETF includerà la versione precedente (HTT1 o HTTP/2) nella risposta. Comprenderà un’intestazione che informa il client che HTTP/3 è disponibile, insieme alle informazioni su porta/host, come descritto nella RFC 7838.

È diverso da HTTP/2, in cui il trasporto può essere negoziato all’interno dell’handshake TLS. Ma poiché IETF ha quasi adottato HTTP/3 su QUIC come prossimo standard, possiamo aspettarci che i client web anticipino sempre di più il supporto di HTTP/3. È possibile che i client memorizzino dati da connessioni HTTP/3 precedenti e connettano direttamente (zero-round-trip o 0-RTT) nelle visite successive allo stesso host.

Riepilogo

C’è chi pensa che, non essendo ancora stato adottato lo standard HTTP/2, potrebbe essere troppo presto per spingere per HTTP/3 (versione tre). È un’obiezione valida, ma, come abbiamo detto, questo protocollo ha già avuto test e implementazioni su larga scala. Google ha iniziato a testarlo già nel 2015, così come Facebook nel 2017.

Da allora, altri attori si sono uniti agli sforzi di standardizzazione, come Akamai e Mozilla. All’ultimo hackathon IETF del novembre 2018, l’elenco dei partecipanti ha dimostrato l’interesse per QUIC da parte di aziende come Facebook, Apple, Google, Mozilla, NetApp e LiteSpeed ​​Tech. Ci sono stati alcuni test promettenti, e sembra che LiteSpeed ​​possa essere il primo importante fornitore con un server HTTP/3 in funzione. Anche Cloudflare sta utilizzando QUIC in versione beta.

Dopo breve tempo, QUIC è stato rinominato in HTTP/3 nell’Internet Draft dell’IETF. Scadrà alla fine di giugno 2019 e, a luglio, possiamo aspettarci la RFC o lo standard definitivo.

Quest’anno sarà emozionante, poiché possiamo attenderci di vedere le mosse dei principali produttori di software per l’implementazione del nuovo standard.

Quando sarà disponibile HTTP/3 su Kinsta?

Qui a Kinsta usiamo Nginx, quindi dobbiamo aspettare che inizino a supportare ufficialmente QUIC. Al momento questo aspetto è in fase di lavorazione e in programma per la branch 1.17 di Nginx. Una volta rilasciata la versione, state sicuri che il team di Kinsta valuterà la possibilità di aggiungere il supporto nella nostra piattaforma.


Se ti è piaciuto questo articolo, allora apprezzerai la piattaforma di hosting WordPress di Kinsta. Metti il turbo al tuo sito web e ricevi supporto 24x7 dal nostro team di veterani di WordPress. La nostra infrastruttura potenziata da Google Cloud è centrata su scaling automatico, performance e sicurezza. Permettici di mostrarti la differenza di Kinsta! Scopri i nostri piani