WebSocket в production: прокси, безопасность и распределённая архитектура

Вы деплоите WebSocket-сервер. Тесты проходят. В production соединения случайно обрываются через 60 секунд тишины, браузеры сообщают о 1006 в idle-периоды, а load balancer иногда возвращает 502 на upgrade. Ни одна из этих проблем — не баг в вашем приложении. Это неправильные настройки прокси, невидимые пока не знаешь куда смотреть.

Неправильные настройки прокси и load balancer

Прокси вроде Nginx, HAProxy и AWS ALB проектировались для HTTP — коротких запрос-ответных диалогов в миллисекундах. Постоянное WebSocket-соединение — чужеродно для них. Распространённые неправильные настройки:

Проблема 1 — Idle timeout закрывает тихие соединения.

• Nginx по умолчанию: proxy_read_timeout 60s (закрывает при отсутствии данных 60 секунд).
• AWS ALB по умолчанию: idle_timeout.timeout_seconds = 60.
• Решение: поднять до минимум 3 600 секунд (1 час).

location /ws {
  proxy_pass http://backend;
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "Upgrade";
  proxy_read_timeout 3600s;
  proxy_send_timeout 3600s;
  proxy_buffering off;
}

Проблема 2 — L7-буферизация задерживает ответ 101. Nginx по умолчанию буферизирует HTTP-ответы. Ответ 101 Switching Protocols удерживается в буфере до «завершения» — но WebSocket никогда не завершает ответ. Это может задержать upgrade на сотни миллисекунд. Решение: proxy_buffering off.

Проблема 3 — Прокси не понимает Upgrade-заголовок. Некоторые прокси вырезают или игнорируют Connection: Upgrade. Бэкенд видит запрос без Upgrade-заголовков и возвращает обычный HTTP-ответ вместо 101. Решение: явно установить оба заголовка как показано выше.

Проблема 4 — HTTP/2-прокси не пробрасывает WebSocket upgrade. Если прокси HTTP/2, а бэкенд HTTP/1.1, прокси может не знать как обработать WebSocket extended CONNECT. Решение: явно тестировать WebSocket через стек прокси при деплое, а не только HTTP-трафик.

Безопасность: проверки Origin, DoS и атаки медленного читателя

Проверка Origin. Браузер всегда отправляет заголовок Origin при WebSocket upgrade. Сервер обязан его проверять:

if request.headers["Origin"] not in ALLOWED_ORIGINS:
    respond 403 Forbidden
    return

WebSocket-клиент не в браузере не отправляет Origin-заголовок по умолчанию — если сервер его требует, небраузерные клиенты должны добавлять его явно. Это основная защита от cross-site WebSocket hijacking (CSWSH), где вредоносная страница на attacker.com открывает WebSocket к api.yoursite.com, используя cookies жертвы.

Rate limiting при handshake. Ботнеты могут исчерпать SYN-backlog TCP попытками соединения. Ограничивайте на load balancer: максимум попыток соединения с IP в секунду (обычно 5–20). Применяйте SYN cookies на уровне ОС (net.ipv4.tcp_syncookies = 1).

Атака медленного читателя (Slow Loris). Вредоносный клиент завершает WebSocket handshake, но никогда не читает из своего сокета. Очередь отправки сервера для этого соединения заполняется. Митигация: закрывать соединения без активности в течение 30 секунд (не отправлено и не получено ни одного сообщения, нет pong-ответа на ping).

Ограничение размера сообщения. Клиент, отправляющий сообщение 100 МБ, вынуждает сервер буферизировать 100 МБ на подписчика. Задавайте максимальный размер сообщения (обычно 64 КБ–1 МБ) и закрывайте соединение с кодом 1009 (“message too big”) при превышении.

Горизонтальное масштабирование: pub/sub и sticky sessions

Один WebSocket-сервер достигает потолка при 500k–2 M соединений. Дальше нужно несколько серверов с общим messaging backbone.

Pub/sub (Redis Streams или RabbitMQ). Каждый сервер подписывается на нужные каналы. Когда приложение публикует сообщение, все подписанные серверы рассылают его своим локально подключённым клиентам:

Пользователь A (подключён к Серверу 1) отправляет сообщение в чат.
Сервер 1 публикует { roomId, message, msgId } в Redis stream "room:42".
Сервер 2 (тоже подписан на "room:42") читает из stream.
Сервер 2 рассылает своим локально подключённым пользователям комнаты 42.

Это развязывает отправителей от получателей и позволяет горизонтальный масштаб без требования всем клиентам быть на одном сервере.

Sticky sessions. Когда load balancer маршрутизирует одного клиента на один и тот же сервер при реконнектах, in-flight состояние (неподтверждённые сообщения, частичные подписки) сохраняется без полной Redis-репликации. AWS ALB реализует это как target group stickiness (1-часовой cookie по умолчанию). Минус: сбой сервера отправляет всех sticky-клиентов переподключаться к другим серверам одновременно — мини thundering herd на каждый упавший инстанс.

Observability: метрики которые нужно экспортировать

WebSocket-сервис без этих метрик тихо умрёт от OOM:

Инструменты: netstat -an / ss -s для подсчёта состояния сокетов, tcpdump для трассировки на уровне пакетов, Prometheus для метрик приложения, eBPF-программы для размеров буферов сокетов и частоты ретрансмитов.