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

Основная идея

SSE использует долгий HTTP-ответ с событиями text/event-stream. Если приложение, reverse proxy или компрессор буферизует части ответа, браузер получит несколько событий одновременно, хотя сервер создал их с интервалом.

В теме «Почему события SSE приходят пачкой через прокси» слово «скорость» нужно разложить на задержку соединения, ожидание первого байта и передачу данных. Один маленький файл почти полностью измеряет задержку, а большой может упереться в канал клиента или сервера. Поэтому вывод делают по серии одинаковых запросов и сравнивают с прямым маршрутом в то же время.

Что подтверждает первичный источник

Ставим временные метки на Server-Sent Events и отделяем серверную задержку от буферизации, heartbeat и восстановления Last-Event-ID.

Первичный источник «WHATWG Server-sent events, MDN Using server-sent events, NGINX proxy module, RFC 9110 — HTTP Semantics, RFC 9112 — HTTP/1.1» задаёт техническую основу, но не описывает конфигурацию каждого клиента и поставщика. Читайте нормативную формулировку рядом с датой и версией документа, затем подтверждайте поведение в своей программе. Если интерфейс обещает больше, чем источник, помечайте это как свойство продукта, которое нужно проверить отдельно.

Практический стенд

Запустите 30 событий по одному в секунду, оборвите соединение после id 12 и подключитесь снова. В первом сценарии оставьте proxy buffering, во втором отключите его документированно только для SSE location. Убедитесь, что Content-Type корректен, соединение не кэшируется, heartbeat проходит, а восстановление начинается с ожидаемого id.

Проверка шаг за шагом

Свой endpoint должен выдавать монотонный id и server timestamp каждую секунду, принудительно flush-ить запись и посылать комментарий heartbeat. Сравните прямой маршрут, proxy с настройками по умолчанию и явно отключённую буферизацию.

Подготовьте два объекта на контролируемом сервере: небольшой ответ для задержки и файл известного размера для пропускной способности. Выполните прогрев, затем не менее пяти измерений напрямую и через прокси. Ограничьте параллельность одним соединением, если проверяете маршрут, и отдельно повторите реальную нагрузку, если приложение обычно открывает несколько соединений.

Записывайте DNS, connect, TLS, time to first byte, total и число переданных байтов. Используйте медиану, а не лучший результат. Если медленным оказался только первый запрос, причиной может быть DNS, TLS или холодный кэш. Если растёт время передачи большого файла, проверяйте канал, потери и ограничения сервера; смена IP без этих данных ничего не доказывает.

• Отметить время генерации события
• Сравнить прямой и proxy-маршрут
• Оборвать после известного id
• Проверить Last-Event-ID

Какие данные сохранить

Сохраняйте четыре временные метки, event id, HTTP-version, настройки buffering/compression, close reason и Last-Event-ID. Содержимое пользовательских событий не требуется.

В отчёт включают размер файла, расположение контрольного сервера, тип подключения, пять исходных значений и медиану. Для 10 МБ указывайте, что это скорость между клиентом и проверочным endpoint WorldProxy через выбранную прокси, а не универсальная скорость всего интернета. Отдельно отмечайте HTTP-ошибки: быстрая страница 403 не является успешным замером.

Сразу задайте имена колонок отчёта и формат времени. Результат без контекста быстро превращается в догадку: неизвестно, какой адрес использовался, был ли кэш и что изменилось. Сохраняйте не только успех, но и контролируемые отказы. Они доказывают, что проверка действительно различает состояния, а не всегда рисует зелёный индикатор.

Как читать результат

Сравнивайте server emit, proxy receive, browser receive и gap между ними. Повторное соединение с Last-Event-ID проверяет восстановление, но приложение само решает, сколько истории хранить и как исключить пропуск или дубль.

Отключение буферизации увеличивает число мелких записей и не подходит всем маршрутам. Разные браузеры и CDN могут вводить свои пределы долгого соединения.

Один успешный запуск подтверждает только конкретную комбинацию клиента, маршрута и времени. Для устойчивого вывода повторите опыт, изменяя одну переменную, и укажите границы. Если наблюдение расходится с документацией, сначала исключите кэш, версию программы и промежуточный сервер, а затем сформулируйте воспроизводимый пример для поддержки.

Разбор рабочего решения

Для темы «Почему события SSE приходят пачкой через прокси» заранее задайте бюджет измерения. Один цикл может включать прогрев, пять маленьких запросов, пять передач файла и такой же прямой контроль. Между тяжёлыми циклами нужна пауза, а параллельность должна быть фиксированной. Это защищает сервис от собственной проверки и делает серии сравнимыми. Если используется тарификация по трафику, в отчёте укажите ожидаемый расход до запуска, чтобы тест не стал неожиданной докупкой.

Разделяйте задержку и пропускную способность. Маленький ответ показывает стоимость DNS, соединения, TLS и первого байта; файл 10 МБ сильнее отражает передачу между клиентом и проверочным сервером через выбранную прокси. Ни один результат не является универсальной скоростью интернета. Для сайта с множеством ресурсов отдельно измерьте реальный сценарий браузера, потому что повторное использование соединений и кэш меняют картину.

Аномалию подтверждают сравнением, а не немедленной сменой IP. Проверьте прямой маршрут, вторую прокси той же географии и повтор после короткой паузы. Если ухудшилась только одна фаза, ищите причину именно там. Храните медиану, разброс и число ошибок; лучший результат скрывает нестабильность, а среднее искажается единичным зависанием. Порог тревоги задавайте относительно обычного уровня конкретного маршрута.

Типичные ошибки

Нельзя сравнивать Wi‑Fi утром с кабелем вечером, разные файлы или разные CDN-узлы. Не отключайте таймаут, пытаясь дождаться бесконечного ответа, и не запускайте десятки тяжёлых тестов подряд. Они расходуют трафик и сами создают очередь. Лучше ограниченная серия, пауза и повтор только аномальных значений.

Остановитесь, если растёт доля ошибок, источник вернул ограничение, результат требует обхода защиты или в журнал попали секреты. Сначала сохраните обезличенную диагностику и устраните причину. Смена IP или увеличение параллельности в такой точке скрывает проблему и может создать лишнюю нагрузку вместо полезных данных.

Критерии внедрения и сопровождение

Перед внедрением сформулируйте критерий решения: какое наблюдение разрешает продолжить работу, какое требует ручной проверки, а какое немедленно останавливает процесс. Укажите допустимый процент ошибок, максимальное время ожидания и владельца исключения. Без этих границ команда начинает объяснять одинаковый результат по-разному, а временный сбой незаметно превращается в постоянную настройку.

Через неделю после запуска проверьте, совпадают ли фактическая нагрузка, расходы и качество с тестом. Затем назначьте регулярный малый контроль и повторную проверку после обновления клиента, прокси-сервиса или сетевой схемы. Устаревшую инструкцию архивируйте вместе с датой и причиной замены, чтобы сотрудники не использовали две конфликтующие конфигурации.

Рабочий регламент

Превратите удачный опыт в короткий регламент: кто запускает, где лежит безопасная конфигурация, какие лимиты действуют и когда работа должна остановиться. Проверка должна завершаться конечным статусом, а не бесконечной попыткой. После обновления браузера, библиотеки или сетевой схемы запускайте малый контроль до основной очереди.

• Есть прямой контроль
• Файл и endpoint одинаковы
• Сохранены отдельные фазы
• Используется медиана серии
• Ошибки отделены от скорости
• Указано, какой участок маршрута измерен