Lesson 11 — Real-Time Internet: WebSockets, SSE & Live Communication: How Instant Web Protocols Work

Throughout the earlier lessons of this course, our mental model of web communication has centered around the classic HTTP Request-Response cycle:

Browser (Client)
   ↓ HTTP Request (e.g. GET /products)
Server
   ↓ (Processes application logic & queries database)
Browser (Client) ← HTTP Response (200 OK + HTML/JSON)

In this model, communication is fundamentally half-duplex and client-initiated. That means:

• The server can never speak first; it only answers when the client explicitly asks a question.
• As soon as the response headers and payload finish transmitting, the HTTP transaction is complete and the connection goes idle or closes.

This request-response architecture is ideal for static web browsing, reading documentation, or fetching catalog pages. But now imagine a very common modern scenario:

The message arrives at the chat server. But how can the server immediately push that incoming message onto your screen if your browser hasn't sent a new request?

You certainly cannot expect the user to manually hit the refresh button (F5) every second. Users expect instant, effortless live updates the moment data changes. This fundamental challenge is what gave rise to Real-Time Communication.

In computer science and distributed networking, real-time communication can be defined very simply:

Modern real-time applications surround us daily:

• Instant Messaging: WhatsApp, Telegram, Slack, Microsoft Teams chat threads.
• Live Financial Feeds: Stock exchange tickers, cryptocurrency order books, and foreign exchange rates updating multiple times per second.
• Collaborative Workspaces: Real-time co-authoring in Google Docs, Figma cursor tracking, and shared whiteboard canvases.
• Multiplayer Online Gaming: Millisecond player coordinate synchronization and game state updates.
• Live Operations Dashboards: Cloud server CPU telemetry, Kubernetes pod health monitoring, and food delivery courier GPS tracking.

Traditional HTTP/1.0 and HTTP/1.1 were designed as stateless, unidirectional request-response protocols. The browser is always the active initiator, and the server is strictly a passive responder.

Client initiates: "Hey server, do you have any new messages?"
Server replies:    "No, nothing new." (Closes / Completes transaction)

[Server receives message from Alice 200ms later]
Server's dilemma:  "I have a message for Bob, but HTTP does not allow me to reach out and speak to Bob!"

Because standard HTTP has no native mechanism for the server to initiate contact with a dormant client, software engineers had to invent clever workarounds. The earliest of these workarounds was Polling.

In Short Polling (regular polling), client-side JavaScript uses a recurring timer (such as setInterval()) to send periodic HTTP GET requests to the server asking: "Is there any new data?"

Time 00:00:00 → Client: "Any new messages?" → Server: "No (Empty)"
Time 00:00:03 → Client: "Any new messages?" → Server: "No (Empty)"
Time 00:00:06 → Client: "Any new messages?" → Server: "No (Empty)"
Time 00:00:09 → Client: "Any new messages?" → Server: "Yes! 1 new message from Alice"

This approach gives the illusion of a live experience because the UI updates every few seconds without the user touching anything. However, behind the scenes, this pattern introduces severe network and computational inefficiencies.

Short polling suffers from three fatal architectural drawbacks at scale:

• Massive Bandwidth & Header Waste: Every single HTTP request includes 500 to 2,000 bytes of headers (User-Agent, Cookies, Authorization tokens, Accept headers). If 99% of requests return an empty response, millions of bytes of data are transferred across the wire for zero useful payload.
• Server Stampedes & High CPU Utilization: Imagine 100,000 users with a chat tab open. If each browser polls every 5 seconds, your backend infrastructure must handle 20,000 incoming HTTP requests every single second, performing authentication checks and database queries repeatedly just to tell users that nothing happened!
• Unnecessary Mobile Battery Drain: On mobile devices, periodically firing radio transmitters to send empty HTTP requests rapidly drains device battery and uses up mobile cellular data plans.

Short polling forces engineers into a painful architectural compromise between update latency and server resource load:

Polling frequency is low → Server load is low, but update delay is high

If you poll every 15 seconds, server CPU load remains manageable. However, if Alice sends a message at second 1, Bob will not see it until second 15—introducing an unacceptable 14-second lag in a conversation.

Polling frequency is high → Fast updates, but overwhelming server load

If you poll every 500 milliseconds to make the chat feel snappy, your servers will quickly be overwhelmed by tens of thousands of requests per second, exhausting connection pools and crashing backends.

Recognizing the flaws of short polling, network engineers asked: "What if the server doesn't reply immediately when it has no data? What if the server simply holds the client's request open until new data actually arrives?"

This ingenious optimization is called Long Polling (also known historically as Comet architecture).

In Long Polling, the client issues a standard HTTP GET request, but the server handles it completely differently:

1. Client sends HTTP GET /chat/messages.
2. Server inspects state: No new messages currently exist.
3. Server does NOT respond immediately; it HOLDS (hangs) the TCP connection open.
4. [12 seconds pass in silence... connection remains alive]
5. Alice sends a message to the chat room!
6. Server immediately packages Alice's message into the held response and sends it to Bob.
7. The HTTP response closes.
8. Bob's browser receives the message, renders it on screen, and IMMEDIATELY sends another long-poll GET request.

If no message arrives before a designated timeout (typically 30 to 60 seconds), the server responds with a blank message or 204 No Content, and the client immediately reconnects.

Long polling was a massive breakthrough for early real-time web applications (such as Gmail chat and Facebook Web Messenger in the late 2000s):

• Instant Event Delivery: Because the server already has an open pipe waiting, messages are pushed to the client within milliseconds of occurring on the server.
• Drastic Reduction in Empty Requests: Instead of 12 empty requests every minute, the browser sends only 1 or 2 requests.

However, long polling still carries major drawbacks:

• Connection Churn: Every single delivered message terminates the HTTP response. The browser must immediately initiate a brand-new HTTP request, repeating TCP handshakes, TLS negotiation, and cookie validation.
• Unidirectional at Heart: Long polling is still one-way. If the client wants to send a message while a long-poll is waiting, it must open a separate, concurrent HTTP POST request.

To overcome all the limitations of polling and long polling once and for all, the IETF standardized the WebSocket Protocol (RFC 6455) in 2011.

Persistent

The connection is established once and stays open indefinitely until either the client or server explicitly decides to close it. It does not close after sending or receiving a message.

Bidirectional & Full-Duplex

Both the client and the server can send messages independently at any given instant. The client does not need to request anything for the server to transmit data, and both sides can speak simultaneously without blocking each other.

To understand why WebSockets are such an architectural leap forward, consider how data travels across the wire:

[Client Browser] <======================================> [WebSocket Server]
                           Single Open TCP Socket
                 ←←←←← Server can push data anytime ←←←←←
                 →→→→→ Client can send data anytime →→→→→

Once established, the protocol does not treat communication as discrete request-and-response transactions. Instead, it operates as a continuous, open two-way conduit. Either party can inject messages into the pipeline at any instant.

WebSockets are the gold standard whenever an application requires bidirectional interaction, high event frequency, and near-zero latency:

• Instant Messaging & Social Chat: Direct messaging on WhatsApp Web, Discord voice/text status, and Slack threads.
• Collaborative Editing: Real-time keystroke and cursor positioning in Figma, Google Docs, Miro, and Notion.
• Multiplayer Web Games: Real-time player coordinates, movement inputs, and physics updates at 60 frames per second.
• Live Trading Platforms: High-frequency cryptocurrency order book depth and stock market bid/ask updates.

Remarkably, a WebSocket connection does not begin on a separate network port. It begins as a standard HTTP/1.1 request! This process is known as the HTTP Upgrade Handshake.

// 1. Client Handshake Request (Browser → Server)
GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

// 2. Server Handshake Response (Server → Browser)
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Let's analyze what happens here:

• The client explicitly requests: Upgrade: websocket and Connection: Upgrade.
• The client sends a random Base64 security key (Sec-WebSocket-Key) to prove the request is a legitimate WebSocket handshake and not a cached HTTP response.
• The server combines this key with a globally standardized GUID (RFC 6455), computes a SHA-1 hash, and returns HTTP/1.1 101 Switching Protocols with Sec-WebSocket-Accept.

The instant the 101 Switching Protocols response is delivered, the underlying TCP connection switches protocol completely. It ceases to speak HTTP!

This drastic reduction in header bloat means you can transmit hundreds of small messages every second without choking client bandwidth or exhausting server buffers.

A very common misconception among beginners is that WebSockets will eventually replace HTTP. They do not replace HTTP; they complement it!

HTTP

Stateless, easy to scale horizontally behind standard load balancers, heavily cacheable by CDNs and browser caches, and perfect for CRUD operations (loading HTML pages, stylesheets, images, and REST APIs).

WebSocket

Stateful, persistent in memory, cannot be cached by CDNs, but unparalleled for high-frequency interactive events, real-time typing indicators, and streaming telemetry.

Just as unencrypted HTTP (http://) has an encrypted counterpart in HTTPS (https://), plain WebSockets (ws://) have an encrypted sibling: WSS (wss://).

Data over a WebSocket connection is transmitted in frames. A message can consist of a single frame or multiple fragmented frames:

• Text Frames (Opcode 0x1): Contains UTF-8 encoded text (such as JSON payloads).
• Binary Frames (Opcode 0x2): Contains raw binary data (ArrayBuffer, Blob, image chunks, audio streams).
• Control Frames (Ping/Pong - 0x9/0xA, Close - 0x8): Heartbeat frames used to detect broken connections (half-open TCP sockets) and cleanly close the connection.

Handling 500,000 open WebSocket connections is fundamentally different from serving 500,000 HTTP requests. An HTTP request finishes in 30ms and frees its memory; a WebSocket stays in RAM for hours or days.

How do modern servers achieve the historic C10K and C1000K milestones (handling 1 million concurrent connections on a single server)?

• Non-Blocking Asynchronous I/O: Instead of dedicating an entire OS thread to each connection (which would consume gigabytes of stack memory), modern servers use asynchronous event-driven I/O engines (epoll on Linux, kqueue on BSD/macOS). A single thread can monitor hundreds of thousands of idle sockets.
• File Descriptor Limits: In Unix-like OSs, every open socket is a file descriptor. System administrators must raise the limits using ulimit -n 1048576.
• Low Per-Socket Memory Footprint: Efficient runtimes (like Go with lightweight goroutines, Node.js with libuv, or Rust with Tokio) keep the memory footprint per idle connection down to just 2 to 10 KB.

As your user base grows to millions, you must add more servers behind a load balancer. But this introduces the famous Distributed State Problem:

User A (Sakib) is connected to → WebSocket Server 1
User B (Tamim) is connected to → WebSocket Server 2

Problem: When Sakib sends a message to Tamim, Server 1 receives it.
But Tamim's TCP socket lives in the RAM of Server 2!
Server 1 has no direct way to write to a socket owned by Server 2!

How do we solve this? The answer is the Pub/Sub Pattern and Message Brokers!

Publish / Subscribe (Pub/Sub) is a messaging design pattern where senders of messages (called Publishers) do not send messages directly to specific receivers. Instead, messages are published to named categories called Channels or Topics.

Receivers (called Subscribers) express interest in one or more topics. Whenever a new message is published to a topic, the messaging system automatically fans out and delivers that message to all active subscribers.

A Message Broker is specialized middleware designed for ultra-high throughput message routing and buffering across distributed servers. Common industry examples include Redis Pub/Sub, RabbitMQ, Apache Kafka, and NATS.

[User A] → (WS) → [WebSocket Server 1]
                        ↓ PUBLISH 'chat:room_42' {"from":"A","text":"Hi!"}
              [ CENTRAL REDIS MESSAGE BROKER ]
                        ↓ Fan-out broadcast to all subscribed servers
[User B] ← (WS) ← [WebSocket Server 2]
[User C] ← (WS) ← [WebSocket Server 3]

Every WebSocket server subscribes to the channels of the users currently connected to it. When an event is published, the broker distributes it across all servers in sub-millisecond time. Each server pushes the frame down to its local clients. This decoupled architecture allows real-time clusters to scale horizontally to millions of users.

Does every real-time web application need full bidirectional communication? Consider these common use cases:

• Viewing live stock price ticks or cryptocurrency ticker updates.
• Watching a live sports scoreboard or election results tally.
• Streaming AI tokens from ChatGPT or Gemini as the model writes code.
• Tracking courier GPS location on a food delivery map.

In all of these scenarios, data flows in only one direction: from the server to the client. The browser never needs to send live continuous streams back to the server. Maintaining a complex, custom full-duplex WebSocket channel for one-way updates is architectural overkill. This is where Server-Sent Events (SSE) shines.

Unlike WebSockets, SSE does not require a custom protocol or an upgrade handshake. It runs over pure, standard HTTP/1.1 or HTTP/2!

// 1. Client opens stream using native browser EventSource API
GET /live-scores HTTP/1.1
Accept: text/event-stream

// 2. Server responds with 200 OK and keeps connection open
HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive

// 3. Server streams text chunks formatted with data: ... 


data: {"team": "BD", "score": "150/2"}

data: {"team": "BD", "score": "154/2"}

event: wicket
data: {"player": "Shakib", "runs": 75}

The browser has native support for this via the built-in EventSource JavaScript interface. If the network connection drops, the browser automatically reconnects and sends the last received event ID (Last-Event-ID) so the server can resume without missing a beat!

SSE is the premier protocol for:

• AI Text Streaming: Streaming tokens chunk-by-chunk from large language models (like ChatGPT or Claude).
• Live Analytics & Metrics: Real-time operational graphs, CPU monitoring, and error logs.
• Notification Systems: Delivery alerts, system status toasts, and friend activity notifications.

Here is a direct architectural comparison between the two premier live web technologies:

With WebSockets and SSE available, is traditional polling dead? Not at all!

Simple periodic polling remains the most practical and cost-effective solution when:

• Update Frequency is Low: Checking for software updates once every 24 hours, or syncing inbox emails every 15 minutes. Maintaining millions of open persistent TCP sockets for data that changes twice a day would be a massive waste of server RAM.
• Simplicity is King: Short polling requires zero specialized backend infrastructure, zero persistent connection state, and works out of the box on any serverless platform (like AWS Lambda).

Now, let's step beyond text chat and metrics into real-time audio and video communications (such as Google Meet, Zoom web, or Discord voice calls).

If you are on a video call with a friend, transmitting 30 frames per second of 1080p video up to a central cloud server and back down to your friend introduces unacceptable lag and requires immense server bandwidth. This led to the creation of WebRTC (Web Real-Time Communication).

WebRTC is used for ultra-low-latency peer-to-peer multimedia streaming:

• Browser-based video conferencing (Google Meet, Microsoft Teams, Whereby).
• Peer-to-peer file transfers and direct browser data sharing.
• Cloud gaming remote desktop streaming (Google Stadia, GeForce Now).

No! WebRTC is fundamentally Peer-to-Peer (P2P) using UDP and SRTP for media streams. WebSockets are Client-to-Server using TCP.

In fact, WebRTC cannot even start without a WebSocket! Because two browsers sitting behind separate routers in different parts of the world cannot find each other directly, they must first exchange connection metadata over a central server. This preparatory coordination is called Signaling.

Before two peers can connect directly, they must negotiate:

• Media Capabilities: Supported codecs (VP9, AV1, Opus), video resolutions, and frame rates via SDP (Session Description Protocol) offers and answers.
• Network Candidates: Public IP addresses and port numbers discovered via ICE (Interactive Connectivity Establishment).

This initial exchange happens over an out-of-band communication channel—most commonly a WebSocket server!

In Lesson 10, we learned that nearly every home computer and mobile device sits behind a private network and a router running NAT (Network Address Translation) with a stateful firewall.

Remember the fundamental firewall rule: unsolicited inbound packets from the outside Internet are dropped immediately.

If Alice's computer in Dhaka has private IP 192.168.1.15, and Bob's laptop in London has private IP 192.168.0.22, neither can directly reach the other's private address! How do two peers punch holes through their respective NATs to stream video directly?

STUN (Session Traversal Utilities for NAT) is a lightweight protocol that answers the question: "What does my public IP and port look like to the outside world?"

This discovered public endpoint is called a Server Reflexive Candidate. Once both peers know their public endpoints, they attempt direct UDP hole punching. STUN succeeds in establishing direct P2P connections roughly 80-85% of the time!

What happens in the remaining 15% of cases, when one or both peers are behind restrictive enterprise firewalls, university networks, or symmetric NATs that block UDP hole punching?

This is where TURN (Traversal Using Relays around NAT) comes to the rescue.

[Peer A (Behind Strict NAT)] → (Relay UDP) → [TURN SERVER] → (Relay UDP) → [Peer B (Behind Strict NAT)]

A TURN server acts as an intermediary relay. Both peers maintain an outbound connection to the TURN server, and the server forwards the media packets between them. While this adds a slight amount of latency and requires server bandwidth, it guarantees that WebRTC calls never fail to connect.

Let us now synthesize everything we have learned across Courses 01 through 11 into a complete 13-step journey of sending a single chat message:

In platforms like Datadog, Grafana, or AWS CloudWatch, hundreds of servers continuously stream CPU utilization, memory pressure, and network throughput metrics.

Engineering teams typically implement Server-Sent Events (SSE) for these dashboards. Because telemetry flows strictly from server to client, SSE provides lower connection overhead, automatic browser reconnection, and frictionless compatibility with existing HTTP/2 corporate proxies.

When you order food on an app like Uber Eats or DoorDash, your phone displays live status changes: "Order Confirmed → Chef is cooking → Driver picked up food → Driver 2 mins away".

Rather than polling every second, mobile apps maintain a persistent streaming connection (often via SSE or lightweight MQTT/WebSocket protocols). When the delivery driver's GPS updates, backend microservices emit an event to a Kafka stream, fan out through Redis, and push a single event to the user's mobile screen instantly.

In colloquial conversation, people often say real-time means "zero delay". In networking physics, zero delay does not exist!

• Propagation Delay: Light travels through fiber optic glass cables at roughly 200,000 kilometers per second. A signal traveling between New York and Sydney will always take at least 70 to 90 milliseconds just due to the fundamental laws of physics.
• Serialization & Queuing Delay: Packets must be queued, inspected by routers, and written to network interfaces.

When engineers talk about "real-time," they mean bounded, predictable low latency (usually under 100 milliseconds for chat and under 30 milliseconds for interactive multiplayer gaming).

These two network metrics are frequently confused:

Latency

The time elapsed for a single data packet to travel from sender to receiver (measured in milliseconds, ms). Essential for live gaming, voice calls, and collaborative whiteboard cursor sync.

Throughput

The raw quantity of data that can be transferred across the network pipe per unit of time (measured in Megabits per second, Mbps). Essential for downloading high-definition video files or bulk database backups.

Real-time architectures extend far beyond web browsers:

• Internet of Things (IoT): Smart thermostats, industrial turbine sensors, and medical telemetry devices communicating via ultra-compact protocols like MQTT and CoAP.
• Autonomous Vehicles & Robotics: Millisecond LiDAR sensor processing and obstacle avoidance over CAN bus and UDP channels.
• High-Frequency Trading (HFT): Financial exchanges transmitting market orders in nanoseconds using FPGA hardware and custom kernel-bypass networking.

Let us look at how all protocols fit together into a unified architecture:

Standard Web Request Journey:
URL → DNS → IP → Port → TCP/QUIC → TLS → HTTP → CDN / Edge Proxy → Load Balancer → App Server → Cache / Database

Real-Time Event Streaming:
Application → WebSocket / SSE → Persistent Open Connection → Client

Audio / Video Peer Streaming:
Browser → WebRTC → STUN / TURN / ICE → Direct Peer Stream (UDP)

                         PUBLIC INTERNET
                                │
                          Edge CDN / WAF
                                │
                         Load Balancer
                                │
              ┌─────────────────┼─────────────────┐
              ▼                 ▼                 ▼
         Web Server        Web Server       WebSocket Gateway
         (Stateless)       (Stateless)          (Stateful)
              │                 │                 │
              └─────────────────┼─────────────────┘
                                │
                      Central Message Broker
                       (Redis / Apache Kafka)
                                │
                   ┌────────────┴────────────┐
                   ▼                         ▼
            Primary Database           Distributed Cache
              (PostgreSQL)                (Redis RAM)

Notice how clean and decoupled this system is. Stateless HTTP servers handle catalog browsing and user signups, while dedicated WebSocket gateways maintain millions of open connections and synchronize instantly through the Redis message broker.

When Course 08 began in Lesson 1, our journey started with a single fundamental question: "What is the Internet?"

Now, step by step, we have mastered every foundational layer:

The Internet is no longer a magic black box or just "opening Google." You now understand it as a breathtaking, layered distributed machine operating continuously across millions of servers worldwide.

One massive architectural puzzle remains:

No single home router has enough memory to store the path to every computer on Earth. So:

• How do independent Internet Service Providers (ISPs) exchange routing paths?
• What is an Autonomous System (AS)?
• What is BGP (Border Gateway Protocol)?
• When a deep-sea fiber optic cable snaps, how does global traffic automatically reroute in seconds?