Stai giocando online e il tuo personaggio corre verso una porta. Per un istante sembra fermarsi, poi scatta di colpo e ti ritrovi più avanti nel corridoio. È il famoso lag, temuto dai gamer, che ha reso parole come ping e latenza familiari anche a chi voleva soltanto giocare.
Dietro quel salto temporale, però, non c’è soltanto la velocità della connessione. Conta anche il modo in cui vengono gestiti i dati: pur di recuperare un aggiornamento mancante, il sistema può far aspettare quelli successivi. Quando finalmente arriva, il messaggio descrive correttamente dove si trovava il personaggio, ma tu sei già altrove. Per il gioco, a quel punto, ricevere tutto può essere meno utile che lasciar perdere qualcosa.
Se gli aggiornamenti viaggiano su un canale che può consegnarli fuori ordine, la posizione nel corridoio potrebbe perfino arrivare dopo quella sulla soglia. Applicarla senza controllarne l'età rischierebbe allora di riportare indietro il personaggio. Su un canale ordinato il problema assume un'altra forma: la posizione nuova deve aspettare quella vecchia. In entrambi i casi, avere tutti i dati non basta a rappresentare bene ciò che sta succedendo.
Gran parte della storia di Internet è stata costruita intorno al problema opposto: come possiamo far arrivare i dati senza perderli, duplicarli o cambiarne l'ordine? La risposta più famosa è TCP, il protocollo che numera i byte, conferma la ricezione e ritrasmette ciò che non è arrivato, permettendoci così di scaricare un documento senza trovare buchi casuali nel mezzo.
Per un'applicazione interattiva, recuperare ogni byte può quindi entrare in conflitto con un'altra esigenza: quanto vale ancora quel dato dopo cinquanta, cento o cinquecento millisecondi?
Un pagamento deve essere registrato correttamente, una volta sola, ed il suo esito deve poter essere verificato anche se la risposta arriva in ritardo. È una responsabilità del programma: il trasporto affidabile porta i byte, ma da solo non impedisce di eseguire due volte una richiesta ripetuta. La posizione istantanea di un cursore condiviso, invece, può essere sostituita appena ne esiste una più recente, mentre per un fotogramma recuperare ogni frammento mancante può lasciare lo spettatore ad aspettare un'immagine ormai vecchia.
WebTransport nasce per gestire questa differenza. Nel 2026 la sua API è diventata disponibile nelle versioni recenti dei principali browser considerate dal programma Baseline ed è stata pubblicata dal W3C come Candidate Recommendation. Offre a un'applicazione web una sessione client-server con più strumenti: flussi affidabili per ciò che deve arrivare, datagrammi per ciò che può essere perso e canali indipendenti che non costringono ogni messaggio ad aspettare tutti gli altri.
È in questo senso che il browser “impara” a perdere pacchetti: lo sviluppatore sceglie quali dati conservare e quali possono scadere, mentre WebTransport gli mette a disposizione gli strumenti per farlo dentro il modello di sicurezza del web. La decisione dipende dal significato del messaggio, che il browser da solo non conosce.
Affidabilità e puntualità
Nel linguaggio comune, una connessione affidabile sembra sempre preferibile. Nei trasporti affidabili e ordinati di cui parliamo qui, la promessa è più precisa: consegnare i byte senza buchi e nella sequenza prevista, oppure segnalare il fallimento della connessione. Se manca un pezzo, il mittente lo ritrasmette ed il destinatario trattiene i byte successivi finché può ricostruire la sequenza.
Questo comportamento è prezioso quando ogni byte dipende dal precedente, come accade con un archivio compresso o una pagina HTML; anche il saldo di un conto e la modifica permanente di un documento non tollerano buchi arbitrari. La ritrasmissione trasforma una rete fisica imperfetta in un canale molto più comodo per i programmi.
L'affidabilità ha però un costo temporale. Se un segmento si perde, infatti, bisogna accorgersene, attendere una copia e rimettere i dati nell'ordine corretto, con tempi che variano in base alla distanza, alla congestione e al comportamento della rete. Durante quell'attesa possono essere già arrivati dati successivi, ma un flusso ordinato non può sempre consegnarli all'applicazione come se il buco non esistesse.
Questa attesa viene chiamata head-of-line blocking: il pezzo mancante in testa alla fila impedisce a quelli dietro di essere consegnati, anche se sono già arrivati. TCP sta rispettando il contratto che gli abbiamo chiesto, cioè restituire all'applicazione un unico flusso di byte nell'ordine in cui sono stati inviati.
Per molte attività il contratto è giusto, visto che in una chat conta la sequenza della conversazione, mentre in un trasferimento file saltare un blocco sarebbe disastroso. Giochi, videoconferenze e lavagne collaborative fanno invece convivere dati con esigenze diverse, tutti raccolti sotto l'etichetta “tempo reale”.
Il corridoio unico di WebSocket
WebSocket ha dato al browser qualcosa che HTTP tradizionale offriva con difficoltà: una connessione bidirezionale persistente fra client e server. Una volta aperta, entrambe le parti possono inviare messaggi senza costruire una nuova richiesta per ogni aggiornamento. Chat, dashboard, notifiche, giochi e strumenti collaborativi l'hanno usata per anni con buoni motivi.
L'applicazione vede un canale affidabile e ordinato, ed è proprio questa semplicità a rendere WebSocket adatto a molti prodotti. Se i messaggi devono tutti arrivare e rispettare la stessa sequenza, non serve chiedere al trasporto molto altro.
Il limite compare quando sullo stesso corridoio passano traffici con priorità e durata differenti. In un editor condiviso, le modifiche al testo devono arrivare in modo affidabile; la posizione del cursore di un collega viene aggiornata molte volte al secondo e non occorre recuperare ogni passaggio intermedio. Se tutto attraversa una sola fila ordinata, un rallentamento che coinvolge un messaggio importante può trattenere anche quelli effimeri. Una massa di aggiornamenti effimeri, a sua volta, può complicare la consegna di ciò che deve restare.
Gli sviluppatori hanno gestito queste differenze aprendo più connessioni, separando le code ed usando numeri di sequenza per ignorare i messaggi vecchi. Sono soluzioni che funzionano, ma richiedono di organizzare nell'applicazione quella separazione che il singolo canale non offre.
WebRTC DataChannel offre da tempo opzioni più flessibili, comprese consegne parzialmente affidabili, ma nasce per comunicazioni fra pari e porta con sé negoziazione, ICE, NAT traversal e un ecosistema pensato soprattutto per audio, video e connessioni peer-to-peer. Per collegare soltanto un browser a un server può quindi risultare più complesso del necessario. WebTransport occupa questo spazio intermedio: conserva il modello client-server di WebSocket, aggiunge più flussi e dati effimeri e non espone al codice web un socket UDP grezzo.
Prima di WebTransport viene QUIC
HTTP/2 aveva già permesso a molte richieste web di condividere una sola connessione, nella quale immagini, fogli di stile e chiamate API potevano procedere come flussi logici separati. Sotto, però, la connessione usava TCP, per il quale tutto restava un unico flusso ordinato di byte: se un pacchetto si perdeva, i dati successivi dovevano attendere la ricostruzione anche quando appartenevano a richieste HTTP/2 differenti.
Con QUIC la separazione scende al livello del trasporto. Il protocollo standardizzato dall'IETF viaggia dentro UDP, integra TLS 1.3 e gestisce più stream nella stessa connessione. Ogni stream affidabile conserva ordine e ritrasmissione al proprio interno, per cui un buco deve ancora essere colmato, ma non obbliga gli altri stream ad aspettare quei byte. Rimangono condivisi la connessione e il controllo della congestione: se la rete è satura, anche i flussi indipendenti ne risentono.
HTTP/3 usa QUIC al posto di TCP e mantiene il significato delle richieste e delle risposte HTTP. Dal trasporto eredita cifratura, controllo della congestione e multiplexing, cioè la possibilità di far convivere più flussi sulla stessa connessione. WebTransport si appoggia a questa base per rendere quelle capacità accessibili alle applicazioni, conservando le protezioni e il controllo delle origini del browser.
UDP è dunque l'involucro con cui QUIC attraversa la rete. La gestione della connessione, la cifratura e l'autenticazione sono aggiunte da QUIC, che fornisce anche affidabilità e ordine agli stream. I datagrammi possono rinunciare alla ritrasmissione senza perdere la protezione del traffico o sottrarsi al controllo della congestione.
Un browser non può consegnare a qualsiasi pagina un socket UDP arbitrario, perché un sito malevolo potrebbe usarlo per scansioni, amplificazione di attacchi o traffico verso macchine che non hanno acconsentito a partecipare. WebTransport stabilisce invece una sessione con un server che supporta esplicitamente il protocollo, usa HTTPS e conserva le regole di sicurezza legate all'origine. La consegna inaffidabile resta dentro una connessione controllata.
Stream e datagrammi nella stessa sessione
WebTransport mette tre strumenti dentro una sola sessione. Il primo è lo stream bidirezionale, nel quale client e server possono leggere e scrivere scambiando byte affidabili e ordinati. Si presta quindi a una conversazione richiesta-risposta, a comandi che richiedono conferma o a dati che non possono perdere pezzi.
Lo stream unidirezionale conserva queste garanzie, ma porta i dati in una sola direzione. Può quindi servire per un trasferimento, un segmento multimediale o un flusso prodotto dal server che non richiede una risposta sullo stesso stream. Più stream possono convivere nella sessione senza condividere un unico ordine di consegna.
Il datagramma è invece un messaggio di dimensione limitata, consegnato intero oppure non consegnato. Il trasporto prova a inviarlo senza promettere di recuperarlo se si perde e senza garantire l'ordine rispetto agli altri datagrammi. Si presta quindi agli aggiornamenti per i quali il messaggio successivo può sostituire quello precedente.
Poiché stream e datagrammi condividono la sessione e il contesto di sicurezza, l'applicazione può scegliere come spedire ciascun dato senza mantenere due tecnologie separate.
Nell'editor collaborativo, le operazioni che modificano il documento viaggiano su uno stream affidabile, mentre la posizione del cursore usa datagrammi. Allo stesso modo, un nuovo permesso assegnato a un collaboratore deve arrivare ed essere verificato, mentre l'animazione che mostra dove sta trascinando il mouse può saltare un aggiornamento e passare direttamente al più recente.
Lo stesso criterio vale per un gioco: l'acquisto di un oggetto ed il risultato di una partita devono restare, mentre la rotazione momentanea della telecamera viene presto sostituita dalla successiva. In un controllo remoto si possono distinguere i comandi che richiedono una conferma dalla telemetria ad alta frequenza; in una trasmissione dal vivo, i metadati essenziali dagli aggiornamenti temporali sacrificabili. La categoria dipende dall'uso, non dal nome del dato: un comando di emergenza, per esempio, richiede garanzie applicative che la sola consegna affidabile non esaurisce.
Il dato con una data di scadenza
L'API espone due proprietà, `incomingMaxAge` e `outgoingMaxAge`, con cui indicare quanto a lungo un datagramma può restare nelle code del browser in entrata e in uscita. Esistono anche limiti al numero di datagrammi accodati. Si tratta di controlli locali: il tempo passato nella coda di ricezione non misura da quanto il messaggio è stato creato dall'altra parte, né impone una scadenza all'intero viaggio sulla rete.
Se l'applicazione produce cento aggiornamenti di posizione al secondo e la rete riesce temporaneamente a inviarne molti meno, una coda tradizionale accumula ritardo. Quando la connessione migliora, consegna una lunga cronaca di dove il personaggio si trovava mezzo secondo fa: informazioni corrette, ma dannose per il gioco.
Impostando una durata massima nella coda in uscita, l'applicazione permette al browser di eliminare gli aggiornamenti scaduti prima di spedirli. Evita così di consumare banda per smaltire tutto il ritardo accumulato, anche se resta suo compito verificare quali messaggi siano ancora utili quando arrivano a destinazione.
I sistemi in tempo reale fanno da tempo scelte simili: assegnano priorità, scartano fotogrammi e sovrascrivono campioni, oppure usano numeri di sequenza per riconoscere uno stato ormai superato. WebTransport porta nel browser controlli per le code dei datagrammi accanto agli stream affidabili, dentro la stessa API. Le regole che riguardano il significato dei dati restano nell'applicazione.
“L'utente ha confermato l'ordine” resta importante anche un secondo dopo e deve sopravvivere al ritardo, mentre “Il cursore è alla coordinata 481,220” può essere sostituito da 482,221. Nel primo caso il programma conserva un fatto; nel secondo sta cercando di mostrare una posizione attuale.
Se trattiamo il fatto come un aggiornamento effimero, rischiamo di perdere un'informazione necessaria. Se invece conserviamo ogni posizione intermedia, la coda può allungarsi fino a mostrare sistematicamente il cursore dove il collega non si trova più. Scegliere cosa scartare richiede perciò di conoscere il funzionamento del programma.
Perdere bene richiede più progetto
Per scegliere quali dati scartare serve anzitutto un protocollo applicativo, nel quale ogni datagramma sia comprensibile da solo oppure contenga abbastanza informazioni per essere confrontato con gli altri. Numeri di sequenza o timestamp aiutano a riconoscere gli aggiornamenti superati, ma se un messaggio dipende da uno stato iniziale mai ricevuto la sua rapidità non serve.
Anche la dimensione conta. I datagrammi sono infatti atomici ed hanno un limite che dipende dal percorso, per cui un grande fotogramma non può essere infilato distrattamente in un solo messaggio. La specifica espone la dimensione massima disponibile; l'applicazione deve rispettarla o scegliere stream e segmentazione.
Quando la rete rallenta, QUIC limita il ritmo di invio attraverso il controllo della congestione ed il browser applica backpressure, chiedendo al produttore dei dati di rallentare quando la coda si riempie. Il codice deve rispettare questo segnale: continuare ad accumulare aggiornamenti altrove vanificherebbe il lavoro sulle code del trasporto. Perdite, ritardi e tempi di attesa vanno misurati, anche quando scartare un datagramma è un comportamento previsto.
L'API nel browser è però soltanto un'estremità: dall'altra parte serve un'implementazione capace di terminare HTTP/3 e WebTransport, gestire stream e datagrammi, osservare la sessione e integrarla con la logica del prodotto. Anche proxy, bilanciatori, firewall e piattaforme cloud devono permettere il percorso. La presenza dell'interfaccia JavaScript, da sola, non aggiorna tutta la filiera.
La valutazione deve quindi comprendere anche il lavoro sul server e sugli intermediari. Se l'infrastruttura esistente usa WebSocket, il costo del cambiamento va confrontato con un problema concreto di latenza o di separazione del traffico.
WebTransport diventa interessante quando nella stessa sessione convivono dati con esigenze davvero differenti ed il ritardo ne riduce l'utilità. Prima di adottarlo bisogna però decidere come si comporterà il servizio durante le perdite e che cosa offrirà sulle reti dove il percorso preferito non funziona.
Scegliere il trasporto, prevedere l'alternativa
HTTP resta adatto a pagine, API ordinarie e contenuti che beneficiano di cache e intermediari. Se un'app invia pochi messaggi e li vuole tutti in ordine, la connessione bidirezionale di WebSocket può bastare ed essere più facile da gestire. Per le comunicazioni fra pari c'è WebRTC, mentre il modello principale di WebTransport collega un client a un server. Sono esigenze diverse, prima ancora che tecnologie da confrontare.
Il fallback resta necessario, perché QUIC viaggia sopra UDP ed alcune reti aziendali, apparati intermedi o configurazioni restrittive possono impedirlo. L'IETF sta sviluppando anche un binding WebTransport su HTTP/2, destinato a offrire le funzioni principali quando un percorso basato su UDP non è disponibile. Nel settembre 2026 quel documento è ancora un Internet-Draft; inoltre, un fallback affidabile non può offrire esattamente la stessa libertà di perdita dei datagrammi su QUIC, quindi l'applicazione deve conoscere le capacità effettive della sessione.
La specifica dell'API permette al programma di richiedere il supporto alla consegna inaffidabile e di fallire se manca, oppure di accettare una modalità soltanto affidabile. L'effettiva disponibilità di queste opzioni va controllata nei browser a cui ci si rivolge. A quel punto resta una scelta di prodotto: rinunciare alla funzione oppure offrirne una versione ridotta.
Un gioco competitivo, ad esempio, potrebbe rifiutare una sessione che non garantisce il comportamento necessario, mentre una lavagna collaborativa potrebbe mantenere le modifiche al documento e aggiornare i cursori con minore frequenza. Per un pannello di monitoraggio, invece, potrebbe bastare il passaggio a richieste periodiche. La resilienza dipende dalla presenza di queste alternative quando il protocollo preferito non è disponibile.
Due etichette per due maturità
MDN classifica WebTransport come Baseline 2026, newly available da marzo: la funzione è presente nelle versioni recenti dei browser principali considerate dal programma WebDX. Per chi sviluppa è un'informazione utile, perché segnala una disponibilità che va oltre un solo motore.
L'etichetta non comprende però ogni dispositivo in circolazione. Vecchi browser, sistemi operativi che non possono essere aggiornati e webview richiedono controlli separati; anche le singole sottofunzioni possono avere un supporto differente. Baseline aiuta quindi a valutare la compatibilità, senza sostituire la verifica sul pubblico reale.
Il 30 luglio il W3C ha pubblicato l'API come Candidate Recommendation Snapshot, una fase del percorso di standardizzazione nella quale il documento ha ricevuto una revisione ampia ed è destinato a diventare Recommendation, ma serve ancora esperienza di implementazione. Il gruppo ha fissato come criterio almeno due user agent indipendenti e interoperabili che superino i test, e la fase Candidate deve restare aperta almeno fino al 30 ottobre 2026.
Nel frattempo, i protocolli IETF che legano WebTransport a HTTP/3 e HTTP/2 sono Internet-Draft destinati al percorso di standardizzazione. Possono quindi ancora cambiare e non vanno presentati come RFC conclusivi.
Baseline descrive la disponibilità pratica nei browser recenti; Candidate Recommendation riguarda la maturità formale della specifica W3C. Una tecnologia può essere implementata e utilizzabile mentre il testo che la definisce completa gli ultimi passaggi.
Chi sviluppa può quindi sperimentare per pubblici controllati, misurare le capacità, predisporre fallback e seguire le modifiche dello standard, mentre sarebbe prematuro dichiarare WebTransport la base universale di ogni applicazione in tempo reale.
Che cosa resta protetto
La parola “inaffidabile” può far pensare a un canale meno sicuro, mentre nel caso dei datagrammi descrive la possibilità che un messaggio non arrivi.
Nel percorso HTTP/3, un datagramma viaggia dentro una connessione QUIC protetta da TLS 1.3: cifratura e autenticazione del server restano presenti anche quando il dato può andare perso. Il server deve accettare esplicitamente WebTransport ed il browser conserva i controlli sull'origine. Anche il controllo della congestione rimane attivo, per evitare che l'invio di dati effimeri sovraccarichi la rete.
La sicurezza applicativa resta comunque responsabilità di chi costruisce il servizio, perché un messaggio può essere cifrato e tuttavia autorizzare un'azione che l'utente non dovrebbe compiere, così come un datagramma può provenire dalla sessione giusta e contenere uno stato incoerente. Restano quindi necessarie autenticazione, autorizzazione, validazione e protezione dagli abusi.
Queste protezioni spiegano perché WebTransport espone una sessione con un server consenziente anziché un accesso UDP generico. Danno alle applicazioni una strada per ottenere bassa latenza dentro il modello web, riducendo la necessità di cercare scorciatoie esterne.
Nei browser anche una pagina potenzialmente ostile deve poter usare un'API senza ottenere poteri arbitrari sul dispositivo o sulla rete. La consegna inaffidabile si inserisce in questo vincolo: cambiano le garanzie sul recapito del messaggio, mentre restano quelle che delimitano l'accesso del sito.
Le scelte che spettano all'applicazione
Quando contenuto, destinatario e permessi sono stati definiti, resta dunque da stabilire per quanto tempo ogni messaggio abbia valore. Nel progetto questa decisione deve diventare una regola riconoscibile, altrimenti due parti dello stesso programma possono trattare lo stesso dato in modi incompatibili.
Per ogni messaggio conviene anzitutto chiedersi se deve arrivare: in quel caso serve uno stream affidabile o un meccanismo applicativo equivalente. Occorre poi capire rispetto a quali altri messaggi debba restare in ordine, perché stream separati possono rappresentare dipendenze separate senza imporre l'ordine rispetto a tutto. Infine conta fino a quando il messaggio è utile: se vive pochi millisecondi e un aggiornamento più recente lo sostituirà, può viaggiare in un datagramma con una coda limitata.
Il criterio si applica anche fuori da giochi e video. Un sensore può produrre campioni utili soltanto finché sono recenti; una piattaforma finanziaria distingue l'ultimo prezzo dalla conferma di un ordine. Un gemello digitale riceve telemetria continua, ma deve conservare allarmi e cambi di configurazione. Come nell'editor condiviso, presenza e contenuto richiedono trattamenti differenti.
L'etichetta “tempo reale” da sola non permette di prendere queste decisioni. In molte applicazioni il presente e la storia convivono, e rendere tutto sacrificabile sarebbe un errore quanto accodare ogni aggiornamento per sempre. WebTransport permette di esprimere la distinzione nel trasporto; chi costruisce il servizio deve darle un significato coerente.
Quando il passato va scartato
Davanti alla porta, se il server conosce già la posizione sulla soglia, recuperare quella del corridoio non aggiunge un'informazione utile a mostrare dove si trova il personaggio. Il programma può ignorare quel vecchio aggiornamento e usare il successivo, purché sia in grado di riconoscerlo.
Nella stessa sessione, “la porta è stata aperta” potrebbe invece essere un evento da conservare, perché sblocca un'area del mondo condiviso. In quel caso il progettista sceglierà una consegna affidabile e verificherà che l'evento sia stato gestito, come farebbe per una modifica all'inventario. La telecamera può già essersi girata altrove, senza che questa operazione perda valore.
Le reti hanno sempre perso pacchetti. Con WebTransport l'applicazione può organizzarsi intorno a questa eventualità, riservando il recupero ai dati che servono ancora ed evitando di trattenere gli altri dietro informazioni scadute. Quando il collegamento torna a funzionare, vorrei ritrovare il personaggio sulla porta, con l'inventario corretto, senza dover prima rivedere ogni passo del corridoio.
Bibliografia
- W3C WebTransport Working Group. WebTransport. Candidate Recommendation Snapshot, 30 luglio 2026.
- W3C WebTransport Working Group. WebTransport Explainer.
- IETF WEBTRANS Working Group. The WebTransport Protocol Framework. Internet-Draft, luglio 2026.
- IETF WEBTRANS Working Group. WebTransport over HTTP/3. Internet-Draft, 6 luglio 2026.
- IETF WEBTRANS Working Group. WebTransport over HTTP/2. Internet-Draft, 6 luglio 2026.
- IETF. QUIC: A UDP-Based Multiplexed and Secure Transport. RFC 9000, maggio 2021.
- IETF. Transmission Control Protocol (TCP). RFC 9293, agosto 2022.
- IETF. An Unreliable Datagram Extension to QUIC. RFC 9221, marzo 2022.
- IETF. HTTP/3. RFC 9114, giugno 2022.
- IETF. HTTP Datagrams and the Capsule Protocol. RFC 9297, agosto 2022.
- MDN Web Docs. WebTransport API.
- MDN Web Docs. Baseline (compatibility).
