WebSocket vs SSE vs long-polling: выбор правильного транспорта

Прежде чем тянуться за WebSocket, спросите: действительно ли нужна двусторонняя связь? SSE покрывает 90% сценариев «сервер должен пушить» — без собственной логики реконнекта и с куда более дружелюбными прокси. Неправильный выбор транспорта стоит недель отладки или ненужной сложности.

Три транспорта, три модели

WebSocket — full-duplex, минимальные накладные расходы

После upgrade-handshake любая сторона отправляет фреймы в любой момент. Накладные расходы на сообщение: 2–6 байт. Сервер может пушить без запроса клиента; клиент может отправлять без нового HTTP-соединения. Это правильный выбор когда:

• Клиент часто отправляет данные (игровой ввод, совместное редактирование, торговые заявки).
• Бюджет задержки менее 10 мс.
• Вы контролируете прокси/инфраструктуру (или знаете, что она поддерживает Upgrade).

Минус: нет встроенного реконнекта. Если соединение обрывается (idle timeout прокси, сетевой глюк), код должен обнаружить close-код 1006 и переподключиться с backoff.

SSE — server push, браузер обрабатывает всё

SSE использует обычный постоянный HTTP-ответ с Content-Type: text/event-stream. Сервер пишет события, разделённые переводом строки:

event: price-update
data: {"symbol":"AAPL","price":182.34}
id: 4291

Нативный API браузера EventSource парсит события и автоматически переподключается с заголовком Last-Event-ID при обрыве соединения. Задержка: 3–8 мс. Ноль кода реконнекта писать не нужно. Работает через любой HTTP/1.1-прокси, включая корпоративные файрволы.

SSE неподходящ когда:

• Клиенту нужно отправлять данные (нужен отдельный REST-эндпоинт, что неудобно).
• Нужны бинарные payload (SSE — только текст).

Long-polling — универсальный запасной вариант

Клиент открывает HTTP-запрос, сервер держит его открытым до появления данных (или до таймаута). Когда сервер отвечает, клиент сразу открывает новый запрос. Это симулирует server push через обычный HTTP.

Задержка = время ожидания сервера + один RTT. В лучшем случае 100 мс для сервера, ответившего сразу. В худшем — 60+ секунд для сервера с длинным таймаутом перед пустым ответом.

Накладные расходы высоки: каждый опрос несёт полные HTTP-заголовки (~500+ байт). При 50 000 клиентов, опрашивающих каждые 100 мс — 500 000 HTTP-запросов/секунду. Ни одно современное приложение не использует long-polling как основной транспорт — это graceful fallback для сред, блокирующих WebSocket.

Согласование subprotocol и расширений

Клиент может запросить subprotocol прикладного уровня во время upgrade:

Sec-WebSocket-Protocol: chat, superchat

Сервер выбирает один и возвращает его обратно. Subprotocol’ы позволяют командам версионировать формат сообщений не затрагивая WebSocket-уровень — chat использует JSON, superchat — компактный бинарный формат. Если сервер не возвращает subprotocol-заголовок, соединение не имеет именованного протокола (это допустимо; приложение неявно определяет формат сообщений).

Расширения работают аналогично через Sec-WebSocket-Extensions. Важнейшее расширение на практике — permessage-deflate (RFC 7692): DEFLATE-сжатие на сообщение. На текстовых payload (JSON, HTML) типичная степень сжатия 50–90%. На маленьких сообщениях (< 64 байт) сжатие может увеличить payload. На уже сжатых данных (изображения, видео) — никакого эффекта. Затраты памяти значительны: при настройках по умолчанию каждый компрессор потребляет ~256 КБ, каждый декомпрессор ~44 КБ — при 100k idle-соединений это ~25 ГБ RAM только на состояние сжатия. Большинство production-инсталляций отключают permessage-deflate по умолчанию.