Real-time: Polling vs SSE vs WebSocket

Пользователи ожидают мгновенные обновления: сообщения появляются сразу, уведомления приходят в момент события. Выбор правильного real-time протокола влияет на UX, серверные затраты и сложность кода.

• **Slack/Discord**: WebSocket для сообщений (bidirectional), fallback на long polling при проблемах с соединением
• **GitHub**: SSE для live updates в pull requests, issues, actions - server push достаточен
• **Trading platforms**: WebSocket для минимальной latency при высокочастотных обновлениях котировок

Предварительные знания

• WebSocket: Two-Way Communication

Short Polling

**Short Polling** - простейший способ получения обновлений: клиент периодически опрашивает сервер. Запрос каждые N секунд, независимо от наличия новых данных.

**Проблемы short polling**: избыточные запросы (большинство пустые), задержка до интервала опроса (5 сек = avg 2.5 сек delay), нагрузка на сервер даже без активности.

Short polling подходит когда: real-time не критичен (обновление раз в минуту), инфраструктура не поддерживает long-lived connections, простота важнее эффективности.

Long Polling

**Long Polling** - клиент делает запрос, сервер держит соединение открытым до появления данных или timeout. Получив ответ, клиент немедленно делает новый запрос.

**Long polling эффективнее** short polling: запросы только при событиях или timeout. Latency почти real-time - сообщение доставляется когда сервер его получил.

Facebook Messenger и Slack изначально использовали long polling. Недостаток: каждое сообщение требует нового HTTP запроса (overhead заголовков). Много открытых соединений на сервере.

Server-Sent Events

**SSE (Server-Sent Events)** - HTTP-based протокол для push от сервера к клиенту. Одно долгоживущее соединение, сервер отправляет события в text/event-stream формате.

**SSE преимущества**: автоматический reconnect, Last-Event-ID для recovery, работает через HTTP/2, нативная поддержка браузера. GitHub использует SSE для live updates.

WebSocket Deep Dive

**WebSocket** - полнодуплексный протокол поверх TCP. После HTTP handshake переключается на binary frame protocol. Минимальный overhead (2-14 байт на фрейм).

**WebSocket vs SSE overhead**: SSE каждое сообщение ~100 bytes headers (event, data, newlines). WebSocket: 2-6 bytes на фрейм. При высокой частоте сообщений разница ощутима.

WebSocket сложности: нет автоматического reconnect (нужна своя логика), некоторые прокси/firewall блокируют, масштабирование требует sticky sessions или pub/sub (Redis). Socket.IO решает эти проблемы.

Choosing the Right Approach

Выбор между polling, SSE и WebSocket зависит от паттерна коммуникации, частоты сообщений, требований к latency и инфраструктурных ограничений.

**Гибридный подход**: начинайте с SSE для server push, добавляйте WebSocket только если нужен bidirectional. Slack использует WebSocket для сообщений, но REST API для всего остального.

HTTP/3 (QUIC) и WebTransport меняют ландшафт: WebTransport даёт bidirectional streams поверх HTTP/3 с мультиплексированием. Но пока широко не поддерживается.

Итоги

• **Polling**: простой но неэффективный - только для редких обновлений
• **Long Polling**: улучшенный polling, но всё ещё HTTP overhead на каждое сообщение
• **SSE**: оптимален для server→client push, auto-reconnect, Last-Event-ID
• **WebSocket**: bidirectional, минимальный overhead, но сложнее масштабировать

Связанные темы

Real-time протоколы связаны с архитектурой масштабируемых систем:

• WebSocket Protocol — Детальное изучение WebSocket протокола
• Message Queues — Backend pub/sub для fan-out WebSocket сообщений
• System Design: Chat — Применение real-time протоколов в chat архитектуре

Вопросы для размышления

• Как бы вы реализовали graceful degradation: WebSocket → SSE → Long Polling?
• Как доставить WebSocket сообщение пользователю, подключённому к другому серверу в кластере?
• Когда HTTP/3 WebTransport заменит WebSocket?

Связанные уроки

• rt-06