Protocolli HTTP/1.1, HTTP/2 e HTTP/3 (QUIC): differenze, confronto e configurazione

Che cos’è il protocollo HTTP

HTTP (HyperText Transfer Protocol) è il protocollo di livello applicativo che regola lo scambio di dati tra client e server nel World Wide Web. Definito originariamente da Tim Berners-Lee al CERN nel 1989, HTTP opera secondo un modello request-response: il client (browser, crawler, app) invia una richiesta e il server restituisce una risposta contenente status code, header e body.

Ogni versione del protocollo ha introdotto miglioramenti su tre fronti: prestazioni, sicurezza e gestione della congestione di rete. La scelta del protocollo HTTP influisce direttamente sul Time To First Byte (TTFB), sul Time To Last Byte (TTLB) e, di conseguenza, sull’esperienza utente e sulle performance SEO.

Evoluzione del protocollo HTTP

Versione	Anno	Specifica	Novità principali
HTTP/0.9	1991	Nessuna RFC formale	Solo GET, nessun header, solo HTML
HTTP/1.0	1996	RFC 1945	Header, status code, Content-Type
HTTP/1.1	1997	RFC 2068 → RFC 9112 (2022)	Keep-alive, chunked transfer, Host header
HTTP/2	2015	RFC 7540 → RFC 9113 (2022)	Multiplexing binario, HPACK, server push
HTTP/3	2022	RFC 9114	QUIC su UDP, 0-RTT, TLS 1.3 integrato

A marzo 2026, secondo i dati W3Techs, HTTP/3 è usato dal 38,2% dei siti web e HTTP/2 dal 34,4%. I principali provider cloud (Google, Cloudflare, AWS CloudFront, Fastly) servono HTTP/3 di default. La quota residua di HTTP/1.1 si concentra su siti con web server non aggiornati o hosting condiviso senza supporto QUIC.

HTTP/1.1

HTTP/1.1 è una mappatura testuale su TCP. Ogni messaggio (richiesta o risposta) è composto da campi di testo delimitati da spazi bianchi e trasmessi su una connessione TCP. Poiché ogni connessione TCP trasporta una sola richiesta alla volta, i browser aprono fino a 6 connessioni parallele per dominio (limite definito dalla specifica RFC 2616 e implementato dalla quasi totalità dei browser moderni).

Connessioni keep-alive e limiti

HTTP/1.1 ha introdotto le connessioni keep-alive (persistenti): il client riutilizza la stessa connessione TCP per più scambi richiesta-risposta senza ripetere il three-way handshake TCP per ogni risorsa. Tuttavia, le richieste sulla stessa connessione restano sequenziali: la seconda richiesta parte solo dopo aver ricevuto la risposta alla prima.

Questo meccanismo genera il problema noto come head-of-line blocking (HOL) a livello HTTP: se una risorsa è lenta, tutte le richieste successive sulla stessa connessione restano in coda. La soluzione adottata dai browser è aprire connessioni multiple, ma questo sovraccarica il controller di congestione TCP e il server DNS con lookup aggiuntivi quando si usa il domain sharding.

Il numero di connessioni simultanee per dominio nei browser moderni è standardizzato a 6 (Chrome, Firefox, Safari, Edge). I browser legacy come Internet Explorer supportavano da 2 a 13 connessioni, ma sono ormai irrilevanti nella quota di mercato attuale.

Limiti strutturali di HTTP/1.1

• Head-of-line blocking — una risorsa lenta blocca l’intera connessione
• Header ridondanti — ogni richiesta invia gli stessi header (cookie, user-agent, accept) senza compressione
• Nessun multiplexing — una sola richiesta alla volta per connessione
• Workaround costosi — domain sharding, concatenazione CSS/JS, sprite di immagini

Questi limiti hanno portato allo sviluppo di SPDY da parte di Google (2009), che ha poi costituito la base per HTTP/2.

HTTP/2

HTTP/2 (RFC 9113, aggiornamento della RFC 7540 del 2015) introduce un livello di framing binario tra il protocollo applicativo HTTP e il trasporto TCP, senza modificare la semantica HTTP. Metodi, status code, header e URI restano identici: cambia il modo in cui i dati vengono serializzati e trasportati.

Multiplexing binario

Il multiplexing è la novità architetturale fondamentale: una singola connessione TCP trasporta più stream paralleli. Ogni stream è una sequenza bidirezionale di frame che trasporta una coppia richiesta-risposta. I frame di stream diversi vengono intervallati (interleaved) sulla stessa connessione e ricomposti all’arrivo.

Il risultato pratico: non servono più 6 connessioni TCP per dominio. Una sola connessione gestisce centinaia di richieste concorrenti, eliminando l’overhead del domain sharding e riducendo la pressione sul controller di congestione TCP.

Compressione header con HPACK

HTTP/2 comprime gli header HTTP con l’algoritmo HPACK (RFC 7541). Ogni endpoint mantiene una tabella di header già trasmessi: nelle richieste successive, gli header identici vengono referenziati per indice anziché ritrasmessi. Su pagine con molte risorse dallo stesso dominio, questo riduce il traffico di header dell’85-95%.

Server push e alternative moderne

Il server push HTTP/2 consente al server di inviare risorse proattivamente senza che il client le richieda. Tuttavia, nella pratica si è rivelato problematico: le risorse pushate spesso finivano per sprecare banda perché già in cache del browser. Chrome ha rimosso il supporto al server push nel 2022.

L’alternativa moderna è 103 Early Hints: il server invia una risposta preliminare con header Link: rel=preload mentre prepara la risposta principale, permettendo al browser di iniziare a scaricare risorse critiche in anticipo senza i problemi del push.

Il problema residuo: HOL blocking a livello TCP

HTTP/2 risolve l’head-of-line blocking a livello HTTP grazie al multiplexing, ma ne introduce uno a livello TCP. Poiché tutti gli stream condividono la stessa connessione TCP, un singolo pacchetto TCP perso blocca la consegna di tutti gli stream, anche quelli non coinvolti dalla perdita. Su reti con packet loss elevato (mobile, Wi-Fi instabile), questo annulla parte dei vantaggi del multiplexing.

Questo problema è la motivazione fondamentale alla base dello sviluppo di HTTP/3 e del protocollo di trasporto QUIC.

HTTP/3 e QUIC

HTTP/3 (RFC 9114, standard IETF dal giugno 2022) sostituisce TCP con QUIC (RFC 9000) come protocollo di trasporto. QUIC è un protocollo connection-oriented costruito su UDP che integra nativamente TLS 1.3, multiplexing a livello di trasporto e controllo di congestione.

Architettura di QUIC

QUIC è stato progettato da Jim Roskind presso Google nel 2012 con l’obiettivo di ridurre la latenza di connessione e migliorare il controllo della congestione. Le caratteristiche architetturali chiave:

• Trasporto su UDP — QUIC usa UDP come meccanismo di trasporto a basso livello e implementa la propria logica di affidabilità, ritrasmissione e ordinamento sopra di esso
• TLS 1.3 integrato — la crittografia non è un livello aggiuntivo (come TCP + TLS) ma è parte strutturale del protocollo, eliminando un intero round-trip dalla fase di handshake
• Stream indipendenti — ogni stream QUIC è gestito in modo autonomo: un pacchetto perso blocca solo lo stream interessato, non l’intera connessione. Questo risolve definitivamente l’HOL blocking di TCP
• Connection migration — le connessioni QUIC sono identificate da un Connection ID, non dalla coppia IP:porta. Se il client cambia rete (es. da Wi-Fi a 4G), la connessione sopravvive senza dover ripetere l’handshake
• 0-RTT resumption — per connessioni già stabilite in precedenza, QUIC può inviare dati applicativi già nel primo pacchetto, azzerando la latenza di connessione

Dati sulle prestazioni

I risultati pubblicati da Google sull’implementazione iniziale di QUIC (gQUIC) indicano miglioramenti significativi:

• -8% di latenza sulle risposte di Google Search su desktop
• -18% sulle percentuali di rebuffering su YouTube
• Miglioramenti più marcati su reti con alto packet loss (mobile, regioni con infrastruttura meno affidabile)

Il protocollo ha raggiunto la standardizzazione IETF come iQUIC (IETF-QUIC), con crittografia basata su TLS 1.3 invece dell’approccio proprietario di gQUIC. Oggi Google, Meta, Cloudflare, Akamai e AWS CloudFront servono traffico HTTP/3 di default.

Compressione header con QPACK

HTTP/3 usa QPACK (RFC 9204) al posto di HPACK per la compressione degli header. QPACK è progettato per funzionare con il modello di stream indipendenti di QUIC: a differenza di HPACK, non richiede la consegna ordinata degli aggiornamenti alla tabella degli header, evitando così di reintrodurre HOL blocking a livello di compressione.

Confronto tra HTTP/1.1, HTTP/2 e HTTP/3

Caratteristica	HTTP/1.1	HTTP/2	HTTP/3
Protocollo di trasporto	TCP	TCP	QUIC (su UDP)
Formato messaggi	Testo	Binario	Binario
Multiplexing	No (1 richiesta per connessione)	Sì (stream su TCP)	Sì (stream nativi QUIC)
Compressione header	No	HPACK	QPACK
HOL blocking	HTTP + TCP	Risolto a livello HTTP, persiste a livello TCP	Risolto completamente
Handshake	TCP (1-RTT) + TLS (1-2 RTT)	TCP (1-RTT) + TLS (1-2 RTT)	QUIC + TLS 1.3 (1-RTT, oppure 0-RTT)
Crittografia	Opzionale (HTTPS)	Opzionale (ma i browser richiedono HTTPS)	Obbligatoria (TLS 1.3 integrato)
Negoziazione protocollo	—	ALPN nel TLS handshake	Header Alt-Svc nella risposta HTTP
Connection migration	No	No	Sì (Connection ID)
Server push	No	Sì (deprecato in Chrome)	Sì (poco usato)
Specifica attuale	RFC 9112	RFC 9113	RFC 9114

HTTP/1.1 vs HTTP/2

La differenza architetturale fondamentale è il livello di framing binario: HTTP/2 serializza i messaggi in frame binari anziché in testo, abilita il multiplexing su una singola connessione e comprime gli header con HPACK. Le applicazioni esistenti funzionano senza modifiche perché la semantica HTTP resta invariata — cambia solo la serializzazione.

Il miglioramento medio documentato è del 5-15% sui tempi di caricamento. Il guadagno effettivo dipende dal numero di risorse per pagina, dalla latenza di rete e dal packet loss. Su pagine con molte dipendenze (CSS, JS, immagini) il vantaggio del multiplexing è più evidente.

HTTP/2 vs HTTP/3

Dal punto di vista funzionale, HTTP/2 e HTTP/3 offrono ai client un set di funzionalità quasi identico: multiplexing, compressione header, server push. Le differenze sono nel protocollo di trasporto:

• Eliminazione HOL blocking TCP — in HTTP/3 ogni stream è indipendente a livello di trasporto, quindi un pacchetto perso non blocca gli altri stream
• Handshake più rapido — QUIC integra TLS 1.3 nel handshake di connessione (1-RTT) e supporta 0-RTT per le riconnessioni. Con TCP + TLS servono almeno 2-3 RTT
• HTTPS obbligatorio — HTTP/3 non esiste in versione non crittografata, a differenza di HTTP/2 che in teoria lo consente (anche se tutti i browser richiedono HTTPS)
• Connection migration — QUIC mantiene la connessione attiva quando il client cambia rete, impossibile con TCP
• Discovery via Alt-Svc — HTTP/2 viene negoziato nel TLS handshake tramite ALPN, mentre HTTP/3 richiede che il server annunci il supporto QUIC con l’header HTTP Alt-Svc

Come verificare il protocollo HTTP usato da un sito

In fase di audit SEO è fondamentale verificare quale protocollo HTTP serve il web server. HTTP/1.1 è obsoleto e introduce bottleneck su siti con molte dipendenze.

Verifica con Chrome DevTools

1. Apri i Chrome DevTools con F12
2. Seleziona la tab Network e ricarica la pagina con F5
3. Click destro sull’intestazione delle colonne → abilita Protocol e Domain
4. Filtra per il dominio del sito e verifica la colonna Protocol: h2 indica HTTP/2, h3 indica HTTP/3

Verifica da terminale con curl

Il comando curl permette di testare il protocollo direttamente da terminale, utile per verifiche automatizzate e script di monitoraggio:

# Verifica HTTP/2
curl -sI --http2 https://www.example.com | head -1
# Output atteso: HTTP/2 200

# Verifica HTTP/3 (richiede curl compilato con HTTP/3)
curl -sI --http3 https://www.example.com | head -1
# Output atteso: HTTP/3 200

# Visualizza header Alt-Svc per scoprire supporto HTTP/3
curl -sI https://www.example.com | grep -i alt-svc
# Output atteso: alt-svc: h3=":443"; ma=86400

L’header Alt-Svc (Alternative Services) è il meccanismo con cui il server comunica al client che HTTP/3 è disponibile. Il browser, dopo aver ricevuto questo header in una risposta HTTP/2, tenterà la connessione QUIC nelle richieste successive.

Come abilitare HTTP/2 e HTTP/3 sul web server

Nginx

Il supporto QUIC/HTTP/3 è disponibile nativamente in Nginx dalla versione 1.25.0. La configurazione richiede l’apertura della porta 443 sia su TCP (per HTTP/2) che su UDP (per QUIC) e l’invio dell’header Alt-Svc per annunciare la disponibilità di HTTP/3:

server {
    listen 443 ssl;
    listen 443 quic reuseport;
    http2 on;
    http3 on;

    ssl_certificate     /etc/ssl/certs/example.com.pem;
    ssl_certificate_key /etc/ssl/private/example.com.key;
    ssl_protocols       TLSv1.3;

    # Annuncia HTTP/3 ai client
    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    # Abilita 0-RTT (opzionale, attenzione al replay attack)
    ssl_early_data on;

    server_name example.com;
    root /var/www/example.com;
}

Nota: la direttiva reuseport è necessaria per il corretto funzionamento con worker multipli. Verifica che il firewall consenta traffico UDP sulla porta 443. Per una configurazione Nginx completa, incluse le ottimizzazioni di cache-control e compressione, consulta le guide dedicate.

Apache

Apache supporta HTTP/2 tramite il modulo mod_http2. Il supporto nativo per HTTP/3 non è ancora disponibile in Apache httpd — per servire HTTP/3 con Apache è necessario un reverse proxy con supporto QUIC (es. Nginx o Cloudflare) davanti ad Apache:

# Apache - abilitare HTTP/2
LoadModule http2_module modules/mod_http2.so

<VirtualHost *:443>
    Protocols h2 http/1.1
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/example.com.pem
    SSLCertificateKeyFile /etc/ssl/private/example.com.key
</VirtualHost>

Cloudflare e CDN

Se il sito è dietro una CDN come Cloudflare, HTTP/3 è spesso abilitato di default senza configurazione server-side. In Cloudflare: Speed → Optimization → Protocol Optimization → HTTP/3 (with QUIC). La CDN gestisce la connessione QUIC verso il client e mantiene HTTP/2 o HTTP/1.1 verso l’origin server.

Impatto sulle prestazioni e sulla SEO

Il protocollo HTTP influisce direttamente sulle metriche di velocità che Google utilizza come segnale di ranking. L’upgrade da HTTP/1.1 a HTTP/2 o HTTP/3 migliora in particolare:

• TTFB — il tempo al primo byte si riduce grazie a handshake più rapidi (1-RTT con HTTP/2+TLS 1.3, 0-RTT con QUIC per le riconnessioni)
• Tempo di caricamento complessivo — il multiplexing elimina i colli di bottiglia delle connessioni parallele, riducendo il TTLB su pagine con molte dipendenze
• Stabilità su mobile — la connection migration di QUIC evita riconnessioni quando l’utente passa da Wi-Fi a rete cellulare, riducendo interruzioni e migliorando i Core Web Vitals

Combinare l’upgrade del protocollo con tecniche di ottimizzazione complementari amplifica il guadagno: preconnect e dns-prefetch per ridurre la latenza DNS, preload degli asset critici, speculation rules per il prerender e una corretta configurazione degli HTTP security header.

Overhead CPU di QUIC

Lo svantaggio principale di HTTP/3 è il maggiore utilizzo CPU, sia lato client che lato server. QUIC opera in user space anziché nel kernel come TCP, e la crittografia di ogni pacchetto aggiunge overhead computazionale. I test mostrano un consumo CPU 2-3x superiore rispetto a TCP+TLS per lo stesso volume di traffico. Questo gap si sta riducendo con l’ottimizzazione delle implementazioni e il supporto hardware per la crittografia, ma resta un fattore da considerare per siti ad alto traffico. Uno stress test del web server aiuta a quantificare l’impatto reale.

Raccomandazioni operative

1. Verifica il protocollo attuale — usa DevTools o curl per determinare quale versione serve il tuo web server
2. Abilita HTTP/2 come minimo — se il server usa ancora HTTP/1.1, l’upgrade a HTTP/2 è il primo intervento con il miglior rapporto costo/beneficio
3. Valuta HTTP/3 — se usi Nginx 1.25+ o una CDN come Cloudflare, abilitare HTTP/3 è semplice e migliora l’esperienza su reti instabili
4. Monitora l’header Alt-Svc — verifica che il server invii correttamente l’header per consentire ai browser di scoprire il supporto HTTP/3
5. Testa l’impatto sulle metriche — misura TTFB e tempi di caricamento prima e dopo l’upgrade per quantificare il miglioramento reale

La migrazione da HTTP a HTTPS è un prerequisito per HTTP/2 e HTTP/3. Se il sito non è ancora su HTTPS, questo è il primo passo da completare. Per la configurazione del certificato SSL, consulta la guida all’installazione di Certbot su Nginx. Per approfondire l’ottimizzazione del TLS handshake, il TLS Session Resumption riduce ulteriormente la latenza sulle riconnessioni.