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

In web development, the core goal of real‑time communication is to achieve low‑latency, bidirectional or unidirectional dynamic data exchange between the browser and server, unlike the traditional HTTP request‑response model. Below is a detailed analysis of the most common real‑time communication technologies on the web, covering concepts, principles, characteristics, applicable scenarios, and comparative selection.

1. WebSocket

1.1 Core Concepts

WebSocket is the “infrastructure” for real‑time communication on the web, providing a full‑duplex long connection and lightweight frame transmission, solving the limitations of HTTP’s one‑way short connections and becoming the preferred technology for instant messaging, collaborative tools, real‑time monitoring, etc. It complements HTTP rather than replaces it—HTTP is suitable for request‑response scenarios (e.g., page loading), while WebSocket is suited for bidirectional real‑time interaction.

1.2 Principle Overview

The WebSocket workflow consists of three stages: handshake protocol upgrade, data‑frame transmission, and connection management.

1. Handshake stage: based on HTTP upgrade protocol

WebSocket connection establishment relies on an HTTP request that upgrades the connection to WebSocket:

GET /ws HTTP/1.1
Host: example.com
Connection: Upgrade  # tells the server this is an upgrade request
Upgrade: websocket   # core: request to upgrade to WebSocket protocol
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==  # random string for server validation
Sec-WebSocket-Version: 13  # client‑supported version (must be 13)

2. Server response confirmation

The server validates the request and returns:

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=  # calculated from the client key

3. Connection established

After a successful handshake, the underlying TCP connection is reused and subsequent communication no longer follows HTTP.

2. Data Transmission: Efficient frame‑based communication

WebSocket uses binary frames to transmit data. The frame header contains only opcode, mask, payload length, and payload, typically 2‑14 bytes, resulting in very high transmission efficiency.

Opcode 0x01: text data; 0x02: binary data; 0x08: connection close.

Mask: client‑sent data must be masked; server responses are not masked.

Advantages: supports text, images, video streams, etc., with latency as low as a few milliseconds.

3. Connection Management: Keep‑alive and termination

Heartbeat keep‑alive : WebSocket includes a Ping/Pong mechanism. The server periodically sends a Ping frame; the client must reply with a Pong frame. If no Pong is received within the timeout, the connection is considered dead and closed.

Active close : Either side can send an opcode 0x08 close frame, after which both sides close the TCP connection.

4. Why the handshake needs protocol upgrade

WebSocket does not completely abandon HTTP; it uses HTTP’s handshake to negotiate a protocol switch, allowing the client and server to agree to use WebSocket while preserving compatibility with existing network infrastructure (firewalls, proxies, etc.).

Compatibility with existing network environments.

Low‑cost establishment of a long‑connection consensus.

4.2 Relationship between WebSocket and HTTP

WebSocket and HTTP are complementary: HTTP handles the initial request‑response, while WebSocket handles subsequent bidirectional data streams.

Application Scenarios

Instant messaging tools (e.g., web WeChat, enterprise WeChat, online customer service).

Real‑time collaboration tools (e.g., online documents, collaborative editing).

Financial market updates (stock, futures, etc.).

Online games (e.g., multiplayer snake).

Real‑time monitoring systems (IoT device telemetry, server performance).

Bullet‑screen systems for video sites.

2. Server‑Sent Events (SSE)

2.1 Core Concepts

SSE (Server‑Sent Events) is a server‑to‑client one‑way real‑time push technology based on HTTP, designed for scenarios where the server actively pushes updates to the client.

The core of SSE is a persistent HTTP long connection that allows the server to push data at any time without the client repeatedly polling.

Advantages include native automatic reconnection, simple API ( EventSource), and low implementation cost for unidirectional push scenarios.

2.2 Principle Overview

The SSE workflow consists of three stages: connection establishment, data push, and reconnection.

1. Connection establishment : The client creates an EventSource object, which sends an HTTP GET request with the header Accept: text/event-stream. The server responds with:

HTTP/1.1 200 OK
Content-Type: text/event-stream; charset=utf-8  # core: identifies SSE stream
Cache-Control: no-cache  # prevent caching
Connection: keep-alive  # keep HTTP long connection
Access-Control-Allow-Origin: *  # CORS if needed

Data is sent as UTF‑8 text lines terminated by a double newline ( \n\n).

Typical event formats:

# Default event
data: You have a new message

# Multi‑line data
data: Line 1

data: Line 2


# Custom event name
event: orderStatus
id: 10086
data: Order shipped


# Heartbeat (comment line)
: keep‑alive comment

2.3 Reconnection Mechanism

SSE automatically attempts reconnection after a disconnection (default 3 seconds, exponential back‑off up to 30 seconds). The client also sends the Last-Event-ID header so the server can resend missed events.

2.4 Application Scenarios

AI assistants with streaming output.

Real‑time notification systems (e.g., social app alerts).

Log or status dashboards (CI/CD pipelines, server metrics).

News or information feeds.

Monitoring data displays.

Collaboration status synchronization.

3. WebRTC

3.1 Core Concepts

WebRTC (Web Real‑Time Communication) is a browser‑native standard that enables peer‑to‑peer (P2P) connections for audio, video, and arbitrary data without requiring third‑party plugins.

Key features include:

Direct P2P communication, reducing latency and server bandwidth.

Native browser APIs such as getUserMedia and RTCPeerConnection.

Low latency (typically 100‑200 ms) using UDP (or TCP fallback).

Built‑in security: all media streams are encrypted via SRTP.

3.2 Principle Overview

The WebRTC workflow consists of three phases: signaling, P2P connection establishment, and media/data transmission.

1. Signaling : Clients exchange Session Description Protocol (SDP) offers/answers and ICE candidates via a signaling server to discover each other’s network addresses.

2. P2P connection establishment : ICE (Interactive Connectivity Establishment) tries host candidates, then STUN‑derived public addresses, and finally TURN relays if direct connectivity fails.

3. Media stream transmission :

Media streams are captured with getUserMedia (or getDisplayMedia for screen sharing) and sent through RTCPeerConnection using RTP.

Data can be sent via RTCDataChannel, which supports both reliable (TCP‑like) and unreliable (UDP‑like) modes.

3.3 Application Scenarios

Real‑time audio/video calls (video conferences, telemedicine, remote interviews).

Screen sharing and remote assistance.

Interactive live streaming with low‑latency audience participation.

Browser‑based P2P file transfer.

Real‑time multiplayer games using RTCDataChannel.

IoT device video monitoring.

4. Polling

Polling is the early solution for web real‑time communication, where the client periodically sends HTTP requests to fetch the latest data. It is simple and highly compatible but incurs high server load and limited real‑time performance. Modern applications prefer WebSocket or SSE, using polling only when compatibility or low‑cost requirements dictate.

5. Comparison and Selection Guidance

WebSocket, SSE, WebRTC, and polling are the four core real‑time communication technologies on the web. The following table compares their technical characteristics, advantages, disadvantages, and suitable scenarios.

5.1 Technical Feature Comparison

(image omitted)

5.2 Core Advantages and Disadvantages

WebSocket – Full‑duplex, low latency, supports any data type; requires long‑connection management and higher implementation complexity.

SSE – Simple server‑push, automatic reconnection, low server cost; only unidirectional, no binary support, IE incompatibility.

WebRTC – P2P communication reduces server bandwidth, ultra‑low latency for audio/video, supports binary data; complex NAT traversal, signaling required, browser compatibility nuances.

Polling – Simplest, 100 % compatibility; poor real‑time performance and high bandwidth waste.

5.3 Scenario Comparison

(image omitted)

6. Advanced Topics

6.1 High Concurrency and Scalability

When connections reach tens of thousands, a single server cannot handle the load; load balancing and connection sharding become necessary.

6.2 Data Security and Authentication

Real‑time communication often carries sensitive data; authentication and encrypted transport (TLS, SRTP) are required.

6.3 Network Stability and Reliability

Weak networks cause disconnections; keep‑alive mechanisms (WebSocket Ping/Pong, SSE comment frames, WebRTC oniceconnectionstatechange) and exponential back‑off reconnection strategies improve reliability.

6.4 Cross‑Origin and Browser Compatibility

WebSocket and SSE support CORS via HTTP headers; SSE only works with GET requests and lacks IE support; WebRTC requires signaling server CORS handling but media streams are P2P; polling relies on standard CORS or JSONP.

7. References

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

SSE documentation: https://developer.mozilla.org/en-US/docs/Web/API/EventSource

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