Зачем нужна real-time коммуникация

REST API работает по модели «запрос — ответ»: клиент спрашивает, сервер отвечает. Но есть задачи, где инициатором должен быть сервер: новые сообщения в чате, уведомления, изменение цены акции, движение игрока в онлайн-игре. Для этого нужна real-time коммуникация — способ обмена данными, при котором сервер может отправлять данные клиенту без запроса.

Ограничения REST: только request-response

В REST клиент всегда инициатор. Чтобы узнать о новых данных, клиент должен периодически спрашивать: «есть что-то новое?» — это называется polling (опрос):

// Каждые 2 секунды проверяем новые сообщения
setInterval(async () => {
  const messages = await fetch('/api/messages?since=' + lastId).then(r => r.json());
  if (messages.length) renderMessages(messages);
}, 2000);

Проблемы polling'а очевидны:

Задержка. Сообщение может прийти сразу после проверки — пользователь увидит его через 2 секунды.
Трафик впустую. 99% запросов возвращают «нет новых сообщений», но HTTP-запросы всё равно отправляются (заголовки, TCP-пакеты).
Нагрузка на сервер. 1000 пользователей опрашивают каждые 2 секунды = 500 запросов/сек, даже когда ничего не происходит.

Три подхода к real-time

До WebSocket'ов разработчики придумывали обходные пути:

1. Polling (опрос). Клиент регулярно спрашивает сервер. Самое простое решение и самое плохое по эффективности.

2. Long Polling. Клиент спрашивает, сервер не отвечает, пока нет данных. Сервер держит соединение открытым (до 30–60 секунд), и как только появляются данные — отправляет ответ:

Клиент:  GET /api/messages?since=42
Сервер:  ...ждёт 20 секунд, появляется новое сообщение...
Сервер:  200 OK, [новое сообщение]
Клиент:  сразу отправляет новый запрос GET /api/messages?since=43

Минусы: каждый ответ — новый HTTP-запрос (заголовки, рукопожатие если не Keep-Alive). Сервер держит открытое TCP-соединение на клиента, расходуя память.

3. WebSocket. Полноценный протокол для двусторонней real-time связи поверх TCP. После установки соединения клиент и сервер могут отправлять данные в любой момент. Нет лишних заголовков, нет overhead'а HTTP. WebSocket — золотой стандарт для чатов, игр, биржевых котировок, коллаборативного редактирования.

Где нужны WebSocket'ы

Real-time коммуникация — не роскошь, а необходимость для целых классов приложений:

Чат и мессенджеры. Новое сообщение должно появиться мгновенно (менее 100 мс).
Онлайн-игры. Позиции игроков, выстрелы, команды — каждая миллисекунда на счету.
Биржевые котировки. Цена акции меняется десятки раз в секунду.
Совместное редактирование. Google Docs, Figma — несколько человек меняют один документ одновременно, нужна синхронизация изменений.
Уведомления. Сервер сообщает о новом email, лайке, заказе без перезагрузки страницы.
IoT и сенсоры. Датчик температуры отправляет данные на сервер, сервер пересылает всем заинтересованным клиентам.

Сравнение с REST по накладным расходам

Представим, что у нас чат и каждую секунду отправляется одно сообщение. Сравним overhead:

REST (HTTP/1.1 с Keep-Alive):
  Запрос:  ~400 байт заголовков
  Ответ:   ~300 байт заголовков
  Итого:   ~700 байт overhead на каждое сообщение

WebSocket:
  Фрейм:   2–10 байт overhead
  Итого:   ~6 байт overhead на сообщение

Разница более чем в 100 раз. Для одного клиента это незаметно, для миллиона — критично.

Проверь себя

Почему обычный polling неэффективен?
Чем Long Polling лучше Polling, но хуже WebSocket?
Какие приложения требуют real-time коммуникации?

<details> <summary>Ответы</summary>

Polling отправляет запросы по таймеру, даже когда новых данных нет. 99% запросов бесполезны — тратят трафик, нагружают сервер и добавляют задержку до следующего опроса.
Long Polling убирает бесполезные ответы (сервер ждёт, пока появятся данные), но каждый ответ — это новый HTTP-запрос с полными заголовками. WebSocket устанавливает соединение один раз и передаёт данные с минимальным overhead.
Чаты, онлайн-игры, биржевые котировки, совместное редактирование, push-уведомления, IoT-датчики.

</details>

Что унести с урока

REST — request-response: клиент спрашивает, сервер отвечает. Для real-time не подходит.
Polling — периодический опрос. Long Polling — ожидание данных перед ответом.
WebSocket — постоянное двустороннее соединение с минимальным overhead (2–10 байт на сообщение).
WebSocketы нужны для чатов, игр, бирж, коллаборативных приложений, IoT.

В следующем уроке разберём, как устанавливается WebSocket-соединение — от HTTP-запроса с заголовком Upgrade до перехода на протокол WebSocket.

Зачем нужна real-time коммуникация