Когда использовать WebSockets, SSE или long-polling вместо обычного HTTP?

Question

IT Interview Practice · Accepted Answer

Обычный HTTP — это **запрос/ответ**: клиент спрашивает, сервер отвечает, готово. Это плохо подходит для **реального времени** (чат, живые дашборды, уведомления, совместное редактирование), где *серверу* нужно проталкивать данные всякий раз, когда у него появляется что-то новое. Варианты — это способы обойти клиент-инициируемую модель HTTP, вдоль спектра сложности:

```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** — запасной вариант, который работает везде: клиент делает обычный запрос, который сервер держит открытым, пока не появятся данные, затем клиент немедленно повторяет запрос. Он приближает push поверх обычного HTTP, но тратит цикл запроса на каждое сообщение и добавляет задержку.

**SSE (Server-Sent Events)** — это лёгкий, стандартизированный **односторонний** поток (server → client) поверх одного долгоживущего HTTP-ответа. Он идеален, когда проталкивает только сервер — живые ленты, уведомления, прогресс, потоковые токены LLM. Он прост, работает поверх обычного HTTP/2 (без специальной инфраструктуры) и автоматически переподключается. Ограничение: он однонаправленный и только текстовый.

**WebSockets** обновляют одно HTTP-соединение до постоянного, **полнодуплексного** TCP-канала, где обе стороны отправляют в любой момент с минимальными накладными расходами на сообщение. Используйте его для по-настоящему двунаправленного, низколатентного взаимодействия: чат, многопользовательские игры, совместные редакторы, трейдинг. Цена — операционная: это соединение с состоянием, под которое должны быть настроены proxy, load balancer и автоскейлеры, и вы сами должны построить переподключение, heartbeats и backpressure.

**Правило большого пальца:** по умолчанию используйте обычный HTTP; используйте **SSE** для потоков server→client; прибегайте к **WebSockets**, только когда вам действительно нужно двунаправленное реальное время; держите **long-polling** как универсальный запасной вариант.

## Почему это важно

Выбор транспорта реального времени — классическое проектное решение уровня senior, где наивный ответ («просто используй WebSockets для всего») обычно неверен. Интервьюеры хотят видеть, что вы подбираете инструмент под *паттерн коммуникации* — односторонний против двунаправленного, требования к задержке, объём сообщений — и что вы взвешиваете **операционную цену** соединений с состоянием и долгой жизнью: sticky-сессии, масштабирование, таймауты proxy и логику переподключения. Осознание того, что SSE часто покрывает «сервер проталкивает обновления» проще, чем WebSockets, и что long-polling остаётся надёжным запасным вариантом, сигнализирует о реальном production-опыте, а не о тяге к самому эффектному варианту.

Почему это важно

Похожие вопросы