WebSocket: как это работает на практике

Question

Accepted Answer

WebSocket — постоянный двунаправленный канал поверх TCP после HTTP-upgrade handshake. Сообщения идут **фреймами** с минимальным заголовком; переподключение, heartbeat и масштабирование — ваша ответственность.

## Разбор

**Upgrade-handshake.** Клиент шлёт `Sec-WebSocket-Key` (случайный nonce); сервер хеширует его с фиксированным GUID и возвращает `Sec-WebSocket-Accept`, доказывая поддержку протокола (не безопасность — только совместимость). После `101` соединение становится двунаправленным бинарным каналом через `ws://` (или `wss://` поверх TLS — всегда используйте `wss://`).

**Фрейминг.** Сообщения передаются **фреймами** с небольшим заголовком (от 2 байт) — намного дешевле HTTP-заголовков и cookies на каждый запрос. Фреймы несут текст или бинарные данные; есть **управляющие фреймы**: `ping`/`pong` (heartbeat) и `close`.

**Проблемы, которые HTTP решал за вас, теперь решаете вы:**

- **Переподключение.** TCP-соединения рвутся — Wi-Fi, сон ноутбука, таймауты прокси, смена сети на мобильном. Встроенного reconnect нет. Нужно обнаруживать обрыв и переподключаться с **экспоненциальным backoff + jitter** (иначе — thundering herd при восстановлении).
- **Heartbeat / обнаружение мёртвого соединения.** Соединение может быть **молча мёртвым** — `close`-фрейм не приходит, а код думает, что канал открыт («half-open»). Шлёте `ping` по интервалу; отсутствие `pong` = мёртвое соединение. Без этого пишете в пустоту.
- **Порядок и доставка.** WebSocket гарантирует порядок (это TCP), но **не доставку через reconnect** — сообщения, отправленные пока вы были offline, пропадают. Реальные приложения добавляют sequence numbers, acks, cursor для догрузки пропущенного.
- **Backpressure.** Если пушите быстрее, чем клиент читает, `ws.bufferedAmount` растёт и память раздувается. Нужно проверять и throttle.

**Auth неудобен.** Конструктор `WebSocket` в браузере не позволяет кастомные заголовки — нельзя отправить `Authorization: Bearer`. Типичные паттерны: короткоживущий токен в query URL (логируется везде — лучше one-time ticket), cookie (CORS/SameSite), или auth в *первом сообщении* после connect.

**Масштабирование stateful.** Каждое соединение привязано к одному серверу на всё время жизни — противоположность stateless HTTP. Для broadcast между серверами нужен **pub/sub backbone** (Redis, Kafka). Load balancer'ам нужны sticky sessions или connection-aware routing.

## Итог

WebSocket даёт дешёвый duplex-real-time, но вы сами строите reconnect, heartbeat, auth и горизонтальное масштабирование через pub/sub.