HTTP/3: il nuovo Hypertext Transfer Protocol

L’HTTP/3 è il nuovo membro della famiglia di pro­to­col­li HTTP che so­sti­tui­rà i suoi pre­de­ces­so­ri HTTP/1, HTTP/2 e HTTP-over-QUIC. Il pro­to­col­lo è ancora in fase di sviluppo, ma è già sup­por­ta­to da Google Chrome, Microsoft Edge, Firefox e da aprile 2020 anche da Safari.

In origine, la terza versione dello standard HTTP è nata con il nome “HTTP-over-QUIC” come pro­to­col­lo spe­ri­men­ta­le basato su UDP. Ini­zial­men­te HTTP-over-QUIC era stato con­si­de­ra­to il po­ten­zia­le suc­ces­so­re di HTTP/2, ma da gennaio 2020 ha uf­fi­cial­men­te assunto il nome di HTTP/3. Rimane da vedere la velocità con cui lo standard riuscirà ad af­fer­mar­si.

In ogni caso, grazie alla tra­smis­sio­ne dati basata su UDP, l’HTTP/3 ga­ran­ti­sce tempi di ca­ri­ca­men­to più brevi e una sicurezza maggiore. Se cal­co­lia­mo, tuttavia, che l’HTTP/2 viene sup­por­ta­to dall’80 percento dei browser dalla sua pub­bli­ca­zio­ne nel 2015, ma che la sua adozione da parte dei fornitori procede a rilento, non dobbiamo aspet­tar­ci un’impennata immediata nel supporto di HTTP/3.

Appena tre anni dopo la pub­bli­ca­zio­ne dello standard HTTP/2, a novembre 2018, l’Internet En­gi­nee­ring Task Force (IETF) ha in­tro­dot­to il nuovo standard Hypertext Transfer Protocol HTTP/3. L’IETF non ha, tuttavia, concepito il pro­to­col­lo da zero, anzi, l’organismo ha sem­pli­ce­men­te ri­co­no­sciu­to i segni del tempo e pro­get­ta­to un pro­to­col­lo web che ga­ran­tis­se una tra­smis­sio­ne dati più veloce, una sicurezza maggiore e con­nes­sio­ni più ef­fi­cien­ti. Google ha svi­lup­pa­to il suc­ces­so­re di HTTP/2 QUIC (Quick UDP Internet Con­nec­tions) già nel 2012, im­ple­men­tan­do­lo come HTTP-over-QUIC in numerosi prodotti.

L’HTTP/3 va quindi ora a riunire i vantaggi dei pro­to­col­li di tra­smis­sio­ne esistenti, HTTP/2 e HTTP-over-QUIC, in un unico standard per offrire una tra­smis­sio­ne dei dati più veloce e stabile. Il pro­to­col­lo HTTP/3 dovrebbe so­sti­tui­re l’HTTP/2 basato su TCP con un approccio QUIC o UDP.

Per capire cosa offra l’HTTP/3 è in­nan­zi­tut­to ne­ces­sa­rio com­pren­de­re la funzione di QUIC, UDP e HTTP/2. In sostanza, l’HTTP/3 nasce dalla com­bi­na­zio­ne di questi tre elementi. Già il nome HTTP-over-QUIC sug­ge­ri­sce che la tra­smis­sio­ne dei dati avviene tramite UDP piuttosto che TCP.

L’HTTP/2 utilizza il TCP, il pro­to­col­lo di tra­smis­sio­ne più diffuso nel web. Il TCP sta­bi­li­sce le con­nes­sio­ni tramite handshake su più livelli e trasmette i pacchetti di dati in ordine cro­no­lo­gi­co, quindi li invia uno alla volta e procede nella tra­smis­sio­ne solo quando quella del pacchetto prima è stata conclusa. La tra­smis­sio­ne è protetta da co­sid­det­ti ACK, ovvero conferme di richiesta e consegna e numeri di verifica. I dati trasmessi tramite il TCP con­ten­go­no un’in­te­sta­zio­ne con parametri che con­sen­to­no ai processi del mittente di con­net­ter­si ai processi cor­ri­spon­den­ti del de­sti­na­ta­rio.

Il TCP è molto af­fi­da­bi­le per quanto riguarda la com­ple­tez­za delle tra­smis­sio­ni dei dati, ma è soggetto a code di dati e tempi di ca­ri­ca­men­to più lunghi dal momento che vengono in­ter­rot­te tutte le tra­smis­sio­ni finché un pacchetto di dati smarrito non viene tra­sfe­ri­to con successo. L’HTTP/2 co­sti­tui­sce in un certo senso il limite della famiglia di pro­to­col­li, dal momento che non è possibile ve­lo­ciz­za­re la tra­smis­sio­ne di dati senza in­tro­dur­re un pro­to­col­lo nuovo.

Google si è attivato im­me­dia­ta­men­te svi­lup­pan­do il proprio pro­to­col­lo di tra­smis­sio­ne QUIC. QUIC aggira il problema delle code di dati tipiche di TCP sfrut­tan­do la tra­smis­sio­ne UDP con­nec­tion­less basata su da­ta­gram­mi. UDP lavora, proprio come TCP, sul livello di trasporto ri­nun­cian­do, tuttavia, alle conferme di de­sti­na­ta­rio e mittente. Questo significa che altre tra­smis­sio­ni non devono aspettare che venga conclusa quella pre­ce­den­te. La co­mu­ni­ca­zio­ne tra client e server viene quindi no­te­vol­men­te ac­ce­le­ra­ta. L’IETF ha ri­co­no­sciu­to i vantaggi del nuovo pro­to­col­lo e lo ha in­tro­dot­to nel 2018 come versione suc­ces­si­va di HTTP/2 con il nome HTTP-over-QUIC.

Il pro­to­col­lo di tra­smis­sio­ne HTTP rimane prin­ci­pal­men­te invariato. Esso è ancora co­sti­tui­to da un’in­te­sta­zio­ne e da un corpo (body) e utilizza verbi, cookie e caching. La dif­fe­ren­za sta nel modo di tra­smis­sio­ne e nella crit­to­gra­fia integrata.

Uti­liz­za­re QUIC per il pro­to­col­lo HTTP/2 implica adat­ta­men­ti fun­zio­na­li concreti che hanno, tramite la versione spe­ri­men­ta­le HTTP-over-QUIC, portato alla nascita di HTTP/3.

La funzione nuova più im­por­tan­te della terza versione del pro­to­col­lo è l’utilizzo esclusivo di URL HTTPS. Ogni URL più datato e non crit­to­gra­fa­to è marcato come non sicuro. L’utilizzo di QUIC e UDP permette a HTTP/3 di saltare il passaggio della crit­to­gra­fia TSL a livello TCP, con­sen­ten­do al pro­to­col­lo di sfruttare au­to­ma­ti­ca­men­te una crit­to­gra­fia TLS 1.3. L’HTTP/3 può quindi essere uti­liz­za­to solo se è presente una crit­to­gra­fia.

Altre funzioni nuove includono una con­nes­sio­ne costante qualora la rete cambiasse nel corso della tra­smis­sio­ne (lato client o lato server), un numero no­te­vol­men­te ridotto di pacchetti di dati, dato che la tra­smis­sio­ne di questi ultimi avviene tramite stream paralleli, e una “forward error cor­rec­tion”, ovvero una cor­re­zio­ne di errori che avviene già a livello di QUIC.

I vantaggi di HTTP/3 sono l’aumento della velocità di tra­smis­sio­ne, tempi di ca­ri­ca­men­to più rapidi e una con­nes­sio­ne più stabile. Basandosi su UDP, l’HTTP/3 aggira i punti deboli di TCP e sfrutta tutti i vantaggi di HTTP/2 e HTTP-over-QUIC.

Anche se l’HTTP/2 sfrutta la mul­ti­pla­zio­ne (o mul­ti­ple­xing), ovvero il download con­tem­po­ra­neo dei dati, deve ancora fare i conti con l’head-of-line-blocking. Si tratta di colli di bottiglia digitali che ral­len­ta­no tutti gli stream quando un pacchetto va perso su uno di questi. Grazie all’UDP, l’HTTP/3 non attende il com­ple­ta­men­te di una tra­smis­sio­ne, ma procede sem­pli­ce­men­te con il processo di ca­ri­ca­men­to.

Il pro­to­col­lo HTTP/3 rinuncia, inoltre, agli handshake iniziali per ve­ri­fi­ca­re la sicurezza di una con­nes­sio­ne. Invece di tra­smet­te­re richieste di sicurezza al livello TLS superiore, la crit­to­gra­fia avviene di­ret­ta­men­te tramite il pro­to­col­lo di tra­smis­sio­ne. Il tempo richiesto per stabilire una con­nes­sio­ne si riduce con HTTP/3 da due a una sola fase.

L’HTTP/3 non ha più bisogno di indirizzi IP per com­ple­ta­re i download, ma utilizza ID di con­nes­sio­ne in­di­vi­dua­li che con­sen­to­no un download costante anche se cambia la rete.

Grazie alla con­nes­sio­ne più stabile, fles­si­bi­le e veloce, l’HTTP/3 ga­ran­ti­sce un’espe­rien­za migliore so­prat­tut­to agli utenti mobile.

Di seguito trovate una pa­no­ra­mi­ca degli aspetti in comune e delle dif­fe­ren­ze di HTTP/3 rispetto a HTTP/2:

Dif­fe­ren­ze:

• L’HTTP/3 si basa su UDP, mentre l’HTTP/2 utilizza TCP.
• Grazie alla crit­to­gra­fia TLS 1.3 integrata, il pro­to­col­lo HTTP/3 non ha bisogno di richieste di crit­to­gra­fia (handshake) ag­giun­ti­ve a livello TLS, aggirando verifiche di sicurezza superflue.
• Grazie alla crit­to­gra­fia TSL 1.3 integrata, l’HTTP/3 supporta solo con­nes­sio­ni criptate, a dif­fe­ren­za di HTTP/2.

Aspetti in comune:

• Entrambi i pro­to­col­li uti­liz­za­no la com­pres­sio­ne dell’in­te­sta­zio­ne, ma l’HTTP/3 utilizza la com­pres­sio­ne QPack invece di quella HPAck dell’HTTP/2 che è legata a un ordine dei pacchetti.
• Sia l’HTTP/3 che l’HTTP/2 sup­por­ta­no server push, ossia l’invio ac­ce­le­ra­to di dati CSS e Ja­va­Script, che servono al browser in ogni caso per vi­sua­liz­za­re una pagina.
• Entrambi i pro­to­col­li uti­liz­za­no il mul­ti­ple­xing di richiesta e risposta, ovvero la tra­smis­sio­ne parallela di dati pro­ve­nien­ti da fonti diverse.
• La prio­ri­tiz­za­zio­ne della tra­smis­sio­ne dei dati comporta, con entrambi i pro­to­col­li, il ca­ri­ca­men­to ge­rar­chi­co dei contenuti di una pagina, senza attendere il com­ple­ta­men­to di ulteriori richieste.

Molti critici dell’HTTP/3 fanno presente che la distanza tra la terza e la seconda versione del pro­to­col­lo è troppo rav­vi­ci­na­ta e che l’UDP è un pro­to­col­lo di rete di dubbia re­pu­ta­zio­ne. Il nuovo pro­to­col­lo HTTP ga­ran­ti­sce, inoltre, vantaggi so­prat­tut­to all’utente. I fornitori invece devono far fronte a diverse dif­fi­col­tà a causa del passaggio da TCP e TLS a UDP e QUIC.

Dato che la verifica di sicurezza e la crit­to­gra­fia non avvengono più tramite TLS, ma di­ret­ta­men­te tramite UDP, che deve re­ca­pi­ta­re il massimo numero di pacchetti nel minor tempo possibile, i fornitori temono che il traffico di dati non venga più con­trol­la­to a suf­fi­cien­za a causa della mancata au­ten­ti­ca­zio­ne TLS. L’aspetto più criticato dai servizi Internet è quindi la sicurezza delle ap­pli­ca­zio­ni e dei dati. Il pro­to­col­lo TCP veniva con­si­de­ra­to af­fi­da­bi­le e orientato alla con­nes­sio­ne grazie alla sua chiara regola di richiesta e risposta. Dato che QUIC svolge molti dei passaggi au­to­no­ma­men­te, sorge il timore che l’HTTP/3 limiti le pos­si­bi­li­tà di verifica da parte dei fornitori, fa­ci­li­tan­do l’ingresso di malware nel flusso di dati.

Con­si­de­ran­do l’offerta crescente di dati mul­ti­me­dia­li, come immagini, video e altri elementi dei social media, che ri­chie­do­no tra­smis­sio­ni più rapide, possiamo solo sperare che, nell’interesse degli utenti, venga ag­gior­na­ta la famiglia di pro­to­col­li e che i fornitori riescano a tenere il passo con le con­di­zio­ni sempre mutevoli del mondo del web.