WebRTC vs WebSocket: media e data channel peer-to-peer contro un socket client-server, perché WebRTC ha comunque bisogno di signaling, più webhook vs WebSocket e HTTP vs WebSocket.
Un WebSocket mantiene una connessione bidirezionale tra un browser e il tuo server, e ogni messaggio passa da quel server. WebRTC collega i browser direttamente tra loro per audio, video e dati arbitrari, cifrati con DTLS e SRTP. Spesso si usano insieme: un WebSocket trasporta i messaggi di signaling che avviano la chiamata WebRTC.
WebRTC e WebSocket a confronto
Domanda
WebRTC
WebSocket
Chi parla con chi
Da browser a browser (peer to peer)
Da browser a server
Pensato per
Audio, video, condivisione schermo, dati tra peer
Messaggi tra app e server
Configurazione
Offer, answer e candidati ICE tramite il tuo signaling
Un solo handshake HTTP Upgrade
Opzioni di consegna
I data channel possono essere ordinati o no, affidabili o no
Ordinata e affidabile
Cifratura
Sempre attiva (DTLS, SRTP)
Solo con wss://
Serve un server
Per il signaling, e relay TURN quando i peer non si connettono direttamente
Sì, è l'altro capo
Scegli cosa stai costruendo nello strumento qui sotto e ti indica la tecnologia adatta, con il motivo. Copre anche le due domande che spesso si confondono con questa: i webhook, che vanno da server a server, e le semplici richieste HTTP.
Scegli la funzionalità più vicina alla tua.
Leggi quale tecnologia è adatta e perché.
Scorri fino alle sezioni di codice per uno schema di signaling e un esempio di data channel.
Usa le due tabelle verso la fine per i confronti con webhook e HTTP.
Non usare WebRTC per inviare aggiornamenti dal tuo server. Lì il server non è un peer, e un WebSocket o un event stream è molto più semplice.
Metti in conto un relay TURN prima di lanciare le chiamate. Alcune reti bloccano le connessioni dirette tra peer, e allora tutto il media passa dal relay che paghi tu.
Tieni il server di signaling stupido: inoltra solo offer, answer e candidati. MDN descrive il payload come una scatola nera che il server non ha bisogno di capire.
Per un gioco o un feed di cursori live tra peer, apri il data channel con ordered impostato a false e maxRetransmits a 0, così un pacchetto in ritardo non blocca mai quelli più recenti.
Domande frequenti
WebRTC sostituisce i WebSocket?
No. WebRTC non ha un modo integrato perché due browser si trovino, quindi serve comunque un canale per scambiare i messaggi di configurazione. Un WebSocket è la scelta abituale, anche se MDN fa notare che va bene qualsiasi trasporto.
WebRTC può inviare semplici dati, non solo video?
Sì. RTCPeerConnection.createDataChannel() apre un canale per dati testuali o binari tra peer, e la sua API è volutamente simile a quella di WebSocket, con send() e un evento message.
Qual è la differenza tra un webhook e un WebSocket?
Un webhook è una richiesta HTTP che un server invia a un URL su un altro server quando si verifica un evento, poi la connessione termina. Un WebSocket è una connessione che resta aperta così un browser e un server possono continuare a parlarsi.
Un WebSocket è più veloce di HTTP?
Per tanti messaggi piccoli di solito sì, perché l'handshake avviene una volta sola e ogni messaggio successivo evita gli header di richiesta. Per caricare una pagina o un file, il normale HTTP è lo strumento giusto e sfrutta la cache.
WebRTC è peer to peer anche con molte persone in chiamata?
Ogni connessione è tra due peer, quindi una mesh completa cresce rapidamente man mano che le persone si uniscono. Molti prodotti per chiamate più grandi instradano il media tramite un server che inoltra gli stream, che resta fuori dall'API WebRTC del browser.
Perché WebRTC ha comunque bisogno di un server
Prima che due browser possano connettersi, ciascuno deve conoscere la descrizione di sessione dell'altro, un'offer e un'answer SDP, e un elenco di possibili indirizzi di rete chiamati candidati ICE. WebRTC lascia a te la consegna di quei messaggi.
Una volta scambiati, ICE prova i candidati, con STUN che aiuta ogni lato a scoprire il proprio indirizzo pubblico. Se nessun percorso diretto funziona, il traffico ripiega su un server TURN che lo inoltra. Da lì il media scorre tra i peer, non attraverso il tuo server di signaling.
Webhook vs WebSocket
Risolvono problemi diversi. Un webhook permette a un servizio come un provider di pagamenti o un host di codice di dire al tuo backend che è successo qualcosa, inviando una richiesta HTTP a un URL che hai registrato. Niente resta aperto e non è coinvolto alcun browser.
Un WebSocket mantiene una linea attiva verso il browser di un utente. Uno schema comune li usa entrambi: un webhook dice al tuo server che un ordine è stato pagato, e il tuo server invia quella notizia alla pagina aperta del cliente tramite un WebSocket.
HTTP vs WebSocket
Il semplice HTTP è richiesta e risposta: il client chiede, il server risponde, e le risposte GET possono essere messe in cache da browser e CDN. È la scelta predefinita giusta per pagine, file e la maggior parte delle chiamate API.
Un WebSocket parte come richiesta HTTP, poi cambia protocollo con una risposta 101 e resta aperto. Usalo solo quando il server deve inviare dati che il client non ha chiesto, o i messaggi sono così frequenti che il costo di ogni richiesta conta.
Configurazione WebRTC tramite un WebSocket
Chiamante: crea un'offer e un data channel
Il WebSocket inoltra solo i messaggi di configurazione. L'URL STUN è un segnaposto per il server che scegli.
Chiamato: rispondi e ricevi il canale
L'altro lato riceve il canale tramite l'evento datachannel invece di crearlo.
Un canale non ordinato e senza ritrasmissioni per lo stato di gioco
maxRetransmits e maxPacketLifeTime non possono essere impostati entrambi; scegline uno.
Webhook vs WebSocket in sintesi
Webhook vs WebSocket
Domanda
Webhook
WebSocket
Chi si connette
Un server chiama un altro server
Un client tiene aperta una linea verso un server
Durata
Una richiesta HTTP per evento
Aperto finché uno dei due lati non lo chiude
Direzione
Dal mittente al destinatario
In entrambe le direzioni
Uso tipico
Eventi di pagamenti, repository o moduli
Chat live, dashboard, presenza
HTTP vs WebSocket in sintesi
HTTP vs WebSocket
Domanda
Richiesta HTTP
WebSocket
Chi avvia un messaggio
Sempre il client
Entrambi i lati
Connessione
Richiesta, poi risposta
Aggiornata con 101, poi resta aperta
Cache
Le risposte GET e HEAD sono memorizzabili in cache
Nessuna
Schemi URL
ws:// (porta 80), wss:// (porta 443)
Videochiamata tra due persone
WebRTC, con un WebSocket per il signaling
Audio e video devono andare direttamente tra i partecipanti con poco ritardo. Un piccolo server WebSocket passa solo offer, answer e candidati durante la configurazione.
Chat di gruppo in una web app
WebSocket
I messaggi vanno salvati, moderati e inviati a tutti nella stanza, quindi stanno comunque sul tuo server. Un socket per utente è la soluzione semplice.
Inviare un file grande al browser di un amico
Data channel WebRTC
Un data channel affidabile e ordinato sposta i byte peer to peer, così il tuo server non salva né inoltra mai il file, a meno che serva TURN.
Mosse veloci in un gioco a due
Data channel WebRTC, non ordinato
Con ordered disattivato e nessuna ritrasmissione, un aggiornamento di posizione perso viene saltato invece di bloccare quelli più recenti. Se ti serve un server arbitro, usa invece un WebSocket verso di esso.
Il provider di pagamenti conferma un ordine
Webhook
Il server del provider chiama un URL sul tuo server quando il pagamento va a buon fine. Nessun browser è coinvolto e niente deve restare aperto.
Caricare una pagina prodotto e i suoi dati
Semplice HTTP
Richiesta e risposta bastano, e le risposte GET possono essere messe in cache. Una connessione persistente aggiungerebbe costi senza benefici.