Cache-Status: наблюдаем работу нескольких кэшей

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

Cache-Status описывает решение одного или нескольких кэшей как список элементов Structured Fields. hit, fwd, ttl и detail помогают увидеть слой, но их нужно читать вместе с Cache-Control, Age, Vary и validator.

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

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

Разбираем путь через browser, edge и origin cache по стандартному полю, сохраняя проверку Age, validators и реального origin.

Первичный источник «RFC 9211 — Cache-Status, RFC 9111 — HTTP Caching, RFC 9651 — Structured Fields, RFC 9209 — Proxy-Status, RFC 9110 — HTTP Semantics» задаёт техническую основу, но не описывает конфигурацию каждого клиента и поставщика. Читайте нормативную формулировку рядом с датой и версией документа, затем подтверждайте поведение в своей программе. Если интерфейс обещает больше, чем источник, помечайте это как свойство продукта, которое нужно проверить отдельно.

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

Origin увеличивает поле version при управляемой публикации. Первый запрос должен пройти в origin, второй — стать hit, третий после max-age — revalidate, четвёртый после публикации — вернуть новую version. Повредите один элемент Cache-Status и убедитесь, что монитор отмечает parsing error отдельно от доступности страницы.

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

На собственном route выдайте версионированный JSON и Cache-Control. Выполните cold request, warm hit, forced revalidation и обновление origin. Если кэшей два, присвойте им разные безопасные имена и проверьте порядок элементов.

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

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

• Получить cold response
• Подтвердить warm hit
• Вызвать revalidation
• Проверить новую origin version

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

Фиксируйте цепочку Cache-Status, Age, Cache-Control, ETag, Vary, body version, HTTP-status и request ID origin. Не используйте header как единственный источник истины.

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

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

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

Один hit не доказывает актуальность: сопоставьте body version и validator с origin. Unknown extension parameters следует сохранять или игнорировать по правилам парсера, а не ломать весь отчёт.

Поле добровольное и может быть сокращено или изменено посредником. Частные кэши браузера не обязаны отражаться в ответе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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