14 min. leggere

HTTP/2: La guida completa alle prestazioni del web moderno

Il protocollo di trasferimento degli ipertesti si è evoluto notevolmente dalla sua nascita e HTTP/2 rappresenta uno dei più significativi passi avanti nel modo in cui trasferiamo i dati sul web. Se negli ultimi anni hai notato che le pagine web si caricano più velocemente, è molto probabile che HTTP/2 stia lavorando dietro le quinte.

Questa guida ti spiega tutto ciò che devi sapere su HTTP/2: dai meccanismi di base ai vantaggi in termini di prestazioni, fino ai passi pratici per l’implementazione. Se sei uno sviluppatore che sta cercando di ottimizzare il proprio server web o semplicemente sei curioso di sapere cosa fa funzionare i siti web moderni, qui troverai spunti pratici.

Risposta rapida: Cos’è HTTP/2 e perché è importante

HTTP/2 è un’importante revisione del protocollo di trasferimento di ipertesti versione 1.1, standardizzato dalla Internet Engineering Task Force nella RFC 7540 (maggio 2015). Si concentra sulla riduzione della latenza, sul miglioramento dell’utilizzo delle risorse di rete e sul caricamento delle pagine web in modo significativamente più veloce, il tuttomantenendo la piena retrocompatibilità con la semantica HTTP esistente.

Nel 2026, l’adozione di HTTP/2 è quasi onnipresente. Secondo i dati di W3Techs, oltre 1/3 dei siti web più importanti utilizza attivamente HTTP/2 e la maggior parte dei principali CDN (Cloudflare, AWS CloudFront, Fastly) lo abilita di default per il traffico HTTPS. Se il tuo sito funziona su HTTPS con un server web moderno, è probabile che tu stia già beneficiando di HTTP/2 senza alcuna configurazione aggiuntiva.

Il protocollo introduce diverse caratteristiche principali che risolvono i colli di bottiglia delle prestazioni di HTTP 1.1:

Multiplexing: Più flussi di dati viaggiano contemporaneamente su una singola connessione TCP.
Compressione delle intestazioni (HPACK): Introduzione della compressione dei campi delle intestazioni che riduce drasticamente i metadati ridondanti delle intestazioni HTTP.
Livello di inquadramento binario: Un livello di frame completamente generico che sostituisce i comandi basati sul testo con un efficiente framing di messaggi binari.
Server push: Consegna proattiva delle risorse prima che il browser le richieda esplicitamente
Priorità dei flussi: Suggerimenti del client che indicano ai server quali risorse sono più importanti

Ecco cosa significa in pratica:

Caricamenti di pagina più rapidi, soprattutto su siti che richiedono molte risorse
Meno connessioni TCP necessarie per ogni origine
Migliori prestazioni sulle reti mobili con latenza elevata
Miglioramento dell’utilizzo della rete su tutta la linea

Da HTTP/0.9 a HTTP/2: una breve storia

Il protocollo HTTP ha fatto molta strada da quando Tim Berners-Lee introdusse HTTP/0.9 nel 1991 come semplice meccanismo per il recupero di documenti HTML. Nel 1996 seguì HTTP/1.0, con l’aggiunta di intestazioni e codici di stato, mentre HTTP/1.1 fu standardizzato nella RFC 2068 (1997) e successivamente perfezionato nella RFC 2616 (1999). Per quasi due decenni, HTTP/1.1 ha rappresentato la spina dorsale della comunicazione client-server sul web.

Ma il web è cambiato radicalmente. Le moderne pagine web sono passate da semplici documenti a complesse applicazioni che caricano decine di pacchetti JavaScript, file CSS, immagini e chiamate API. Anche con connessioni a banda larga e hardware potente, l ‘architettura di HTTP/1.1 creava dei colli di bottiglia:

Blocco della linea: Ogni connessione TCP poteva gestire solo una richiesta alla volta, causando un inutile traffico di rete in quanto le risorse si accodavano.
Overhead di connessione: I browser web desktop e i browser web mobile aprono in genere 6-8 connessioni TCP parallele per origine per ovviare a questa limitazione.
Intestazioni ridondanti: Ogni richiesta HTTP inviava ripetutamente le stesse intestazioni verbose (cookie, user-agent, intestazioni di accettazione).

Google ha riconosciuto questi problemi e ha lanciato il progetto SPDY nel 2009. Implementato per la prima volta in Chrome intorno al 2010, SPDY ha introdotto diverse innovazioni:

Inquadratura binaria invece di protocolli basati sul testo
Multiplexing di più richieste su una singola connessione
Compressione dell’intestazione per ridurre l’overhead
Definizione delle priorità del flusso per le risorse critiche

Il gruppo di lavoro HTTP dell’IETF ha visto il potenziale di SPDY e lo ha adottato come punto di partenza per HTTP/2 nel 2012. Dopo un lungo lavoro da parte del gruppo di lavoro ietf http, nel maggio 2015 sono state pubblicate le RFC 7540 (HTTP/2) e RFC 7541 (HPACK).

L’adozione dei browser è stata rapida:

Chrome ha deprecato SPDY in favore di HTTP/2 a partire da Chrome 51 (maggio 2016).
Firefox ha aggiunto il supporto HTTP/2 nella versione 36 (febbraio 2015)
Safari ha seguito la versione 9 (settembre 2015)
Microsoft Edge è stato fornito con il supporto HTTP/2 fin dal suo rilascio iniziale
Anche Internet Explorer 11 ha ottenuto il supporto HTTP/2 su Windows 8.1 e successivi.

Obiettivi di progettazione e differenze chiave rispetto a HTTP/1.1

HTTP/2 mantiene la piena compatibilità con la semantica HTTP/1.1. Metodi come GET e POST funzionano in modo identico. I codici di stato rimangono invariati. Gli URI e i campi delle intestazioni HTTP seguono le stesse regole. Ciò che cambia è il modo in cui questi dati si muovono sul filo: le meccaniche del livello di trasporto che determinano la velocità effettiva del carico.

Gli obiettivi di progettazione del protocollo erano chiari:

Obiettivo	Come HTTP/2 ottiene questo risultato
Ridurre la latenza	Il multiplexing elimina il blocco della testa della linea a livello HTTP
Migliore utilizzo della connessione	Un’unica connessione TCP gestisce tutte le richieste verso un’origine
Tagliare la testata sopra la testa	La compressione HPACK riduce i valori delle intestazioni precedentemente trasferite
Migliorare le prestazioni dei dispositivi mobili	Un minor numero di connessioni e intestazioni più piccole favoriscono le reti ad alta latenza

Il bello di questo design è la retrocompatibilità a livello di applicazione. Il codice dell’applicazione web esistente – percorsi, gestori, logica di risposta – non deve essere modificato. Solo lo stack di client e server deve supportare HTTP/2 per trarne vantaggio.

Questo contrasta nettamente con le soluzioni di HTTP/1.1 che gli sviluppatori dovevano implementare manualmente:

Sharding del dominio: Distribuire le risorse su più domini per aprire più connessioni
Concatenazione degli asset: Accorpare i file CSS e JavaScript per ridurre le richieste
Sprite di immagini: Combinare più immagini in un unico file
Inlining: Incorporare CSS e JavaScript direttamente nell’HTML

La meccanica di base di HTTP/2 sostituisce questi hack:

Livello di framing binario: I messaggi suddivisi in frame trasportano i dati in modo efficiente come unità di protocollo binarie.
Flussi multipli: Più scambi simultanei avvengono sulla stessa connessione.
Compressione delle intestazioni HPACK: Le tabelle dinamiche tengono traccia delle intestazioni, eliminando la ridondanza
Server push: I server inviano in modo proattivo le risorse di cui il cliente avrà bisogno
Priorità dei flussi: I client segnalano quali risorse sono più importanti attraverso i pesi di dipendenza dei flussi

Framing binario, flussi, messaggi e multiplexing

Il cuore di HTTP/2 è il livello di framing binario, un’evoluzione fondamentale rispetto al formato testuale di HTTP/1.1. Ogni messaggio HTTP viene suddiviso in frame binari con un layout coerente: un’intestazione di 9 byte contenente lunghezza, tipo, flag e identificatori di flusso, seguita dai dati opzionali del payload.

Per comprendere la gerarchia è necessario afferrare tre concetti:

I flussi sono canali indipendenti e bidirezionali all’interno di una singola connessione. Ogni flusso ha un identificatore unico di 31 bit. I client avviano gli stream con ID dispari (1, 3, 5…), mentre i server utilizzano ID pari (2, 4, 6…) per gli stream avviati dal server come il push. Un identificatore di flusso inaspettato provoca un errore. L’impostazione del numero massimo di flussi contemporanei controlla il numero di flussi attivi simultaneamente.

I messaggi rappresentano richieste o risposte HTTP complete. Un blocco di intestazione completo è composto da uno o più frame, mentre le risposte possono includere più frame di dati per il corpo. Quando un destinatario incontra dei frammenti di blocco di intestazione, li riassembla per ricostruire il messaggio completo.

I frame sono le unità più piccole sul filo. I tipi di frame e di errore più comuni sono:

Frame DATI: Trasportano il contenuto del corpo della richiesta/risposta
Riquadro HEADERS: Contiene i campi dell’intestazione HTTP, eventualmente suddivisi in più frame chiamati frammenti di blocco dell’intestazione.
IMPOSTAZIONI: Messaggi di controllo della connessione per la configurazione
WINDOW_UPDATE: Regolazioni della finestra di controllo del flusso
PUSH_PROMISE: Annuncia il push del server
RST_STREAM: Termina un flusso con un codice di errore
GOAWAY: Avvia la chiusura di grazia della connessione

La magia avviene grazie al multiplexing. Poiché i fotogrammi di più flussi aperti simultaneamente possono essere interlacciati su un’unica connessione TCP – con entrambi gli endpoint che interlacciano i fotogrammi secondo le necessità – non c’è attesa. Il ricevitore riassembla i frame in base all’identificativo del flusso.

Consideriamo il caricamento di una tipica pagina web che necessita di:

index.html (10 KB)
styles.css (25 KB)
app.js (100 KB)
logo.png (15 KB)
immagine-eroe.jpg (200 KB)

Con HTTP/1.1, il tuo browser apre più connessioni per recuperare queste risorse in parallelo, ma con limiti. Con HTTP/2, tutte e cinque le risorse vengono trasmesse contemporaneamente su un’unica connessione come flussi di dati multipli. I frame di dati provenienti da flussi diversi si intersecano e sia il client che il server gestiscono l’intera connessione in modo efficiente.

Questo elimina la necessità di più connessioni TCP, riducendo l’overhead della finestra di controllo del flusso di connessione e migliorando notevolmente le prestazioni del web.

Compressione delle intestazioni con HPACK

HPACK, definito nell’RFC 7541 (pubblicato insieme a HTTP/2 nel maggio 2015), fornisce una compressione delle intestazioni progettata specificamente per HTTP/2. Questo è importante perché le intestazioni HTTP/1.1 erano verbose e completamente non compresse, causando un inutile traffico di rete per ogni richiesta.

Considera le intestazioni di una tipica richiesta HTTP:

Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)...
Accept: text/html,application/xhtml+xml,application/xml;q=0.9...
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Cookie: session=abc123def456; tracking=xyz789...

Queste intestazioni spesso superano i 700-800 byte per richiesta. Con i cookie, possono arrivare a diversi kilobyte. Se si moltiplicano per decine di richieste per pagina, lo spreco di banda è notevole, soprattutto per le reti mobili.

HPACK comprime le intestazioni attraverso tre meccanismi:

Tabella statica: 61 coppie campo/valore di intestazione comuni predefinite (come :method: GET o :status: 200) che non devono mai essere trasmesse.
Tabella dinamica: Una tabella specifica per la connessione che il client e il server costruiscono insieme, memorizzando i valori dell’intestazione trasferiti in precedenza per riutilizzarli.
Codifica Huffman: I valori delle stringhe vengono codificati utilizzando una tabella Huffman predefinita, riducendo le rappresentazioni del testo.

Il risultato è drammatico. Dopo che la prima richiesta stabilisce intestazioni comuni nella tabella dinamica, le richieste successive potrebbero trasmettere solo riferimenti agli indici. Le intestazioni che all’inizio erano di kilobyte si riducono a decine di byte.

HPACK è stato progettato appositamente per evitare le vulnerabilità di sicurezza come CRIME e BREACH che affliggevano i precedenti schemi di compressione come DEFLATE di SPDY. Utilizzando codici Huffman statici e un’attenta gestione delle tabelle, HPACK impedisce agli aggressori di utilizzare l’analisi del rapporto di compressione per estrarre segreti dai dati misti dell’aggressore e della vittima.

Vale la pena notare che HPACK opera solo sulle intestazioni HTTP. I corpi delle risposte utilizzano ancora meccanismi standard di codifica del contenuto come gzip o Brotli a livello HTTP, completamente separati dalla compressione delle intestazioni.

Server Push e priorità dei flussi

HTTP/2 introduce due funzioni di ottimizzazione progettate per sostituire i workaround di HTTP/1.1: il server push per la consegna proattiva delle risorse e la prioritizzazione dei flussi per un ordine intelligente delle risorse.

Server Push

Il push del server consente a un server web di inviare risorse al client prima che queste vengano esplicitamente richieste. Il meccanismo funziona attraverso i frame PUSH_PROMISE:

Il cliente richiede /index.html
Il server risponde con l’HTML ma invia anche i frame PUSH_PROMISE annunciando che spingerà /styles.css e /app.js
Il server invia queste risorse su nuovi flussi avviati dal server (con identificatori di flusso che utilizzano numeri pari, secondo le regole di assegnazione degli identificatori di flusso a valore inferiore)
Il browser riceve le risorse prima di analizzare l’HTML e scopre di averne bisogno.

In questo modo si eliminano i viaggi di andata e ritorno. Invece di:

Richiedi HTML → Ricevi HTML
Analizza l’HTML, scopri il CSS necessario → Richiedi il CSS
Analizzare i CSS, scoprire i font necessari → Richiedere i font

La spinta del server fa collassare i passaggi 2-3 nel passaggio 1.

Tuttavia, il server push si è rivelato problematico nella pratica:

I browser potrebbero avere già delle risorse nella cache, rendendo le spinte inutili.
I server mal configurati spingono in modo troppo aggressivo, sprecando larghezza di banda
I meccanismi di digest della cache non hanno mai raggiunto un’adozione diffusa
Molti CDN e browser ora limitano o disabilitano il push per impostazione predefinita

I client possono disabilitare completamente il push impostando SETTINGS_ENABLE_PUSH = 0 nella loro prefazione di connessione. Quando la prefazione di connessione di un client disabilita immediatamente il push, la prefazione di connessione del server consiste in un riconoscimento e in una conformità.

Priorità ai flussi

La prioritizzazione dei flussi consente ai client di segnalare l’importanza delle risorse, aiutando i server ad allocare la larghezza di banda in modo efficace. Il meccanismo utilizza:

Pesi: Valori da 1-256 che indicano l’importanza relativa
Dipendenze: I flussi possono dipendere da altri flussi, formando un albero di dipendenza attraverso le dichiarazioni di dipendenza dei flussi.

Esempio pratico:

Flusso HTML (peso 256, nessuna dipendenza) – massima priorità
Flusso CSS (peso 200, dipende dall’HTML) – priorità alta
Immagini in alto (peso 100, dipende dal CSS)
Analytics JavaScript (peso 16, dipende dall’HTML) – priorità bassa

Questo garantisce che le risorse critiche del percorso di rendering arrivino per prime, migliorando la velocità di caricamento percepita anche se il tempo di trasferimento totale rimane simile.

Avvertenze importanti:

La definizione delle priorità è consultiva, non obbligatoria
Le implementazioni dei server variano molto nel modo in cui onorano le priorità
Gli intermediari (proxy, CDN) possono riordinare i frame
La messa a punto richiede test con traffico reale, non ipotesi

Il limite di flussi contemporanei pubblicizzato influisce sul numero di flussi che possono avere priorità attive contemporaneamente.

Controllo del flusso, gestione degli errori e considerazioni sulla sicurezza

HTTP/2 implementa il proprio controllo di flusso e la gestione degli errori al di sopra del TCP, affrontando gli scenari in cui l’intelligenza del livello applicativo supera i valori predefiniti del livello di trasporto.

Controllo del flusso

Il controllo del flusso impedisce ai mittenti veloci di sopraffare i ricevitori lenti. HTTP/2 utilizza un sistema basato sui crediti con i frame WINDOW_UPDATE:

Ogni flusso ha la sua finestra di controllo del flusso del ricevitore
La connessione ha anche una finestra di controllo del flusso di connessione
Dimensione predefinita della finestra: 65.535 byte (64 KB)
I mittenti non possono trasmettere fotogrammi DATI che superano la finestra disponibile del ricevitore.
I ricevitori inviano frame WINDOW_UPDATE per concedere un credito maggiore

Caratteristiche principali:

Il controllo di flusso è hop-by-hop (si applica tra ogni coppia mittente/ricevitore)
Non può essere disattivato
Solo i fotogrammi DATA contano per la finestra; gli altri dati obbligatori dei fotogrammi non contano.
Il controllo del flusso di corrente e il controllo del flusso di connessione funzionano in modo indipendente.

In questo modo si evita che un singolo flusso veloce monopolizzi le risorse della connessione, cosa particolarmente importante quando i proxy o i CDN si frappongono tra i clienti e le origini.

Gestione degli errori

HTTP/2 fornisce una segnalazione granulare degli errori:

Errori a livello di flusso: RST_STREAM termina immediatamente un flusso senza influenzare gli altri, con codici di errore come PROTOCOL_ERROR o FLOW_CONTROL_ERROR.
Errori a livello di connessione: GOAWAY chiude con grazia la connessione, consentendo di completare le richieste in corso e impedendone di nuove.

Il protocollo definisce un registro dei codici di errore che comprende:

PROTOCOL_ERROR (0x1): Violazione del protocollo generale
FLOW_CONTROL_ERROR (0x3): Regole di controllo del flusso violate
FRAME_SIZE_ERROR (0x6): Il fotogramma è stato superato SETTINGS_MAX_FRAME_SIZE
INADEQUATE_SECURITY (0xc): Configurazione della sicurezza del livello di trasporto insufficiente

Considerazioni sulla sicurezza

Sebbene la RFC 7540 non richieda tecnicamente la crittografia, tutti i principali browser web richiedono HTTP/2 su Transport Layer Security (TLS). Questo rende TLS 1.2+ la linea di base de facto:

La connessione inizia con l’handshake TLS che include l’ALPN (Application-Layer Protocol Negotiation).
L’estensione ALPN negozia l’identificatore “h2” per HTTP/2
I server devono evitare le suite di cifratura deboli inserite nella lista nera delle specifiche.
Le suite di cifratura che utilizzano l’RC4 o altri algoritmi deprecati generano l’errore INADEQUATE_SECURITY.

Le considerazioni sulla privacy includono:

Le IMPOSTAZIONI e i modelli di priorità possono rilevare le impronte digitali dei client
Una singola connessione per origine correla tutta l’attività dell’utente a quell’origine
Il protocollo binario oscura il traffico ma non lo nasconde agli osservatori della rete

Blocco TCP Head-of-Line

HTTP/2 risolve il blocco di testa della linea a livello HTTP grazie al multiplexing, ma il blocco a livello TCP rimane. Quando un pacchetto TCP viene perso, tutti i flussi su quella connessione si bloccano fino al completamento della ritrasmissione, anche quelli i cui dati sono arrivati correttamente.

Questa limitazione ha motivato HTTP/3, che gira su QUIC (basato su UDP) per fornire una vera indipendenza dai flussi. La perdita di pacchetti che colpisce un flusso non blocca gli altri.

Distribuzione e utilizzo pratico di HTTP/2

Nel 2026, abilitare HTTP/2 è semplice. La maggior parte dei server web e dei CDN moderni lo supportano immediatamente, principalmente su HTTPS. Il meccanismo di aggiornamento HTTP gestisce la negoziazione in modo trasparente.

Requisiti lato client

Gli utenti non devono fare nulla di particolare:

Tutti i moderni browser web per desktop (Chrome, Firefox, Safari, Edge) supportano HTTP/2 per impostazione predefinita.
I browser web per dispositivi mobili (Chrome per Android, Safari su iOS) includono il supporto completo
La compatibilità con le versioni più recenti del browser è assicurata
HTTP/2 si negozia automaticamente quando è disponibile

Configurazione lato server

Server HTTP Apache (2.4.17+):

Abilita il modulo mod_http2 (non il vecchio mod_spdy)
Aggiungi i protocolli h2 http/1.1 agli host virtuali TLS
Assicurati che la versione di OpenSSL supporti ALPN

Nginx (1.9.5+):

server {
    listen 443 ssl http2;
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
    # ... rest of configuration
}

IIS (Windows Server 2016+):

HTTP/2 è abilitato per impostazione predefinita per HTTPS con TLS 1.2+.
Non è richiesta alcuna configurazione aggiuntiva

Fornitori di CDN:

Cloudflare: HTTP/2 abilitato di default su tutti i piani
AWS CloudFront: Abilitato per impostazione predefinita per le distribuzioni HTTPS
Fastly: supportato e abilitato per impostazione predefinita

Verifica e risoluzione dei problemi

Conferma che HTTP/2 funziona con questa lista di controllo:

Browser DevTools: Apri la scheda Rete, attiva la colonna Protocollo, cerca “h2”.
Riga di comando: curl –http2 -I https://example.com mostra HTTP/2 nella risposta
Strumenti online: I servizi di test HTTP/2 verificano la configurazione
Controlla gli intermediari: Il CDN o il reverse proxy devono supportare HTTP/2, non solo il server di origine.

Problemi comuni che impediscono l’HTTP/2:

La versione di OpenSSL è troppo vecchia per il supporto ALPN
Configurazione solo TLS 1.0/1.1
Suite di cifratura deboli che attivano il fallback
Un proxy mal configurato elimina il supporto HTTP/2

HTTP/2 e oltre

HTTP/2 rimane il protocollo dominante per la comunicazione web moderna, anche se HTTP/3 (RFC 9114, pubblicato nel 2022) sta iniziando a diffondersi. HTTP/3 risolve il problema del blocco dell’head-of-line TCP grazie all’esecuzione su QUIC, ma il modello di connessione TCP singola di HTTP/2 continua a servire efficacemente la maggior parte del traffico web.

Per la maggior parte dei siti, HTTP/2 offre miglioramenti sostanziali delle prestazioni web con un minimo sforzo di configurazione. Inizia a scambiare frame su HTTP/2 oggi stesso e i tuoi utenti, sia su desktop che su mobile, sperimenteranno un caricamento delle pagine più veloce ed efficiente.

Punti di forza

HTTP/2 rivoluziona le prestazioni del web grazie al multiplexing, che consente più scambi simultanei su una singola connessione.
La compressione dell’intestazione HPACK elimina la trasmissione di intestazioni ridondanti, a vantaggio soprattutto degli utenti mobili.
Il server push e la prioritizzazione dei flussi ottimizzano la distribuzione delle risorse, anche se l’implementazione varia.
Il controllo del flusso impedisce di affamare le risorse su più flussi.
L’implementazione è semplice sui server moderni e richiede principalmente una configurazione HTTPS.
Tutti i principali browser supportano HTTP/2, rendendo l’adozione senza problemi per gli utenti finali.

I prossimi passi

Se non hai ancora verificato HTTP/2 sul tuo server web, questo è il momento giusto. Apri gli strumenti per sviluppatori del tuo browser, carica il tuo sito e controlla la colonna Protocollo. Se vedi “http/1.1” invece di “h2”, rivedi la configurazione del tuo server: stai lasciando sul tavolo un significativo aumento delle prestazioni.

Per coloro che già utilizzano HTTP/2, considera il monitoraggio delle metriche di connessione HTTP/2 del tuo server. Capire come si comportano più flussi simultanei in presenza di traffico reale aiuta a identificare le opportunità di ottimizzazione prima che i tuoi utenti notino dei problemi.