Khi nào nên dùng WebSockets, SSE, hay long-polling thay cho HTTP thường?

Question

IT Interview Practice · Accepted Answer

HTTP thường là **request/response**: client hỏi, server đáp, xong. Điều đó không hợp với các tính năng **real-time** (chat, dashboard trực tiếp, thông báo, chỉnh sửa cộng tác) nơi *server* cần đẩy dữ liệu bất cứ khi nào nó có cái mới. Các lựa chọn là những cách vòng qua mô hình client-khởi-xướng của HTTP, trải trên một phổ độ phức tạp:

```text
Long-polling   client ──req──▶ server ...holds... ──resp──▶ then immediately re-asks
               (near-real-time over plain HTTP; one message per held request)

SSE            client ──req──▶ server ═══stream of events═══▶ (one-way, server→client)
               (HTTP-based, text, auto-reconnect; NO client→server on same channel)

WebSocket      client ──handshake──▶ server ══full-duplex, both directions══▶
               (persistent TCP; low overhead; binary or text; you build the rest)
```

**Long-polling** là phương án dự phòng chạy được ở mọi nơi: client gửi một request bình thường mà server giữ mở cho tới khi có dữ liệu, rồi client lập tức hỏi lại. Nó xấp xỉ push trên HTTP thường nhưng lãng phí một chu kỳ request mỗi thông điệp và thêm độ trễ.

**SSE (Server-Sent Events)** là một luồng **một chiều** (server → client) nhẹ, đã chuẩn hoá, trên một response HTTP dài duy nhất. Nó lý tưởng khi chỉ có server đẩy — feed trực tiếp, thông báo, tiến độ, stream token LLM. Nó đơn giản, chạy trên HTTP/2 bình thường (không cần hạ tầng đặc biệt), và tự động kết nối lại. Giới hạn: nó một chiều và chỉ text.

**WebSockets** nâng cấp một kết nối HTTP đơn thành một kênh TCP **full-duplex** bền bỉ, nơi cả hai bên gửi bất cứ lúc nào với overhead mỗi thông điệp tối thiểu. Dùng nó cho tương tác thật sự hai chiều, độ trễ thấp: chat, game nhiều người, editor cộng tác, giao dịch. Cái giá là vận hành — đó là một kết nối có trạng thái mà proxy, load balancer và autoscaler phải được cấu hình cho, và bạn phải tự dựng reconnect, heartbeat và backpressure.

**Nguyên tắc ngón tay cái:** mặc định dùng HTTP thường; dùng **SSE** cho stream server→client; chỉ với tới **WebSockets** khi bạn thực sự cần real-time hai chiều; giữ **long-polling** làm phương án dự phòng phổ quát.

## Tại sao điều này quan trọng

Chọn một transport real-time là một quyết định thiết kế cấp senior kinh điển, nơi câu trả lời ngây thơ ("cứ dùng WebSockets cho mọi thứ") thường là sai. Người phỏng vấn muốn thấy bạn khớp công cụ với *mẫu giao tiếp* — một chiều vs hai chiều, nhu cầu độ trễ, khối lượng thông điệp — và bạn cân nhắc **chi phí vận hành** của các kết nối có trạng thái, sống lâu: sticky session, mở rộng quy mô, proxy timeout, và logic reconnect. Nhận ra rằng SSE thường bao trọn "server đẩy cập nhật" đơn giản hơn WebSockets, và long-polling vẫn là phương án dự phòng chắc chắn, cho thấy kinh nghiệm production thật thay vì với lấy lựa chọn hào nhoáng nhất.

Tại sao điều này quan trọng

Câu hỏi liên quan