HTTP/3 o HTTP/2: mezzo milione di misure smentisce la latenza sempre minore

Abilitare HTTP/3 non garantisce una latenza inferiore a HTTP/2 nelle reti domestiche e dei piccoli uffici. Uno studio su oltre mezzo milione di misure RTT trova mediane comparabili sui collegamenti Ethernet e Wi-Fi, mentre l’upload concorrente allunga i tempi delle richieste più lente.

HTTP/3 offre un vantaggio tecnico quando la perdita di pacchetti blocca richieste parallele, ma il risultato dipende anche da ciò che accade sul collegamento d’accesso. Su una linea stabile HTTP/2 può restare competitivo; quando l’uscita è satura, la mediana da sola nasconde le attese che contano per le richieste interattive.

Che cosa cambia passando da TCP a QUIC

HTTP/2 può gestire più richieste sulla stessa connessione TCP. La specifica HTTP/3 spiega la differenza di trasporto: se TCP deve recuperare un pacchetto perso, le transazioni attive sulla connessione possono fermarsi; con QUIC, la perdita che blocca uno stream non impedisce agli altri di avanzare. HTTP/3 conserva quindi il parallelismo delle richieste senza imporre a tutte l’attesa causata da uno stream.

Questa indipendenza non crea capacità aggiuntiva sulla linea. Gli stream QUIC condividono il controllo della congestione della connessione e attraversano lo stesso collegamento in uscita delle altre applicazioni. Se un upload continuo riempie la coda del router, anche una richiesta breve può aspettare prima di essere trasmessa. Sul Wi-Fi si aggiungono la contesa per il mezzo radio e le ritrasmissioni: sono condizioni che la scelta della versione HTTP, da sola, non elimina.

C’è inoltre una distinzione fra il tempo necessario ad aprire una connessione e quello delle richieste successive. Un eventuale vantaggio nella fase iniziale non implica che ogni richiesta su una connessione già aperta riceva prima la risposta. Per questo i due tempi vanno tenuti separati quando si interpreta un confronto di latenza.

Perché la mediana non racconta le richieste lente

La tabella delle prove Wi-Fi con upload HTTP/2 concorrente riporta per le sonde HTTP/2 una mediana di 15,95 ms, un 95º percentile di 110,84 ms e un 99º di 157,02 ms; per le sonde HTTP/3 i valori sono rispettivamente 11,53, 97,63 e 141,65 ms. In questa configurazione HTTP/3 è più rapido anche ai percentili alti: l’aumento delle attese sotto carico riguarda entrambi i protocolli, non dimostra che HTTP/3 sia più lento di HTTP/2.

La distanza fra mediana e percentili alti descrive richieste che incontrano una coda affollata solo a tratti. Il 95º percentile indica un’attesa superata da una piccola parte delle sonde; il 99º porta l’attenzione sulle richieste ancora più lente. Se si guarda soltanto alla risposta tipica, quella variabilità resta quasi invisibile, anche quando può incidere su scambi brevi e frequenti.

Nelle tracce con upload TCP sul collegamento cablato compaiono anche picchi e occasionali timeout delle sonde HTTP/3. Il timeout è quello della richiesta nel programma di misura: non è una misura diretta del timer di ritrasmissione di QUIC. I risultati vanno letti insieme alle tabelle dei percentili, che nelle prove Wi-Fi citate mostrano valori inferiori per HTTP/3.

Le sonde interrogavano un endpoint leggero su connessioni persistenti, attraverso apparati d’accesso di fascia domestica e percorsi Ethernet o Wi-Fi. Il tempo misurato andava dall’invio della richiesta ai primi byte della risposta. Questa impostazione isola bene le attese dei piccoli scambi sotto carico, ma non fornisce direttamente il tempo di caricamento di una pagina completa nel browser né quello di una nuova connessione.

Perdita di pacchetti e upload portano a risultati diversi

Quando più richieste condividono una connessione soggetta a perdite, gli stream indipendenti danno a HTTP/3 una ragione concreta per avvantaggiarsi. Un confronto sperimentale su percorsi degradati e configurazioni con proxy rileva vantaggi per HTTP/3 con perdite elevate e durante la migrazione della connessione; trova anche che HTTP/2 con proxy e BBR può recuperare terreno. Sono risultati delle configurazioni provate, non una previsione valida per ogni rete domestica.

Con l’upload saturo cambia il meccanismo dominante. Un trasferimento lungo occupa la capacità in uscita mentre le brevi richieste cercano spazio nella stessa coda. Nelle prove d’accesso, un upload concorrente basato su QUIC produceva code più stabili rispetto allo scenario con upload TCP e sonde di protocolli diversi. Il tipo di traffico concorrente conta dunque quanto il protocollo della richiesta che si sta misurando.

• Su un accesso stabile e poco carico, mediane vicine lasciano HTTP/2 competitivo.
• Con perdite o cambi di rete, HTTP/3 ha vantaggi di trasporto da valutare sulle richieste interessate.
• Con upload frequenti, sono le code dell’accesso e i percentili alti a mostrare dove cresce l’attesa.

UDP, NAT e fallback incidono sulla latenza effettiva

Un servizio che offre HTTP/3 non raggiunge necessariamente ogni client con QUIC: il percorso UDP può essere bloccato o trattato in modo irregolare. La RFC 9312 sulla gestione di QUIC descrive un caso insidioso: se passano i pacchetti iniziali ma quelli successivi vengono scartati, la connessione può completare l’avvio senza attivare il ripiego su TCP e poi soffrire perdite gravi. Quando invece l’avvio QUIC fallisce, il client può ripiegare su una versione HTTP basata su TCP.

Il NAT è un’altra variabile del percorso, ma va distinto da una causa accertata. Nelle prove sulle reti d’accesso, la gestione dello stato NAT era indicata come possibile contributo ai ritardi, senza una misura diretta dei suoi timer o delle regole di mappatura. Un tentativo QUIC fallito seguito da fallback e una connessione QUIC riuscita ma lenta durante un upload sono problemi diversi, anche se l’utente vede in entrambi una risposta tardiva.

Quali metriche servono per scegliere

Per decidere se abilitare HTTP/3 accanto a HTTP/2, la telemetria deve distinguere il protocollo effettivamente usato, non solo quello offerto dal server. Per ciascun gruppo di richieste sono utili la mediana e i percentili 95º e 99º del tempo ai primi byte, insieme a errori e timeout. Separare connessioni nuove da connessioni riutilizzate evita di confondere il costo dell’avvio con la latenza degli scambi successivi.

Conviene inoltre confrontare richieste della stessa classe e accessi in condizioni simili: linea poco carica, upload concorrente, perdita di pacchetti o Wi-Fi conteso. Il tasso di negoziazione QUIC riuscita, la quota di fallback e il tempo consumato dai tentativi falliti mostrano quante richieste usufruiscono davvero di HTTP/3. Se l’attesa cresce soprattutto durante l’upload, la gestione della coda e la capacità in uscita possono spiegare il risultato meglio della sola versione HTTP.

HTTP/3 ha una base empirica per l’abilitazione quando riduce le attese nelle condizioni d’accesso rilevanti senza aumentare errori e ripieghi lenti. Dove le mediane restano vicine e la coda dell’upload governa i picchi, mantenere HTTP/2 disponibile preserva un percorso competitivo mentre si interviene sul collo di bottiglia condiviso.

Leggi anche:

• NIH investe 88 milioni nei modelli umani: IA e robot sostituiscono parte dei test
• OpenAI Dots resta sempre attivo mentre cresce l’allarme sicurezza
• #adv non basta sempre: come segnalare una sponsorizzazione in Italia