Представьте: ваш чат или дашборд тормозит из-за 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?
| Характеристика | Socket.io | Нативный WebSocket |
|---|---|---|
| Оверхед | Средний (заголовки протокола) | Минимальный |
| Fallback | Long-polling/Flash | Нет |
| Reconnect | Автоматический | Нужно реализовать |
| Комнаты | Встроенные | Реализация вручную |
| Производительность | До 10K соединений | 100K+ соединений |
| Контроль протокола | Ограничен | Полный |
Для проектов с числом соединений до 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)); }); Полный пример сервера с аутентификацией и heartbeat (Node.js + ws)
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); Процесс работы
- Анализ и прототип — определяем нагрузку, сценарии, протокол сообщений.
- Проектирование — архитектура, выбор стека, схема аутентификации.
- Разработка — реализация сервера, клиента, интеграция с Redis.
- Тестирование — нагрузочные тесты (10K+ коннектов), тесты на отказоустойчивость.
- Деплой и мониторинг — CI/CD, SRE-дашборды, алерты по задержкам.
Что входит в работу
- Полная архитектурная документация (PDF/Markdown)
- Репозиторий с серверным и клиентским кодом (TypeScript)
- Интеграция с Redis Pub/Sub для масштабирования
- Настройка heartbeat и механизма reconnect
- Инструкция по деплою на вашу инфраструктуру
- 1 месяц бесплатной поддержки после релиза
Сроки разработки
- MVP с комнатами и аутентификацией: 2–3 недели
- Полноценное решение с Redis, тестами и документацией: от 3 до 5 недель
Точные сроки зависят от сложности протокола и необходимой нагрузки. Оценим ваш проект бесплатно — свяжитесь с нами. Закажите разработку WebSocket API, и мы гарантируем стабильное соединение даже при пиковых нагрузках.
WebSocket протокол описан в RFC 6455.