Card 07/ 10
WebSocket vs SSE vs WebRTC on the Wire
Each sends a message differently and fails differently, which decides which one a network will let through.
WebSocket, server-sent events and WebRTC differ on the wire in ways that decide where each works: SSE is plain HTTP, WebSocket is HTTP that turns into something else, and WebRTC leaves HTTP and TCP behind for UDP. The further a protocol moves from ordinary HTTP, the more proxies, load balancers and firewalls it has to get past.
| Question | WebSocket | Server-sent events | WebRTC |
|---|---|---|---|
| How it starts | GET with Upgrade, answered by 101 | GET answered with text/event-stream | Offer and answer by signalling, then ICE checks |
| Who may send | Both sides | Server only | Both peers, directly |
| One message on the wire | Binary frame, masked from the client | Text lines ending in an empty line | SRTP or SCTP inside DTLS, on UDP |
| After a drop | Application reconnects and catches up | Browser reconnects with Last-Event-ID | ICE restart through signalling |
| Through a proxy or load balancer | Needs upgrade support and long idle timeouts | Works if responses are not buffered | Media bypasses them; may need TURN through a firewall |
| Data it carries | Text or binary | UTF-8 text only | Audio, video, text or binary |
WebSocket through infrastructure. Every proxy and load balancer on the path must understand the Upgrade request and pass the connection through afterwards. Most current ones do, some only when configured. All of them still count the connection as idle when no frames pass.
SSE through infrastructure. It is an HTTP response, so anything that carries HTTP carries it. The usual fault is a proxy that collects the response before forwarding it, which holds every event until the buffer fills. Sending Cache-Control: no-cache, and disabling buffering for that route, avoids it.
WebRTC through infrastructure. Media does not pass through the web servers at all, so they never see the load. The obstacles are NATs and firewalls instead, which is what TURN is for.
The rule. Choose by the conversation first: server to many readers, SSE; both directions through your servers, WebSocket; device to device with media, WebRTC. Then check the path, because a protocol the network does not carry well is the wrong one whatever it was designed for.
← → move through sections and cards