Разработка WebSocket API для веб-приложений под ключ

Представьте: ваш чат или дашборд тормозит из-за polling-запросов каждые 500 мс. Пользователи жалуются на задержки, а бэкенд захлёбывается от N+1 запросов. Решение — WebSocket: постоянное соединение с задержкой менее 10 мс вместо секунд. Замена polling на WebSocket снижает нагрузку на сеть и сервер в 10–20 раз, а также сокращает затраты на серверную инфраструктуру в 3-5 раз и экономит до 90% трафика. Мы разрабатываем такие realtime-системы уже более 5 лет и реализовали 30+ проектов для чатов, уведомлений и совместной работы. Двунаправленная связь по WebSocket позволяет мгновенно передавать обновления котировок, курсоры или игровые события — без лишнего оверхеда.

Какие проблемы решает WebSocket API?

• Высокая задержка при опросе: polling каждые 2 секунды даёт лаг до 2000 мс, WebSocket — единицы миллисекунд.
• Избыточный трафик: каждый poll-запрос отправляет HTTP-заголовки (700+ байт), WebSocket — лишь данные (несколько байт).
• Сложность с realtime-функциями: уведомления, курсоры, котировки — polling неэффективен.
• Разрывы соединения: мобильные сети и прокси закрывают idle-каналы — нужен heartbeat.
• Масштабирование: один сервер не выдерживает >10 тыс. коннектов — требуется кластеризация с Redis Pub/Sub.

Как мы разрабатываем WebSocket-решение

Начинаем с архитектурного проектирования: выбираем протокол (нативный WebSocket или Socket.io), определяем модель сообщений (JSON-схемы), продумываем аутентификацию и решаем вопросы масштабирования. Недавно мы реализовали WebSocket-сервер для финтех-стартапа: 50K одновременных подключений, задержка менее 10 мс, полное резервирование через Redis кластер. Ниже — типовой подход.

Базовая реализация с комнатами (Node.js + ws)

import { WebSocketServer } from 'ws';
import { createServer } from 'http';

const server = createServer(app);
const wss = new WebSocketServer({ server });
const rooms = new Map<string, Set<WebSocket>>();

wss.on('connection', (ws, req) => {
  const roomId = new URL(req.url!, 'http://x').searchParams.get('room');
  if (!roomId) return ws.close(4000, 'Missing room');
  if (!rooms.has(roomId)) rooms.set(roomId, new Set());
  rooms.get(roomId)!.add(ws);

  ws.on('message', (data) => {
    const message = JSON.parse(data.toString());
    rooms.get(roomId)?.forEach(client => {
      if (client !== ws && client.readyState === WebSocket.OPEN) {
        client.send(JSON.stringify(message));
      }
    });
  });

  ws.on('close', () => {
    rooms.get(roomId)?.delete(ws);
  });
});

Сообщения структурируем в типизированный JSON-протокол: { type, roomId, data, timestamp }. Это упрощает отладку и обработку.

Аутентификация и безопасность

Так как WebSocket не поддерживает кастомные заголовки при handshake, используем первое сообщение для аутентификации — отправляем токен сразу после подключения. Если токен невалиден — закрываем соединение с кодом 4001.

ws.on('connection', (socket) => {
  let authenticated = false;
  const authTimeout = setTimeout(() => {
    if (!authenticated) socket.close(4001, 'Auth timeout');
  }, 5000);
  socket.once('message', (data) => {
    const { type, token } = JSON.parse(data.toString());
    if (type === 'auth' && validateToken(token)) {
      authenticated = true;
      clearTimeout(authTimeout);
      socket.send(JSON.stringify({ type: 'auth_success' }));
    } else {
      socket.close(4001, 'Invalid token');
    }
  });
});

Этот подход безопаснее query-строки, так как токен не светится в логах.

Горизонтальное масштабирование через Redis Pub/Sub

При кластеризации клиенты распределяются по разным серверам. Чтобы сообщение от клиента на сервере 1 дошло до клиента на сервере 2, используем Redis Pub/Sub:

import { createClient } from 'redis';
const pub = createClient();
const sub = createClient();

ws.on('message', async (data) => {
  await pub.publish(`room:${roomId}`, data.toString());
});

sub.subscribe(`room:${roomId}`, (message) => {
  rooms.get(roomId)?.forEach(client => {
    if (client.readyState === WebSocket.OPEN) client.send(message);
  });
});

Redis работает как шина — все серверы получают события и доставляют их своим клиентам. Это проверенное решение, выдерживающее 100K+ подключений.

Как выбрать между Socket.io и нативным WebSocket?

Для проектов с числом соединений до 10 тыс. и нежёсткими требованиями к задержке Socket.io удобнее. Нативный WebSocket лучше при >10 тыс. коннектов, минимальном оверхеде и полном контроле над протоколом.

Почему важен heartbeat?

Браузеры и прокси закрывают idle-соединения через 20–120 секунд. Heartbeat (ping/pong) каждые 30 секунд поддерживает канал живым и детектит разрывы. Без него клиенты «зависают» в списке пользователей.

wss.on('connection', (ws) => {
  let alive = true;
  ws.on('pong', () => {
    alive = true;
  });
  const interval = setInterval(() => {
    if (!alive) return ws.terminate();
    alive = false;
    ws.ping();
  }, 30000);
  ws.on('close', () => clearInterval(interval));
});

import { WebSocketServer } from 'ws';
import { createServer } from 'http';

const server = createServer();
const wss = new WebSocketServer({ server });

wss.on('connection', (socket, req) => {
  const roomId = new URL(req.url!, 'http://x').searchParams.get('room');
  if (!roomId) {
    socket.close(4000, 'Missing room');
    return;
  }

  let authenticated = false;
  const authTimeout = setTimeout(() => {
    if (!authenticated) socket.close(4001, 'Auth timeout');
  }, 5000);

  socket.once('message', (data) => {
    const { type, token } = JSON.parse(data.toString());
    if (type === 'auth' && validateToken(token)) {
      authenticated = true;
      clearTimeout(authTimeout);
      socket.send(JSON.stringify({ type: 'auth_success' }));
    } else {
      socket.close(4001, 'Invalid token');
    }
  });

  let alive = true;
  socket.on('pong', () => {
    alive = true;
  });

  const heartbeat = setInterval(() => {
    if (!alive) {
      socket.terminate();
      return;
    }
    alive = false;
    socket.ping();
  }, 30000);

  socket.on('close', () => {
    clearInterval(heartbeat);
    clearTimeout(authTimeout);
  });
});

server.listen(8080);

Процесс работы

1. Анализ и прототип — определяем нагрузку, сценарии, протокол сообщений.
2. Проектирование — архитектура, выбор стека, схема аутентификации.
3. Разработка — реализация сервера, клиента, интеграция с Redis.
4. Тестирование — нагрузочные тесты (10K+ коннектов), тесты на отказоустойчивость.
5. Деплой и мониторинг — CI/CD, SRE-дашборды, алерты по задержкам.

Что входит в работу

• Полная архитектурная документация (PDF/Markdown)
• Репозиторий с серверным и клиентским кодом (TypeScript)
• Интеграция с Redis Pub/Sub для масштабирования
• Настройка heartbeat и механизма reconnect
• Инструкция по деплою на вашу инфраструктуру
• 1 месяц бесплатной поддержки после релиза

Сроки разработки

• MVP с комнатами и аутентификацией: 2–3 недели
• Полноценное решение с Redis, тестами и документацией: от 3 до 5 недель

Точные сроки зависят от сложности протокола и необходимой нагрузки. Оценим ваш проект — свяжитесь с нами. Закажите разработку WebSocket API, и мы гарантируем стабильное соединение даже при пиковых нагрузках.

WebSocket протокол описан в RFC 6455.