«Обновлять в реальном времени» — пока не требование. Нужно договориться, кто кому передаёт данные, сколько можно ждать и что делать после обрыва. Polling подходит для редких проверок, long polling — для ожидания события, SSE — для потока от сервера в браузер, WebSocket — для обмена в обе стороны. Выбор транспорта не отменяет контракт, авторизацию и восстановление состояния.
Представьте кабинет с выгрузкой отчёта. Пользователь нажал «Сформировать» и смотрит на крутилку. Заказчик говорит: «Хочу, чтобы всё было современно, через сокеты». Я бы начал с другого: сколько делается отчёт и насколько страшно показать готовность на пять секунд позже? От ответа зависит архитектура. Слово «современно» здесь ничего не измеряет.
Что спросить до выбора технологии?
Разделите команду и наблюдение за результатом. Создание отчёта — команда. Изменения его статуса — данные для экрана. Они не обязаны ездить одним способом: обычный POST запускает работу, а отдельный канал сообщает о прогрессе.
- Направление. Сервер сообщает о готовности или обе стороны постоянно обмениваются сообщениями?
- Задержка. Нужны 200 миллисекунд, две секунды или минута? Измеряем от изменения на сервере до отображения на клиенте, например p95.
- Смысл потери. Достаточно последнего процента выполнения или нужно восстановить каждое сообщение чата?
- Масштаб. Сколько одновременно открытых экранов, вкладок и подписок? Как часто меняются данные?
- Жизненный цикл. Нужны обновления только при открытой странице или уведомление должно прийти после её закрытия?
Это продолжение темы синхронной и асинхронной интеграции: бизнес-операция может быть асинхронной, даже если каждый запрос к её статусу — обычный HTTP request/response.
Чем отличаются способы доставки?
| Способ | Как работает | Пример выбора | За что платим |
|---|---|---|---|
| Polling | Клиент периодически спрашивает состояние | Готовность месячного отчёта | Пустые запросы и задержка до следующего опроса |
| Long polling | Сервер держит запрос до события или таймаута; затем клиент открывает следующий | Редкие уведомления через HTTP | Ожидающие запросы и восстановление между ними |
| SSE | Сервер отдаёт последовательность текстовых событий в одном HTTP-ответе | Прогресс операции, лента изменений | Долгие подключения, replay и настройки прокси |
| WebSocket | Обе стороны отправляют сообщения по открытому каналу | Совместная работа, частые команды и обновления | Прикладной протокол, reconnect, лимиты очередей |
| Webhook | Сервис вызывает HTTP-адрес другого сервиса | Платёжный провайдер уведомляет наш бэкенд | Повторы, подпись и доступный входящий endpoint |
Развёрнутые контракты — в главах про polling и long polling, SSE и HTTP-стриминг, WebSocket и вебхуки. Таблица — ориентир для обсуждения, а не запрет делать чат через HTTP.
Почему HTTP/2 — не замена SSE?
Здесь часто смешивают уровни. HTTP/2 и HTTP/3 отвечают за передачу HTTP. SSE задаёт формат событий в теле ответа. Polling описывает, когда клиент повторяет запрос. REST — архитектурный стиль. Это не пять взаимоисключающих протоколов: REST API может опрашиваться polling, а SSE может передаваться поверх HTTP/2.
gRPC предлагает server streaming, client streaming и двунаправленный streaming в дополнение к одиночным вызовам. Это отдельный кандидат для взаимодействия сервисов; доступность режимов в браузерном клиенте нужно проверять у конкретного gRPC-Web стека. Режимы описаны в документации gRPC.
У WebTransport есть надёжные потоки и датаграммы, где допустимы потери. Это полезное различие для данных, которые быстро устаревают, но не повод выбирать его для каждого кабинета. Сначала докажите необходимость этих свойств, затем проверьте целевые браузеры и инфраструктуру по документации WebTransport.
Как выбрать для одного продукта?
Возьмём учебный сервис отчётов. Отчёт строится до двух минут, пользователь готов подождать лишние пять секунд, экран открывают 300 человек в день. Начинаем с polling. Если потом появляется требование показывать шаги выполнения с задержкой до секунды, рассматриваем SSE. Если добавляется совместный редактор с постоянными командами участников, отдельно оцениваем WebSocket для редактора. Не нужно переносить весь продукт на один транспорт ради единообразия.
Запись в решение
«Для статуса отчёта используем polling раз в 5 секунд при открытом экране. После терминального статуса останавливаем опрос. При сетевой ошибке сохраняем последнее состояние с пометкой о потере связи. Пересматриваем решение, если требование по задержке станет меньше интервала или замеры покажут чрезмерную нагрузку». Это уже можно реализовать и проверить.
Что останется проблемой при любом выборе?
После разрыва клиент не знает, что произошло за время отсутствия. Для экрана с процентом выполнения можно заново прочитать снимок. Для истории сообщений нужен журнал и курсор. А если сначала получить снимок, а потом подписаться, между действиями появится окно потери. Контракт должен связывать снимок с версией: «состояние на ревизии 81, дальше события после 81». Сервер обязан уметь отдать этот хвост, пока клиент подключается.
Второй вопрос — права. Разрешение открыть канал не означает право читать любую сущность через него. Третий — медленный клиент: копим всё, объединяем обновления состояния или отключаем и пересинхронизируем? Четвёртый — наблюдаемость: как отличаем открытый канал от реально свежего экрана? Эти решения важнее имени библиотеки.
Что принести на приёмку?
- Измеримую задержку обновления при ожидаемом числе подключений.
- Сценарий обрыва: экран не врёт о свежести данных и восстанавливается без потери обязательных событий.
- Сценарий отзыва доступа во время подключения.
- Поведение при повторе, медленном клиенте, перезапуске сервера и открытии нескольких вкладок.
- Границу фоновой работы: закрытая страница не считается постоянным подписчиком.
Голос и видео с небольшой задержкой — отдельный сценарий. В главе как работают звонки на WebRTC разбираем путь от приглашения до медиа: signaling, поиск маршрута и серверы групповой встречи.
Частые вопросы
Long polling устарел?
Возраст способа не определяет пригодность. Если он укладывается в требования, а команда умеет его эксплуатировать, переписывание ради нового названия не добавит ценности. Проверяйте нагрузку и ограничения инфраструктуры.
Можно заменить очередь сообщений на SSE?
SSE доставляет события подключённому HTTP-клиенту. Хранение, обработка отключённых потребителей и повторное чтение — отдельные задачи. За SSE может стоять журнал событий, но формат SSE сам его не создаёт.
А вебхук можно прислать прямо во вкладку?
Обычная вкладка не публикует входящий HTTP endpoint. Вебхук принимает наш сервер, а экран узнаёт об изменении выбранным клиентским способом. Это два участка одной цепочки.