Protocolli per i servizi multimediali

I servizi multimedialiUn servizio multimediale trasporta uno o più media (testo, suono, immagini, video) come segnali digitali. Si classifica in streaming (si consuma mentre arriva, serve un playout buffer) e bulk transfer (si usa solo a file completo); poi in stored, live e real-time (ritardo sotto 150 ms) e in interattivo o no. I requisiti si esprimono con bit-rate, latenza, jitter, tasso d'errore, complessità e fedeltà: ogni servizio pesa questi parametri in modo diverso (il video in streaming vuole poco jitter e tollera errori, un file vuole zero errori e tollera latenza). Aumentare solo il bit-rate non basta.Servizi multimediali e loro requisiti → hanno requisiti molto diversi (una videochiamata vuole latenza minima, un film vuole continuità e qualità, un file vuole zero errori). Nessun protocollo li soddisfa tutti: per questo esistono molte combinazioni di protocolli a livelli diversi. Questa nota presenta i protocolli di trasporto, quelli pensati per il tempo reale (famiglia RTP, WebRTC, SIP) e le pile protocollari tipiche per videochiamata, streaming live e video on demand. I numeri di gestione dello streaming adattativo sono in Streaming adattativo e DASHPer non stallare serve $R_C\le S$ (tasso di codifica non superiore al throughput), ma $R_C$ si controlla e $S$ no. Se $S<R_C$ la latenza cresce, i buffer dei router si riempiono e si perdono pacchetti; né il drop brutale né il transcoding in rete sono praticabili, la scalabilità (SVC) è parziale. La soluzione dominante è lo streaming adattativo (ABR) tirato dal client su HTTP: il video è diviso in $N$ segmenti da $T_S$ secondi, ciascuno in $K$ livelli di bit-rate $R_C(k)$ descritti nell'MPD; il client sceglie il livello $q(n)$ di ogni segmento con $T_D=\frac{T_SR_C(q)}{S_n}$. Il playout buffer $B(t)$ (in secondi di video) segue $B'=\frac S{R_C}$ durante lo stallo e $B'=\frac S{R_C}-1$ durante la riproduzione; si parte dopo $L$ segmenti e dopo uno stallo si riprende con $M$ nuovi segmenti. La QoE si modella con $J=\sum_n\lambda_1k_n-\lambda_2\lvert k_n-k_{n-1}\rvert-\phi(\Delta_n)-\lambda_3T_{ST}$. Gli algoritmi ABR sono basati su throughput, buffer o ibridi; MPEG-DASH standardizza MPD e segmenti, non il client.Streaming adattativo e DASH →, le metriche (ritardo, jitter, perdite) in Metriche e prestazioni di rete per i servizi multimedialiUna rete è una pila di livelli: ogni livello offre un servizio al superiore tramite un'interfaccia e dialoga con il livello pari con un protocollo; il pacchetto di un livello è il payload del livello inferiore ($\mathrm{PDU}n=\mathrm{PCI}n+\mathrm{SDU}n$), con efficienza $\eta=\frac{|\mathrm{SDU}n|}{|\mathrm{PDU}n|}$. Metriche: bit-rate $R_0$ (livello fisico) $\ge$ throughput $S$ $\ge$ goodput (throughput a lungo termine a livello applicazione). Ritardo nodale $d=d{proc}+d{queue}+d{trans}+d{prop}$ con $d{trans}=\frac LR$ e $d_{prop}=\frac xc$; ritardo end-to-end = somma dei nodali; jitter = variabilità del ritardo; BDP $=S\cdot\mathrm{RTT}$ (con il bit-rate minimo del percorso). Affidabilità: nel canale binario simmetrico $\mathrm{PER}=1-(1-\varepsilon)^L$ e $P(\ell)=\binom L\ell\varepsilon^\ell(1-\varepsilon)^{L-\ell}$; codici di canale $R=\frac kn$, parità, Hamming, interleaving per i burst; perdite per errori o congestione, $\mathrm{PDR}=1-P_{\text{LOSS}}$.Metriche e prestazioni di rete per i servizi multimediali →.

1. Il servizio di trasporto

L'interfaccia tra le applicazioni multimediali e la rete è il livello di trasporto: le applicazioni sono costruite usando le sue primitive. Il servizio sfruttato è un canale per flussi di bit, end-to-end e tra processi:

• canale per flusso di bit: la sorgente non si preoccupa della lunghezza del flusso (può solo dare indicazioni su come frammentarlo);
• end-to-end: da sorgente a destinazione; l'applicazione non definisce il percorso, solo chi sono trasmettitore e ricevitore;
• per processi: identifica un preciso processo su un preciso host come sorgente e come destinazione (tramite le porte, Livello di trasporto - porte e multiplexingIl livello di trasporto (transport layer) offre la comunicazione logica end-to-end tra processi applicativi di host diversi, ed è realizzato solo negli host finali, non nei router. Il livello di rete consegna al computer giusto (indirizzo IP), il trasporto consegna al processo giusto (numero di porta di 16 bit, 0-65535). Una porta più un indirizzo IP formano un socket; la quaterna (IP sorgente, porta sorgente, IP destinazione, porta destinazione) identifica una connessione. I servizi sono: comunicazione processo-processo, indirizzamento, incapsulamento/decapsulamento, multiplexing/demultiplexing e, se il protocollo è affidabile, controllo di errore, di flusso e di congestione. I protocolli sono UDP (senza connessione, inaffidabile), TCP (con connessione, affidabile) e SCTP (combina i due).Livello di trasporto - porte e multiplexing →).

Il livello di trasporto somiglia al livello di rete (entrambi danno un canale end-to-end) ma ne differisce: può offrire servizi orientati alla connessione (fase di set up, trasmissione, rilascio; i dati arrivano nell'ordine di invio) o connectionless (nessun set up; i pacchetti sono trasferiti indipendentemente). Nell'architettura di Internet esiste un solo servizio di rete, connectionless: IP. Il trasporto deve mascherare alle applicazioni l'eterogeneità delle reti e, in alcuni casi, i loro difetti (perdite, disordine, congestione), e permette di identificare un processo su un host, mentre il livello di rete offre solo un canale tra host.

Funzioni principali: multiplexing/demultiplexing (più processi sullo stesso host comunicano con processi remoti), concetto di porta, controllo errori. Funzioni opzionali: trasferimento affidabile, controllo di flusso (il mittente non sovraccarica un ricevente specifico), controllo di congestione (non sovraccaricare la rete), connessione (sequenza ordinata di pacchetti).

1.1 TCP e UDP

Dettagli in TCP - connessione, affidabilità e controllo di flussoTCP (Transmission Control Protocol) è il protocollo di trasporto con connessione e affidabile: trasforma il servizio senza connessione e inaffidabile di IP in un flusso di byte ordinato, senza errori né duplicati. La connessione si apre con l'handshake a tre vie (SYN, SYN+ACK, ACK) e si chiude con tre o quattro segmenti (FIN). I byte sono numerati: il numero di sequenza è quello del primo byte del segmento, il numero di ACK (cumulativo) è il prossimo byte atteso. Il mittente può inviare $\min(\text{rwnd},\text{cwnd})$ byte non ancora confermati; rwnd (finestra del ricevitore, in un campo di 16 bit) è il controllo di flusso. L'errore si gestisce con checksum, ACK, timeout di ritrasmissione (RTO) e ritrasmissione rapida dopo tre ACK duplicati. Per usare tutto il canale la finestra deve valere almeno il prodotto banda-ritardo (BDP); il throughput massimo è $\text{MSS}\cdot W_{\max}/\text{RTT}$.TCP - connessione, affidabilità e controllo di flusso →, TCP - controllo di congestioneLa congestione nasce quando collegamenti veloci alimentano un collegamento lento: le code dei router si riempiono, i pacchetti si perdono o ritardano e, nel caso peggiore, la rete collassa (quasi solo ritrasmissioni). TCP controlla la propria finestra di congestione cwnd con il feedback delle perdite (timeout o tre ACK duplicati): slow start (cwnd raddoppia a ogni RTT) fino alla soglia ssthresh, poi congestion avoidance (+1 MSS per RTT); a ogni perdita ssthresh = W/2. Le varianti si distinguono per come reagiscono ai tre dupACK: Tahoe riparte da cwnd = 1 dopo la ritrasmissione rapida; Reno usa il fast recovery (ssthresh = cwnd/2, cwnd = ssthresh + 3, +1 per ogni altro dupACK); NewReno gestisce gli ACK parziali e recupera più perdite nella stessa finestra; SACK riscontra i blocchi ricevuti e ritrasmette solo quello che manca.TCP - controllo di congestione → e Protocollo UDPUDP (User Datagram Protocol) è il protocollo di trasporto senza connessione e inaffidabile: rispetto a IP aggiunge soltanto la comunicazione processo-processo (numeri di porta) e un controllo d'errore facoltativo. L'intestazione è di soli 8 byte (porta sorgente, porta destinazione, lunghezza, checksum). Il checksum copre pseudo-intestazione (indirizzi IP, protocollo 17, lunghezza), intestazione e dati, ed è il complemento a uno della somma a 16 bit; se vale 0 significa "non calcolato", e un risultato 0 si trasmette come 0xFFFF. UDP non ha connessione, numeri di sequenza, controllo di flusso, di errore né di congestione: si sceglie per i messaggi brevi (DNS, DHCP, RIP, SNMP) e per le applicazioni in tempo reale, dove conta non aggiungere ritardo.Protocollo UDP →. TCP offre molte funzioni che lo rendono più oneroso (e, per esempio, un pacchetto perso blocca la consegna di quelli successivi finché non è ritrasmesso). UDP è leggero: senza connessione, best-effort. Nei servizi multimediali spesso si preferisce decidere a livello applicazione quali funzioni servono e come realizzarle: per esempio in una videochiamata la bassa latenza conta più del controllo degli errori (un frame in ritardo è inutile), oppure il controllo di flusso deve rispettare la semantica del servizio.

Vantaggi di UDP per lo streaming: bassa latenza (adatto al real-time); flessibilità nel controllo di flusso (gestito dall'applicazione); controllo d'errore, se serve, fatto dall'applicazione. Servizi più adatti a TCP: trasferimento in blocco di file multimediali (FTP), e-mail e messaggi multimediali, messaggi di controllo.

2. La famiglia RTP

Insieme di protocolli progettati per applicazioni multimediali in tempo reale; flessibili e adattabili a diverse condizioni di rete; molto usati in VoIP, videoconferenza e streaming.

2.1 RTP e SRTP

RTP (Real-time Transport Protocol) è la base per il trasporto di dati multimediali in tempo reale (audio, video). Funziona in teoria su qualunque protocollo di trasporto, ma in pratica quasi sempre su UDP. Supporta il multicast (inoltro dello stesso flusso a più destinatari usando un gruppo multicast come indirizzo). Non garantisce la QoS. Funzioni:

• sequenziamento (sequence number): permette di rilevare i pacchetti persi (buchi nella numerazione) e di rimettere in ordine;
• timestamp: sincronizzazione tra flussi e calcolo del jitter; il timestamp conta i campioni (ticks di clock del segnale) e non i secondi;
• identificazione del tipo di payload (payload type): quale codec c'è dentro.

Approfondimento: l'header RTP (RFC 3550, non nelle slide). Ha 12 byte fissi: versione (2 bit), padding (1), estensione (1), numero di sorgenti contribuenti CC (4), marker (1), payload type (7), numero di sequenza (16), timestamp (32), SSRC (identificatore della sorgente di sincronizzazione, 32). Per una voce PCM a 8 kHz con pacchetti da 20 ms il numero di sequenza aumenta di 1 a ogni pacchetto e il timestamp di $160$ (160 campioni).

SRTP (Secure RTP) fornisce cifratura, autenticazione e integrità a RTP (e RTCP); è compatibile con RTP standard e ha overhead basso.

Esempio (overhead). Voce G.711 a 64 kbit/s con pacchetti da 20 ms: payload $160$ byte; header RTP $12$ + UDP $8$ + IP $20$ = $40$ byte; pacchetto IP di $200$ byte, efficienza $\eta=\frac{160}{200}=0{,}8$, bit-rate a livello IP $\frac{200\cdot8}{0{,}02}=80$ kbit/s. Con un codec a 8 kbit/s (payload $20$ byte ogni 20 ms) la stessa intestazione da 40 byte dà $\eta=\frac{20}{60}=33\%$ e $\frac{60\cdot8}{0{,}02}=24$ kbit/s: gli header triplicano il flusso. Perciò per le voci compresse l'overhead conta moltissimo (Metriche e prestazioni di rete per i servizi multimedialiUna rete è una pila di livelli: ogni livello offre un servizio al superiore tramite un'interfaccia e dialoga con il livello pari con un protocollo; il pacchetto di un livello è il payload del livello inferiore ($\mathrm{PDU}n=\mathrm{PCI}n+\mathrm{SDU}n$), con efficienza $\eta=\frac{|\mathrm{SDU}n|}{|\mathrm{PDU}n|}$. Metriche: bit-rate $R_0$ (livello fisico) $\ge$ throughput $S$ $\ge$ goodput (throughput a lungo termine a livello applicazione). Ritardo nodale $d=d{proc}+d{queue}+d{trans}+d{prop}$ con $d{trans}=\frac LR$ e $d_{prop}=\frac xc$; ritardo end-to-end = somma dei nodali; jitter = variabilità del ritardo; BDP $=S\cdot\mathrm{RTT}$ (con il bit-rate minimo del percorso). Affidabilità: nel canale binario simmetrico $\mathrm{PER}=1-(1-\varepsilon)^L$ e $P(\ell)=\binom L\ell\varepsilon^\ell(1-\varepsilon)^{L-\ell}$; codici di canale $R=\frac kn$, parità, Hamming, interleaving per i burst; perdite per errori o congestione, $\mathrm{PDR}=1-P_{\text{LOSS}}$.Metriche e prestazioni di rete per i servizi multimediali →).

2.2 RTCP

RTCP (RTP Control Protocol) serve per il monitoraggio della qualità del servizio e il controllo della sessione. Tipi di pacchetti: Sender Report (SR), Receiver Report (RR), Source Description (SDES), Application-specific (APP) (più BYE in RFC 3550). Permettono: feedback sulla qualità della trasmissione (perdite, jitter, ritardo, osservati dai ricevitori), sincronizzazione tra flussi (audio e video con lo stesso orologio), identificazione dei partecipanti, controllo della sessione. (Per non appesantire la rete i rapporti RTCP sono limitati a una piccola frazione, circa il 5%, della banda della sessione.) Ricevitori e mittenti usano i rapporti per adattare il bit-rate di codifica.

2.3 RTSP e RTMP

• RTSP (Real Time Streaming Protocol): protocollo testuale (simile a HTTP) che funziona come un "telecomando di rete" per sessioni di streaming, con metodi come SETUP, PLAY, PAUSE, TEARDOWN. Non trasporta i dati multimediali: usa RTP/RTCP. In declino per lo streaming consumer (web e mobile), sostituito da protocolli su HTTP (HLS, DASH), ancora usato in nicchie come la videosorveglianza IP.
• RTMP (Real-Time Messaging Protocol): sviluppato da Adobe per Flash, per streaming live e on demand. Basato su TCP con connessioni persistenti a bassa latenza; handshake, multiplexing di più stream, spezzettamento dei messaggi (chunking), comandi per il controllo della riproduzione (porta tipica 1935, spesso bloccata dalle reti aziendali).

3. WebRTC

WebRTC (Web Real-Time Communication) è un framework per applicazioni di comunicazione in tempo reale, basato su tecnologia open-source e su uno standard aperto (W3C e IETF). Permette la comunicazione peer-to-peer in tempo reale tra browser e applicazioni mobili. Non è un singolo protocollo:

• una suite di API JavaScript standardizzate per cattura audio e video (microfono, webcam), connessione peer-to-peer, scambio di dati;
• una collezione di protocolli esistenti: RTP/SRTP per i media, DTLS per la sicurezza (cifratura obbligatoria), ICE, STUN e TURN per la connettività peer-to-peer, cioè per attraversare NAT e firewall (NAT e indirizzi privatiUna rete privata (intranet) usa il protocollo TCP/IP con indirizzi privati ($10.0.0.0/8$, $172.16.0.0/12$, $192.168.0.0/16$), riutilizzabili da intranet diverse ma da non instradare in Internet: i router di bordo scartano i pacchetti con indirizzi privati. Per accedere a Internet servono un proxy applicativo (uno per applicazione) o il NAT (Network Address Translation): un router che traduce indirizzi privati in indirizzi pubblici di un pool, con una tabella NAT e un'associazione dinamica per sessione. Il NAT tradizionale è outbound: Basic NAT traduce solo l'IP (uno a uno, quindi servono tanti indirizzi pubblici quante le sessioni contemporanee), NAPT traduce anche la porta ([IP privato, porta] $\to$ [IP pubblico, porta del NAT]) e permette a molte sessioni di condividere un solo IP pubblico. Il Twice NAT permette sessioni anche dall'esterno, con un DNS interno e associazioni statiche.NAT e indirizzi privati →).

Usi: videoconferenze, cloud gaming, telechirurgia, webinar. È il framework dei sistemi real-time moderni (Meet, Zoom, Teams, WhatsApp).

4. SIP

SIP (Session Initiation Protocol, IETF RFC 3261) è un protocollo di segnalazione per sessioni multimediali: serve a iniziare, modificare e terminare sessioni in tempo reale (VoIP, videochiamate). Testuale (simile a HTTP), indipendente dal trasporto (può usare TCP o UDP), scalabile e flessibile, facilmente estensibile e interoperabile. Architettura con User Agent (gli endpoint: telefoni o applicazioni), Proxy server (inoltra richieste e risposte), Registrar server (localizza gli utenti), Redirect server. In una chiamata tipica: INVITE $\to$ risposta provvisoria (squillo) $\to$ 200 OK $\to$ ACK, poi i media viaggiano via RTP, infine BYE. SIP non trasporta i media.

5. Pile protocollari per i servizi

L'eterogeneità dei requisiti si traduce in pile diverse.

Videochiamata e videoconferenza.

• Applicazione: H.264/AVC (video), AAC (audio);
• Sessione: WebRTC (browser) oppure SIP;
• Trasporto: RTP/RTCP su UDP; controllo: RTCP; rete: IP.
• Motivi: codec efficienti e compatibili per il tempo reale; WebRTC gestisce sessione e segnalazione tra peer; RTP su UDP è ottimizzato per bassa latenza; i problemi di attraversamento NAT richiedono soluzioni specifiche (ICE, STUN, TURN).

Streaming live.

• Applicazione: H.264/AVC o H.265/HEVC (video), AAC (audio);
• Streaming: HLS (HTTP Live Streaming) o MPEG-DASH su CMAF (Common Media Application Format);
• Trasporto dei segmenti: HTTP su TCP; rete: IP.
• Motivi: HLS e DASH sono adattivi alle variazioni di banda; HTTP/TCP è affidabile e compatibile con CDN e firewall.

Video on demand.

• Codifica: H.264, H.265, VP9, AV1 (video), AAC (audio);
• Streaming: MPEG-DASH o HLS; distribuzione tramite CDN; trasporto HTTP su TCP; rete IP.
• Motivi: qualità e compressione efficienti; DASH/HLS con più bit-rate; la CDN è una rete distribuita di server che fa caching distribuito, bilanciamento del carico e instradamento intelligente e usa HTTP per soddisfare le richieste del protocollo di streaming (Caching, autenticazione, tipi MIME e URI in HTTPLa cache HTTP riusa le risposte senza contattare il server finche' sono fresche (Cache-Control: max-age, Expires; in mancanza una durata euristica pari a circa il 10% del tempo trascorso da Last-Modified) e, quando sono scadute, le rivalida con una richiesta condizionale (If-None-Match con ETag, If-Modified-Since con Last-Modified) alla quale il server risponde 304 senza corpo; no-store vieta di memorizzare, no-cache obbliga a rivalidare, private esclude le cache condivise. L'autenticazione usa 401 con WWW-Authenticate e la risposta Authorization: Basic (base64 di utente:password, solo sopra TLS) o Digest (hash con nonce); 407 vale per i proxy. Content-Type porta il tipo MIME (tipo/sottotipo; parametri come charset e boundary), Accept e gli altri header Accept-* guidano la negoziazione. Un URI (RFC 3986) e' scheme://userinfo@host:porta/percorso?query#frammento, con percent-encoding %HH per i byte non ammessi e regole per risolvere i riferimenti relativi.Caching, autenticazione, tipi MIME e URI in HTTP →).

Perché HTTP per lo streaming (Livello applicazione - HTTPIl livello applicazione è il più alto della pila: offre servizi all'utente con una connessione logica tra le due applicazioni e riceve servizi solo dal trasporto (DNS, HTTP, e-mail, FTP). Il Web (WWW, nato al CERN nel 1989) è un servizio client-server distribuito di pagine collegate da ipertesti; ogni pagina ha un URL protocollo://host:porta/percorso. HTTP: il client manda una richiesta, il server una risposta, su TCP (server sulla porta 80, client su una porta temporanea); senza stato. Messaggi di testo (riga di richiesta o di stato, intestazioni, riga vuota, corpo), metodi GET, POST, HEAD, PUT, DELETE, codici di stato 2xx-5xx. Una pagina con N oggetti incorporati richiede 2(N+1) RTT con connessioni non persistenti e (N+2) RTT con connessione persistente (trascurando la trasmissione). I cookie danno memoria al protocollo: Set-Cookie nella risposta, Cookie nelle richieste, file nel browser e base di dati nel sito. Un proxy (web cache) tiene le copie delle risposte recenti: meno carico sul server, meno traffico, meno ritardo.Livello applicazione - HTTP →, HTTP 1.1 - connessioni persistenti, Content-Length e chunked transfer encodingHTTP/1.1 (oggi RFC 9110 e 9112) rende la connessione persistente di default (si chiude solo con "Connection: close"), rende obbligatorio l'header Host (virtual hosting) e introduce i nuovi metodi PUT, DELETE, OPTIONS, TRACE, Expect: 100-continue, richieste di intervalli (206) e Transfer-Encoding: chunked; con la connessione persistente il client deve sapere dove finisce ogni risposta: lunghezza del corpo nell'ordine HEAD/1xx/204/304 senza corpo, Transfer-Encoding chunked, Content-Length, altrimenti fino alla chiusura; il chunked divide il corpo in blocchi preceduti dalla lunghezza in esadecimale, termina con un chunk 0 e un trailer facoltativo, e si decodifica contando i byte dichiarati (non cercando CRLF).HTTP 1.1 - connessioni persistenti, Content-Length e chunked transfer encoding →):

1. attraversa NAT e firewall senza configurazioni speciali (porte web standard 80 e 443; i protocolli legacy come RTMP usano porte non standard, per esempio 1935, e UDP, spesso bloccati nelle reti aziendali);
2. compatibilità con l'infrastruttura web esistente: i segmenti video sono trattati come normali file (le immagini JPG), quindi cache e CDN danno scalabilità a costi bassi;
3. facilità di implementazione, stateless: il server risponde a richieste GET isolate e lo stato sta nel client (modello pull), mentre RTSP/RTMP sono stateful (il server ricorda lo stato di ogni client: costoso in RAM e CPU) e push.

QUIC e HTTP/3 (WebSocket, QUIC e HTTP-3HTTP e' richiesta e risposta, quindi poco adatto a notifiche e dati in tempo reale (polling, long polling, SSE); WebSocket (RFC 6455) apre con un handshake HTTP/1.1 Upgrade (Sec-WebSocket-Key a 16 byte casuali in Base64, risposta 101 con Sec-WebSocket-Accept = Base64 di SHA-1 di chiave piu' GUID fisso) un canale bidirezionale persistente sulla stessa connessione TCP, con frame di 2-14 byte di intestazione (FIN, opcode, MASK, lunghezza su 7, 16 o 64 bit, chiave di mascheramento obbligatoria dal client al server) e messaggi di testo, binari, close, ping e pong. QUIC (RFC 9000) e' un protocollo di trasporto sopra UDP con TLS 1.3 integrato, flussi indipendenti (niente head-of-line blocking fra flussi), connection ID che permettono di cambiare rete, handshake in 1 RTT e ripresa in 0 RTT; HTTP/3 (RFC 9114) mappa HTTP su QUIC con un flusso per richiesta e QPACK per gli header, ed e' annunciato con Alt-Svc.WebSocket, QUIC e HTTP-3 →). Il limite principale di TCP per il video è l'head-of-line (HOL) blocking: TCP è un flusso di byte ordinato, se un pacchetto si perde la consegna all'applicazione si ferma finché è ritrasmesso: un errore nell'audio blocca anche i frame video già arrivati. QUIC (su UDP) ricostruisce l'affidabilità nello user-space e offre: stream indipendenti (audio e video su stream separati: una perdita non blocca l'altro), 0-RTT (connessioni quasi istantanee, meno ritardo di avvio), connection migration (usa un Connection ID indipendente dall'indirizzo IP: il passaggio Wi-Fi/mobile non interrompe il video), evoluzione rapida (il controllo di congestione passa dal kernel all'applicazione). HTTP/3 = HTTP su QUIC: oggi la base di DASH/HLS, passa i firewall sulla porta standard UDP 443. Paradosso della latenza: con link sempre più veloci il tempo di trasmissione $\frac LR$ crolla, ma il RTT resta dominato da propagazione (limite fisico) e accodamento, quindi gli handshake ripetuti e i round-trip "vuoti" costano molto.

Le CDN portano i contenuti agli edge, vicino all'utente, con quattro vantaggi: (1) riduzione della latenza (meno propagazione), (2) scalabilità e gestione dei picchi (flash crowd: per esempio la finale di Champions League), (3) affidabilità e ridondanza (se un nodo edge cade l'utente passa al più vicino; nessun single point of failure), (4) risparmio di banda nel backbone (il traffico pesante resta nelle reti di accesso locali).

Dualità del multimedia su Internet. Bulk transfer (integrità assoluta, latenza non critica); streaming VoD e live (convergenza verso DASH/HLS su HTTP/3, segmenti e CDN); real-time interattivo (latenza minima, dominio di WebRTC/UDP). I protocolli "legacy" (SIP, RTSP, RTMP) declinano, sostituiti da soluzioni più facili da scalare e compatibili con firewall e NAT: tutto ciò che non è interattività pura si sposta su HTTP.

5.1 Altri esempi

(Tabella di approfondimento nelle slide.)

Domande d'esame

1. Perché per le videochiamate si preferisce UDP a TCP? Traccia: un frame in ritardo è inutile, quindi conta più la bassa latenza della consegna affidabile; TCP ritrasmette e blocca i dati successivi (HOL blocking), aumentando ritardo e jitter; con UDP il controllo di flusso e di errore, se serve, lo decide l'applicazione (RTP aggiunge numeri di sequenza e timestamp).

2. Quali funzioni aggiunge RTP a UDP? Traccia: sequenziamento (rilevare perdite e riordinare), timestamp (sincronizzazione e stima del jitter), identificazione del tipo di payload; RTCP aggiunge feedback e sincronizzazione; SRTP cifratura e autenticazione.

3. Quale pila protocollare si usa per il video on demand e perché HTTP? Traccia: codec (H.264, H.265, AV1), MPEG-DASH o HLS, CDN, HTTP su TCP (o HTTP/3 su QUIC), IP. HTTP passa NAT e firewall, usa cache e CDN (i segmenti sono file normali), è stateless (il server risponde a GET isolate, il client decide la qualità).