Розробка WebSocket API для веб-додатків під ключ
Уявіть: ваш чат або дашборд гальмує через polling-запити кожні 500 мс. Користувачі скаржаться на затримки, а бекенд захлинається від N+1 запитів. Рішення — WebSocket: постійне з'єднання із затримкою менше 10 мс замість секунд. Заміна polling на WebSocket знижує навантаження на мережу та сервер у 10–20 разів, а також скорочує витрати на серверну інфраструктуру в 3-5 разів і економить до 90% трафіку. Ми розробляємо такі realtime-системи вже понад 10 років і реалізували 40+ проєктів для чатів, сповіщень та спільної роботи. Двонаправлений зв'язок по 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.