Web Long Connections

How to maintain persistent / long-lived connections in web applications

Table of Contents

1. HTTP Keep-Alive (Persistent Connection)
2. HTTP Pipelining
3. Long Polling
4. Streaming (Chunked Transfer)
5. Server-Sent Events (SSE)
6. WebSocket
7. HTTP/2 Multiplexing
8. Summary

In HTTP, a “long connection” usually refers to keeping a TCP connection open for multiple requests instead of closing it after each one (often called persistent connections or keep-alive). There are several ways this concept shows up in practice depending on what you’re trying to achieve.

1. HTTP Keep-Alive (Persistent Connection)

• Default in HTTP/1.1.
• The client and server reuse the same TCP connection for multiple requests/responses.
• Reduces latency and overhead from repeatedly opening/closing connections.

Header example:

Connection: keep-alive

Flow:

Client ──── request 1 ────▶ Server
Client ◀─── response 1 ─── Server
Client ──── request 2 ────▶ Server   (same TCP connection)
Client ◀─── response 2 ─── Server

2. HTTP Pipelining

• Multiple HTTP requests are sent without waiting for previous responses.
• Responses must still come back in order.
• Rarely used today due to head-of-line blocking issues.

Flow:

Client ──── request 1 ────▶
Client ──── request 2 ────▶ Server
Client ──── request 3 ────▶
Client ◀─── response 1, 2, 3 (in order)

3. Long Polling

• Client sends a request.
• Server holds the request open until new data is available.
• Once data is sent, the connection closes and the client immediately reconnects.
• Common for near–real-time updates (older technique).

Flow:

Client ──── request ─────────────────────▶ Server
                                           (server waits for new data)
Client ◀─── response (when data ready) ── Server
Client ──── reconnect immediately ───────▶ Server

Use case: Chat apps, notification systems (legacy approach).

4. Streaming (Chunked Transfer)

• Server keeps the connection open and continuously sends data in chunks.
• Useful for logs, live feeds, progress updates.

Header:

Transfer-Encoding: chunked

Example (Node.js):

res.writeHead(200, { 'Transfer-Encoding': 'chunked' });
setInterval(() => res.write('data chunk\n'), 1000);

5. Server-Sent Events (SSE)

• One-way communication: server → client only.
• Browser keeps a long-lived HTTP connection open.
• Simpler than WebSockets for real-time updates (push notifications, dashboards).
• Automatically reconnects on disconnect.

Header:

Content-Type: text/event-stream

Server example (Node.js):

res.setHeader('Content-Type', 'text/event-stream');
res.setHeader('Cache-Control', 'no-cache');
setInterval(() => res.write(`data: ${JSON.stringify({ time: Date.now() })}\n\n`), 1000);

Client example:

const source = new EventSource('/events');
source.onmessage = (e) => console.log(e.data);

6. WebSocket (Upgrade from HTTP)

• Starts as HTTP, then upgrades to a persistent full-duplex connection.
• Enables real-time bidirectional communication.
• Best for chat, gaming, live collaboration.

Upgrade headers:

Upgrade: websocket
Connection: Upgrade

Server example (Node.js with ws):

const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });
wss.on('connection', (ws) => {
  ws.on('message', (msg) => ws.send(`echo: ${msg}`));
});

Client example:

const ws = new WebSocket('ws://localhost:8080');
ws.onmessage = (e) => console.log(e.data);
ws.send('hello');

7. HTTP/2 Multiplexing

• Multiple streams share a single long-lived connection.
• Solves head-of-line blocking at the HTTP layer (unlike HTTP/1.1 pipelining).
• More efficient: headers are compressed (HPACK), streams are independent.

Key features vs HTTP/1.1:

Summary

Quick decision guide:

• Connection reuse: Keep-Alive, HTTP/2
• Client waiting for data: Long Polling
• Continuous data flow from server: Streaming, SSE
• Full-duplex (bidirectional) communication: WebSocket

Pros, Cons & Use Cases Comparison

Scalability Considerations

Ref

• https://systemdesignschool.io/problems/google-doc/solution