Choosing the Right Real‑Time Communication Tech for Web Apps: WebSocket, SSE, WebRTC & Polling

Overview

Real‑time communication on the web replaces the classic request‑response model with low‑latency, bidirectional or unidirectional data streams between browsers and servers. The four primary techniques are WebSocket, Server‑Sent Events (SSE), WebRTC, and traditional polling.

WebSocket

Core concept : WebSocket establishes a full‑duplex, long‑lived TCP connection that bypasses HTTP after an initial upgrade handshake, making it suitable for chat, collaborative editing, live dashboards, and other high‑frequency interactions.

Handshake (HTTP upgrade) :

GET /ws HTTP/1.1
Host: example.com
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

Server response:

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

After the handshake the underlying TCP socket is reused for all subsequent frames.

Frame format (binary header 2‑14 bytes): 0x01 – text data 0x02 – binary data 0x08 – connection close

Connection management :

Heartbeat via Ping / Pong frames – the server sends Ping, the client must reply with Pong; missing replies trigger a timeout and close.

Active close – either side can send a close frame (opcode 0x08) to terminate the connection.

Why upgrade from HTTP? The initial HTTP request traverses existing firewalls and proxies, then the protocol switches to a lightweight binary stream that can pass through the same network path.

Server‑Sent Events (SSE)

Core concept : SSE creates a persistent, unidirectional HTTP connection where the server continuously pushes UTF‑8 text events to the client. It is ideal when only server‑to‑client updates are required.

Handshake (client request):

GET /events HTTP/1.1
Host: example.com
Accept: text/event-stream
Cache-Control: no-cache
Connection: keep-alive

Server must respond with:

HTTP/1.1 200 OK
Content-Type: text/event-stream; charset=utf-8
Cache-Control: no-cache
Connection: keep-alive
Access-Control-Allow-Origin: *

Event format – each event ends with a double newline ( \n\n).

# default event
data: You have a new message


event: orderStatus
data: Order shipped
id: 10086

#: keep‑alive comment line (ignored)

Reconnection : The browser automatically retries after 3 seconds, increasing up to 30 seconds. The Last-Event-ID header is sent on reconnection so the server can resend missed events.

WebRTC

Core concept : Web Real‑Time Communication enables peer‑to‑peer audio, video, and arbitrary data streams directly between browsers without plugins. Only the signaling phase (exchange of SDP and ICE candidates) requires a server.

Key APIs : getUserMedia – captures microphone and camera streams. RTCPeerConnection – creates the P2P connection, handles ICE negotiation, and transports media via RTP. RTCDataChannel – bi‑directional data channel for arbitrary binary or text payloads.

Signaling flow (out‑of‑band server) :

Client A creates an SDP offer and sends it to the signaling server.

Client B receives the offer, creates an SDP answer, and returns it.

Both peers gather ICE candidates (host, STUN‑derived, TURN) and exchange them via the signaling server.

Each side selects the best candidate (direct, STUN, or TURN) and establishes a direct P2P connection.

Media transmission :

Capture with getUserMedia → MediaStream.

Encode (e.g., H.264/VP8 video, OPUS audio) and send via RTCPeerConnection over RTP.

Render with <video> or <audio> elements.

Use RTCDataChannel for chat, file transfer, or game commands; supports reliable (TCP‑like) and unreliable (UDP‑like) modes.

Polling

Polling is the earliest technique where the client periodically issues HTTP GET requests to fetch the latest state. It is trivial to implement and works everywhere, but incurs high latency and unnecessary bandwidth usage.

Technical comparison & selection guidance

WebSocket – best for high‑frequency bidirectional communication (chat, collaborative editing, live dashboards). Low latency, supports any payload type, but requires long‑lived connections and more server resources.

SSE – ideal when the server only pushes updates (notifications, logs, news feeds). Simpler server implementation and automatic reconnection, but limited to unidirectional text data and lacks binary support.

WebRTC – chosen for ultra‑low‑latency audio/video, P2P file transfer, or real‑time gaming. Reduces server bandwidth, but adds complexity (NAT traversal, signaling, browser compatibility).

Polling – fallback when none of the above are available (e.g., legacy environments). Simple but inefficient for real‑time workloads.

Advanced considerations

Scalability : Tens of thousands of concurrent connections require load balancers, connection sharding, or stateless gateways (e.g., NGINX, HAProxy, or cloud‑native WebSocket services).

Security & authentication : Use token‑based authentication (JWT), enforce TLS (wss://, https://), and validate the Origin header for WebSocket/SSE.

Network stability : Implement heartbeats (WebSocket Ping/Pong, SSE comment frames, WebRTC oniceconnectionstatechange) and exponential‑backoff reconnection strategies to survive intermittent networks.

Cross‑origin & browser compatibility :

WebSocket and SSE honor CORS via Access-Control-Allow-Origin.

WebRTC signaling must be CORS‑compatible; media streams themselves are not subject to CORS.

Polling works in all browsers; JSONP can be used for legacy GET‑only scenarios.

IE lacks native WebSocket and SSE; libraries such as Socket.IO (WebSocket fallback) or polyfills can provide compatibility.

References

WebSocket API Specification: https://www.w3.org/TR/websockets/

Server‑Sent Events (EventSource) MDN documentation: https://developer.mozilla.org/en-US/docs/Web/API/EventSource

WebRTC Specification: https://www.w3.org/TR/webrtc/