Что такое Server-Sent Events (SSE)?
Server-Sent Events (SSE) — это механизм, при котором сервер держит одно долгоживущее HTTP-соединение и по мере появления данных отправляет в браузер поток текстовых событий. Передача идёт строго в одну сторону: от сервера к клиенту.
SSE расшифровывается как Server-Sent Events — «события, отправляемые сервером». Это способ доставлять на уже открытую страницу свежие данные без перезагрузки и без бесконечных запросов: новую строку ленты, изменение статуса заказа, кусок ответа ИИ-ассистента. Бизнесу он нужен там, где важна мгновенная реакция интерфейса: пользователь видит результат сразу, дольше остаётся на странице и чаще доходит до целевого действия.
Как работает Server-Sent Events
Клиент создаёт в JavaScript объект EventSource и указывает адрес эндпоинта. Браузер открывает обычный GET-запрос к серверу с заголовком Accept: text/event-stream, а тот отвечает Content-Type: text/event-stream, Cache-Control: no-cache, Connection: keep-alive — и соединение не закрывает. Дальше он просто дописывает в ответ текстовые блоки, разделённые пустой строкой:
- data: — полезная нагрузка события, чаще всего JSON или строка;
- event: — имя события, на которое подписывается клиент через addEventListener;
- id: — идентификатор события, по нему поток продолжится после обрыва;
- retry: — через сколько миллисекунд переподключаться.
Разбирать формат браузеру не нужно вручную: он делает это сам, вызывает обработчик и обновляет DOM уже средствами вашего JS-кода. Ключевые плюсы — автоматическое переподключение с отправкой заголовка Last-Event-ID, обычный HTTP без отдельных протоколов и портов, читаемый текстовый формат, который легко проверить прямо из консоли.
Зачем SSE нужен бизнесу
Главный сценарий 2026 года — стриминг ответов ИИ: чат-ассистент, подбор товара, генерация текста или сводки отдают токены по мере появления. Пользователь видит, что работа идёт, и не уходит со страницы, пока ждёт результат.
- живые уведомления: заявка с формы, сообщение в чате поддержки, ответ менеджера;
- трекинг: статус заказа, доставки, заявки на кредит, очереди на обслуживание;
- дашборды: цены, остатки, ставки, онлайн-метрики без перезагрузки таблицы;
- прогресс долгих задач: импорт каталога, проверка сайта, сбор отчёта.
Экономика тоже в пользу SSE: одно открытое соединение дешевле, чем частый опрос сервера (polling) каждые несколько секунд. Вы экономите трафик, процессорное время и батарею мобильных устройств, а интерфейс ощущается быстрее — а это напрямую влияет на вовлечённость и конверсию.
Как применять SSE на практике
Отдавайте поток с отдельного эндпоинта, а не через ту же страницу, что рендерится на сервере. Обязательно проверьте буферизацию: ни прокси, ни CDN, ни промежуточный кэш не должны накапливать ответ, иначе события придут одной пачкой и весь эффект стрима пропадёт.
- отключите буферизацию на уровне веб-сервера (для nginx это proxy_buffering off и заголовок X-Accel-Buffering: no);
- добавьте heartbeat — строку-комментарий вида «: ping» раз в 15–30 секунд, чтобы соединение не считалось простаивающим;
- следите за таймаутами прокси и балансировщика: они должны быть больше, чем время жизни потока;
- учитывайте лимит соединений: в HTTP/1.1 браузер держит около шести соединений на домен, в HTTP/2 и HTTP/3 этого ограничения нет;
- если потоков много, выносите их на отдельные мощности — недорогой VPS с асинхронным рантаймом держит тысячи одновременных соединений;
- помните, что EventSource не умеет передавать собственные заголовки: для авторизации используйте cookie, токен в ссылке или fetch-стриминг.
Типичные ошибки
- Буферизация на nginx или CDN. Самая частая причина «SSE не работает»: поток есть, но приходит целиком в конце.
- Нет heartbeat и обработки обрыва. Соединение закрывают провайдеры и мобильные сети, а поток после этого молча умирает.
- Дубли событий. Без полей id и Last-Event-ID при переподключении клиент получит часть данных повторно — ломаются счётчики, уведомления, аналитика.
- Утечка соединений. Забыли вызвать close() при уходе со страницы — браузер держит поток, а сервер копит висящие подключения.
- Попытка двустороннего обмена. SSE — односторонний канал, отправлять данные обратно через него нельзя: для этого нужен POST, fetch-стриминг или WebSocket.
- Отсутствие проверки прав. Поток, отдающий чужие заказы или внутренние метрики без авторизации на каждом событии, — прямая утечка данных.
От WebSocket SSE отличается прежде всего простотой: там двунаправленный протокол, бинарные кадры и своя инфраструктура, здесь — обычный HTTP и встроенный реконнект. Если данные идут только от сервера, WebSocket почти всегда избыточен.
Коротко: что учесть в 2026 году
К 2026 году SSE перестал быть экзотикой: HTTP/2 и HTTP/3 сняли лимит соединений, стриминг токенов стал стандартом для ИИ-интерфейсов, а поддержка потоковых ответов появилась в большинстве серверных рантаймов и edge-платформ. Основная работа теперь не в браузерном API, а в инфраструктуре: буферизация, таймауты и авторизация. Если эти три пункта закрыты, SSE — самый дешёвый способ сделать интерфейс по-настоящему «живым».
