WebRTC vs WebSocket (en webhooks, en HTTP) | We.Inc
WebRTC vs WebSocket: peer-to-peer media en datakanalen tegenover een client-server-socket, waarom WebRTC toch signaling nodig heeft, plus webhook vs WebSocket en HTTP vs WebSocket.
Een WebSocket houdt één tweerichtingsverbinding open tussen een browser en uw server, en elk bericht gaat via die server. WebRTC verbindt browsers rechtstreeks met elkaar voor audio, video en willekeurige data, versleuteld met DTLS en SRTP. Ze worden vaak samen gebruikt: een WebSocket vervoert de signaling-berichten die het WebRTC-gesprek opzetten.
WebRTC en WebSocket vergeleken
Vraag
WebRTC
WebSocket
Wie praat met wie
Browser naar browser (peer-to-peer)
Browser naar server
Gemaakt voor
Audio, video, scherm delen, data tussen peers
Berichten tussen app en server
Opzet
Offer, answer en ICE candidates via uw eigen signaling
Eén HTTP Upgrade-handshake
Afleveropties
Datakanalen kunnen geordend of ongeordend zijn, betrouwbaar of niet
Geordend en betrouwbaar
Versleuteling
Altijd aan (DTLS, SRTP)
Alleen met wss://
Heeft een server nodig
Voor signaling, en TURN-relays als peers niet direct kunnen verbinden
Ja, die is de andere kant
Kies hieronder in de hulp wat u bouwt, en die noemt de technologie die past, met de reden erbij. Ook de twee vragen die mensen hiermee door elkaar halen komen aan bod: webhooks, die van server naar server gaan, en gewone HTTP-requests.
Kies de functie die het dichtst bij de uwe ligt.
Lees welke technologie past en waarom.
Scroll naar de codesecties voor een schets van signaling en een voorbeeld van een datakanaal.
Gebruik de twee tabellen onderaan voor de vergelijkingen met webhooks en HTTP.
Grijp niet naar WebRTC om updates vanaf uw server te pushen. De server is daar geen peer, en een WebSocket of een event stream is veel eenvoudiger.
Reken op een TURN-relay voordat u gesprekken lanceert. Sommige netwerken blokkeren directe peerverbindingen, en dan loopt alle media via de relay waarvoor u betaalt.
Houd de signaling-server dom: hij stuurt alleen offers, answers en candidates door. MDN beschrijft de payload als een black box die de server niet hoeft te begrijpen.
Open voor een game of een live cursorfeed tussen peers het datakanaal met ordered op false en maxRetransmits op 0, zodat een laat pakket nooit nieuwere blokkeert.
Veelgestelde vragen
Vervangt WebRTC WebSockets?
Nee. WebRTC heeft geen ingebouwde manier waarop twee browsers elkaar vinden, dus u hebt nog steeds een kanaal nodig om de setupberichten uit te wisselen. Een WebSocket is de gebruikelijke keuze, al merkt MDN op dat elk transport werkt.
Kan WebRTC gewone data versturen, niet alleen video?
Ja. RTCPeerConnection.createDataChannel() opent een kanaal voor tekst of binaire data tussen peers, en de API lijkt bewust sterk op die van WebSocket, met send() en een message-event.
Wat is het verschil tussen een webhook en een WebSocket?
Een webhook is een HTTP-request die de ene server naar een URL op een andere server stuurt wanneer er iets gebeurt, waarna de verbinding eindigt. Een WebSocket is een verbinding die open blijft zodat een browser en server met elkaar kunnen blijven praten.
Is een WebSocket sneller dan HTTP?
Bij veel kleine berichten meestal wel, omdat de handshake maar één keer gebeurt en elk volgend bericht de request-headers overslaat. Voor het laden van een pagina of bestand is gewone HTTP het juiste gereedschap, en dat profiteert van caching.
Is WebRTC peer-to-peer, ook met veel mensen in een gesprek?
Elke verbinding loopt tussen twee peers, dus een volledig mesh groeit snel naarmate er mensen bijkomen. Veel grotere belproducten sturen media in plaats daarvan via een server die streams doorstuurt, en die valt buiten de WebRTC-browser-API zelf.
Waarom WebRTC toch een server nodig heeft
Voordat twee browsers kunnen verbinden, moet elk de sessiebeschrijving van de ander leren kennen, een SDP-offer en -answer, plus een lijst met mogelijke netwerkadressen, de zogeheten ICE candidates. WebRTC laat het bezorgen van die berichten aan u over.
Zodra ze uitgewisseld zijn, probeert ICE de candidates, waarbij STUN elke kant helpt zijn publieke adres te ontdekken. Werkt geen enkele directe route, dan valt het verkeer terug op een TURN-server die het doorgeeft. Daarna stroomt de media tussen de peers, niet via uw signaling-server.
Webhook vs WebSocket
Deze lossen verschillende problemen op. Met een webhook kan een dienst zoals een betaalprovider of een codehost uw backend laten weten dat er iets is gebeurd, door een HTTP-request te sturen naar een URL die u hebt geregistreerd. Er blijft niets open en er komt geen browser aan te pas.
Een WebSocket houdt een live lijn open naar de browser van een gebruiker. Een veelgebruikt patroon combineert beide: een webhook vertelt uw server dat een bestelling is betaald, en uw server pusht dat nieuws vervolgens via een WebSocket naar de open pagina van de klant.
HTTP vs WebSocket
Gewone HTTP is request en response: de client vraagt, de server antwoordt, en GET-responses kunnen door browsers en CDN's worden gecachet. Het is de juiste standaard voor pagina's, bestanden en de meeste API-calls.
Een WebSocket begint als een HTTP-request, wisselt dan van protocol met een 101-response en blijft open. Kies ervoor alleen als de server data moet sturen waar de client niet om vroeg, of als berichten zo vaak heen en weer gaan dat de overhead per request ertoe doet.
WebRTC-setup via een WebSocket
Beller: maak een offer en een datakanaal
De WebSocket stuurt alleen setupberichten door. De STUN-URL is een placeholder voor de server die u kiest.
Gebelde: antwoord en ontvang het kanaal
De andere kant krijgt het kanaal via het datachannel-event in plaats van het zelf aan te maken.
Een ongeordend kanaal zonder herhaalpogingen voor gamestatus
maxRetransmits en maxPacketLifeTime kunnen niet allebei worden ingesteld; kies er één.
Webhook vs WebSocket in één oogopslag
Webhook vs WebSocket
Vraag
Webhook
WebSocket
Wie verbindt
De ene server roept een andere server aan
Een client houdt een lijn naar een server open
Levensduur
Eén HTTP-request per event
Open tot een van beide kanten hem sluit
Richting
Van verzender naar ontvanger
Beide kanten op
Typisch gebruik
Events van betalingen, repository's of formulieren
Live chat, dashboards, aanwezigheid
HTTP vs WebSocket in één oogopslag
HTTP vs WebSocket
Vraag
HTTP-request
WebSocket
Wie begint een bericht
Altijd de client
Elke kant
Verbinding
Request, dan response
Geüpgraded met 101, blijft daarna open
Caching
GET- en HEAD-responses zijn cachebaar
Geen
URL-schema's
ws:// (poort 80), wss:// (poort 443)
Videogesprek tussen twee mensen
WebRTC, met een WebSocket voor signaling
Audio en video moeten met weinig vertraging rechtstreeks tussen de bellers gaan. Een kleine WebSocket-server geeft tijdens de setup alleen de offer, answer en candidates door.
Groepschat in een webapp
WebSocket
Berichten moeten worden opgeslagen, gemodereerd en naar iedereen in de ruimte gestuurd, dus ze horen sowieso op uw server. Eén socket per gebruiker is de eenvoudige oplossing.
Een groot bestand naar de browser van een vriend sturen
WebRTC-datakanaal
Een betrouwbaar, geordend datakanaal verplaatst de bytes peer-to-peer, zodat uw server het bestand nooit opslaat of doorgeeft, tenzij TURN nodig is.
Snelle zetten in een game voor twee spelers
WebRTC-datakanaal, ongeordend
Met ordered uit en zonder retransmits wordt een verloren positie-update overgeslagen in plaats van nieuwere op te houden. Hebt u een scheidsrechter-server nodig, gebruik dan in plaats daarvan een WebSocket daarheen.
Betaalprovider bevestigt een bestelling
Webhook
De server van de provider roept een URL op uw server aan wanneer de betaling slaagt. Er komt geen browser aan te pas en er hoeft niets open te blijven.
Een productpagina en de bijbehorende data laden
Gewone HTTP
Request en response zijn alles wat u nodig hebt, en GET-responses kunnen worden gecachet. Een blijvende verbinding zou kosten toevoegen zonder voordeel.