Mastering Real-Time Web Communication: WebSocket, SSE, WebRTC & Polling Explained

WebSocket

WebSocket provides a full‑duplex, low‑latency channel over a single TCP connection, complementing HTTP’s request‑response model for real‑time scenarios such as instant messaging, collaborative editing, and live monitoring.

Protocol overview

The client initiates an HTTP GET request with Upgrade: websocket and Sec-WebSocket-Key. The server replies with 101 Switching Protocols and a calculated Sec-WebSocket-Accept. After the handshake the connection is upgraded to a binary‑frame protocol where each frame contains an opcode, mask, payload length and payload. Typical opcodes are 0x01 (text), 0x02 (binary) and 0x08 (close). Ping/Pong frames are used for keep‑alive.

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

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

Typical use cases

Instant messaging and chat applications

Collaborative document editing

Financial market data streaming

Live multiplayer games

Real‑time comment or bullet‑screen systems

Server‑Sent Events (SSE)

SSE is a unidirectional, HTTP‑based mechanism where the server pushes UTF‑8 text events over a persistent text/event-stream connection. The client creates an EventSource object, which automatically issues a GET request with Accept: text/event-stream. The server streams lines such as data:, optionally preceded by event: and id:. Browsers automatically reconnect after a disconnection, sending the last received Last-Event-ID to allow the server to resume the stream.

Protocol overview

Connection establishment : HTTP GET with Accept: text/event-stream.

Data push : Server sends data: … lines terminated by a double newline ( \n\n).

Reconnection : Browser retries automatically; the Last-Event-ID header enables gap‑filling.

GET /service/stream HTTP/1.1
Accept: text/event-stream
Cache-Control: no-cache
Connection: keep-alive

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

id: 10086
event: orderStatus
data: Order shipped

Typical use cases

AI assistants that stream token‑by‑token responses

Real‑time notifications (e.g., new comment alerts)

Live logs, CI/CD pipeline status, or server metrics dashboards

News or financial tickers

Collaborative editing status indicators (e.g., “user is typing”)

WebRTC

Web Real‑Time Communication (WebRTC) enables peer‑to‑peer audio, video, and arbitrary data exchange directly between browsers without plugins. It relies on a signaling phase (exchange of SDP offers/answers and ICE candidates) and then establishes a direct RTP/DTLS media path.

Core steps

Signaling : Clients exchange SDP and ICE information via a signaling server (commonly over WebSocket or HTTP).

ICE (Interactive Connectivity Establishment) : Determines the optimal network path (host, STUN‑derived reflexive, or TURN‑relayed candidates) to traverse NATs and firewalls.

Media/Data transfer : Once the peer connection is established, media streams are sent via RTP and arbitrary data can be sent over RTCDataChannel in reliable or unreliable mode.

// Create a reliable data channel
const pc = new RTCPeerConnection();
const dc = pc.createDataChannel('chat', {ordered: true});

Typical use cases

Video conferencing, online tutoring, remote interviews

Screen sharing and remote assistance

Live interactive streaming with low latency

Browser‑to‑browser file transfer

Real‑time multiplayer games using data channels

IoT device video feeds displayed in a web page

Polling (Short / Long)

Polling simulates real‑time updates by repeatedly sending HTTP requests. Short polling issues frequent requests at fixed intervals, causing high latency and load. Long polling holds a request open until new data is available, then the client immediately issues another request. Polling works everywhere but is generally superseded by WebSocket, SSE, or WebRTC for most real‑time needs.

Technical comparison & selection guidance

WebSocket

Pros: full‑duplex, low latency, binary support.

Cons: requires the server to maintain many long‑lived connections; higher implementation complexity.

SSE

Pros: simple server‑push, automatic reconnection, low server overhead.

Cons: unidirectional, no native binary support, not supported by IE.

WebRTC

Pros: peer‑to‑peer reduces server bandwidth, ultra‑low latency for audio/video, supports data channels.

Cons: complex signaling and NAT traversal, requires STUN/TURN servers, browser quirks.

Polling

Pros: works in any environment, trivial to implement.

Cons: high latency (short polling) or high server load (long polling), bandwidth waste.

Advanced considerations

High concurrency & scaling : WebSocket servers need load‑balancing (sticky sessions) or a message broker; SSE scales better for broadcast‑only scenarios.

Security & authentication : Use token‑based auth (e.g., JWT) during the handshake; all transports support TLS ( wss://, https://).

Connection reliability

WebSocket: implement Ping/Pong heartbeats; close on timeout.

SSE: send comment lines ( :) as keep‑alive.

WebRTC: monitor oniceconnectionstatechange for failed state and renegotiate.

Polling: set a reasonable timeout (e.g., 30 s) and retry immediately.

Reconnection strategies : exponential back‑off, network‑type aware delays using navigator.connection.effectiveType, and data‑gap recovery via Last-Event-ID (SSE) or custom offsets (WebSocket).

CORS & browser compatibility :

WebSocket & SSE: require Access-Control-Allow-Origin during handshake/response.

SSE: only GET requests; authentication often via query parameters.

WebRTC: signaling server must handle CORS; media streams are peer‑to‑peer.

Polling: works with standard CORS or JSONP for legacy browsers.

Reference URLs

https://www.w3.org/TR/websockets/

– WebSocket API Specification (W3C) https://developer.mozilla.org/en-US/docs/Web/API/EventSource – MDN documentation for Server‑Sent Events https://www.w3.org/TR/webrtc/ – WebRTC 1.0 Specification (W3C)