HTTP/2 e HTTP/3: differenze e verifica del sito

Questa guida approfondisce HTTP/2 e HTTP/3 differenze con controlli progressivi, modifiche reversibili e verifiche finali. Non inviare password, cookie, token, chiavi private o codici 2FA nei ticket.

Che cosa significa

HTTP/3 non sostituisce immediatamente HTTP/2. Browser e server negoziano il protocollo e mantengono un fallback, utile quando UDP è filtrato o il client non supporta QUIC.

L’attivazione del protocollo non corregge immagini pesanti, JavaScript eccessivo o un backend lento. È un livello della strategia prestazionale.

Come riconoscere il problema

• Il browser mostra h2 o h3.
• HTTP/3 funziona tramite CDN ma non direttamente sull’origine.
• Una rete aziendale usa sempre HTTP/2.
• Il primo accesso usa h2 e i successivi h3.
• UDP 443 è filtrato.

Cause più frequenti

1. Supporto client

Browser o libreria non implementano HTTP/3. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

2. UDP bloccato

Firewall o rete impediscono QUIC. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

3. CDN

Il protocollo edge può differire da quello verso l’origine. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

4. TLS e certificato

La negoziazione sicura è parte del collegamento. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

5. Alt-Svc e discovery

Il client deve conoscere la disponibilità di h3. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

6. Configurazione server

LiteSpeed o proxy devono avere HTTP/3 abilitato. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

Diagnosi passo per passo

1. Controlla DevTools. Osserva la colonna Protocol. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
2. Usa curl compatibile. Verifica `–http2` o `–http3` se la build li supporta. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
3. Confronta reti. Prova rete mobile e aziendale. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
4. Controlla UDP 443. Verifica firewall e NAT. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
5. Distingui edge e origine. Cloudflare può terminare h3 e usare altro protocollo a monte. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
6. Controlla TLS. Certificato e hostname devono essere validi. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
7. Misura prestazioni reali. Confronta TTFB, risorse e stabilità, non soltanto il protocollo. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.

Metodo sicuro di diagnosi

Prima di applicare modifiche, registra lo stato iniziale: URL o servizio coinvolto, messaggio completo, data e ora, rete o client, ultima operazione eseguita e risultato da un secondo strumento. Questo consente di distinguere una causa locale da una configurazione condivisa e rende possibile il rollback.

Cambia un solo elemento alla volta. Dopo ogni intervento ripeti esattamente lo stesso test, controlla i log dello stesso intervallo temporale e annota il risultato. Modificare contemporaneamente DNS, cache, PHP, plugin e firewall rende impossibile stabilire quale correzione abbia avuto effetto.

Controllo incrociato

Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin e WP-CLI; per DNS interroga nameserver autoritativo e resolver pubblico; per la posta confronta header, Webmail e Track Delivery. Cache e proxy possono mostrare stati differenti per alcuni minuti.

Quando il problema sembra risolto, ripeti il test con una seconda rete o un secondo account e verifica che le protezioni restino attive. Una soluzione che disabilita globalmente TLS, WAF, autenticazione o controlli di sicurezza non è considerata definitiva.

Procedura di risoluzione

1. Abilita HTTP/3 nel livello previsto. Server o CDN devono supportarlo. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
2. Consenti UDP 443 quando gestisci il firewall. Mantieni TCP 443 per fallback. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
3. Aggiorna browser e client. Versioni recenti migliorano QUIC. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
4. Mantieni HTTP/2 attivo. È il fallback essenziale. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
5. Ottimizza il sito. Riduci peso, richieste e lavoro backend. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
6. Verifica dopo cambi CDN. Controlla edge, origine e cache. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
7. Non forzare il protocollo ai client. Lascia la negoziazione automatica. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.

Verifica della stabilità dopo l’intervento

Non fermarti al primo test riuscito. Ripeti l’operazione dopo aver aperto una nuova sessione, svuotato soltanto la cache pertinente e atteso l’eventuale scadenza del TTL o del rate limit. Controlla inoltre che una seconda pagina, un secondo utente o un secondo destinatario non presentino ancora il problema.

Conserva per almeno il tempo necessario il backup e la configurazione precedente. Se l’anomalia ricompare, confronta orario, log e processo pianificato: una ricorrenza regolare può dipendere da cron, rinnovi, rotazioni, cache rigenerate o servizi esterni.

Controlli finali

• Browser usa h2 o h3 correttamente.
• TCP fallback funziona.
• TLS valido.
• Nessun blocco su reti comuni.
• Prestazioni misurate e non presunte.

Prevenzione

• Mantieni server aggiornato.
• Monitora UDP.
• Conserva fallback.
• Testa più reti.
• Ottimizza applicazione.

Errori da evitare

• Non disabilitare HTTP/2.
• Non aprire porte UDP indiscriminate.
• Non confondere protocollo edge e origine.
• Non promettere velocità automatica.
• Non usare test singoli come prova definitiva.

Quando contattare l’assistenza Xlogic

Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi o richiede log e configurazioni non disponibili nel pannello. Indica:

• dominio
• rete e browser
• protocollo rilevato
• uso CDN
• risultato DevTools o curl

Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.

Fonti tecniche ufficiali

• IETF RFC 9114: HTTP/3
• IETF RFC 9113: HTTP/2

Verifica prolungata dopo la correzione

Una singola prova riuscita non dimostra che il problema sia definitivamente risolto. Ripeti l’operazione dopo una nuova sessione, da una seconda rete o con un secondo utente quando applicabile. Per DNS e posta considera anche TTL, code e cache dei resolver; per HTTP e WordPress controlla una pagina dinamica, una funzione amministrativa e il relativo registro degli errori.

Conserva temporaneamente il backup, i valori precedenti e gli estratti dei log. Se l’anomalia ricompare, confronta l’orario con cron, backup, aggiornamenti, rinnovi SSL, rotazioni DNS, code email e servizi esterni. Una ricorrenza regolare è spesso più significativa del messaggio mostrato durante il singolo evento.

Prima di chiudere l’intervento verifica inoltre che le misure di sicurezza siano ancora operative: HTTPS valido, autenticazione richiesta, WAF attivo, permessi non eccessivi e nessun endpoint di debug o manutenzione lasciato pubblico. La soluzione deve correggere la causa senza ridurre stabilmente le protezioni del servizio.

Domande frequenti su HTTP/2 e HTTP/3 differenze