Giao tiếp Real-timeReal-time Communication

Thuộc bộ kiến thức Backend Roadmap.

Tổng quan

Web cổ điển được xây trên mô hình HTTP request/response: client hỏi, server trả lời, rồi kết thúc. Mô hình này là client-initiated — server chỉ được “nói” khi bị “hỏi”. Điều đó hoàn hảo khi tải một trang hay submit một form, nhưng nó sụp đổ ngay khi server có tin mà client chưa hề hỏi tới: một tin nhắn chat mới, một biến động giá cổ phiếu, một thông báo “đơn hàng đã giao”, hay con trỏ của người dùng khác đang di chuyển trong một tài liệu chung.

Real-time communication là tập hợp các kỹ thuật cho phép server đẩy (push) dữ liệu xuống client (và thường là chiều ngược lại, với độ trễ thấp) để UI phản ánh thay đổi ngay khi chúng xảy ra, thay vì đợi lần refresh trang kế tiếp. Không có một “real-time protocol” duy nhất; thay vào đó là cả một phổ các cách tiếp cận, mỗi cách đánh đổi khác nhau giữa latency, overhead, độ phức tạp và chi phí hạ tầng:

• Short polling — client lặp đi lặp lại câu hỏi “có gì mới không?” theo một khoảng thời gian.
• Long polling — client hỏi, và server giữ request mở cho đến khi có gì đó để trả lời.
• Server-Sent Events (SSE) — một HTTP response sống lâu (long-lived) stream các event theo chiều server→client.
• WebSockets — một kết nối TCP bền vững, full-duplex cho trao đổi hai chiều.
• WebTransport / HTTP/3 datagrams — một transport hiện đại, multiplexed trên nền QUIC.

Note này giải thích từng kỹ thuật hoạt động ra sao, khi nào nên dùng cái nào, và — quan trọng nhất — cách scale hệ thống real-time trên nhiều server, đây chính là chỗ mà đa số team bị bất ngờ.

Vì sao “real-time” là một phổ, không phải một công tắc

“Real-time” trong ngữ cảnh backend hiếm khi mang nghĩa hard real-time (đảm bảo cỡ microsecond). Nó nghĩa là độ trễ cảm nhận thấp — cập nhật đến trong khoảng vài chục đến vài trăm mili-giây. Kỹ thuật phù hợp phụ thuộc vào:

• Hướng (direction) — bạn chỉ cần server→client, hay cần full-duplex?
• Tần suất — một event mỗi phút, hay hàng nghìn event mỗi giây?
• Fan-out — một người nhận, hay một triệu subscriber?
• Đảm bảo phân phối (delivery guarantees) — “best effort” là đủ, hay cần đúng thứ tự và không mất mát?
• Hạ tầng — proxy, load balancer và CDN của bạn có giữ được kết nối mở không?

Kiến thức nền tảng

Vấn đề cốt lõi: HTTP là client-initiated

Trong HTTP/1.1 thuần, một kết nối mang một request và một response (hoặc vài cái tuần tự nhờ keep-alive). Server không có kênh nào để chủ động gửi tin. Nếu một giá trị thay đổi trên server tại thời điểm T, client sẽ không biết cho đến lần request kế tiếp của nó. Mọi kỹ thuật bên dưới đều là một chiến lược để thu hẹp khoảng cách đó — hoặc bằng cách hỏi thường xuyên hơn, hoặc bằng cách giữ một request mở, hoặc bằng cách nâng cấp lên một transport thực sự hai chiều.

TCP, kết nối, và vì sao chúng tốn tài nguyên

Mọi kỹ thuật real-time trừ short polling đều dựa vào việc giữ một kết nối mở. Một kết nối được giữ tiêu tốn một file descriptor và bộ nhớ trên server, một slot trong mỗi thành phần trung gian (load balancer, reverse proxy), và thường là một thread trừ khi server dùng I/O bất đồng bộ (async/event-driven). Đây là lý do real-time ở quy mô lớn về bản chất là một bài toán quản lý kết nối (connection management), chứ không chỉ là chọn protocol — một server mạnh có thể phục vụ hàng triệu request HTTP stateless mỗi phút nhưng có thể chạm trần ở vài chục nghìn WebSocket mở đồng thời.

Latency, overhead và độ tươi của dữ liệu

Ba yếu tố này căng kéo lẫn nhau:

• Poll thường xuyên → dữ liệu tươi, nhưng lãng phí request và tải khi chẳng có gì thay đổi.
• Poll thưa → rẻ, nhưng dữ liệu cũ (stale).
• Giữ kết nối → tươi và rẻ trên đường truyền, nhưng đắt về tài nguyên bị chiếm giữ và khó scale/vận hành hơn.

Khái niệm chính

Short polling

Client hỏi theo một khoảng cố định. Mỗi lần poll là một HTTP request độc lập; server trả lời ngay lập tức, hoặc là dữ liệu mới hoặc là “chưa có gì”.

// Client: ask every 3 seconds
async function shortPoll() {
  const res = await fetch("/api/messages?since=" + lastSeenId);
  const data = await res.json();
  if (data.length) render(data);
}
setInterval(shortPoll, 3000);

Cách hoạt động: cực đơn giản — chỉ là các GET lặp lại. Đánh đổi: đơn giản tối đa và chạy ở mọi nơi (không cần server hỗ trợ đặc biệt), nhưng lãng phí request khi không có gì mới, và latency tệ nhất bằng đúng khoảng poll. Muốn tươi gấp đôi thì lượng request cũng gấp đôi. Tốt cho các kiểm tra trạng thái tần suất thấp, fan-out thấp; tệ cho chat.

Long polling

Client gửi một request, và server không trả lời ngay. Nó giữ request mở cho đến khi có dữ liệu (hoặc hết timeout), rồi mới trả lời. Client lập tức mở một request mới. Cách này cho phân phối gần real-time trên nền HTTP thông thường.

// Client: reconnect as soon as each response arrives
async function longPoll() {
  try {
    const res = await fetch("/api/messages/stream?since=" + lastSeenId);
    const data = await res.json();
    if (data.length) { render(data); lastSeenId = data.at(-1).id; }
  } catch (e) {
    await sleep(1000); // back off on error
  }
  longPoll(); // immediately re-establish
}
longPoll();

// Server (Express-ish): hold the response until an event or timeout
app.get("/api/messages/stream", async (req, res) => {
  const since = Number(req.query.since);
  const timeout = setTimeout(() => res.json([]), 25000); // avoid proxy idle-kill
  emitter.once("message", (msg) => {
    if (msg.id > since) { clearTimeout(timeout); res.json([msg]); }
  });
});

Đánh đổi: tươi hơn hẳn short polling và không cần protocol đặc biệt, nhưng mỗi message vẫn phải trả cái giá của một round-trip HTTP đầy đủ (headers, reconnect), và việc giữ request mở làm bận tài nguyên server. Đây là “con ngựa kéo cày” trước thời WebSockets/SSE và vẫn là một fallback vững chắc.

Server-Sent Events (SSE)

SSE là một stream một chiều (unidirectional) server→client trên một HTTP response sống lâu duy nhất với Content-Type: text/event-stream. API EventSource có sẵn trong browser lo việc kết nối, parse event, và — một tính năng then chốt — tự động reconnect rồi resume bằng header Last-Event-ID.

// Client: one line to subscribe
const es = new EventSource("/api/events");
es.onmessage = (e) => console.log("data:", e.data);
es.addEventListener("price", (e) => updateTicker(JSON.parse(e.data)));
es.onerror = () => {/* EventSource auto-reconnects; no code needed */};

// Server: stream text/event-stream frames
app.get("/api/events", (req, res) => {
  res.set({
    "Content-Type": "text/event-stream",
    "Cache-Control": "no-cache",
    "Connection": "keep-alive",
  });
  const send = (event, data, id) => {
    if (id) res.write(`id: ${id}\n`);
    if (event) res.write(`event: ${event}\n`);
    res.write(`data: ${JSON.stringify(data)}\n\n`); // blank line ends the event
  };
  const timer = setInterval(() => send("price", { sym: "AAPL", px: 199.9 }, Date.now()), 1000);
  req.on("close", () => clearInterval(timer));
});

Định dạng đường truyền là text thuần: các dòng như data:, event:, id:, và retry:, với một dòng trống kết thúc mỗi event. Điểm mạnh: cực đơn giản, chạy trên HTTP thông thường (đi qua được đa số proxy và HTTP/2), có sẵn reconnect và event ID, và text dễ debug. Giới hạn: chỉ server→client (gửi dữ liệu client→server bằng HTTP request thường), chỉ text (không có binary nếu không encode), và trên HTTP/1.1 browser giới hạn số kết nối mỗi domain (~6) — một vấn đề thực tế nhưng đã được HTTP/2 multiplexing giải quyết phần lớn. Use case: live dashboard, notification, feed, ticker giá/cổ phiếu, stream log, stream token của AI.

WebSockets

WebSockets cung cấp một kết nối bền vững, full-duplex: sau một handshake HTTP ban đầu, cả hai phía có thể gửi message bất kỳ lúc nào trên cùng một kết nối TCP. Được định nghĩa bởi RFC 6455.

Upgrade handshake: client gửi một HTTP GET kèm Upgrade: websocket, Connection: Upgrade, và một Sec-WebSocket-Key ngẫu nhiên. Nếu server đồng ý, nó trả về 101 Switching Protocols cùng một Sec-WebSocket-Accept được suy ra từ key đó (SHA-1 của key + một GUID cố định, rồi encode base64). Sau khi có 101, các byte trên đường truyền không còn là HTTP nữa — chúng là WebSocket frame.

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

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

Frames: dữ liệu đi trong các message được đóng frame nhỏ, mang một opcode (text, binary, ping, pong, close), một độ dài payload, và — theo chiều client→server — một masking key. Các control frame (ping/pong) giữ kết nối sống và phát hiện peer đã chết.

// Server: Node.js with the "ws" library
import { WebSocketServer } from "ws";
const wss = new WebSocketServer({ port: 8080 });
wss.on("connection", (ws) => {
  ws.send("welcome");
  ws.on("message", (buf) => {
    const msg = buf.toString();
    // broadcast to everyone
    for (const client of wss.clients) {
      if (client.readyState === client.OPEN) client.send(msg);
    }
  });
});

// Client: browser WebSocket API
const ws = new WebSocket("wss://example.com/chat");
ws.onopen = () => ws.send("hello");
ws.onmessage = (e) => console.log("got:", e.data);
ws.onclose = () => console.log("closed"); // no auto-reconnect — you implement it

Khi nào dùng: tương tác hai chiều thực sự, độ trễ thấp — chat, game nhiều người, collaborative editing, giao dịch trực tuyến, điều khiển IoT. Cần lưu ý: không có reconnect sẵn (khác SSE, bạn tự viết backoff), bạn phải gửi ping/heartbeat định kỳ để phát hiện kết nối hỏng và đánh bại idle timeout, dùng wss:// (TLS) trong production, và luôn validate header Origin để chống cross-site WebSocket hijacking.

WebTransport / HTTP/3 datagrams (hiện đại)

WebTransport là một API browser mới hơn được xây trên HTTP/3 (QUIC). Nó cung cấp nhiều stream độc lập, đúng thứ tự, tin cậy cùng với datagram không đảm bảo (unreliable) trên một kết nối duy nhất — mà không bị TCP head-of-line blocking (một packet chậm/mất trên một stream không làm nghẽn các stream khác). Datagram cho phép kiểu phân phối “fire and forget” lý tưởng cho state game hay media, nơi một update bị rớt còn tốt hơn một update bị trễ. Đây là kẻ kế nhiệm đang nổi cho các use case mà WebSockets bắt đầu đuối (nhiều stream song song, hoặc dữ liệu nhạy latency chấp nhận mất mát), dù hỗ trợ của browser và hạ tầng vẫn đang hoàn thiện — hãy coi nó là hướng tương lai, với WebSockets là mặc định của hiện tại.

Bảng so sánh

Kỹ thuật	Hướng	Kết nối	Overhead đường truyền	Độ phức tạp	Phù hợp nhất cho
Short polling	Client kéo (pull)	Request mới mỗi lần poll	Cao (headers mỗi poll, gọi phí phạm)	Rất thấp	Kiểm tra trạng thái thưa, fallback đơn giản nhất
Long polling	Server→client (giả lập)	Giữ request, mở lại mỗi message	Trung bình (một round-trip mỗi message)	Thấp–trung bình	Gần real-time mà không cần protocol đặc biệt
SSE	Chỉ server→client	Một HTTP response sống lâu	Thấp (frame text, auto-reconnect)	Thấp	Dashboard, notification, feed, stream token
WebSockets	Full-duplex	Một kết nối TCP bền vững	Rất thấp (frame nhỏ)	Trung bình–cao	Chat, game, collaboration, app hai chiều
WebTransport (HTTP/3)	Full-duplex + datagram	Một kết nối QUIC, nhiều stream	Rất thấp, không HOL blocking	Cao (mới, ít hỗ trợ)	Dữ liệu throughput cao / lossy latency thấp

Best Practices

Chọn đúng kỹ thuật

Bắt đầu từ yêu cầu, không phải từ công nghệ. Chỉ cần cập nhật server→client trên hạ tầng HTTP tiêu chuẩn? Hãy nghĩ tới SSE trước — nó đơn giản hơn và reconnect miễn phí. Cần trao đổi hai chiều độ trễ thấp (typing indicator, presence, con trỏ live)? Dùng WebSockets. Không giữ kết nối được (proxy hạn chế, serverless)? Long polling là fallback bền bỉ. Chỉ cần độ tươi thi thoảng? Short polling là ổn và rẻ nhất để vận hành. Nhiều hệ thống production xếp chồng các kỹ thuật này (WebSockets với fallback SSE hoặc long polling), đó chính xác là điều các thư viện như Socket.IO làm giúp bạn.

Scale hệ thống real-time

Đây là chỗ real-time trở nên khó. Một HTTP API stateless scale bằng cách thêm server sau một load balancer; một hệ thống real-time còn phải định tuyến message tới đúng server đang giữ kết nối mở của người nhận.

Sticky sessions. Kết nối của một client sống trên đúng một server cụ thể. Load balancer của bạn phải gửi traffic (và mọi lần reconnect) của client đó về đúng instance ban đầu — qua sticky sessions (session affinity theo cookie hoặc IP hash). Không có stickiness, một lần reconnect có thể rơi vào một server không biết client này, và luồng long-polling/handshake sẽ hỏng.

Pub/sub backplane (Redis). Khi các kết nối rải khắp nhiều server, server A phải phân phối một message tới một user đang kết nối với server B. Giải pháp chuẩn là một backplane: mọi server đăng ký một kênh pub/sub chung (thường là Redis Pub/Sub, hoặc một message broker — xem ./15-message-brokers-and-async.md). Khi bất kỳ server nào nhận được message, nó publish lên backplane; mỗi server sau đó đẩy tới các subscriber đang kết nối cục bộ với nó.

1. 01client
2. ws
   02WS server A
3. publish
   03Redis Pub/Sub
4. 04WS server B
5. ws
   05client

// Fan-out across instances via Redis
import Redis from "ioredis";
const pub = new Redis(), sub = new Redis();
sub.subscribe("room:42");
sub.on("message", (_ch, payload) => {
  // deliver to this server's local sockets in room 42
  for (const ws of localSocketsInRoom("42")) ws.send(payload);
});
// when a message arrives on any server:
function onIncoming(msg) { pub.publish("room:42", JSON.stringify(msg)); }

Horizontal scaling & giới hạn kết nối. Hãy hoạch định capacity quanh số kết nối đồng thời (concurrent connections), không phải request/giây: tinh chỉnh giới hạn file descriptor của OS (ulimit -n), các thiết lập socket của kernel, và bộ nhớ mỗi process. Ưu tiên server async/event-driven (Node.js, Go, hoặc async Python/Java) không dành riêng một thread cho mỗi kết nối. Thêm instance theo chiều ngang phía sau backplane, và từ chối/loại bỏ kết nối một cách nhẹ nhàng khi một node bão hòa thay vì làm mọi người cùng chậm. Xem ./17-scalability-and-reliability.md cho load balancing, hoạch định capacity, và các pattern về reliability — tất cả đều áp dụng ở đây.

Reliability và tính đúng đắn

• Heartbeats. Gửi ping định kỳ (WebSocket ping/pong hoặc dòng comment của SSE :\n\n) để phát hiện kết nối half-open và tránh bị proxy ngắt do idle.
• Reconnect kèm backoff. SSE tự reconnect; với WebSockets, hãy tự implement exponential backoff kèm jitter, và resume state bằng một cursor/Last-Event-ID để không bỏ sót hay lặp event.
• Thứ tự & phân phối message. TCP đảm bảo phân phối đúng thứ tự trong một kết nối, nhưng không xuyên qua reconnect hay nhiều server. Hãy gắn sequence ID và cho client yêu cầu resync khi có khoảng trống.
• Backpressure. Một client chậm có thể khiến server buffer không giới hạn. Theo dõi buffer gửi ra của từng kết nối và drop, gộp (coalesce), hoặc ngắt các consumer chậm.
• Security. Luôn dùng TLS (wss:// / HTTPS). Xác thực kết nối (token trong handshake), phân quyền từng subscription/room, validate header Origin, và rate-limit message đầu vào.

Use case và pattern real-time

• Chat & messaging — WebSockets full-duplex; presence và typing indicator qua các event nhẹ; một broker/backplane để fan-out tới các room.
• Notification — thường là một chiều; SSE rất hợp và rẻ hơn WebSockets.
• Live dashboard & ticker — SSE hoặc WebSockets stream metric; gộp các update tần suất cao về một tick cố định để bảo vệ client.
• Collaborative editing — full-duplex kèm giải quyết xung đột (OT hoặc CRDT) đặt trên transport; latency thấp và đúng thứ tự là quan trọng nhất.
• Streaming response (ví dụ token của LLM) — SSE stream các token ngay khi chúng được sinh ra.

Về cách server phơi bày những thứ này qua HTTP và thương lượng protocol, xem ./06-apis.md; về việc phân phối event bền vững, tách rời (decoupled) phía sau lớp real-time, xem ./15-message-brokers-and-async.md.

Tài liệu tham khảo

• MDN — WebSocket API
• MDN — Server-Sent Events / Using EventSource
• RFC 6455 — The WebSocket Protocol
• WHATWG HTML — Server-sent events specification
• MDN — WebTransport API
• Redis — Pub/Sub
• Ably — WebSockets vs SSE vs long polling

// Client: ask every 3 seconds
async function shortPoll() {
  const res = await fetch("/api/messages?since=" + lastSeenId);
  const data = await res.json();
  if (data.length) render(data);
}
setInterval(shortPoll, 3000);

// Client: reconnect as soon as each response arrives
async function longPoll() {
  try {
    const res = await fetch("/api/messages/stream?since=" + lastSeenId);
    const data = await res.json();
    if (data.length) { render(data); lastSeenId = data.at(-1).id; }
  } catch (e) {
    await sleep(1000); // back off on error
  }
  longPoll(); // immediately re-establish
}
longPoll();

// Server (Express-ish): hold the response until an event or timeout
app.get("/api/messages/stream", async (req, res) => {
  const since = Number(req.query.since);
  const timeout = setTimeout(() => res.json([]), 25000); // avoid proxy idle-kill
  emitter.once("message", (msg) => {
    if (msg.id > since) { clearTimeout(timeout); res.json([msg]); }
  });
});

// Client: one line to subscribe
const es = new EventSource("/api/events");
es.onmessage = (e) => console.log("data:", e.data);
es.addEventListener("price", (e) => updateTicker(JSON.parse(e.data)));
es.onerror = () => {/* EventSource auto-reconnects; no code needed */};

// Server: stream text/event-stream frames
app.get("/api/events", (req, res) => {
  res.set({
    "Content-Type": "text/event-stream",
    "Cache-Control": "no-cache",
    "Connection": "keep-alive",
  });
  const send = (event, data, id) => {
    if (id) res.write(`id: ${id}\n`);
    if (event) res.write(`event: ${event}\n`);
    res.write(`data: ${JSON.stringify(data)}\n\n`); // blank line ends the event
  };
  const timer = setInterval(() => send("price", { sym: "AAPL", px: 199.9 }, Date.now()), 1000);
  req.on("close", () => clearInterval(timer));
});

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

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

// Server: Node.js with the "ws" library
import { WebSocketServer } from "ws";
const wss = new WebSocketServer({ port: 8080 });
wss.on("connection", (ws) => {
  ws.send("welcome");
  ws.on("message", (buf) => {
    const msg = buf.toString();
    // broadcast to everyone
    for (const client of wss.clients) {
      if (client.readyState === client.OPEN) client.send(msg);
    }
  });
});

// Client: browser WebSocket API
const ws = new WebSocket("wss://example.com/chat");
ws.onopen = () => ws.send("hello");
ws.onmessage = (e) => console.log("got:", e.data);
ws.onclose = () => console.log("closed"); // no auto-reconnect — you implement it

// Fan-out across instances via Redis
import Redis from "ioredis";
const pub = new Redis(), sub = new Redis();
sub.subscribe("room:42");
sub.on("message", (_ch, payload) => {
  // deliver to this server's local sockets in room 42
  for (const ws of localSocketsInRoom("42")) ws.send(payload);
});
// when a message arrives on any server:
function onIncoming(msg) { pub.publish("room:42", JSON.stringify(msg)); }