Представьте: ваш чат или дашборд тормозит из-за 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.