Cache key

Когда CDN-узел на краю сети получает запрос, он вычисляет ключ кэша – обычно на основе хоста, пути и отдельных заголовков с query-параметрами – и по этому ключу ищет запись в кэше. Два запроса с одинаковым ключом используют одну и ту же запись; запросы с разными ключами хранятся отдельно. По умолчанию у большинства CDN ключ кэша включает только URL, но его можно настроить, чтобы включать или исключать определённые заголовки, query-параметры и куки.

Классическая ошибка, губящая CHR, – использование session ID или случайного трекинг-параметра в ключе кэша. Если `https://example.com/segment.m4s?session=12345` отличается от `https://example.com/segment.m4s?session=67890`, каждый зритель получит отдельную запись в кэше. Запросы к origin идут не один на сегмент, а один на зрителя, и CHR падает почти до нуля. У каждого стриминг-инженера есть история, как он нашёл куку или параметр из query в ключе кэша во время расследования по CHR.

Лечение – нормализация cache key: чёткие правила на уровне CDN, что включать, а что игнорировать. Стандартное правило для стриминга – «кешировать по URL-пути, игнорировать query string, большинство заголовков – тоже, но оставить Accept-Encoding». Настройки со signed-URL требуют особой осторожности: подпись нужно проверять, но не включать в cache key – обычно это реализуется отдельным правилом «проверить и отрезать». Каждый CDN предоставляет такую конфигурацию; главная сложность – не забыть про неё до того, как начнётся трафик.