Короткое определение

Набор атрибутов запроса (URL, заголовки, query string), по которым CDN идентифицирует cache-запись. Плохой cache key – самая частая причина низкого CHR.

Когда CDN-edge получает запрос, он вычисляет cache key – обычно host, path и выборочные заголовки и query-параметры – и по нему ищет запись в кеше. Два запроса с одинаковым ключом разделяют одну запись; два с разными – хранятся отдельно. Дефолтный ключ у большинства CDN – только URL, но дефолт настраивается, чтобы включить или исключить конкретные заголовки, query-параметры и куки.

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

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

Считаете параметры для своего продукта?

Поможем собрать энкодер-леддер и посчитать стоимость доставки – до старта разработки.