WebSocket и SSE

WebSocket и SSE (Server-Sent Events) — это протоколы прикладного уровня (уровень 7 модели OSI), которые обеспечивают режим реального времени в вебе. Они решают фундаментальное ограничение классического HTTP: невозможность для сервера самостоятельно инициировать отправку данных клиенту.

WebSocket

WebSocket — протокол полностью двустороннего взаимодействия между клиентом и сервером. Первая версия появилась примерно в 2012 году.

Зачем понадобился WebSocket

Классическая проблема взаимодействия фронта и бэка: сервер не может сам инициировать отправку данных на клиент. В стандартной модели HTTP клиент отправляет запрос — сервер отвечает. Если нужно регулярно получать с сервера обновления, приходится либо использовать short/long polling (что создаёт лишнюю нагрузку), либо устанавливать WebSocket-соединение.

Хотя WebSocket чаще всего ассоциируется с фронтом и бэком, он может применяться и в back-to-back взаимодействиях.

Как работает WebSocket

Как и HTTP, WebSocket использует в качестве транспорта TCP. Установка соединения начинается с обычного GET-запроса, в котором клиент указывает специальные заголовки: «давай перейдём на протокол WebSocket». Если сервер поддерживает, он отвечает подтверждением — и после этого начинается двусторонний обмен сообщениями.

Важные особенности:

• Нет привязки к модели request-response. После установки соединения и клиент, и сервер могут отправлять сообщения в произвольном порядке, в любой момент.
• Можно представить как две очереди сообщений в разные стороны (без брокера посередине).
• Протокол поддерживает передачу как текстовых, так и бинарных данных.

Request-response поверх WebSocket

Несмотря на то что WebSocket сам по себе не требует формата «запрос-ответ», на уровне прикладной логики ничто не мешает его реализовать: достаточно в сообщении указывать идентификатор запроса и в ответе ссылаться на него. Таким образом, при желании WebSocket можно использовать как транспорт для RPC-стиля взаимодействия.

Что важно запомнить

• Двунаправленность — главное отличие WebSocket от HTTP (даже HTTP/2, где стрим всегда инициируется клиентом).
• WebSocket работает поверх TCP (как и HTTP).
• Долгоживущее соединение. Это одновременно и удобство, и потенциальная проблема (ресурсы заняты, пока соединение висит).

Проблема WebSocket: долгоживущие соединения

Главный минус WebSocket по сравнению с HTTP — необходимость постоянно держать соединение открытым.

Чем это плохо:

• Расход ресурсов. Каждое открытое соединение — это занятая память и процессорное время на стороне сервера. Если WebSocket-соединение установлено, но данные по нему давно не передавались (например, пользователи перестали писать в чате), ресурсы всё равно остаются выделенными.
• Риск исчерпания ресурсов. Если количество таких «висящих» соединений растёт, и их своевременно не закрывать, сервер может перегрузиться.
• Необходимость переустановки. Если соединение оборвалось (потеря сети, тайм-аут), его нужно восстанавливать заново — это дополнительная работа и задержка.

Сравнение с HTTP

В классической модели HTTP (request-response) соединение после получения ответа закрывается. Да, при частых запросах можно создать нагрузку поллингом, но вероятность скопления большого числа одновременных соединений значительно ниже. Каждое соединение живёт ровно столько, сколько нужно для одного запроса-ответа.

При выборе подхода стоит учитывать характер взаимодействия:

• Если обновления происходят редко (например, раз в 15 минут), эффективнее сделать обычный HTTP-запрос, чем держать WebSocket-соединение.
• Если нужен мгновенный двусторонний обмен (чат, поддержка в реальном времени), WebSocket оправдан, но нужно быть готовым к управлению долгоживущими соединениями.

Резюме

• WebSocket — удобный двусторонний протокол, но дорогой с точки зрения ресурсов из-за долгоживущих соединений.
• HTTP/1.x, HTTP/2, SSE — обходятся без постоянного открытого канала и эффективнее при редких или односторонних обновлениях.

SSE (Server-Sent Events)

SSE (Server-Sent Events) — это механизм, который часто ошибочно воспринимают как самостоятельный протокол. На самом деле SSE — часть спецификации HTTP, доступная начиная с версии HTTP/1.1 и работающая во всех последующих версиях (HTTP/2, HTTP/3).

SSE можно рассматривать как «половину WebSocket» — только в одну сторону:

1. Клиент отправляет обычный GET-запрос со специальным заголовком, указывающим, что он хочет переключиться на SSE.
2. Сервер, если поддерживает, отвечает подтверждением и держит соединение открытым.
3. По мере возникновения событий на сервере он отправляет их клиенту через это соединение.
4. Когда события заканчиваются, соединение закрывается.

Важная особенность: клиент не может отправлять данные через SSE — только получать. Это односторонний канал (сервер → клиент).

WebSocket vs SSE

В контексте взаимодействия фронта и бэка разумность выбора между WebSocket и SSE определяется характером обмена данными.

Когда использовать WebSocket

WebSocket подходит для двустороннего взаимодействия, когда обмен данными идёт в обе стороны и в произвольном порядке. Примеры:

• Совместная работа в реальном времени (Google Docs, Miro, Figma). Когда один участник рисует или редактирует, его действия отправляются на сервер, а сервер рассылает их остальным участникам через их WebSocket-соединения.
• Чат в режиме реального времени (как Telegram, чат поддержки и т. п.). Участники могут в любой момент отправлять и получать сообщения.
• Любые сценарии, где клиент активно генерирует события, которые нужно доставить серверу, а сервер, в свою очередь, может рассылать изменения другим клиентам.

Когда использовать SSE

SSE — это односторонний канал (только от сервера к клиенту). Он удобен, когда клиенту не нужно постоянно отправлять данные, а достаточно получать обновления с сервера. Примеры:

• Уведомления на сайте (алерты, всплывающие сообщения).
• Обновление статуса (например, статус доставки заказа, передвижение курьера или такси на карте).
• Страница заказа — сервер периодически присылает изменения, клиенту не нужно ничего отправлять обратно.

Краткое правило

• WebSocket — когда нужен двусторонний обмен (клиент и сервер общаются в обе стороны).
• SSE — когда сервер только «пушит» данные на клиент, а клиенту не нужно ничего отправлять обратно.