HTTP/3 e QUIC su Cloudflare: come abilitare il protocollo del futuro
HTTP/3 è la terza versione major del protocollo HTTP, basata su QUIC (Quick UDP Internet Connections) anziché su TCP. Riduce la latenza di handshake, elimina il problema dell'head-of-line blocking e migliora la connessione su reti mobili instabili. Cloudflare è stata pioniera nell'adozione e oggi supporta HTTP/3 in modo nativo su tutti i piani, anche quello gratuito.
Differenze tra HTTP/2 e HTTP/3
HTTP/2 ha introdotto multiplexing su una sola connessione TCP, ma soffre del head-of-line blocking: se un pacchetto si perde, tutti gli stream si bloccano. HTTP/3 lavora su QUIC, un protocollo UDP che gestisce gli stream in modo realmente indipendente. Inoltre QUIC integra TLS 1.3 nel handshake riducendo i round-trip da 2-3 a 1, con vantaggi enormi su reti ad alta latenza come 4G/5G mobile.
Procedura passo-passo
- Apri il dashboard Cloudflare e seleziona il dominio.
- Vai su Network nel menu laterale.
- Trova la voce HTTP/3 (with QUIC) e attiva il toggle.
- Attiva anche 0-RTT Connection Resumption per latency ulteriormente ridotta.
- Verifica che il firewall di origine non blocchi UDP 443 in uscita (per Argo).
- Apri il sito su Chrome aggiornato e ispeziona Network tab, colonna Protocol.
- Cerca il valore h3 tra i protocolli usati.
- Esegui un test su http3check.net.
- Monitora la quota di traffico HTTP/3 in Analytics → Network.
- Considera di abilitare anche gRPC se l'origine espone servizi gRPC.
0-RTT e implicazioni di sicurezza
0-RTT (Zero Round-Trip Time) permette al client di inviare dati nella prima richiesta dopo una connessione precedente, senza attendere il completamento del handshake. È velocissimo ma introduce un rischio di replay attack: un'attaccante potrebbe rispedire una richiesta intercettata. Cloudflare mitiga questo limitando 0-RTT solo a metodi idempotenti (GET) e con anti-replay window. Per la maggior parte dei siti il vantaggio supera il rischio.
Errori comuni e come risolverli
- HTTP/3 non si attiva: il browser è obsoleto. Aggiorna a Chrome 88+, Firefox 88+, Safari 14+.
- Connessione fallisce su rete corporate: alcuni firewall bloccano UDP. HTTP/3 ricade automaticamente su HTTP/2.
- Protocol Alt-Svc non visibile: la cache del browser ha vecchi valori. Forza il riavvio e svuota la cache.
- Performance peggiorate dopo attivazione: improbabile, ma verifica MTU adeguato sulla rete server origine.
- Test online dice HTTP/3 non disponibile: aspetta qualche minuto per la propagazione delle modifiche.
Compatibilità lato client
I browser moderni supportano HTTP/3 da metà 2020: Chrome (88+), Firefox (88+), Edge, Safari (14+ su iOS e macOS), Opera. Sul mobile la copertura è praticamente totale tra Android e iOS recenti. I client più datati semplicemente continuano a usare HTTP/2 o HTTP/1.1: HTTP/3 è completamente backward compatible. Anche curl supporta HTTP/3 dalle versioni recenti compilate con --with-nghttp3.
Performance reali
I benchmark Cloudflare mostrano miglioramenti del 10-20% sul Time To First Byte su reti mobili. Su connessioni desktop stabili la differenza è minore (2-5%). Il guadagno maggiore si ha su connessioni con perdita pacchetti elevata: HTTP/3 è significativamente più resiliente di TCP. Per siti con traffico mobile dominante l'attivazione è praticamente obbligatoria.
Domande frequenti
D: HTTP/3 richiede TLS 1.3 obbligatoriamente?
R: Sì, QUIC integra TLS 1.3 by design. Non esiste QUIC con TLS 1.2.
D: Devo configurare anche il server di origine?
R: No. Cloudflare termina HTTP/3 sull'edge e parla HTTP/1.1 o HTTP/2 con l'origine.
D: HTTP/3 ha impatto sui costi?
R: No, è incluso gratuitamente in tutti i piani Cloudflare.
D: Posso disattivarlo se ho problemi?
R: Sì, è un semplice toggle reversibile in qualsiasi momento.
Considerazioni operative finali
Quando applichi una configurazione di questo tipo in produzione è sempre buona norma seguire un'approccio incrementale: parti con un test su staging, monitora gli effetti per qualche giorno, poi estendi gradualmente al traffico live. La rete Cloudflare elabora ogni cambiamento in pochi secondi a livello globale, quindi le modifiche sono effettive quasi immediatamente, ma gli effetti collaterali su utenti reali possono richiedere ore o giorni per emergere. Annota nel runbook interno data, motivo e parametri di ogni modifica significativa. Una documentazione precisa accelera enormemente il troubleshooting futuro e facilita il passaggio di consegne tra membri del team.
Vale anche la pena ricordare che Cloudflare aggiorna frequentemente l'interfaccia del dashboard e le posizioni delle voci di menu. La logica e le funzionalità descritte in questa guida restano valide, ma il percorso esatto per raggiungere ogni opzione può variare leggermente nel tempo. In caso di difficoltà a trovare una specifica voce, utilizza la barra di ricerca interna del dashboard oppure consulta la documentazione ufficiale aggiornata. La community Cloudflare sul forum ufficiale e su Stack Overflow è inoltre molto attiva e offre spesso risposte rapide a problemi specifici di configurazione.
Per progetti complessi che coinvolgono più servizi Cloudflare contemporaneamente (CDN, Workers, WAF, Access, R2) conviene strutturare la configurazione come codice tramite Terraform o Pulumi. Questo permette versioning, code review, rollback atomici e deploy ripetibili tra environment. Per team con esigenze più semplici la gestione manuale via dashboard resta perfettamente valida, soprattutto se accompagnata da una checklist scritta delle impostazioni applicate. La scelta dell'approccio dipende dalle dimensioni del progetto e dal grado di automazione desiderato. L'importante è essere consistenti e mantenere tracciabilità delle modifiche effettuate.
Hai bisogno di aiuto?
Se vuoi configurare Cloudflare per il tuo sito con il team di G Tech Group, scrivici tramite il modulo di contatto.