Indice dei contenuti dell'articolo:
Sono sicuro che, come me, avete accolto con favore la notizia che la terza versione principale dell’Hypertext Transfer Protocol, ovvero HTTP/3, è stata adottata il mese scorso come standard IETF (Internet Engineering Task Force). No, certo, non l’hai fatto: il web funziona e basta, quindi perché preoccuparsene? Ma se sei vagamente incuriosito dal motivo per cui sta avvenendo il cambiamento, ecco una breve analisi della storia dietro di esso. Quindi approfondiremo i motivi per cui dovresti adottarlo per la tua azienda.
HTTP/3 è la terza versione dell’Hypertext Transfer Protocol (HTTP) ed era precedentemente noto come HTTP-over-QUIC. QUIC è stato inizialmente sviluppato da Google ed è il successore di HTTP/2. Aziende come Google e Facebook utilizzano già QUIC per velocizzare il web.
Una storia molto breve di HTTP
In passato, c’erano due protocolli Internet con cui potevi scegliere di lavorare. Anche prima del Web, dovevamo ancora spruzzare pacchetti di informazioni (o datagrammi) da una macchina all’altra su Internet. Per uno sviluppatore di giochi, il protocollo importante era UDP (User Datagram Protocol). Questo era lo standard rapido, spara e dimentica: hai lanciato un pacchetto attraverso la rete ed è stato catturato, o talvolta non lo era. Era perfetto per rappresentare (ad esempio) il proiettile di un giocatore mentre proveniva dalla tua pistola, attraverso la rete, per essere visualizzato sulla macchina del tuo bersaglio. Anche se un proiettile si perdesse lungo la strada, almeno la sessione di gioco nel suo insieme andrebbe comunque bene.
Ma per sistemi più stabili come il web, il protocollo sottostante corretto da utilizzare era il TCP (Transmission Control Protocol). Si trattava di un sistema più formale, che garantiva la consegna e il corretto ordine dei pacchi. Così ha creato connessioni affidabili e in seguito flussi di informazioni affidabili.
Alla fine, il World Wide Web e HTTP, sono scritti sopra TCP/IP, hanno preso il sopravvento come l’uso principale di Internet. L’altro acronimo mancante è TLS (Transport Layer Security), che ha fornito l’elemento di crittografia ed è diventato lo standard di sicurezza de facto quando HTTP/2 era pronto.
A quei tempi la connessione tra i PC era solitamente cablata e l’eventuale perdita era dovuta al rumore sulle vecchie linee di rame. Il protocollo TCP era buono per il raggruppamento di pacchetti errati occasionali. Con l’affermarsi del web, le ragioni per l’utilizzo di UDP sono diminuite.
Entra in scena QUIC
Internet oggi è un posto molto diverso. Sì, ho una buona connessione in fibra e buone linee al mio PC a casa, ma la maggior parte degli utenti utilizza Internet tramite telefoni o laptop. Quando ci si sposta da un albero all’altro, da dietro i muri che bloccano o rimbalzano i segnali, le connessioni vengono comunemente interrotte e riavviate. Questo non è ciò che piace a TCP: non vuole davvero comunicare senza presentazioni formali e una buona stretta di mano. In effetti, si scopre che la rigorosa contabilità di TCP e l’attesa dell’ultimo pacchetto vagante significa solo che gli utenti devono attendere il caricamento delle pagine Web e il download di nuove app o il ripristino di un timeout di connessione.
Quindi, per sfruttare l’informalità dell’UDP e per consentire alla rete di utilizzare al volo alcune cose intelligenti, il nuovo formato QUIC (Quick UDP Internet Connections) ha ricevuto maggiore attenzione.
Anche se non vogliamo vedere troppa intelligenza all’interno della rete stessa, oggigiorno siamo molto più a nostro agio con il processo decisionale automatico. QUIC comprende che un sito è composto da più file e non danneggerà l’intera connessione solo perché un file non ha terminato il caricamento.
L’altra tendenza seguita da QUIC è la sicurezza integrata. Mentre la crittografia era facoltativa prima (ad esempio HTTP o HTTPS), QUIC è sempre crittografata. Al giorno d’oggi è un dato di fatto che ogni sito dovrebbe essere crittografato, nonostante il sovraccarico. Questo non è solo per garantire che un uomo nel mezzo non possa vedere che tipo di succo d’arancia stai ordinando; conferma che stai effettivamente parlando con il tuo vero fornitore di succo d’arancia.
I formati migliorano quasi sempre, ma quello che fanno davvero è affrontare diverse preoccupazioni nel tempo.
Uso attivo
Allora come sta andando l’implementazione? Ci sono tre lati da considerare qui. Il browser, l’infrastruttura cloud e il codice utente.
Innanzitutto, il browser. Questa è una tabella dal sito Web “Can I Use”
Chiaramente, Google è entusiasta: le versioni di Chrome dalla v87 (fine 2020) in poi sono state in grado di utilizzare il protocollo HTTP/3. Non sorprende che, data la recente storia di Apple nello sviluppo dei browser, Safari sia in ritardo.
Puoi utilizzare uno di questi siti in questo momento per verificare se il tuo browser è compatibile con HTTP/3 (potrebbe essere necessario ricaricare):
Ma per quanto riguarda i siti Web esistenti? Il tuo sito lo sta attualmente utilizzando? Quindi, per testare un sito esistente, prova https://geekflare.com/tools/http3-test . E prima che tu lo chieda, no thenewstack.io attualmente lo supporta!
Chi sta promuovendo HTTP/3?
Ora, chi sta spingendo HTTP/3? Bene, lo sai già; è Google. Ma anche le CDN, ad esempio Cloudflare e Fastly. Il loro pane quotidiano è la velocità di risposta del web. Di conseguenza, il modo più semplice per implementare HTTP/3 è tramite una CDN. È anche un cambiamento che avvantaggia un po’ di più gli utenti mobili.
Esistono server creati con QUIC (ad esempio Litespeed) ma l’adozione non è stata uniforme. Molti server dipendono da librerie di terze parti, quindi il modello di riutilizzo delle interruzioni di lavoro esistenti e verificate in questo caso si interrompe. I server esistenti, come Node.js, NGINX e Apache, perdono i vantaggi dell’esperienza utente quando iniziano a implementare nuovi interni. E al contrario, le nuove librerie sono relativamente non provate. Il punto di utilizzare un server web è che è affidabile, ben testato e mantenuto.
Attualmente in Managed Server, la nostra azienda, dopo circa 6 mesi di testing e monitoraggio abbiamo rilasciato in produzione il supporto per il protocollo QUIC per i webserver NGINX che sono alla base del nostro stack software web orientato alle performance.
Possiamo affermare di essere un Hosting che fornisce HTTP3 e QUIC sui piani di fascia alta.
A differenza, dunque, di molti altri fornitori di Hosting che utilizzano QUIC esclusivamente con webserver che supportano di default QUIC come LiteSpeed, siamo stati in grado di integrare questa importante miglioria in un webserver di eccellenza come NGINX.
Adozione di HTTP/3
In circostanze normali, mi immergerei in un po’ di codice, ma ritengo che sarebbe un po’ prematuro in questa fase. Ci sono una miriade di progetti che probabilmente cambiano tutti regolarmente, quindi approfondisci.
Osservando alcuni dei semplici esempi di funzionamento minimo (ad esempio un semplice server e un semplice client), possiamo riconoscere diversi livelli di lavoro.
Innanzitutto, la connessione. Questo canale di livello superiore è stabilito inizialmente tra due endpoint. Viene stabilito un identificatore di connessione. Una volta stabilito, se cambiano i protocolli sottostanti (un telefono che cambia wi-fi, ad esempio), la connessione rimane per evitare di dover ricominciare da capo la trattativa.
Le connessioni aprono quindi flussi che trasportano il proprio tipo di dati e non interferiscono tra loro.
Al di sotto ci sono ancora i pacchetti. Ogni pacchetto, come una lettera ben indirizzata, ha la sua connessione e le sue informazioni crittografiche. E all’interno della busta ci sono delle cornici. Questi rappresentano i dati effettivi trasmessi.
Come ho detto prima, il progresso in realtà riflette solo il cambiamento dei modelli di utilizzo. Oggi apprezziamo la sicurezza e la velocità perché non trattiamo più il Web come una magia inaffidabile e quindi lo usiamo per gestire i nostri affari personali. HTTP/3 aiuterà ad allinearsi con queste preoccupazioni. Gli elefanti nella stanza potrebbero essere Web3 e i ricchi mondi emergenti del metaverso. Forse nuove idee da queste aree contribuiranno ad un eventuale, possibile e probabile HTTP/4 in futuro.
