Media over QUIC — MoQ — è il protocollo di streaming emergente più discusso del 2025-2026. Gli articoli sui blog si moltiplicano, gli interventi alle conferenze si accumulano e i fornitori di CDN fanno a gara per annunciarne il supporto. Se lavorate nel live streaming, probabilmente vi è stato chiesto: dovremmo passare a MoQ?
La risposta breve, per la maggior parte dei prodotti in produzione oggi, è no — non ancora. Ma vale la pena comprendere MoQ, perché i problemi che risolve sono reali e la tempistica per il raggiungimento della maturità produttiva si misura ormai in trimestri, non in anni.
Questo articolo spiega cos'è realmente MoQ, a che punto si trova a marzo 2026, cosa cambia rispetto a HLS, WebRTC e SRT — e se avrebbe senso per due prodotti reali che abbiamo implementato: WeSpeakSports (commento audio live dei tifosi tramite WebRTC) e DJing Stream (audio DJ di qualità broadcast tramite SRT e HLS Lossless).
Cos'è realmente MoQ
MoQ sta per Media over QUIC. È un'iniziativa del gruppo di lavoro IETF avviata nel 2022, per definire un nuovo protocollo di distribuzione multimediale costruito su QUIC (il livello di trasporto alla base di HTTP/3).
La specifica di trasporto principale, draft-ietf-moq-transport, ha raggiunto la versione 17 nel marzo 2026. È in corso anche una specifica per il formato di streaming (draft-ietf-moq-msf), insieme a bozze complementari per il packaging CMAF e la compressione degli header. Nessuna di queste è ancora un RFC ratificato.
Alla base, MoQ è un protocollo publish/subscribe. Un publisher invia oggetti multimediali denominati (frame audio, frame video, metadati) ai relay, e i subscriber li ricevono iscrivendosi a tracce denominate. Questo è fondamentalmente diverso sia da HLS (richiesta/risposta HTTP per i segmenti) sia da WebRTC (negoziazione di sessione peer-to-peer con SDP/ICE).
MoQ funziona su stream e datagrammi QUIC, nativamente o tramite WebTransport (l'API del browser per QUIC). Questo gli dà accesso alle funzionalità di multiplexing, prioritizzazione e affidabilità parziale di QUIC — il che significa che il protocollo può, per progettazione, scartare un frame video in ritardo piuttosto che bloccare l'intero stream in attesa della ritrasmissione.
Cosa MoQ intende sostituire
Come afferma Cullen Jennings di Cisco (partecipante al gruppo di lavoro MoQ), il mondo dello streaming ha attualmente due silos. Da un lato, servizi come Netflix e YouTube distribuiscono contenuti multimediali su larga scala attraverso CDN basate su HTTP, ma con secondi di latenza. Dall'altro, strumenti di conferencing come Zoom e piattaforme basate su WebRTC distribuiscono contenuti in tempo quasi reale, ma non riescono a scalare in modo economicamente efficiente verso grandi audience.
MoQ mira a collegare questi due mondi con un unico protocollo capace di servire sia i casi d'uso in tempo reale che quelli in quasi-tempo reale, dalla contribuzione (ingest) alla distribuzione (consegna agli spettatori), con un'infrastruttura di relay compatibile con le CDN nel mezzo.
A che punto è MoQ oggi (marzo 2026)
Facciamo il punto preciso sulla situazione attuale:
La specifica è vicina al completamento ma non è finita. La bozza del trasporto è alla versione 17, con iterazioni rapide. La bozza del formato di streaming è stata pubblicata a gennaio 2026. C'è un lavoro complementare attivo sul packaging CMAF e la compressione degli header. Ma non c'è ancora nessun RFC ratificato.
Il divario Safari/WebTransport si sta chiudendo. MoQ nel browser dipende da WebTransport, che richiede HTTP/3 e QUIC. Chrome e Firefox supportano già WebTransport. Safari era l'assente — ma Apple ha aggiunto il supporto WebTransport nella beta di Safari 26.4 (febbraio 2026), ed è un impegno ufficiale di Interop 2026 da parte di WebKit. A marzo 2026, questo non è ancora stato rilasciato in una versione stabile di Safari, ma non è più una questione di se — solo di quando nel prossimo ciclo di aggiornamento del sistema operativo. Per i prodotti che si rivolgono agli utenti iPhone e iPad tramite browser, il divario è quasi colmato.
Esistono primi deployment in produzione, ma sono limitati. Nanocosmos ha dimostrato la distribuzione MoQ end-to-end (ingest da OBS verso un'audience globale) al MonteVIDEO Summer Project. Cloudflare ha lanciato una beta di MoQ. Red5 ha annunciato il supporto MoQ entro la fine del 2026. Ma si tratta di deployment da early adopter, non di infrastruttura mainstream.
La comunità è onesta riguardo alla maturità. Persino Luke Curley, che ha costruito una delle prime implementazioni di MoQ su Twitch (ora Discord) e ha redatto la bozza di semplificazione moq-lite, afferma esplicitamente che la specifica completa del trasporto MoQ "è diventata troppo complicata" con "troppi messaggi, modalità opzionali e funzionalità appena abbozzate." La sua bozza moq-lite è una risposta a questa complessità.
I veterani del settore sono misurati. Tsahi Levent-Levi di BlogGeek.me ha previsto che nel 2026 gli sviluppatori si sarebbero lamentati più di WebRTC che di MoQ — non perché MoQ sia migliore, ma perché gli utenti di MoQ sono ancora early adopter che si aspettano problemi. WebRTC è quello in produzione ovunque, che porta il peso delle aspettative del mondo reale.
Cosa cambia MoQ rispetto a HLS
HLS (HTTP Live Streaming) funziona dividendo i contenuti multimediali in segmenti, scrivendoli su un server HTTP, e facendo sì che i player richiedano nuovi segmenti tramite playlist. È maturo, compatibile con le CDN, ampiamente diffuso e ben documentato nel RFC 8216 e nell'Apple HLS Authoring Specification. Low-Latency HLS (LL-HLS) riduce la latenza a circa 2-4 secondi.
MoQ cambia il modello di distribuzione in diversi modi:
Da polling a push. I player HLS richiedono i segmenti. I subscriber MoQ ricevono gli oggetti non appena vengono pubblicati. Questo elimina la latenza del polling.
Da segmenti a oggetti. HLS opera su segmenti di più secondi (o segmenti parziali in LL-HLS). MoQ può operare a livello di frame. Un singolo frame video o frame audio può essere un oggetto individualmente indirizzabile e individualmente consegnabile.
Da TCP a QUIC. HLS funziona su HTTP/TCP. Quando un pacchetto TCP viene perso, tutto ciò che segue si blocca (head-of-line blocking). MoQ funziona su QUIC, dove gli stream sono indipendenti — un pacchetto perso su uno stream non blocca gli altri.
Prioritizzazione esplicita. La bozza di trasporto di MoQ definisce priorità e ordine di consegna a livello di protocollo. Durante la congestione, un relay può scartare oggetti a priorità inferiore (ad es. B-frames) anziché ritardare tutto in modo uguale.
Ingest e distribuzione unificati. Oggi la maggior parte dei flussi di lavoro live usa un protocollo per la contribuzione (RTMP, SRT, WHIP) e un altro per la distribuzione (HLS, DASH). MoQ può potenzialmente servire entrambi i percorsi con un unico protocollo, eliminando il passaggio di riconfezionamento al server di origine.
Quando HLS resta la scelta migliore
Nulla di tutto questo significa che HLS sia obsoleto. HLS resta la scelta più forte quando:
- Qualche secondo di latenza è perfettamente accettabile
- Un'ampia compatibilità con i dispositivi è essenziale (ogni telefono, TV e set-top box riproduce HLS)
- L'investimento esistente in CDN e strumenti funziona bene
- La semplicità operativa e l'affidabilità comprovata contano più della riduzione della latenza
Per la distribuzione standard OTT live e VOD — che costituisce la stragrande maggioranza del traffico streaming — HLS non è rotto, e MoQ non risolve un problema che esiste.
Cosa cambia MoQ rispetto a WebRTC
WebRTC è stato progettato per la comunicazione peer-to-peer in tempo reale: videochiamate, condivisione dello schermo, conversazioni uno-a-uno o in piccoli gruppi. L'industria lo ha esteso ben oltre il suo ambito originale, utilizzando architetture SFU (Selective Forwarding Unit) per scalare WebRTC verso audience più ampie.
MoQ differisce da WebRTC in diversi aspetti importanti:
Architettura. WebRTC è fondamentalmente un protocollo peer-to-peer orientato alle sessioni, anche quando mediato attraverso SFU. MoQ è un protocollo publish/subscribe client-server progettato fin dall'inizio attorno a relay e distribuzione in stile CDN.
Modello di scalabilità. Scalare WebRTC richiede un'infrastruttura SFU costruita ad hoc e costosa. I relay MoQ sono progettati per integrarsi con l'infrastruttura CDN esistente — i server HTTP/3 possono essere estesi per gestire il traffico MoQ, motivo per cui fornitori CDN come Akamai e YouTube sono attivamente coinvolti.
Complessità. WebRTC comporta una complessità significativa: negoziazione SDP offer/answer, raccolta dei candidati ICE, server STUN/TURN per l'attraversamento NAT, SRTP per la crittografia, SCTP per i canali dati. L'impostazione della connessione MoQ è più semplice — un handshake QUIC seguito da messaggi subscribe/publish.
Flessibilità dei codec. La negoziazione dei codec di WebRTC è strettamente accoppiata al protocollo. MoQ è agnostico rispetto ai codec a livello di trasporto — il formato multimediale è gestito dal livello applicativo (MSF, LOC o container personalizzati).
Dipendenza dal browser. Entrambi i protocolli dipendono dalle API del browser per la distribuzione basata su web. WebRTC ha supporto universale nei browser. MoQ dipende da WebTransport, che Safari ha aggiunto solo in beta (26.4, febbraio 2026) e non ha ancora rilasciato in versione stabile. Questo divario si sta chiudendo ma resta una considerazione pratica per MoQ oggi.
Quando WebRTC resta la scelta migliore
WebRTC resta la scelta migliore quando:
- È necessaria una vera comunicazione bidirezionale in tempo reale (videochiamate, conferencing)
- È richiesta la compatibilità browser su tutte le piattaforme, incluso Safari/iOS
- Il caso d'uso è peer-to-peer o in piccoli gruppi senza necessità di distribuzione su scala CDN
- La maturità degli strumenti e degli SDK collaudati in produzione è importante
Cosa cambia MoQ rispetto a SRT
SRT (Secure Reliable Transport) eccelle nel trasferimento di contenuti multimediali di alta qualità dal punto A al punto B su reti imprevedibili. Offre crittografia AES, recupero dalla perdita di pacchetti tramite ARQ (Automatic Repeat Request) e supporto per il bitrate adattivo. SRT è ampiamente adottato per i flussi di lavoro di ingest (telecamere verso studi, produzione remota verso encoder cloud) ma serve anche come protocollo di distribuzione punto-a-punto — come dimostra DJing Stream.
MoQ e SRT servono scopi sovrapposti ma diversi:
SRT è punto-a-punto; MoQ è publish/subscribe. SRT collega un mittente a un ricevente. MoQ supporta nativamente la distribuzione uno-a-molti attraverso i relay.
SRT garantisce la consegna; MoQ può scegliere di non farlo. Il meccanismo ARQ di SRT ritrasmette ogni pacchetto perso, il che assicura una consegna senza perdite ma aggiunge latenza in caso di perdita di pacchetti. MoQ può essere configurato per l'affidabilità parziale — scartando oggetti in ritardo invece di ritrasmettarli — il che è meglio per la distribuzione live sensibile alla latenza ma inaccettabile quando ogni campione conta.
SRT è maturo e diffuso; MoQ è emergente. SRT gode di un ampio supporto hardware e software (OBS, vMix, FFmpeg, Haivision, ogni encoder importante). MoQ ha implementazioni in fase iniziale.
Quando SRT resta la scelta migliore
SRT è la scelta più forte quando:
- Il caso d'uso è punto-a-punto (dalla sorgente all'encoder, dall'encoder all'origine, o distribuzione diretta alla sede)
- La consegna senza perdite conta più della latenza minima assoluta
- Il flusso di lavoro coinvolge apparecchiature di produzione broadcast professionali che già parlano SRT
- La fedeltà audio a livello di bit non è negoziabile
Caso di studio: WeSpeakSports — commento live dei tifosi tramite WebRTC
WeSpeakSports è una piattaforma di commento audio live dei tifosi. I tifosi creano o ascoltano commenti audio in tempo reale durante le partite sportive — calcio, basket, rugby, F1 e altro. L'app è disponibile su iPhone, iPad, Mac (Apple Silicon) e Vision Pro.
L'architettura attuale utilizza WebRTC per lo streaming audio. Un tifoso commentatore trasmette l'audio dal proprio dispositivo, e gli ascoltatori lo ricevono in tempo quasi reale. L'audio è di qualità vocale, non di qualità musicale — l'intelligibilità e la bassa latenza contano molto più della fedeltà da audiofilo.
MoQ avrebbe senso per WeSpeakSports?
In teoria, sì — è un'ottima corrispondenza per questo caso d'uso. WeSpeakSports è una trasmissione audio live 1-a-molti con aspettative di tempo reale. Questa è precisamente la lacuna che MoQ è progettato per colmare: troppi ascoltatori per una scalabilità efficiente con WebRTC, ma troppo sensibile alla latenza per HLS.
Il modello publish/subscribe di MoQ si adatta naturalmente all'architettura di WeSpeakSports: un commentatore pubblica una traccia audio, gli ascoltatori si iscrivono ad essa, e i relay CDN gestiscono la distribuzione. Questo sarebbe più semplice e più economico da scalare rispetto all'infrastruttura SFU di WebRTC.
In pratica, non ancora — per due ragioni concrete:
- Safari/iOS è quasi pronto, ma non ancora. WeSpeakSports richiede iOS 18.0. Il pubblico principale dell'app è su iPhone. MoQ nel browser dipende da WebTransport, che Apple ha aggiunto nella beta di Safari 26.4 ma non ha ancora rilasciato in versione stabile. Anche per le app iOS native, non esiste oggi un SDK MoQ pronto per la produzione per le piattaforme Apple. Lo stack WebRTC su iOS (tramite il supporto WebKit integrato di Apple e SDK di terze parti maturi) è collaudato e funziona.
- Maturità. WeSpeakSports è un prodotto rilasciato con utenti reali. Sostituire il livello di trasporto da un protocollo collaudato a una specifica pre-1.0 sarebbe prematuro. WebRTC gestisce la scala attuale. Il costo della complessità della migrazione non è giustificato dalla base utenti attuale.
Quando rivalutare
MoQ diventa degno di valutazione per WeSpeakSports quando:
- WebTransport viene rilasciato in una versione stabile di Safari — il che è ormai imminente data la beta di Safari 26.4 — e emerge un SDK MoQ nativo maturo per iOS/macOS
- La base utenti cresce a una scala in cui i costi SFU di WebRTC diventano un vincolo significativo
- L'infrastruttura di relay MoQ è disponibile da almeno due fornitori CDN con impegni SLA
- La specifica di trasporto MoQ raggiunge lo stato di RFC
A quel punto, MoQ potrebbe semplificare significativamente l'architettura di distribuzione e ridurre il costo per ascoltatore. Il modello commentatore-relay-ascoltatori è un caso d'uso da manuale per MoQ. È una questione di tempistica, non di idoneità.
Caso di studio: DJing Stream — audio DJ di qualità broadcast tramite SRT
DJing Stream è un'app macOS progettata per un caso d'uso molto specifico: trasmettere audio di qualità broadcast dalla postazione di un DJ all'impianto audio di un locale, via internet, in tempo reale. L'architettura privilegia la qualità audio sopra ogni altra cosa.
Lo stack attuale utilizza SRT per la distribuzione in tempo reale — consegnando audio stereo PCM a 24 bit a 48 kHz (circa 2,3 Mbps) dal Mac del DJ all'impianto audio del locale. Per una distribuzione più ampia verso ascoltatori remoti, l'audio può anche essere servito tramite HLS con audio lossless. L'intera filosofia progettuale è che l'audio di un DJ merita la stessa fedeltà di un collegamento via cavo fisico.
MoQ avrebbe senso per DJing Stream?
No — e questa non è una questione di tempistica. MoQ è fondamentalmente disallineato con i requisiti di DJing Stream.
Ecco perché:
- La consegna senza perdite non è negoziabile. DJing Stream invia audio PCM non compresso. Ogni campione conta. Il meccanismo di ritrasmissione ARQ di SRT garantisce che ogni pacchetto arrivi — aggiungerà latenza in caso di perdita piuttosto che scartare l'audio. Il modello di affidabilità parziale di MoQ, che è uno dei suoi vantaggi chiave per il video live, è esattamente il compromesso sbagliato per l'audio di qualità broadcast. Un frame audio scartato è un difetto udibile su un impianto audio da club. Questo non è accettabile.
- Il punto-a-punto è il caso d'uso principale. Lo scenario principale di DJing Stream è un DJ che trasmette a un locale. Questo è un collegamento punto-a-punto, non un problema di distribuzione. Il modello publish/subscribe con relay di MoQ aggiunge complessità senza beneficio per questa topologia.
- Nessun requisito del browser. DJing Stream è un'app macOS nativa che si collega all'hardware del locale. Non c'è nessun browser web nel circuito. Il divario WebTransport/Safari è irrilevante, ma lo è anche il principale vantaggio di MoQ della distribuzione nativa nel browser.
- SRT è già lo strumento giusto. SRT è stato progettato esattamente per questo: trasporto affidabile, crittografato e a bassa latenza di contenuti multimediali di alta qualità su reti imprevedibili. È collaudato nella produzione broadcast. Ogni encoder e media server lo supporta. Sostituire SRT con MoQ per il collegamento di distribuzione DJ-locale significherebbe rinunciare alla consegna garantita senza alcun guadagno significativo.
- HLS Lossless gestisce il lato distribuzione. Per il caso d'uso secondario di distribuzione verso un pubblico più ampio (ascoltatori web), HLS con codec audio lossless è collaudato e compatibile con ogni dispositivo. La tolleranza alla latenza per gli ascoltatori remoti è più alta rispetto al locale stesso, quindi il modello basato su segmenti di HLS è perfettamente adeguato.
Quando rivalutare
Onestamente? Probabilmente mai per il collegamento principale DJ-locale. SRT fa esattamente ciò di cui DJing Stream ha bisogno, e gli obiettivi progettuali di MoQ (distribuzione scalabile con perdita di qualità accettabile in caso di congestione) sono opposti agli obiettivi progettuali di DJing Stream (consegna senza perdite di ogni campione audio).
L'unico scenario in cui MoQ potrebbe diventare rilevante per DJing Stream è se il prodotto si espandesse verso la distribuzione su larga scala per i fan con aspettative di fedeltà inferiori — per esempio, trasmettere una versione compressa di un DJ set a migliaia di ascoltatori simultaneamente. Anche in quel caso, HLS o LL-HLS resterebbero probabilmente più semplici e più ampiamente compatibili.
Il quadro decisionale
Dopo aver ricercato MoQ in modo approfondito — le bozze IETF, i commenti del settore da Broadpeak, Red5, BlogGeek.me, webrtcHacks, Meetecho e Nanocosmos — ecco la regola decisionale più semplice che posso offrire:
Mantieni il tuo stack attuale quando
- Il tuo prodotto è in produzione oggi e il tuo protocollo attuale funziona
- Hai bisogno del supporto browser Safari/iOS oggi (WebTransport è nella beta di Safari ma non ancora stabile)
- Qualche secondo di latenza è accettabile (→ HLS/LL-HLS)
- Hai bisogno di consegna garantita senza perdite (→ SRT)
- Hai bisogno di vera comunicazione bidirezionale in tempo reale (→ WebRTC)
Inizia a valutare MoQ quando
- La latenza ultra-bassa verso grandi audience è fondamentale per il valore del tuo prodotto (scommesse live, aste, esperienze sincronizzate su secondo schermo)
- Controlli l'intero stack dall'ingest alla riproduzione e puoi assorbire un nuovo protocollo
- I costi di scalabilità di WebRTC stanno diventando un vero problema di business
- Stai costruendo un nuovo prodotto che non sarà rilasciato prima della fine del 2026 o del 2027
- Puoi accettare che la specifica potrebbe ancora cambiare prima di raggiungere lo stato di RFC
Tieni d'occhio MoQ se
- Gestisci infrastruttura CDN o relay (MoQ è progettato per funzionare con le CDN HTTP/3)
- Costruisci prodotti per lo sport live con requisiti di sincronizzazione
- Vuoi convergere ingest e distribuzione su un unico protocollo
- Sei frustrato dall'overhead di riconfezionamento dell'ingest RTMP/SRT → distribuzione HLS
In conclusione
MoQ è reale, è ben progettato e affronta limitazioni genuine nel panorama attuale dei protocolli di streaming. L'ambizione — un unico protocollo sia per il tempo reale che per il quasi-tempo reale, dall'ingest alla distribuzione, con supporto relay su scala CDN — è convincente.
Ma l'ambizione non è la stessa cosa della maturità. La specifica non è finalizzata. Safari ha WebTransport in beta ma non ancora in una versione stabile. I deployment in produzione sono limitati agli early adopter. L'ecosistema di SDK, strumenti e conoscenza operativa che rende HLS, WebRTC e SRT affidabili in produzione semplicemente non esiste ancora per MoQ.
Per la maggior parte dei prodotti di streaming in produzione nel 2026, MoQ è qualcosa da monitorare — non qualcosa da adottare. Quando maturerà, e succederà, ha il potenziale di semplificare architetture che attualmente uniscono più protocolli con livelli di riconfezionamento nel mezzo.
Fino ad allora: se HLS funziona per la tua distribuzione, mantienilo. Se WebRTC funziona per le tue esigenze in tempo reale, mantienilo. Se SRT funziona per i tuoi collegamenti punto-a-punto, mantienilo. Il protocollo migliore è quello che è in produzione e funziona, non quello più entusiasmante su una slide di conferenza.
Fonti
- IETF MoQ Transport draft (v17, marzo 2026): datatracker.ietf.org/doc/draft-ietf-moq-transport
- IETF MoQ Charter: datatracker.ietf.org/group/moq/about
- moq-lite draft: ietf.org/archive/id/draft-lcurley-moq-lite-02.html
- IETF Blog — What's the deal with MoQ: ietf.org/blog/moq-overview
- BlogGeek.me — MOQ: How it will redefine realtime media: bloggeek.me/moq-redefine-realtime
- webrtcHacks — WebRTC vs. MoQ by Use Case: webrtchacks.com/webrtc-vs-moq-by-use-case
- RFC 8216 (HLS): rfc-editor.org/rfc/rfc8216.html
- Apple HLS overview: developer.apple.com/streaming
- WebKit — Announcing Interop 2026 (WebTransport commitment): webkit.org/blog/17818/announcing-interop-2026
- MoQ CDN — Open-source MoQ CDN relay infrastructure: moqcdn.net
- Erik Herz on LinkedIn: linkedin.com/in/erikherz