Що таке WebSocket і коли використовувати реальний час у веб-додатках

Стандартна комунікація між браузером і сервером працює за схемою запит-відповідь. Браузер запитує, сервер відповідає, з'єднання закривається. Для більшості сценаріїв це ідеально. Але що якщо сервер повинен сам надсилати дані браузеру без запиту? Що якщо потрібно щоб зміни на одному екрані миттєво з'являлися у всіх інших користувачів? Саме для цього існують WebSocket.

Як працює WebSocket

WebSocket — це протокол який встановлює постійне двонаправлене з'єднання між браузером і сервером. На відміну від HTTP де кожен запит це окреме з'єднання WebSocket відкривається один раз і залишається відкритим до тих пір поки одна зі сторін його не закриє.

Процес починається зі звичайного HTTP запиту, так званого handshake. Клієнт відправляє запит з заголовком Upgrade: websocket, сервер підтверджує і з'єднання переходить в WebSocket режим. Тепер і клієнт і сервер можуть надсилати повідомлення в будь-який момент без очікування запиту від іншої сторони.

Це фундаментально інша модель комунікації. HTTP — це телефонний дзвінок який завершується після кожного питання і відповіді. WebSocket — це відкрита телефонна лінія де обидві сторони можуть говорити коли захочуть.

Чим WebSocket відрізняється від polling

До появи WebSocket для отримання оновлень в реальному часі використовували polling, браузер регулярно запитував сервер "є щось нове?". Кожні кілька секунд новий HTTP запит незалежно від того чи є нові дані.

Long polling — вдосконалена версія: сервер тримає з'єднання відкритим поки не з'являться нові дані або поки не мине таймаут. Менше зайвих запитів але все одно значне навантаження.

WebSocket вирішує цю проблему елегантно: одне постійне з'єднання, дані надходять тільки коли є що надсилати, мінімальні накладні витрати на кожне повідомлення.

Коли потрібен WebSocket

Чати і месенджери. Класичний кейс. Повідомлення повинні з'являтися миттєво без polling і без перезавантаження сторінки.

Колаборативні інструменти. Google Docs, Figma, онлайн дошки, коли кілька користувачів одночасно редагують один документ і повинні бачити зміни один одного в реальному часі.

Живі дашборди. Моніторинг серверів, фінансові графіки, аналітика в реальному часі, дані постійно оновлюються і повинні відображатися без затримки.

Онлайн-ігри. Мультиплеєрні ігри де позиції гравців і стан гри синхронізуються між всіма учасниками.

Сповіщення. Push сповіщення всередині додатку: нові повідомлення, зміни статусу замовлення, алерти системи.

Коли WebSocket зайвий

WebSocket не потрібен скрізь де є будь-яке оновлення даних. Якщо дані оновлюються раз на хвилину або рідше, звичайний polling або Server-Sent Events будуть простішим і достатнім рішенням.

Для односпрямованого потоку даних від сервера до клієнта — наприклад стрічка новин або прогрес довгої операції, Server-Sent Events є простішою альтернативою. SSE використовує звичайний HTTP і підтримує автоматичне перепідключення з коробки.

Реалізація і масштабування

На практиці WebSocket рідко реалізують з нуля. Socket.IO — найпопулярніша бібліотека яка абстрагує WebSocket і додає корисний функціонал: автоматичне перепідключення, кімнати для групової комунікації, fallback на polling якщо WebSocket недоступний.

Масштабування WebSocket вимагає окремої уваги. Постійні з'єднання означають що один сервер може тримати обмежену кількість клієнтів. При горизонтальному масштабуванні потрібно вирішити проблему розподілу повідомлень між серверами, Redis Pub/Sub є стандартним рішенням для синхронізації між екземплярами.

WebSocket — потужний інструмент для конкретних сценаріїв. Ключ до правильного використання, чітко розуміти чи справді потрібна двонаправлена комунікація в реальному часі чи можна обійтися простішим рішенням.