System Design (HLD)WebSockets

WebSockets: Real-Time Bidirectional Communication

LevelIntermediate

Duration75 mins

TopicWebSockets

1 / 5

Full-Duplex Communication

Understanding Full-Duplex: The Foundation of Real-Time Web

Imagine a telephone conversation. Both parties can speak and listen simultaneously—you don't have to wait for the other person to stop talking before you can respond, and they don't have to wait for you. This intuitive model of communication, where data flows freely in both directions at the same time, is full-duplex communication.

Now consider the traditional web: your browser sends a request, waits patiently for the server to respond, and only then can it send another request. This request-response paradigm served us well for decades, but it fundamentally cannot support the instantaneous, bidirectional interactions that modern applications demand—chat messages appearing instantly, stock prices updating in real-time, collaborative editing where you see your colleague's cursor moving as they type.

WebSockets revolutionize web communication by introducing true full-duplex capability. Understanding what full-duplex means, why it matters, and how it differs from traditional communication patterns is essential before diving into WebSocket implementation.

What You Will Learn

By the end of this page, you will understand the fundamental differences between simplex, half-duplex, and full-duplex communication; why HTTP's request-response model is inherently half-duplex; how WebSockets achieve true full-duplex operation at the protocol level; and the architectural implications of full-duplex communication for distributed systems.

Communication Direction Fundamentals

Before understanding full-duplex, we need a clear taxonomy of how communication channels can operate. These categories apply broadly across all communication systems—from radio waves to network protocols—and understanding them provides the conceptual framework for appreciating what WebSockets achieve.

The Three Communication Modes

•Simplex Communication — Data flows in one direction only. Think of a traditional television broadcast: the station transmits, and viewers receive. The viewer cannot send information back through the same channel. In computing, logging systems often use simplex patterns—log producers write events, consumers read them, but the channel is unidirectional.
•Half-Duplex Communication — Data can flow in both directions, but only one direction at a time. This is like a walkie-talkie: you either speak OR listen, never both simultaneously. The classic HTTP request-response cycle is half-duplex—the client sends a complete request, then the server sends a complete response. The channel alternates between them.
•Full-Duplex Communication — Data flows in both directions simultaneously. Like a telephone call, both parties can transmit and receive at the same instant. WebSockets provide full-duplex communication between browser and server, enabling truly interactive applications.

Why does mode matter?

The communication mode fundamentally constrains what applications you can build:

Simplex is efficient when data genuinely flows one way. Metrics collection, event streaming to analytics, and broadcast notifications naturally fit simplex patterns. Implementing bidirectional behavior over simplex requires separate channels for each direction.
Half-duplex works well for transactional interactions where requests naturally precede responses. Web page loading, API calls, and file downloads fit comfortably here. However, half-duplex creates awkward patterns for real-time features—you must either poll repeatedly or simulate push with techniques like long-polling.
Full-duplex is essential when both parties need to initiate communication independently and simultaneously. Chat applications, multiplayer games, collaborative tools, and live dashboards all require the server to push updates without waiting for client requests.

Communication Modes Compared
Mode	Direction	Real-World Analog	Web Example	Best Use Case
Simplex	A → B only	Television broadcast	CDN streaming	One-way data distribution
Half-Duplex	A ↔ B (alternating)	Walkie-talkie	HTTP request-response	Transactional interactions
Full-Duplex	A ⇆ B (simultaneous)	Telephone call	WebSocket connection	Real-time bidirectional apps

The HTTP Half-Duplex Limitation

To understand why WebSockets represent a paradigm shift, we must examine exactly how HTTP's design creates a half-duplex constraint—and why this limitation persists even in HTTP/2 and HTTP/3.

HTTP's fundamental model:

HTTP was designed for document retrieval. A client (browser) requests a resource, the server delivers it, and the transaction completes. This request-response paradigm is inherently client-initiated—the server cannot spontaneously contact the client. The connection exists only to serve the client's request.

HTTP Request-Response Flow
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// Conceptual HTTP communication flow
// Time flows downward →
 
CLIENT                                  SERVER
   |                                       |
   |──── GET /api/messages ─────────────>│|   (Client initiates)
   |                                       |
   |                          Processing...|
   |                                       |
   |<─── 200 OK + JSON ─────────────────── |   (Server responds)
   |                                       |
   |          CONNECTION IDLE              |
   |                                       |
   |──── GET /api/messages ─────────────>│|   (Client must initiate again)
   |                                       |
 
// Key observation: Server CANNOT send data unless client requests it
// This is the fundamental half-duplex limitation of HTTP

The polling problem:

When applications need real-time updates—new chat messages, price changes, notifications—HTTP's client-initiated model forces awkward workarounds:

Short polling: The client repeatedly asks "any updates yet?" every few seconds. This wastes bandwidth, creates server load, and introduces latency (average delay is half the polling interval).

Long polling: The client sends a request and the server holds it open until new data is available. This improves latency but consumes server resources (one thread/connection per waiting client) and still doesn't allow true simultaneous bidirectional communication.

Server-Sent Events (SSE): HTTP allows the server to stream data to the client over a single request. This is simplex (server-to-client only), not full-duplex. The client still needs separate HTTP requests to send data to the server.

HTTP/2 and HTTP/3 Don't Solve This

Many engineers assume HTTP/2's multiplexing enables full-duplex operation. It doesn't. HTTP/2 allows multiple request-response pairs over one TCP connection, but each remains a separate half-duplex transaction. HTTP/3's QUIC transport is similarly multiplexed but still HTTP-semantics bound. Neither protocol allows the server to spontaneously push data without a prior request (Server Push in HTTP/2 is for prefetching resources, not arbitrary bidirectional communication).

Why HTTP-Based Workarounds Fall Short

•Short Polling: Creates massive overhead—repeated headers, connection setup, server processing for "no new data" responses. At scale, this overwhelms infrastructure.
•Long Polling: Ties up server resources (threads, connections, memory) even when no data flows. Hard to scale; difficult to handle multiple simultaneous message types.
•SSE: Only server-to-client. Client-to-server still requires separate HTTP requests. Binary data is awkward; limited browser connection pooling.
•All workarounds add latency: Even the best case has noticeable delay compared to true persistent connections where data flows instantly.

Full-Duplex Architecture Deep Dive

Full-duplex communication at the protocol level requires specific architectural characteristics that differentiate it fundamentally from request-response patterns. Understanding these characteristics reveals why WebSockets work the way they do.

Characteristic 1: Persistent Connection

Full-duplex communication requires a persistent, long-lived connection between parties. Unlike HTTP where connections may be closed after each transaction, a full-duplex channel remains open for the duration of the interaction—potentially minutes, hours, or even days.

This persistence is essential because:

Either party can initiate transmission at any moment
There's no "request" to signal when the server should prepare to respond
State is maintained throughout the session
The overhead of connection establishment is amortized across many messages

Characteristic 2: Independent Transmission Channels

In a full-duplex system, each direction of communication operates as a logically independent channel. The client can send messages without waiting for server acknowledgment, and vice versa. Messages traveling in opposite directions can "cross in the air" without causing collisions or requiring arbitration.

At the TCP level (which WebSockets run over), this is achieved through separate send and receive buffers. Each endpoint writes to its send buffer and reads from its receive buffer independently. The TCP layer handles the actual bidirectional data flow over the network.

Characteristic 3: No Request-Response Coupling

In HTTP, every response corresponds to exactly one request. In full-duplex communication, messages are independent entities. The server might send three messages before the client sends one. Messages don't need to be "responses" to anything—they can be initiated spontaneously by either party.

This decoupling enables patterns that are impossible with HTTP:

Server pushing updates as they occur, not when polled
Client and server communicating asynchronously
Multiple independent "conversations" over a single connection

Full-Duplex vs Half-Duplex Message Flow
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// Half-Duplex (HTTP-style): Strictly alternating
// Client and server take turns; one waits while the other communicates
 
Time →
CLIENT:  [REQUEST 1]----wait----wait----[REQUEST 2]----wait----
SERVER:  ----wait----[RESPONSE 1]----wait----wait----[RESPONSE 2]
 
 
// Full-Duplex (WebSocket-style): Simultaneous and independent
// Both parties communicate freely; no waiting required
 
Time →
CLIENT:  [MSG_A]--[MSG_B]--[MSG_C]--------[MSG_D]--[MSG_E]------
SERVER:  ---[MSG_1]--[MSG_2]--------[MSG_3]--[MSG_4]--[MSG_5]---
 
// Note: Client MSG_B and Server MSG_2 might literally be in transit
// simultaneously. Neither party waits for the other.

The TCP Foundation

WebSockets run over TCP, which is inherently full-duplex at the transport layer. The key innovation of WebSockets isn't inventing full-duplex—it's exposing TCP's full-duplex capability to web applications through a standardized protocol that works with web infrastructure (proxies, load balancers, firewalls) and browsers' security models.

How WebSockets Achieve Full-Duplex

WebSockets achieve full-duplex web communication through a clever design that transitions from HTTP to a different protocol. This "upgrade" mechanism allows WebSockets to work with existing web infrastructure while escaping HTTP's request-response constraints.

The WebSocket Upgrade Process:

A WebSocket connection begins life as a standard HTTP request—but with special headers indicating the client wants to upgrade to the WebSocket protocol. If the server supports WebSockets, it responds with a 101 Switching Protocols status, and both parties immediately switch to WebSocket framing over the same TCP connection.

WebSocket Handshake
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// Client initiates upgrade request (this is HTTP)
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket                    // Requesting protocol switch
Connection: Upgrade                   // Must include this
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==    // Random base64 key
Sec-WebSocket-Version: 13             // WebSocket protocol version
Origin: http://example.com            // For security validation
 
// Server accepts upgrade (still HTTP)
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=  // Computed from key
 
// After this handshake, the TCP connection switches to WebSocket framing
// Both parties can now send messages freely in either direction

After the handshake:

Once upgraded, the connection no longer uses HTTP semantics. Instead, both parties communicate using WebSocket "frames"—lightweight message containers with minimal overhead. Each frame has:

A small header (2-14 bytes depending on payload size)
An opcode indicating the frame type (text, binary, close, ping, pong)
Optional masking (required for client-to-server frames for security)
The payload data

This framing is dramatically more efficient than HTTP headers, which can easily exceed 500 bytes per message.

HTTP Request vs WebSocket Frame Overhead
Protocol	Typical Header Size	Per-Message Overhead	Connection Reuse
HTTP/1.1	500-2000 bytes	Headers + payload	Limited (Connection: keep-alive)
HTTP/2	100-300 bytes (compressed)	Headers + framing	Multiplexed on one connection
WebSocket	2-14 bytes	Frame header only	Persistent until explicitly closed

The full-duplex capability:

After the handshake, both client and server can send WebSocket frames at any time without waiting for permission or acknowledgment. The underlying TCP connection provides reliable, ordered delivery in each direction. This creates the full-duplex channel:

Client perspective: Can call websocket.send() at any moment; receives messages via onmessage event handler
Server perspective: Can write to the WebSocket at any moment; receives messages via a similar event/handler mechanism

Neither party needs to "request" that the other send data. The connection is permanently ready for bidirectional communication.

Why Start with HTTP?

Starting with HTTP and upgrading has practical benefits: it uses port 80/443 (avoiding firewall issues), works through most proxies and load balancers, and allows servers to serve regular HTTP and WebSocket on the same port. The initial HTTP request also allows the server to apply normal authentication and routing logic before establishing the persistent connection.

Architectural Implications of Full-Duplex

Embracing full-duplex communication has profound implications for system architecture. The shift from request-response to persistent bidirectional channels changes how you design, scale, and operate distributed systems.

Key Architectural Shifts

•Stateful Connections — Unlike HTTP where each request is independent, WebSocket connections maintain state. The server must track which users are connected, what they're subscribed to, and route messages accordingly. This complicates horizontal scaling.
•Push-Based Data Flow — Systems can shift from poll-based to push-based architectures. Instead of clients repeatedly asking "anything new?", servers push updates as they occur. This reduces latency and server load but requires infrastructure for event propagation.
•Connection Management Overhead — Long-lived connections consume resources differently than short HTTP requests. Servers must handle connection heartbeats, detect and clean up stale connections, and manage memory for potentially thousands of concurrent connections.
•Load Balancer Considerations — Traditional HTTP load balancers make routing decisions per-request. With WebSockets, the initial connection must be routed to a server that will handle all future messages. This affects load balancing strategies and session affinity.
•Message Routing Complexity — When a message arrives that should be broadcast to multiple clients, and those clients are connected to different servers, you need a pub/sub system (Redis, Kafka, RabbitMQ) to coordinate message distribution.

Architectural Comparison
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// HTTP Architecture (Stateless Request-Response)
┌─────────┐     Request      ┌─────────────┐     Query      ┌──────────┐
│ Browser │ ───────────────> │ Load        │ ─────────────> │ Any      │
│         │ <─────────────── │ Balancer    │ <───────────── │ Server   │
└─────────┘     Response     └─────────────┘     Result     └──────────┘
 
// Any server can handle any request. Scaling is simple: add more servers.
 
 
// WebSocket Architecture (Stateful Full-Duplex)
┌─────────┐                  ┌─────────────┐                ┌──────────┐
│ Browser │ <══════════════> │ Load        │ <═══════════>  │ Server A │
│         │   Persistent     │ Balancer    │   Persistent   │ (sticky) │
└─────────┘   Connection     └─────────────┘   Connection   └──────────┘
                                    ║
                                    ║ Pub/Sub       ┌──────────┐
                                    ╚══════════════>│ Redis/   │
                                                    │ Kafka    │
                                                    └──────────┘
 
// Connection is sticky to one server. Cross-server messaging needs pub/sub.

The Statefulness Trade-off

WebSocket's stateful nature is both its power and its challenge. The persistent connection enables real-time features, but the state it introduces complicates deployments, failover, and horizontal scaling. Before adopting WebSockets, ensure you understand and can handle the operational implications.

Full-Duplex in Practice

Understanding full-duplex conceptually is one thing; seeing it in action clarifies the practical benefits. Let's examine how full-duplex communication transforms a common application pattern.

Example: Real-Time Collaborative Editing

Consider a document editing application like Google Docs. Multiple users edit simultaneously, and everyone sees changes in real-time. Let's compare how this would work with HTTP versus WebSockets:

HTTP Approach

•User A makes an edit
•Client A sends POST request with change
•Server processes and returns OK
•User B's client polls for changes (every 500ms)
•After 0-500ms delay, User B receives update
•With 10 users, server handles 20 requests/second just for polling
•Most polling requests return 'no changes'
•Cursor positions require even more frequent polling

WebSocket Approach

•User A makes an edit
•Client A sends edit over WebSocket instantly
•Server broadcasts to all connected clients
•User B receives update within milliseconds
•No polling—updates arrive as they happen
•With 10 users, server handles only actual edits
•Zero wasted requests
•Cursor positions stream continuously

The multiplier effect:

As user count grows, the difference becomes dramatic:

100 users with HTTP polling (500ms interval): 200 requests/second baseline, plus actual edits
100 users with WebSockets: Only actual edits generate traffic; quiet periods = zero messages

For applications like gaming (where position updates might occur 60 times per second) or financial trading (where price updates stream continuously), the efficiency difference is measured in orders of magnitude.

Full-Duplex Code Example (Client)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
// Practical WebSocket client demonstrating full-duplex nature
const socket = new WebSocket('wss://collab.example.com/document/123');
 
// SET UP RECEIVING (one direction)
socket.onmessage = (event) => {
    const message = JSON.parse(event.data);
    
    switch (message.type) {
        case 'user_edit':
            applyRemoteEdit(message.changes);
            break;
        case 'cursor_moved':
            showRemoteCursor(message.userId, message.position);
            break;
        case 'user_joined':
            showUserPresence(message.user);
            break;
    }
};
 
// SENDING (other direction, completely independent)
// These can happen at ANY time, regardless of what we're receiving
 
document.addEventListener('selectionchange', () => {
    // Send cursor position as user navigates
    socket.send(JSON.stringify({
        type: 'cursor_moved',
        position: getCaretPosition()
    }));
});
 
editor.on('change', (changes) => {
    // Send edits as user types
    socket.send(JSON.stringify({
        type: 'user_edit',
        changes: changes
    }));
});
 
// Note: We can be RECEIVING other users' edits at the SAME MOMENT
// we're SENDING our own edits. True simultaneous bidirectional.

Summary: Full-Duplex as the Foundation

Full-duplex communication is the fundamental capability that makes WebSockets transformative for real-time web applications. Let's consolidate the key concepts:

Key Takeaways

•Full-duplex means simultaneous bidirectional communication — Both client and server can transmit independently at the same time, like a telephone conversation.
•HTTP is fundamentally half-duplex — Its request-response model requires alternation between client and server. Even HTTP/2 and HTTP/3 don't change this semantic limitation.
•WebSockets achieve full-duplex by upgrading from HTTP — The handshake starts as HTTP, then transitions to a lightweight framing protocol that allows free bidirectional message flow.
•Full-duplex enables push-based architectures — Servers can send data the moment it's available, without waiting for client requests. This reduces latency and eliminates polling overhead.
•The trade-off is statefulness — Persistent connections require different architectural patterns, affect load balancing, and introduce new operational considerations.
•Efficiency gains compound at scale — For applications with frequent small updates (chat, gaming, collaboration), WebSockets reduce server load by orders of magnitude compared to polling.

What's next:

Understanding that WebSockets provide full-duplex communication is the foundation. In the next page, we'll examine the WebSocket lifecycle in detail—how connections are established, maintained, and gracefully closed, including the ping/pong heartbeat mechanism and reconnection strategies that production systems require.

Page Complete

You now understand full-duplex communication as the foundational concept behind WebSockets. You can explain why HTTP's request-response model is inherently half-duplex, how WebSockets upgrade to achieve true bidirectional communication, and the architectural implications of maintaining persistent, stateful connections.

1 / 5

Loading learning content...

System Design (HLD)WebSockets

WebSockets: Real-Time Bidirectional Communication

LevelIntermediate

Duration75 mins

TopicWebSockets

1 / 5

Full-Duplex Communication

Understanding Full-Duplex: The Foundation of Real-Time Web

What You Will Learn

Communication Direction Fundamentals

The Three Communication Modes

•Simplex Communication — Data flows in one direction only. Think of a traditional television broadcast: the station transmits, and viewers receive. The viewer cannot send information back through the same channel. In computing, logging systems often use simplex patterns—log producers write events, consumers read them, but the channel is unidirectional.
•Half-Duplex Communication — Data can flow in both directions, but only one direction at a time. This is like a walkie-talkie: you either speak OR listen, never both simultaneously. The classic HTTP request-response cycle is half-duplex—the client sends a complete request, then the server sends a complete response. The channel alternates between them.
•Full-Duplex Communication — Data flows in both directions simultaneously. Like a telephone call, both parties can transmit and receive at the same instant. WebSockets provide full-duplex communication between browser and server, enabling truly interactive applications.

Why does mode matter?

The communication mode fundamentally constrains what applications you can build:

Simplex is efficient when data genuinely flows one way. Metrics collection, event streaming to analytics, and broadcast notifications naturally fit simplex patterns. Implementing bidirectional behavior over simplex requires separate channels for each direction.
Half-duplex works well for transactional interactions where requests naturally precede responses. Web page loading, API calls, and file downloads fit comfortably here. However, half-duplex creates awkward patterns for real-time features—you must either poll repeatedly or simulate push with techniques like long-polling.
Full-duplex is essential when both parties need to initiate communication independently and simultaneously. Chat applications, multiplayer games, collaborative tools, and live dashboards all require the server to push updates without waiting for client requests.

Communication Modes Compared
Mode	Direction	Real-World Analog	Web Example	Best Use Case
Simplex	A → B only	Television broadcast	CDN streaming	One-way data distribution
Half-Duplex	A ↔ B (alternating)	Walkie-talkie	HTTP request-response	Transactional interactions
Full-Duplex	A ⇆ B (simultaneous)	Telephone call	WebSocket connection	Real-time bidirectional apps

The HTTP Half-Duplex Limitation

To understand why WebSockets represent a paradigm shift, we must examine exactly how HTTP's design creates a half-duplex constraint—and why this limitation persists even in HTTP/2 and HTTP/3.

HTTP's fundamental model:

HTTP Request-Response Flow
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// Conceptual HTTP communication flow
// Time flows downward →
 
CLIENT                                  SERVER
   |                                       |
   |──── GET /api/messages ─────────────>│|   (Client initiates)
   |                                       |
   |                          Processing...|
   |                                       |
   |<─── 200 OK + JSON ─────────────────── |   (Server responds)
   |                                       |
   |          CONNECTION IDLE              |
   |                                       |
   |──── GET /api/messages ─────────────>│|   (Client must initiate again)
   |                                       |
 
// Key observation: Server CANNOT send data unless client requests it
// This is the fundamental half-duplex limitation of HTTP

The polling problem:

When applications need real-time updates—new chat messages, price changes, notifications—HTTP's client-initiated model forces awkward workarounds:

Short polling: The client repeatedly asks "any updates yet?" every few seconds. This wastes bandwidth, creates server load, and introduces latency (average delay is half the polling interval).

HTTP/2 and HTTP/3 Don't Solve This

Why HTTP-Based Workarounds Fall Short

•Short Polling: Creates massive overhead—repeated headers, connection setup, server processing for "no new data" responses. At scale, this overwhelms infrastructure.
•Long Polling: Ties up server resources (threads, connections, memory) even when no data flows. Hard to scale; difficult to handle multiple simultaneous message types.
•SSE: Only server-to-client. Client-to-server still requires separate HTTP requests. Binary data is awkward; limited browser connection pooling.
•All workarounds add latency: Even the best case has noticeable delay compared to true persistent connections where data flows instantly.

Full-Duplex Architecture Deep Dive

Characteristic 1: Persistent Connection

This persistence is essential because:

Either party can initiate transmission at any moment
There's no "request" to signal when the server should prepare to respond
State is maintained throughout the session
The overhead of connection establishment is amortized across many messages

Characteristic 2: Independent Transmission Channels

Characteristic 3: No Request-Response Coupling

This decoupling enables patterns that are impossible with HTTP:

Server pushing updates as they occur, not when polled
Client and server communicating asynchronously
Multiple independent "conversations" over a single connection

Full-Duplex vs Half-Duplex Message Flow
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// Half-Duplex (HTTP-style): Strictly alternating
// Client and server take turns; one waits while the other communicates
 
Time →
CLIENT:  [REQUEST 1]----wait----wait----[REQUEST 2]----wait----
SERVER:  ----wait----[RESPONSE 1]----wait----wait----[RESPONSE 2]
 
 
// Full-Duplex (WebSocket-style): Simultaneous and independent
// Both parties communicate freely; no waiting required
 
Time →
CLIENT:  [MSG_A]--[MSG_B]--[MSG_C]--------[MSG_D]--[MSG_E]------
SERVER:  ---[MSG_1]--[MSG_2]--------[MSG_3]--[MSG_4]--[MSG_5]---
 
// Note: Client MSG_B and Server MSG_2 might literally be in transit
// simultaneously. Neither party waits for the other.

The TCP Foundation

How WebSockets Achieve Full-Duplex

The WebSocket Upgrade Process:

WebSocket Handshake
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// Client initiates upgrade request (this is HTTP)
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket                    // Requesting protocol switch
Connection: Upgrade                   // Must include this
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==    // Random base64 key
Sec-WebSocket-Version: 13             // WebSocket protocol version
Origin: http://example.com            // For security validation
 
// Server accepts upgrade (still HTTP)
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=  // Computed from key
 
// After this handshake, the TCP connection switches to WebSocket framing
// Both parties can now send messages freely in either direction

After the handshake:

Once upgraded, the connection no longer uses HTTP semantics. Instead, both parties communicate using WebSocket "frames"—lightweight message containers with minimal overhead. Each frame has:

A small header (2-14 bytes depending on payload size)
An opcode indicating the frame type (text, binary, close, ping, pong)
Optional masking (required for client-to-server frames for security)
The payload data

This framing is dramatically more efficient than HTTP headers, which can easily exceed 500 bytes per message.

HTTP Request vs WebSocket Frame Overhead
Protocol	Typical Header Size	Per-Message Overhead	Connection Reuse
HTTP/1.1	500-2000 bytes	Headers + payload	Limited (Connection: keep-alive)
HTTP/2	100-300 bytes (compressed)	Headers + framing	Multiplexed on one connection
WebSocket	2-14 bytes	Frame header only	Persistent until explicitly closed

The full-duplex capability:

Client perspective: Can call websocket.send() at any moment; receives messages via onmessage event handler
Server perspective: Can write to the WebSocket at any moment; receives messages via a similar event/handler mechanism

Neither party needs to "request" that the other send data. The connection is permanently ready for bidirectional communication.

Why Start with HTTP?

Architectural Implications of Full-Duplex

Key Architectural Shifts

•Stateful Connections — Unlike HTTP where each request is independent, WebSocket connections maintain state. The server must track which users are connected, what they're subscribed to, and route messages accordingly. This complicates horizontal scaling.
•Push-Based Data Flow — Systems can shift from poll-based to push-based architectures. Instead of clients repeatedly asking "anything new?", servers push updates as they occur. This reduces latency and server load but requires infrastructure for event propagation.
•Connection Management Overhead — Long-lived connections consume resources differently than short HTTP requests. Servers must handle connection heartbeats, detect and clean up stale connections, and manage memory for potentially thousands of concurrent connections.
•Load Balancer Considerations — Traditional HTTP load balancers make routing decisions per-request. With WebSockets, the initial connection must be routed to a server that will handle all future messages. This affects load balancing strategies and session affinity.
•Message Routing Complexity — When a message arrives that should be broadcast to multiple clients, and those clients are connected to different servers, you need a pub/sub system (Redis, Kafka, RabbitMQ) to coordinate message distribution.

Architectural Comparison
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// HTTP Architecture (Stateless Request-Response)
┌─────────┐     Request      ┌─────────────┐     Query      ┌──────────┐
│ Browser │ ───────────────> │ Load        │ ─────────────> │ Any      │
│         │ <─────────────── │ Balancer    │ <───────────── │ Server   │
└─────────┘     Response     └─────────────┘     Result     └──────────┘
 
// Any server can handle any request. Scaling is simple: add more servers.
 
 
// WebSocket Architecture (Stateful Full-Duplex)
┌─────────┐                  ┌─────────────┐                ┌──────────┐
│ Browser │ <══════════════> │ Load        │ <═══════════>  │ Server A │
│         │   Persistent     │ Balancer    │   Persistent   │ (sticky) │
└─────────┘   Connection     └─────────────┘   Connection   └──────────┘
                                    ║
                                    ║ Pub/Sub       ┌──────────┐
                                    ╚══════════════>│ Redis/   │
                                                    │ Kafka    │
                                                    └──────────┘
 
// Connection is sticky to one server. Cross-server messaging needs pub/sub.

The Statefulness Trade-off

Full-Duplex in Practice

Understanding full-duplex conceptually is one thing; seeing it in action clarifies the practical benefits. Let's examine how full-duplex communication transforms a common application pattern.

Example: Real-Time Collaborative Editing

Consider a document editing application like Google Docs. Multiple users edit simultaneously, and everyone sees changes in real-time. Let's compare how this would work with HTTP versus WebSockets:

HTTP Approach

•User A makes an edit
•Client A sends POST request with change
•Server processes and returns OK
•User B's client polls for changes (every 500ms)
•After 0-500ms delay, User B receives update
•With 10 users, server handles 20 requests/second just for polling
•Most polling requests return 'no changes'
•Cursor positions require even more frequent polling

WebSocket Approach

•User A makes an edit
•Client A sends edit over WebSocket instantly
•Server broadcasts to all connected clients
•User B receives update within milliseconds
•No polling—updates arrive as they happen
•With 10 users, server handles only actual edits
•Zero wasted requests
•Cursor positions stream continuously

The multiplier effect:

As user count grows, the difference becomes dramatic:

100 users with HTTP polling (500ms interval): 200 requests/second baseline, plus actual edits
100 users with WebSockets: Only actual edits generate traffic; quiet periods = zero messages

Full-Duplex Code Example (Client)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
// Practical WebSocket client demonstrating full-duplex nature
const socket = new WebSocket('wss://collab.example.com/document/123');
 
// SET UP RECEIVING (one direction)
socket.onmessage = (event) => {
    const message = JSON.parse(event.data);
    
    switch (message.type) {
        case 'user_edit':
            applyRemoteEdit(message.changes);
            break;
        case 'cursor_moved':
            showRemoteCursor(message.userId, message.position);
            break;
        case 'user_joined':
            showUserPresence(message.user);
            break;
    }
};
 
// SENDING (other direction, completely independent)
// These can happen at ANY time, regardless of what we're receiving
 
document.addEventListener('selectionchange', () => {
    // Send cursor position as user navigates
    socket.send(JSON.stringify({
        type: 'cursor_moved',
        position: getCaretPosition()
    }));
});
 
editor.on('change', (changes) => {
    // Send edits as user types
    socket.send(JSON.stringify({
        type: 'user_edit',
        changes: changes
    }));
});
 
// Note: We can be RECEIVING other users' edits at the SAME MOMENT
// we're SENDING our own edits. True simultaneous bidirectional.

Summary: Full-Duplex as the Foundation

Full-duplex communication is the fundamental capability that makes WebSockets transformative for real-time web applications. Let's consolidate the key concepts:

Key Takeaways

•Full-duplex means simultaneous bidirectional communication — Both client and server can transmit independently at the same time, like a telephone conversation.
•HTTP is fundamentally half-duplex — Its request-response model requires alternation between client and server. Even HTTP/2 and HTTP/3 don't change this semantic limitation.
•WebSockets achieve full-duplex by upgrading from HTTP — The handshake starts as HTTP, then transitions to a lightweight framing protocol that allows free bidirectional message flow.
•Full-duplex enables push-based architectures — Servers can send data the moment it's available, without waiting for client requests. This reduces latency and eliminates polling overhead.
•The trade-off is statefulness — Persistent connections require different architectural patterns, affect load balancing, and introduce new operational considerations.
•Efficiency gains compound at scale — For applications with frequent small updates (chat, gaming, collaboration), WebSockets reduce server load by orders of magnitude compared to polling.

What's next:

Page Complete

1 / 5