Backpressure в WebSocket: когда клиенты не успевают

Ваш WebSocket broadcast-сервер на тестах справляется с 10 000 клиентами. В production 100 клиентов на медленном мобильном интернете начинают отставать. Память сервера растёт. GC-паузы удлиняются. Потом срабатывает OOM killer и укладывает весь сервис. Это классический режим отказа WebSocket — и он не имеет никакого отношения к протоколу.

TCP-окно приёма с точки зрения приложения

TCP даёт каждому сокету окно приёма — количество байт, которые получатель готов принять, прежде чем отправитель должен приостановиться. Когда приложение на принимающей стороне читает байты, окно открывается; когда отстаёт — окно сжимается до нуля и отправитель останавливается.

С точки зрения сервера:

1. Сервер вызывает send(socket, message).
2. Ядро копирует сообщение в буфер отправки сокета.
3. TCP передаёт из буфера отправки с учётом рекламируемого клиентом окна приёма.
4. Если окно клиента равно нулю (его буфер чтения заполнен), TCP прекращает передачу.
5. Вызов send() ядра блокируется, если буфер отправки заполнен, или возвращает EAGAIN в неблокирующем режиме.

Для broadcast-сервера с тысячами клиентов это создаёт критическую асимметрию: быстрые клиенты опустошают буферы за миллисекунды; медленные оставляют байты лежать в буферах отправки ядра, и когда те заполняются — сервер застревает.

Очередь отправки на уровне приложения

Production WebSocket-серверы никогда не блокируются на send(). Вместо этого они поддерживают очередь отправки уровня приложения на соединение. Когда сервер рассылает сообщение, он ставит его в очередь для каждого соединения и сразу возвращает управление. Фоновый поток записи опустошает каждую очередь в ядро так быстро, как позволяет TCP-окно клиента.

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

Рассмотрим сценарий:

• Сервер рассылает сообщение 100 КБ каждые 10 мс.
• 100 из 10 000 клиентов медленные — запросы к БД блокируют их поток чтения.
• Очередь каждого медленного клиента растёт: 100 сообщений/секунду × 100 КБ = 10 МБ/секунду.
• Через 10 секунд: 100 медленных клиентов × 10 МБ × 10 с = 10 ГБ RAM в очередях.
• Срабатывает OOM killer.

Паттерн high-water mark

Решение — high-water mark: ограничение очереди на соединение, триггерирующее вытеснение или backpressure.

Когда очередь соединения превышает high-water mark (например, 100 сообщений или 10 МБ), сервер выбирает:

Вариант A — вытеснить соединение. Принудительно закрыть медленного клиента с кодом 1013 (“try again later”). Клиент переподключится когда сеть освободится. Другие клиенты не затронуты. Стандартный выбор для broadcast-сервисов.

Вариант B — дропать сообщения. Для идемпотентных данных (биржевые цены, снимки игрового состояния), где последнее значение заменяет предыдущее — дропать старые сообщения и оставлять только N последних на соединение. Медленный клиент получит актуальное состояние при переподключении, а не устаревшую историю.

Вариант C — приостановить продюсера. Для peer-to-peer стримов (видеоконференции, передача файлов) — сигнализировать отправляющему приложению приостановиться до опустошения очереди ниже low-water mark. Это полное распространение backpressure.

Режим отказа из-за idle timeout прокси

Есть второй распространённый режим отказа: прокси между клиентом и сервером имеет 60-секундный idle timeout. Если в течение 60 секунд через TCP-соединение не проходят байты, прокси закрывает его — без отправки WebSocket close-фрейма.

Клиент и сервер об этом не подозревают, пока сервер не попытается отправить следующее сообщение: send() вернёт EPIPE или ECONNRESET. Клиент увидит событие close с кодом 1006 (аномальное закрытие). Соединение мертво.

Решение: сервер отправляет ping-фрейм каждые 25–30 секунд. Ping сбрасывает таймер idle прокси. Клиент должен ответить pong в разумное время (сервер может вытеснять клиентов, не ответивших pong в течение 10 секунд, как очистку устаревших соединений).

2026-05-15T14:32:00Z broadcast_service[5234]:
active_connections: 50234
total_queued_bytes: 8589934592  (8 ГБ)
slow_client_count: 127
p95_queue_depth: 156 сообщений
p99_queue_depth: 341 сообщений
broadcast_latency_p99: 18432мс
memory_usage: 15.2 ГБ / 16 ГБ кучи
gc_pause_time: 1247мс

2026-05-15T14:32:15Z broadcast_service[5234]:
active_connections: 49891  (-343 за 15с)
total_queued_bytes: 10737418240  (10 ГБ)
slow_client_count: 412
p95_queue_depth: 287 сообщений
p99_queue_depth: 502 сообщений
broadcast_latency_p99: 32568мс
memory_usage: 15.8 ГБ / 16 ГБ кучи
gc_pause_time: 2100мс

2026-05-15T14:32:30Z broadcast_service[5234]: OOM killer вызван; процесс убит