Realtime и WebSockets

01Polling, long-polling, SSE и WebSockets

Polling — это вопрос «есть что-нибудь новое?» каждые несколько секунд. Он простой и работает везде, но тратит запросы впустую и добавляет задержку. Long-polling держит каждый запрос открытым, пока у сервера не появятся новости или не сработает таймаут, после чего клиент переподключается; меньше потерь, больше сложности. Server-Sent Events (SSE) держат открытым один HTTP-ответ, и сервер стримит по нему текстовые события; это односторонний канал (от сервера к клиенту), он автоматически переподключается и хорошо работает через прокси и HTTP/2. WebSockets открывают полноценный двусторонний канал поверх одного TCP-соединения — идеально, когда клиент тоже часто отправляет сообщения, как в чате, совместном редактировании или играх. Эмпирическое правило: polling для редких обновлений, SSE для потоков от сервера к клиенту вроде уведомлений или стриминга токенов AI, WebSockets для интерактивного двустороннего трафика.

02Как работает WebSocket-соединение

WebSocket начинается как обычный HTTP-запрос с просьбой сменить протокол (upgrade). Если сервер согласен, он отвечает 101 Switching Protocols, и с этого момента то же TCP-соединение передаёт уже не HTTP, а WebSocket-фреймы. Фреймы — это небольшие пакеты: фреймы данных (текстовые или бинарные) и управляющие фреймы для ping, pong и close. Фреймы от клиента к серверу маскируются. Ping и pong поддерживают соединение живым и помогают обнаружить «мёртвых» собеседников. Поскольку upgrade происходит через HTTP, соединение проходит через балансировщики и reverse proxy, но их нужно настроить так, чтобы они разрешали upgrade и долгоживущие соединения. В продакшене всегда используйте wss:// (TLS).

1GET /ws HTTP/1.1
2Host: api.example.com
3Upgrade: websocket
4Connection: Upgrade
5Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
6Sec-WebSocket-Version: 13
7 
8HTTP/1.1 101 Switching Protocols
9Upgrade: websocket
10Connection: Upgrade
11Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

03socket.io: namespaces, комнаты и авторизация

socket.io — библиотека поверх WebSockets, которая добавляет автоматическое переподключение, подтверждения (acknowledgements), откат на long-polling и простую модель группировки соединений. Namespace (например, /staff или /customers) — отдельный канал со своими middleware, удобный для разных аудиторий. Комната — группа внутри namespace; сервер добавляет сокеты в комнаты и отправляет событие сразу всей комнате. Типичные комнаты: по одной на тенанта, филиал, терминал и пользователя. Аутентифицируйте в middleware рукопожатия, до того как соединение принято, и решайте о членстве в комнатах на сервере на основе проверенной личности. Никогда не позволяйте клиенту войти в комнату только потому, что он об этом попросил.

1io.of('/staff').use(async (socket, next) => {
2  try {
3    socket.data.user = await verifyAccessToken(socket.handshake.auth.token);
4    next();
5  } catch {
6    next(new Error('unauthorized'));
7  }
8});
9 
10io.of('/staff').on('connection', (socket) => {
11  const { companyId, branchId, sub } = socket.data.user;
12  socket.join(['company:' + companyId, 'branch:' + branchId, 'user:' + sub]);
13});
14 
15// elsewhere, after an order changes:
16io.of('/staff').to('branch:' + order.branchId).emit('order.updated', { id: order.id, status: order.status, version: order.version });

04Масштабирование на несколько серверов с Redis

Один процесс знает только о своих подключённых сокетах. Когда вы запускаете четыре экземпляра API, пользователь, подключённый к экземпляру A, не увидит событие, отправленное на экземпляре B. Решение — общая шина сообщений. Redis-адаптер socket.io публикует каждую отправку в комнату в Redis pub/sub; каждый экземпляр подписан и доставляет событие своим локальным сокетам. Если вы используете откат socket.io на long-polling за балансировщиком, включите sticky sessions, чтобы запросы клиента попадали на один и тот же экземпляр; при транспорте только через WebSocket это не нужно. Для очень большого fan-out или гарантированной доставки есть Redis Streams или шардированный адаптер. Отправляйте события и из фоновых воркеров через тот же адаптер (пакет socket.io emitter), чтобы задача в очереди могла напрямую уведомлять пользователей.

1import { createClient } from 'redis';
2import { createAdapter } from '@socket.io/redis-adapter';
3 
4const pub = createClient({ url: process.env.REDIS_URL });
5const sub = pub.duplicate();
6await Promise.all([pub.connect(), sub.connect()]);
7 
8io.adapter(createAdapter(pub, sub));

05Laravel: broadcasting через Pusher, Reverb и Echo

В Laravel broadcasting встроен. Вы помечаете событие интерфейсом ShouldBroadcast, указываете, в какой канал оно уходит, и Laravel отправляет его через драйвер. Pusher — облачный сервис: серверов держать не нужно, платите за соединения и сообщения. Reverb — собственный официальный WebSocket-сервер Laravel, работающий по протоколу Pusher, так что можно хостить его самому с тем же клиентским кодом. php artisan install:broadcasting всё настраивает. На фронтенде на каналы подписывается Laravel Echo. Приватные и presence-каналы авторизуются в routes/channels.php: Echo вызывает эндпоинт /broadcasting/auth, а ваш колбэк решает, может ли этот пользователь слушать канал. Ставьте broadcast-события в очередь, чтобы медленный сокет-сервер никогда не замедлял HTTP-ответ.

1// routes/channels.php
2Broadcast::channel('orders.{orderId}', function (User $user, int $orderId) {
3    return Order::whereKey($orderId)->where('customer_id', $user->id)->exists();
4});
5 
6// Frontend (Echo)
7echo.private('orders.' + orderId)
8    .listen('OrderStatusChanged', (e) => updateStatus(e.status));

06Переподключение, порядок и пропущенные сообщения

Мобильные сети постоянно обрываются, поэтому проектируйте с расчётом на разрывы. Клиенты переподключаются с экспоненциальной задержкой и jitter, чтобы перезапуск сервера не вызвал лавину из тысяч одновременных переподключений. События, отправленные, пока клиент был офлайн, в обычном pub/sub теряются. Относитесь к сокету как к сигналу «что-то изменилось», а REST API считайте источником истины: при переподключении заново запрашивайте текущее состояние. Добавляйте в каждое событие номер версии или временную метку, чтобы клиент мог игнорировать устаревшие или пришедшие не по порядку обновления. Если для одной сущности важен порядок, пускайте её события через один канал и обрабатывайте последовательно. Для критичных данных используйте подтверждения или сохраняемый лог событий с курсором «since».

• Держите payload маленьким: id и статус, а не объекты целиком.
• Отправляйте heartbeat; закрывайте и очищайте мёртвые соединения.
• Настройте таймауты прокси (nginx proxy_read_timeout) больше интервала ping.

07Ёмкость: файловые дескрипторы, прокси и heartbeats

Каждый открытый WebSocket — это открытый файловый дескриптор на сокет-сервере и на каждом прокси перед ним. Linux ограничивает их число на процесс, часто до 1,024 по умолчанию, поэтому первая стена при масштабировании — обычно «too many open files», а не CPU. Поднимите лимит для сервиса (ulimit -n, LimitNOFILE в systemd, minfds в supervisor), а в nginx увеличьте worker_connections и worker_rlimit_nofile, помня, что проксируемый сокет занимает в nginx два соединения: со стороны клиента и со стороны upstream. Следующий предел — память на соединение, поэтому измеряйте её под нагрузкой. Прокси закрывают простаивающие соединения: proxy_read_timeout в nginx по умолчанию 60 секунд, а socket.io по умолчанию пингует каждые 25 секунд, поэтому таймаут должен оставаться больше интервала пинга. У Laravel Reverb есть особая ловушка: его цикл stream_select по умолчанию ограничен примерно 1,024 соединениями, и сверх этого нужно расширение ext-uv.

1map $http_upgrade $connection_upgrade {
2    default upgrade;
3    ''      close;
4}
5 
6server {
7    location /socket.io/ {
8        proxy_pass http://127.0.0.1:3001;
9        proxy_http_version 1.1;
10        proxy_set_header Upgrade $http_upgrade;
11        proxy_set_header Connection $connection_upgrade;
12        proxy_set_header Host $host;
13        proxy_read_timeout 75s;   # above the 25 s ping interval plus timeout
14        proxy_send_timeout 75s;
15    }
16}

08Гарантии доставки: подтверждения и восстановление состояния

Обычный emit работает по принципу «отправил и забыл»: если сокет оборвался мгновение назад, сообщение пропало. socket.io предлагает два инструмента. Acknowledgements позволяют получателю подтвердить обработку, а emitWithAck с таймаутом превращает это в Promise, который можно ждать через await, так что сервер знает, напечатала ли касса чек на самом деле, и может повторить через очередь, если нет. Connection state recovery позволяет клиенту, переподключившемуся в пределах окна (по умолчанию две минуты), вернуть свой id, комнаты и пропущенные пакеты. У этого есть ограничения: покрываются только короткие разрывы, поддерживают это не все адаптеры (классический Redis pub/sub адаптер — нет, адаптер Redis Streams — да), и по умолчанию при восстановлении пропускается ваш auth middleware, что, возможно, стоит отключить. Для всего, что нельзя терять никогда, надёжным ответом остаётся сохраняемый журнал событий с курсором.

1const io = new Server(httpServer, {
2  connectionStateRecovery: {
3    maxDisconnectionDuration: 2 * 60 * 1000,
4    skipMiddlewares: false, // re-run auth on recovered connections
5  },
6});
7 
8try {
9  const replies = await io.to('terminal:' + terminalId)
10    .timeout(5_000)
11    .emitWithAck('receipt.print', { orderId });
12  logger.info({ replies }, 'terminal confirmed');
13} catch {
14  await printQueue.add('retry', { orderId, terminalId }); // no ack in time
15}

09Fan-out, горячие комнаты и троттлинг обновлений

Fan-out — это одно событие, доставленное множеству сокетов. Комната с 50,000 зрителей живого дашборда превращает один emit в 50,000 записей, умноженных адаптером на число экземпляров. Три техники держат это в рамках. Объединяйте: вместо отправки каждого изменения храните последнее состояние по каждой сущности и сбрасывайте не чаще, чем раз в несколько сотен миллисекунд, так что 40 обновлений остатков в секунду превращаются в два сообщения. Используйте volatile emits для данных, где важно только самое свежее значение, например позиции курсора или живые метрики: socket.volatile.emit отбрасывает пакет, если клиент не готов, а не буферизует его. Держите payload маленькими — только id и изменившиеся поля — и для большого объёма рассмотрите бинарный парсер вроде msgpack. Для множества экземпляров sharded Redis адаптер socket.io использует sharded pub/sub из Redis 7, так что трафик распределяется по Redis Cluster, а не каждый узел получает каждое сообщение.

• Измеряйте сообщения в секунду на комнату и на экземпляр, а не только количество соединений.
• Сжатие perMessageDeflate в socket.io по умолчанию выключено; оно стоит памяти на каждый сокет, поэтому включайте его, только когда payload большие.
• Очень горячие комнаты можно делить по регионам или шардам, а клиенты подключаются к одному шарду.

10Безопасность долгоживущих соединений

WebSockets обходят часть защит, на которые вы полагаетесь в HTTP. Браузеры отправляют cookies с WebSocket handshake, но CORS к нему не применяется, поэтому вредоносная страница может открыть сокет к вашему серверу с cookies пользователя: cross-site WebSocket hijacking. При аутентификации через cookie всегда проверяйте заголовок Origin по allow-list. Токен, проверенный при подключении, может истечь за часы до закрытия соединения, поэтому планируйте отключение в момент истечения токена или требуйте, чтобы клиент обновил токен и заново аутентифицировался через сокет. Относитесь к каждому входящему сообщению как к телу HTTP-запроса: валидируйте его схемой, проверяйте права на конкретное действие и ограничивайте частоту сообщений на сокет. Ограничьте размер сообщения: по умолчанию socket.io принимает до 1 MB на сообщение, а это гораздо больше, чем нужно большинству приложений.

1const io = new Server(httpServer, {
2  maxHttpBufferSize: 64 * 1024, // default is 1 MB
3  allowRequest: (req, cb) => cb(null, ALLOWED_ORIGINS.has(req.headers.origin ?? '')),
4});
5 
6io.on('connection', (socket) => {
7  const expiresInMs = socket.data.user.exp * 1000 - Date.now();
8  const timer = setTimeout(() => socket.disconnect(true), expiresInMs);
9  socket.on('disconnect', () => clearTimeout(timer));
10 
11  socket.on('cart.update', (raw, ack) => {
12    const msg = CartUpdateSchema.safeParse(raw);
13    if (!msg.success) return ack?.({ error: 'invalid_payload' });
14    // permission check, then handle msg.data
15  });
16});