Ключи кэша CDN и токенизированные URL

Кратко

Edge-кэширование – это то, что делает стриминг дешёвым: сегмент видео, один раз взятый с вашего origin и сохранённый на edge-серверах CDN, может отдаваться тысячам зрителей, не трогая origin снова, – но только если все они запрашивают его под одним и тем же ключом кэша, коротким идентификатором (обычно это хост плюс путь URL), по которому edge решает «отдавал ли я уже именно это?». Самая дорогая ошибка в доставке видео – положить в этот ключ что-то персональное (session id, токен пользователя, параметр трекинга), потому что это форкает один общий сегмент в миллион приватных копий, обрушивает долю байтов из кэша с ~95% почти до нуля и направляет весь поток на ваш origin. Токенизированные URL (они же signed URL) решают обратную задачу – не пускать неоплативших – добавляя короткоживущий криптографически подписанный пропуск, который edge проверяет на каждом запросе; инженерное искусство в том, чтобы проверять токен на edge, не кладя его в ключ кэша, чтобы контроль доступа и высокий cache-hit ratio уживались вместе. Эта статья простыми словами объясняет, как работает ключ кэша для сегментированного видео, разбирает катастрофу ключа «на зрителя» с арифметикой, показывает, как крупные CDN реализуют signed URL и signed cookie, как держать токены вне ключа, и как инвалидация кэша и edge-prefetch дополняют картину.

Почему это важно

Cache-hit ratio – доля отданных байтов, которые приходят с edge CDN, а не с вашего origin – это число, решающее, будет ли счёт за доставку посильным или разорительным, и обе темы этой статьи двигают его напрямую. Ошибитесь в ключе кэша – и платформа, которая должна работать при hit ratio 95%, работает при 30%, кратно умножая трафик и стоимость origin, пока зрители буферизуются. Ошибитесь в токенизированных URL – и вы либо сливаете премиум-контент любому, кто скопировал ссылку, либо защищаете его так, что тихо разрушаете кэш, на который и рассчитывали, чтобы вообще потянуть доставку. Статья – для основателя, продакт-менеджера или стриминг-инженера, которому нужно понять оба рычага достаточно, чтобы ставить задачу вендору CDN, читать счёт за доставку и не допустить конфигурации, превращающей запуск в обвал origin. К концу вы сможете посмотреть на URL видео и сказать, что входит в ключ кэша, что – в токен, и почему это никогда не должно быть одним и тем же полем.

Минута повторения про edge-кэш

Статья опирается на механику кэша, разобранную в как CDN доставляет видео; вот та часть, что нужна под рукой.

Сеть доставки контента – глобальный парк кэширующих серверов, CDN, держащий копии вашего видео близко к зрителям, – работает как сеть магазинов у дома, снабжаемых из одного центрального склада. Ваш origin – это склад: авторитетный сервер с единственной истинной копией каждого файла. Edge-серверы CDN – магазины у дома: тысячи машин рядом со зрителями, хранящие копии того, что просит их район. Когда зритель запрашивает сегмент, а ближайший edge уже его имеет – это попадание в кэш (cache hit): отдаётся мгновенно и дёшево, не беспокоя склад. Если edge его не имеет – это промах (cache miss): edge сначала тянет его с origin, что медленно и идёт в счёт за отдачу байтов из origin.

Экономический мотор – offload ratio, доля байтов, отданных из edge-кэша, а не из origin. Один популярный сегмент, закэшированный однажды на edge, удовлетворяет тысячи зрителей из единственной сохранённой копии. Эта сходимость – и есть причина доступности стриминга. Всё в этой статье в итоге о её защите: ключ кэша – это как edge понимает, что двум зрителям нужна одна и та же копия, а токенизированный URL – как не пустить к ней не тех зрителей, не сообщив случайно edge, что каждому зрителю нужна своя копия.

Ключ кэша: как edge решает «видел ли я это раньше?»

Когда запрос приходит на edge-сервер, edge должен ответить на один вопрос раньше всего: есть ли у меня уже то, что просит запрос? Отвечает он, вычисляя ключ кэша – короткий идентификатор из запроса – и ища его в локальном хранилище. Тот же ключ, что у прошлого запроса, и объект ещё свежий? Hit. Новый ключ? Miss, идём в origin.

Стандарт HTTP-кэширования точен в том, что это за ключ. По RFC 9111 (спецификация HTTP Caching 2022 года, заменившая RFC 7234), «ключ кэша – это информация, по которой кэш выбирает ответ», и базис прост: кэш «использует URI как ключ кэша». Проще говоря, дефолтный ключ кэша – это метод запроса плюс полный URL, для видео фактически хост и путь. Документация Amazon CloudFront подтверждает тот же дефолт конкретно: ключ кэша – это доменное имя дистрибуции плюс «путь URL запрошенного объекта», а «другие значения из запроса зрителя в ключ кэша по умолчанию не входят». Два запроса к /movie/ep1/segment_00042.m4s дают один ключ и делят один кэшированный объект, даже если их query-строки, заголовки User-Agent и cookie полностью разные.

Этот дефолт ровно правильный для видео, и чтобы понять почему, вспомним структуру стримингового медиа. Ваше видео – не один файл; это манифест (небольшой индексный файл) плюс сотни или тысячи коротких сегментов (по несколько секунд видео), и каждый сегмент – отдельно адресуемый HTTP-ресурс со своим URL – структуру мы разбираем в упаковка: CMAF, HLS и DASH. Спецификация HLS, IETF RFC 8216, задаёт плейлист как текстовый файл, в котором «каждая строка – это URI, идентифицирующий медиасегмент или файл плейлиста». MPEG-DASH, стандартизованный как ISO/IEC 23009-1, генерирует URL сегментов детерминированно из SegmentTemplate (подставляя индекс сегмента в $Number$) под BaseURL. В обоих случаях адреса стабильны и одинаковы для каждого зрителя: у сегмента 42 эпизода 1 в рендишне 1080p один URL – общий для всех. Эта стабильность и позволяет одной копии обслуживать весь мир.

Есть один санкционированный способ сделать ключ зависящим не только от URL – заголовок ответа Vary. RFC 9111 говорит, что кэш «может включать дополнительный материал в ключ кэша» через Vary, который перечисляет заголовки запроса, чьё значение меняет ответ – это иногда зовут вторичным ключом кэша. Если ваш origin отдаёт разные байты клиентам, приславшим Accept-Encoding: gzip, он ставит Vary: Accept-Encoding, и edge ключует по пути и этому заголовку. С дисциплиной (известный заголовок с малой кардинальностью) Vary безопасен. Без неё – Vary: User-Agent, у которого тысячи значений – он дробит кэш так же, как ключ «на зрителя». RFC 9111 даже выделяет патологический случай: сохранённый ответ со значением Vary равным * «всегда не совпадает», то есть не может быть переиспользован.

Нажмите, чтобы увеличить

Ошибка на миллион: ключ кэша «на зрителя»

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

Чтобы управлять доступом или атрибутировать аналитику, команда добавляет к каждому URL медиа что-то персональное – session id, подписанный токен, параметр ?user=... – и затем, по ошибке конфигурации или оставив дефолт включённым, пускает этот параметр в ключ кэша. Теперь edge считает /segment_00042.m4s?token=AAA и /segment_00042.m4s?token=BBB двумя разными объектами, потому что их ключи различаются. Запрос первого зрителя – промах, который тянет сегмент 42 с origin и кэширует под ключом-с-токеном-AAA. Второй зритель, с токеном BBB, – тоже промах: у edge есть сегмент 42, но не под этим ключом, поэтому он снова тянет идентичные байты с origin. Каждый зритель форкает каждый сегмент в приватную копию. Общий кэш, который должен был обслуживать тысячи из одного объекта, теперь хранит тысячи идентичных объектов, каждый использован один раз.

Пройдём арифметику вслух, потому что важен масштаб. Возьмём сервис, стримящий популярный live-эпизод на 100 000 одновременных зрителей, каждый тянет свежий 4-секундный сегмент, так что edge обрабатывает около 25 000 запросов сегментов в секунду.

С верным ключом кэша (только путь):
  один сегмент берётся с origin ОДИН раз, затем отдаётся всем с edge.
  обращений к origin на сегмент ≈ 1
  offload ratio ≈ 99,99%  → origin почти не замечает

С ключом «на зрителя» (token в ключе):
  запрос каждого зрителя — уникальный ключ → уникальное обращение к origin.
  обращений к origin на сегмент ≈ 100 000
  offload ratio ≈ 0%  → origin должен отдавать 25 000 req/s видео

Верно ключованный origin отдаёт ручеёк; тот же origin за ключом «на зрителя» вынужден отдавать всю аудиторию напрямую, на полном битрейте, разом. Он не может – и падает, причём ровно во время премьеры, которую не переиграть. Полевые отчёты вендоров описывают тот же коллапс мягче: ввод токен-параметров в ключ кэша может уронить hit ratio с 98% ниже 40% «за минуты». Причина не в баге CDN; это RFC 9111, работающий ровно как написано. Каждый edge – отдельный общий кэш, который надо наполнять по каждому отдельному ключу, а вы дали ему отдельный ключ на зрителя.

Нажмите, чтобы увеличить

Исправление – единственный принцип, и остаток статьи – его применение: ключ кэша задаёт контент; токен задаёт зрителя; никогда не кладите второе в первое.

Токенизированные URL: запереть дверь, не перерезая каждый ключ

Теперь обратная задача. Тот же стабильный общий URL сегмента, что удешевляет кэширование, делает контент лёгкой добычей: если /movie/ep1/1080p/segment_00042.m4s – фиксированный адрес, любой, кто его скопировал, может тянуть ваше премиум-видео и вставить ссылку на форуме на весь мир. Нужен способ пускать оплативших зрителей и заворачивать остальных – на edge, до отдачи байтов, и без ключа кэша «на зрителя».

Этот механизм – токенизированный URL, он же signed URL: обычный URL контента с добавленным криптографически подписанным пропуском, обычно в query-строке. Думайте о нём как о браслете с тайм-кодом на фестивале. Браслет – не касса и не сцена; это быстрый для проверки токен, который охрана на входе (edge) валидирует на месте: подлинный ли он (подпись сходится), действует ли ещё (срок не истёк), пускает ли на эту сцену (путь, на который выдан). Подлинный непросроченный браслет пускает; подделанный или просроченный заворачивают у входа. Важно: edge может проверить браслет и затем отдать тот же общий кэшированный сегмент, что и всем – браслет управляет дверью, а не тем, какую копию вы получите.

Конкретно: сервер приложения платформы решает, что зритель имеет право (вошёл, подписка активна, аренда оплачена), затем считает подпись – обычно HMAC (ключевой хэш) или дайджест RSA/ECDSA – над канонической строкой, называющей путь ресурса и метку истечения, опционально привязанной к диапазону IP или географии. Плеер зрителя шлёт токен с каждым запросом; edge пересчитывает или проверяет подпись общим секретом или открытым ключом, проверяет срок и ограничения и пускает либо отклоняет запрос. Без запроса к БД, без обращения к вашим серверам – пропуск самодостаточен, потому он достаточно быстр, чтобы проверяться на каждом из тех 25 000 запросов в секунду.

Токенизированный URL – это контроль доступа, не шифрование. Он решает, кто может тянуть байты; сами байты он не шифрует. Решительный атакующий, которого пустили, всё ещё может захватить полученное. Для премиум-каталогов, которым надо остановить копирование расшифрованного потока, токен-аутентификация – первый шлюз, поверх которого слоится DRM (система, шифрующая поток и управляющая ключами); где проходит эта граница, мы разбираем в зачем нужен DRM и что он защищает. Akamai описывает это как спектр защиты: открытый доступ, затем токен-аутентификация, затем гео-блокировка, затем HTTPS, затем шифрование медиа, затем полный DRM – каждый слой сильнее и дороже. Токен-аутентификация – дешёвый универсальный первый шаг, нужный каждой платной платформе.

Нажмите, чтобы увеличить

Как это реализуют крупные CDN

Механизм стандартен; имена полей различаются. Назвать несколько полезно, чтобы питчи вендоров стали понятны, и сравнение важно, ведь переведённый зритель может перемещаться между ними (об этом ниже).

Amazon CloudFront даёт две формы. Signed URL несут пропуск в query-строке и бывают по canned-политике (один файл, только срок) или custom-политике (wildcard-пути ресурсов, опциональное время старта и ограничение по диапазону IP); CloudFront проверяет подпись ключами RSA 2048 или ECDSA 256. Его документация предупреждает: «если добавить query-строку к signed URL после подписи, URL вернёт HTTP 403» – подпись покрывает query-строку. Signed cookie несут тот же пропуск в HTTP-cookie (по стандарту cookie RFC 6265), а не в URL, что лучше для стриминга: вы подписываете один раз, браузер сам прикрепляет cookie к каждому запросу сегмента, и – поскольку cookie не входят в дефолтный ключ кэша – сегменты остаются общими. Совет самого CloudFront – использовать signed cookie, чтобы «дать доступ к нескольким защищённым файлам», а это ровно множество сегментов видео.

Akamai использует двухтокенную модель, аккуратно ложащуюся на то, как реально работают стриминг-сессии. Access token («короткий токен», в виде hdnts) генерируется вашим origin, чтобы подтвердить, что сессия аутентифицирована; edge проверяет его HMAC и проверяет, что он не истёк и что его access-control-list покрывает запрошенный URL, плюс опциональная проверка клиентского IP. Когда это прошло, Akamai выдаёт session token («длинный токен», hdntl), действующий весь поток, и плеер возвращает его на каждый последующий сегмент. Срок жизни session token – «полная длительность запрошенного медиа или одни сутки (86 400 секунд), что короче». Для плееров или устройств, блокирующих сторонние cookie, Akamai поддерживает cookie-less режим, кладущий токен в query-строку URL – полезно, но это ровно случай, где гигиена ключа кэша становится критичной.

Cloudflare Stream делает видео требующим подписанного токена, чтобы оно «больше не было доступно публично только по video ID», и проверяет этот токен на edge на каждом запросе, блокируя любой без валидного. Для высокого объёма он позволяет выпускать токены самому из ключа подписи, не вызывая API на каждый просмотр – та же идея самодостаточного пропуска.

Табл. 1. Как четыре частых схемы токенизированных URL размещают и проверяют пропуск. Колонка «Безопасен для ключа по умолчанию?» решает ваш hit ratio: любую схему можно настроить так, чтобы держать токен вне ключа, но query-string-токен требует это подтвердить.

Примирение двух: контроль доступа И высокий hit ratio

Две половины этой статьи тянут в разные стороны, только если им позволить. Примирение – сделать токен проверяемым, но невидимым для ключа: edge осматривает пропуск как шлюз доступа, затем вычисляет ключ кэша только из пути, так что все правомочные зрители сходятся на одном объекте.

К этому ведут три практики, и они усиливают друг друга. Первая: предпочитайте signed cookie (или подписанные заголовки) query-string-токенам для сегментов. Cookie едет с каждым запросом автоматически и по умолчанию исключён из ключа кэша на каждом крупном CDN, так что путь ключуется чисто. Поэтому CloudFront рекомендует signed cookie для многофайлового контента, и поэтому cookie-based session token – дефолт в других местах.

Вторая: когда query-string-токен необходим – для плееров, теряющих cookie, или для шаринг-ссылок – явно исключите токен-параметры из ключа кэша. Каждый серьёзный CDN даёт этот контроль: дефолт CloudFront уже опускает query-строки (вы включаете их параметр через cache policy – просто не добавляйте токен); Akamai даёт отдельное поведение «Cache Key Query Parameters», позволяющее перечислить, какие параметры идут в ключ, и проверять токен, игнорируя его при ключевании. Edge всё равно читает токен; он просто не даёт ему форкать объект.

Третья – практический консенсус 2026 для больших каталогов – подписывайте манифест, а не каждый сегмент. Выпустите один короткоживущий подписанный пропуск (URL или cookie), ограниченный wildcard или префиксом пути, чтобы покрыть сегменты под ним, и пусть запросы сегментов едут на session-cookie или wildcard. Вы аутентифицируете один раз за сессию, а не штампуете токен на каждый сегмент, сегменты делят один ключ кэша, и радиус поражения утёкшей ссылки – одно короткое окно, а не весь каталог. Компромисс для взвешивания – гранулярность: подпись на манифест не отзовёт отдельный сегмент в потоке, что обычно нормально для VOD и решается отдельно для live.

Паритет токенов между CDN – ловушка multi-CDN

Если вы используете больше одного CDN – архитектуру, разобранную в архитектура и оркестрация multi-CDN – токенизированные URL обретают острый край. Каждый CDN защищает URL своей токен-схемой и своим секретом, поэтому зритель, переведённый в потоке с CDN A на CDN B, может быть отклонён на шлюзе B, потому что токен у него выпущен для A. Симптом сводит с ума: воспроизведение работает до события переключения, затем стена 403. Отраслевое лечение – Common Access Token (CAT), усилие, стандартизуемое Streaming Video Technology Alliance и CTA-WAVE, чтобы выразить один переносимый пропуск, который проверит каждый участвующий CDN. Если multi-CDN в дорожной карте, закладывайте паритет токенов с самого начала, а не открывайте его во время failover.

Инвалидация кэша: менять то, что edge уже сохранил

Кэширование – это обещание не перезапрашивать, и отсюда очевидный вопрос: как изменить то, что edge уже отдаёт? У вас три рычага, по нарастанию силы, и для видео вы тянетесь к ним на удивление редко.

Самый мягкий – истечение TTL (time-to-live). Каждый кэшированный объект несёт срок свежести, заданный origin через заголовок Cache-Control: max-age или Expires; RFC 9111 определяет «свежий» ответ как тот, чей возраст не превысил этот срок, после чего edge ревалидирует у origin. Для видео это делает почти всё бесплатно: неизменяемым медиасегментам – очень долгий TTL (они не меняются после публикации: сегмент 42 навсегда сегмент 42), а live-манифесту – короткий TTL (несколько секунд, ведь он растёт с каждым новым сегментом). Настройте эти два верно – и почти ничего не придётся очищать.

Рычаг твёрже – явный purge – команда CDN сбросить объект сейчас. Purge по точному URL – грубый вариант. Масштабируемый, придуманный Fastly, – surrogate key («cache tag»): вы помечаете связанные объекты общей меткой через заголовок ответа Surrogate-Key, затем очищаете всё с этой меткой одним вызовом – например, помечаете каждый рендишн и сегмент тайтла его content id и очищаете тайтл одним запросом (Fastly очищает до 256 ключей за батч). Так вы убираете видео, опубликованное по ошибке или попавшее под takedown, не перечисляя тысячи его URL сегментов.

Самый тонкий рычаг – soft purge – пометить объекты устаревшими, а не удалять. Soft-очищенный объект всё ещё может отдаваться мгновенно, пока edge тянет свежую копию в фоне (паттерн stale-while-revalidate), так что зрители не ждут промаха. Для высоконагруженного каталога это безопасный дефолт для обновлений: вы обновляете, ни разу не подставив origin под лавину одновременных промахов.

Слово о дисциплине, возвращающее к ключу кэша: чище всего «изменить» видео-ассет обычно не очисткой, а публикацией по новому пути (новый версионный сегмент или cache-busting-суффикс в имени файла, не в query-строке). Новый путь – это новый ключ кэша, который наполняется естественно, без purge и без риска полуобновлённого edge. Purge – для удаления и аварий; версионирование – для изменений.

Нажмите, чтобы увеличить

Prefetch: наполнить edge до прихода толпы

Зеркальная противоположность инвалидации – prefetch (он же прогрев): положить контент в edge-кэш до того, как зрители его запросят, чтобы первый запрос был уже попаданием. Для VOD-каталогов рутинный поток делает это сам – первый зритель сегмента прогревает его для остальных. Случай, требующий намеренного прогрева, – live-премьера, где 100 000 зрителей бьют в сегмент 1 в одну секунду; без прогретого edge этот одновременный залп промахов – «громовое стадо» (thundering herd) – весь устремляется на origin разом, что и призван поглотить origin shield.

Две техники укрощают это, и обе опираются на верный ключ кэша. Edge prefetch заталкивает или подтягивает стартовые сегменты и манифест в edge-кэши до старта, чтобы стадо приземлилось на попадания. Origin-assist prefetch, предлагаемый среди прочих Akamai, позволяет origin подсказать следующий сегмент, чтобы edge тянул его чуть впереди спроса для live. Ни одна не поможет, если ключ кэша «на зрителя» – нельзя прогреть копию, которую каждый зритель будет ключевать по-своему, – ещё одна причина, почему гигиена ключа из этой статьи – фундамент, на котором стоит всё остальное. Как пережить одновременный live-старт, мы разбираем подробно в доставка живых событий и всплеск премьеры.

Частые ошибки, тихо ломающие доставку

Большинство сбоев кэша и токенов – это конфигурация, не архитектура, и у них общая привычка выглядеть нормально на тесте с одним зрителем и ломаться на масштабе.

Главная ошибка – ключ кэша «на зрителя», уже разобранный: любой session id, токен авторизации или параметр аналитики, пущенный в ключ, форкает каждый сегмент на зрителя и обрушивает hit ratio. Его тихий родственник – злоупотребление Vary: Vary: User-Agent или Vary: Cookie дробят так же через вторичный ключ, поэтому варьируйте только по заголовкам с малой кардинальностью, которые вы реально отдаёте по-разному. Третья – подписывать каждый сегмент query-string-токеном и ключевать по нему – худшее из двух миров, сочетающее максимум накладных расходов на токен с максимумом фрагментации кэша; подписывайте манифест и предпочитайте cookie. Четвёртая – очищать там, где надо версионировать – долбить purge для обычных правок зовёт полуобновлённые edge и нагрузку на origin, где новый путь наполнился бы чисто. И в multi-CDN забытый паритет токенов оставляет переведённых зрителей за бортом на шлюзе второй сети. Каждая из них невидима на однопользовательском QA и очевидна на графике origin-egress в ночь запуска.

Где здесь Фора Софт

Cache-hit ratio – это число масштаба и стоимости раньше, чем техническое: на петабайтных объёмах это разница между счётом за доставку, растущим с вашей аудиторией, и счётом, растущим с вашим origin, и ключ кэша, и токен сидят прямо на нём. Фора Софт строит ПО для видеостриминга, OTT/Internet TV, e-learning, телемедицины и видеонаблюдения с 2005 года, в 250+ выпущенных проектах для 400+ клиентов, и эта работа сосредоточена ровно на такой инженерии доставки: проектировании ключей кэша, держащих сегментированное медиа общим; настройке токенизированного доступа – signed cookie или signed URL – пускающего оплативших зрителей без фрагментации кэша; сохранении работы валидации токенов при переключении multi-CDN; и прогреве edge, чтобы live-премьера приземлялась на попадания, а не плавила origin. Когда медиакомпании нужен путь доставки, чей hit ratio переживает реальную, растущую, глобальную аудиторию, эта инженерия кэша и доступа – та способность, что мы приносим.

Ключевые выводы

• Ключ кэша – это хост и путь; он сообщает edge, что двум зрителям нужна одна копия.
• Ключ «на зрителя» (token в ключе) форкает каждый сегмент и обрушивает hit ratio почти до нуля.
• Токенизированные (signed) URL шлюзуют доступ на edge подписанным короткоживущим пропуском – это контроль доступа, не шифрование.
• Проверяйте токен, но держите вне ключа кэша: предпочитайте signed cookie или явно исключайте токен-параметры.
• Подписывайте манифест, а не каждый сегмент; версионируйте новым путём вместо purge для обычных правок.
• Долгий TTL на неизменяемых сегментах, короткий на live-манифесте; surrogate keys очищают весь тайтл разом.

Что почитать дальше

• Как CDN доставляет видео: origin, edge и кэш
• Cost engineering для CDN: egress, коммиты и 95-й перцентиль
• Архитектура и оркестрация multi-CDN