© 2026 febogamedev.com. Created with ❤️ using WordPress and Kubio

WebRTC: scopri come funziona la comunicazione interattiva real-time

WebRTC è una delle principali tecnologie utilizzate sul Web per realizzare applicazioni di comunicazione real-time, come videochiamate, videoconferenze, condivisione dello schermo e collaborazione online. In questa dispensa analizzeremo come WebRTC utilizzi SDP e un sistema di signaling per configurare la sessione, per poi affidarsi a ICE, STUN e TURN per individuare un percorso di rete utilizzabile anche in presenza di NAT e firewall. Vedremo quindi come audio e video vengano trasportati attraverso RTP e RTCP e protetti tramite SRTP, con DTLS utilizzato nella negoziazione delle chiavi. Approfondiremo infine il WebRTC Data Channel e SCTP, che consentono di scambiare messaggi, comandi, file e dati applicativi con differenti livelli di ordinamento e affidabilità, mostrando perché una comunicazione interattiva richieda un’architettura molto diversa dallo streaming destinato principalmente alla distribuzione verso un grande pubblico.

Protocolli streaming: Comunicazione
interattiva real-time

Schermo interoDownload

Elementi chiave

  • WebRTC (Web Real-Time Communication) = insieme di API e protocolli che permette comunicazioni interattive audio, video e dati con latenza molto bassa.
  • WebRTC ≠ HLS/DASH: WebRTC privilegia interattività e bassa latenza, mentre HLS e DASH privilegiano distribuzione scalabile attraverso HTTP e CDN
  • Signaling = processo attraverso cui gli endpoint scambiano informazioni necessarie per configurare e negoziare una sessione WebRTC.
  • SDP ≠ Signaling Server: SDP descrive i parametri multimediali della sessione, mentre il Signaling Server trasporta le informazioni tra gli endpoint.
  • Modello Offer/Answer → Peer A genera SDP Offer → Signaling Server → Peer B genera SDP Answer → Signaling Server → Peer A.
  • ICE (Interactive Connectivity Establishment) = meccanismo che raccoglie, verifica e seleziona possibili percorsi di connessione tra endpoint attraverso NAT e firewall.
  • STUN (Session Traversal Utilities for NAT) = protocollo che permette di individuare l’indirizzo IP pubblico e la porta osservati attraverso un NAT.
  • TURN (Traversal Using Relays around NAT) = protocollo che consente di inoltrare il traffico attraverso un server relay quando la comunicazione diretta non è possibile.
  • STUN ≠ TURN: STUN aiuta a individuare indirizzi utilizzabili, mentre TURN fornisce un percorso alternativo trasportando effettivamente i dati.
  • ICE Candidates → Host identifica indirizzi locali, Server-Reflexive indirizzi pubblici ottenuti tramite STUN e Relay indirizzi forniti da TURN.
  • Connessione diretta ≠ connessione tramite relay: la prima comunica senza intermediari di inoltro, mentre la seconda utilizza TURN con possibili costi aggiuntivi di latenza e banda.
  • SFU (Selective Forwarding Unit) = media server che riceve e inoltra selettivamente i flussi dei partecipanti, senza necessariamente ricodificarli completamente.
  • SFU ≠ mesh P2P: la SFU centralizza l’inoltro dei flussi, mentre una mesh richiede connessioni individuali tra partecipanti.
  • Trasporto audiovisivo WebRTC → RTP organizza i media, RTCP fornisce feedback, SRTP/SRTCP proteggono la comunicazione e DTLS negozia le chiavi crittografiche.
  • Adattamento WebRTC ≠ ABR HLS/DASH: WebRTC può modificare l’encoding in tempo reale, mentre HLS/DASH selezionano segmenti tra versioni già preparate.
  • NACK ≠ FEC: NACK richiede la ritrasmissione dei pacchetti mancanti, mentre FEC utilizza informazioni ridondanti per ricostruirli senza ritrasmissione.
  • SCTP (Stream Control Transmission Protocol) = protocollo orientato ai messaggi che supporta multistreaming e differenti livelli di affidabilità.
  • SCTP ≠ TCP: SCTP conserva i confini dei messaggi e gestisce più stream indipendenti, mentre TCP presenta un flusso continuo di byte.
  • Multistreaming SCTP → permette di trasportare flussi logici differenti riducendo il rischio che un messaggio ritardato blocchi gli altri stream.
  • Partial Reliability = possibilità di limitare le ritrasmissioni, abbandonando messaggi ormai obsoleti invece di garantirne necessariamente la consegna.
  • WebRTC Data Channel = canale bidirezionale per scambiare dati generici, configurabile con differenti proprietà di ordinamento e affidabilità.
  • Stack Data Channel → Dati → SCTP → DTLS → UDP → IP, combinando trasporto orientato ai messaggi e protezione crittografica.
  • Comunicazione WebRTC → Segnalazione SDP → Ricerca del percorso tramite ICE/STUN/TURN → Protezione della connessione → Trasporto di audio, video e dati.
febogamedev | Novembre 1, 2026 | 11:11 pm
LEZIONE PRECEDENTE
LEZIONE SUCCESSIVA

Vuoi aiutarmi a scrivere articoli come questo?

Contattami!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

No responses yet

Sostieni il progetto

Tutti i materiali che condivido nascono da una convinzione molto semplice: una buona formazione non dovrebbe limitarsi a insegnare quali pulsanti premere, ma aiutare a comprendere le idee, i principi e i processi che stanno dietro agli strumenti.

Per questo dedico una parte significativa del mio tempo a studiare, organizzare e produrre contenuti gratuiti dedicati al multimedia, al design e alla comunicazione visiva. Articoli, lezioni, approfondimenti e risorse che hanno l’obiettivo di rendere accessibili argomenti spesso affrontati in modo frammentario o superficiale.

Questo lavoro richiede però tempo, ricerca e cura. Ogni guida, ogni video, ogni materiale pubblicato gratuitamente è il risultato di molte ore di studio, scrittura e revisione.
Sostenere il progetto attraverso Patreon significa permettermi di continuare a produrre contenuti educativi di qualità, mantenerli accessibili al maggior numero possibile di persone e dedicare più energie alla costruzione di una risorsa che possa essere utile a studenti, professionisti e appassionati.

Se credi che una conoscenza più profonda, rigorosa e consapevole del multimedia abbia valore, il tuo contributo non sostiene soltanto il mio lavoro: aiuta a rendere queste risorse disponibili per tutta la comunità.
Grazie per il supporto e per la fiducia.

PARTECIPA AL PATREON

Patreon è troppo impegnativo?

Puoi sostenermi anche con una donazione libera, senza abbonamento e senza impegno.
Anche un piccolo contributo mi aiuta a continuare a creare giochi, contenuti didattici e materiali gratuiti con più libertà.

Donazione libera
Regala uno strumento utile

Support the project

All the materials I share stem from a very simple conviction: good training should not be limited to teaching which buttons to press, but should help people understand the ideas, principles, and processes behind the tools.

That is why I dedicate a significant portion of my time to researching, organizing, and producing free content focused on multimedia, design, and visual communication—articles, lessons, in-depth analyses, and resources aimed at making accessible topics that are often addressed in a fragmented or superficial way.

However, this work requires time, research, and care. Every guide, video, and piece of material published for free is the result of many hours of study, writing, and revision.
Supporting the project via Patreon enables me to continue producing high-quality educational content, keep it accessible to as many people as possible, and devote more energy to building a resource that benefits students, professionals, and enthusiasts alike.

If you believe that a deeper, more rigorous, and informed understanding of multimedia is valuable, your contribution does more than just support my work: it helps make these resources available to the entire community.
Thank you for your support and trust.

JOIN THE PATREON

Is Patreon too demanding?

You can also support me with a voluntary donation—no subscription or commitment required.

Even a small contribution helps me continue creating games, educational content, and free materials with greater freedom.

voluntary donation
Give a useful tool as a gift

FEBO

Privacy policyCookie policy