Что такое CDN с точки зрения инженера стриминга

TL;DR

Сеть доставки контента – Content Delivery Network, или CDN – это слой серверов между источником видео и плеером зрителя; через него проходит каждый байт, который когда-либо увидит ваша аудитория. CDN для стриминга устроен иначе, чем CDN для статического сайта: он строится вокруг более глубокой иерархии кэшей – origin shield, региональные mid-tier-кэши и edge-точки присутствия, – потому что один популярный live-эфир в противном случае мгновенно перегрузит origin. Основной показатель эффективности стримингового CDN – это коэффициент попаданий в кэш (cache hit ratio) на каждом уровне: у Netflix Open Connect для популярных тайтлов он превышает 99%, а у здорового коммерческого CDN составляет 95–99% на edge-уровне. Эта статья предлагает стриминг-инженеру, продакт-лиду или архитектору инфраструктуры практическую модель: научиться читать счёт от CDN, анализировать всплеск ребуферизации и понимать, что запрашивать у поставщиков на следующем RFP.

Зачем это вам

Если стриминговый продукт реально тратит деньги, половина расходов идёт на CDN; если стриминговый продукт падает в продакшене, CDN почти всегда оказывается первым или вторым в цепочке инцидента. Несмотря на это, большинство команд воспринимают CDN как чёрный ящик – купленный у инженера по продажам и управляемый кем-то другим. Именно так счёт за квартал утраивается, а архитектор не может объяснить, почему стрим начал ребуфериться в Бразилии во вторник в 21:00 по местному времени. Эта статья даёт нетехническому читателю достаточно понимания механики, чтобы планировать и контролировать работу, а инженеру – точную модель слой за слоем: origin → shield → mid-tier → edge → последняя миля – на которой построен весь Блок 6. К концу вы должны быть в состоянии нарисовать диаграмму по памяти, назвать ключевую метрику для каждого слоя и объяснить финансовому директору, как origin shield превращает счёт в $40 000 в месяц в счёт в $4 000.

Что такое CDN в одном абзаце

CDN – это глобально распределённый парк кэширующих серверов, который копирует ваш контент ближе к зрителям и отдаёт его из этих копий, а не из вашего origin. CDN делает пять работ одновременно: укорачивает сетевое расстояние между контентом и зрителем; поглощает нагрузку запросов, которую один origin никогда бы не выдержал; добавляет отказоустойчивость, отдавая с тысяч машин вместо одной; применяет edge-уровневую политику вроде подписанных URL и геоблокировки; и даёт оператору единую поверхность для биллинга вместо сотен контрактов на co-location. Вся конструкция – это, по сути, один трюк (кэшировать в множестве мест), применённый в масштабе, с обвязкой, удерживающей кэши свежими, точными и подотчётными.

Нетехническому читателю проще всего объяснить через сеть угловых магазинов. Origin – это один склад на другом конце города. Edge – это угловой магазин в каждом районе. Когда покупатель хочет бутылку воды, угловой магазин выдаёт её со своей полки – быстро, дёшево, без поездки на склад. За магазинами стоит региональный распределительный центр, который пополняет десятки точек одним выездом со склада, так что сам склад видит несколько оптовых заказов вместо тысяч одиночных. Этот центр – origin shield. Замените воду на HLS-сегменты, и вы получите стриминговый CDN.

Иерархия кэшей, специфичная для стриминга

Большинство инженеров впервые сталкиваются с CDN как с ускорителем статического сайта: один origin, один кэш на edge – и готово. CDN для стриминга устроен иначе. Здесь больше слоёв, они оптимизированы под видеотрафик, а ключевой метрикой на каждом уровне становится cache hit ratio – доля запросов, обслуженных из кэша без обращения к вышестоящему уровню. Двуслойный CDN с hit ratio 85% на edge отправляет 15% запросов в origin; четырёхслойный стриминговый CDN с тем же показателем на edge перехватывает почти все эти 15% на промежуточных уровнях, и до origin доходит лишь около 0,5%. Именно такая арифметика делает стриминговый продукт финансово жизнеспособным.

Сверху вниз канонический маршрут состоит из пяти этапов. Плеер – на устройстве зрителя. Edge POP – Point of Presence, ближайший CDN-сервер к зрителю, обычно расположенный в той же городской агломерации; Akamai во втором квартале 2026 года заявляет о более чем 4 200 таких локаций, у Cloudflare – 330+ городов. Mid-tier-кэш, или региональный кэш, находится за группой edge-серверов и хранит длинный хвост менее популярного контента, который нецелесообразно дублировать на каждом edge. Origin shield – единственный региональный слой, один из регионов внутри сети CDN-провайдера, через который проходит каждый запрос от edge-сервера, если он не был найден в mid-tier, прежде чем достичь origin. Origin – собственный упаковщик или хранилище оператора, единственное место в мире, где хранится каноническая копия каждого сегмента.

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

Именно эта форма иерархии отличает стриминговый CDN от CDN для статического контента. Пост в блоге может пережить один edge-кэш; концерт на 100 000 зрителей – нет. Причина в временном паттерне запросов при стриминге: каждый зритель одновременно запрашивает одни и те же несколько сегментов каждые 2–6 секунд – и так часами подряд. Иерархия превращает «100 000 зрителей просят сегмент 4172» в «один запрос к origin, четыре – к shield, 25 – к mid-tier и сотни тысяч ответов с edge». Без иерархии origin пришлось бы обслуживать 100 000 одинаковых запросов на один и тот же файл. С иерархией – всего один.

Пять работ CDN в простых цифрах

Каждая задача, выполняемая CDN, отображается на дашборде оператора в виде числа.

Первая задача – сократить сетевое расстояние. Чем короче путь между зрителем и данными, тем быстрее приходит первый байт, а значит, плеер сможет запросить более высокий битрейт. Time to First Byte – сокращённо TTFB – снижается с 300–800 миллисекунд при обращении к origin на другом континенте до менее чем 50 миллисекунд при попадании на ближайший edge. Это единственное изменение даёт наибольший вклад в ускорение времени запуска.

Вторая задача – поглощать нагрузку запросов. Live-эфир с частотой обновления одного сегмента каждые две секунды и 100 000 одновременных зрителей генерирует 50 000 запросов на получение сегментов в секунду. Один origin-веб-сервер способен обрабатывать примерно 1 000–5 000 запросов в секунду – в зависимости от мощности оборудования и сложности обработки. Соответственно, CDN должен принять на себя 95–99% этой нагрузки, не допуская её до origin. Четырёхуровневая иерархия с коэффициентом попадания в кэш end-to-end на уровне 99,9% направляет в origin всего 50 запросов в секунду – что вполне комфортно для одного сервера.

Третья задача – отказоустойчивость. Сервис с одним origin может выйти из строя из-за обрыва оптики – достаточно одного инцидента, чтобы он стал недоступен. CDN с 4 200 edge-локациями – нет. Даже если сам origin недоступен, edge-узлы с валидным кэшем продолжают отдавать контент; многие CDN поддерживают политики «stale-while-revalidate» или «stale-if-error», позволяющие edge-узлам на короткое время отдавать слегка устаревший контент, вместо того чтобы падать.

Четвёртая задача – применение политики на edge. Подписанные URL, токен-аутентификация, гео-ограничения, IP-белый список и лимиты на частоту запросов – всё это работает на edge, близко к пользователю, ещё до того, как запрос попадёт в сеть оператора. Арифметика проста: гео-правило, обрабатываемое на origin, требует полного цикла round-trip даже для заблокированных запросов; а гео-правило на edge блокирует их за микросекунды, не пересекая океан.

Пятая задача – консолидация биллинга. Без CDN глобальному стриминговому сервису требуются транзитные контракты с десятками провайдеров в десятках стран, соглашения о пиринге с eyeball-сетями, физическое размещение серверов в каждом регионе и финансовый отдел, способный вести переговоры со всеми. С использованием CDN всё это сводится к одному счёту. Цена компромисса – тарификация по объёму (per-GB), включающая маржу CDN-оператора (обычно $0,002–$0,085 за гигабайт в 2026 году), однако операционное упрощение, как правило, окупает затраты на нескольких инженеров в год.

Cache hit ratio – это и есть метрика

Стриминговый инженер, отслеживающий одну метрику из CDN, следит за коэффициентом попаданий в кэш (cache hit ratio). Формула проста:

Cache Hit Ratio (CHR) = cache_hits / (cache_hits + cache_misses)

Cache hit – это запрос, который был обслужен из локального хранилища кэша. Cache miss – запрос, переданный выше по цепочке, поскольку нужный контент отсутствовал или его срок действия истёк. Соотношение рассчитывают на каждом уровне – edge CHR, mid-tier CHR, shield CHR, – и дашборд оператора отображает каждый показатель отдельной линией.

Бенчмарки берутся прямо из индустрии. Здоровый стриминговый CDN обеспечивает 95–99% на edge-уровне. Если cache hit ratio стабильно ниже 80% – это признак неправильной настройки: почти всегда проблема в cache key, который включает параметры, привязанные к пользователю, или сессионные токены, из-за чего общий кэш фрагментируется на миллионы копий по одному зрителю. Инженеры Netflix оптимизировали свои Open Connect Appliances до 99%+ cache hit ratio для популярных тайтлов; публично опубликованный результат показал, что эта работа позволила сократить время запуска видео на 20% и практически полностью устранить ребуферы в середине стрима.

Покажем арифметику на примере одного live-эфира. Эфир с 100 000 зрителей генерирует 50 000 запросов на сегменты в секунду. При hit ratio на edge в 95% – 2 500 запросов в секунду направляются выше, на mid-tier. При hit ratio на mid-tier в 92% от этих запросов ещё 200 в секунду уходят на shield. При hit ratio на shield в 95% – всего 10 запросов в секунду доходят до origin. На входе у origin – 10 запросов в секунду из 50 000, то есть нагрузка снижается в 5 000 раз. Уберите shield – и origin будет получать 200 запросов в секунду, то есть в двадцать раз больше, и часто именно это – разница между спокойной работой origin и его перегрузкой.

Четыре распространённые причины низкого hit ratio, и что с каждой делать. Cache key включает данные пользователя. Уберите session-токены и auth-заголовки из cache key; проверяйте их на edge отдельной проверкой подписанного URL, не включая подпись в ключ. Per-viewer-кастомизация манифеста. SSAI персонализирует манифест на зрителя и взрывает пространство cache key; решение – server-guided ad insertion (SGAI), который оставляет сегменты кэшируемыми и персонализирует только манифест. Короткие TTL для VOD. Cache-Control: max-age=60 на фильме, который не менялся три года, – это мусор; ставьте дни и недели. Частые инвалидации. Используйте версионированные имена файлов (segment-00042-v2.m4s) вместо purge по URL при перекодировании; новая версия наполнится по мере запросов.

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

Чем live отличается от VOD на CDN

Видео по запросу и live-стриминг выглядят для плеера одинаково – оба используют HLS- или DASH-сегменты по HTTPS, – но CDN обрабатывает их по-разному. VOD-тайтлы записываются один раз и просматриваются годами; сегменты редко обновляются; TTL кэша составляет дни и недели; коэффициент попаданий в кэш на edge для популярных тайтлов регулярно достигает 98–99%. Live-эфир записывается в реальном времени, по секундам; сегменты существуют всего несколько минут, пока не выйдут за пределы окна DVR; TTL здесь короткие – 2–6 секунд, как и длительность сегмента. Edge-кэш постоянно обновляется; ключевой вопрос не в том, закэширован ли конкретный сегмент, а в том, успел ли он попасть в кэш до того, как первый зритель запросит его.

Из-за временной разницы live-трансляции используют две дополнительные техники, которые редко требуются для VOD.

Request collapsing (он же request coalescing, или «collapse forwarding») – техника, призванная решить проблему «громового стада». Когда 10 000 зрителей одновременно запрашивают у edge-сервера сегмент 4172, а он ещё не закэширован, CDN с использованием request collapsing отправляет один запрос upstream, а остальные 9 999 ставит в очередь, выдавая всем ответ сразу после его получения. Cloudflare, AWS CloudFront, Akamai, Fastly и кастомные shield на Varnish – все реализуют эту функцию. Официальный инженерный пост Cloudflare сообщает, что request coalescing сокращает количество запросов к origin более чем на 90% во время стампидов, и документация Varnish приводит ту же цифру. Без collapsing запуск прямого эфира – гарантированный сбой origin; с ним – обычное, ничем не примечательное событие.

Origin shielding – вторая техника, подробно описанная в статье 6.2; здесь достаточно понимать, что origin shield – это один выбранный регион, через который все запросы от edge-серверов направляются в единый кэш. Это повышает вероятность попадания в кэш (hit rate) до того, как запрос дойдёт до origin. Официальная документация AWS CloudFront прямо указывает, что Origin Shield «идеален для рабочих нагрузок со зрителями, распределёнными по разным географическим регионам, или для нагрузок с just-in-time-упаковкой видеостриминга, on-the-fly-обработкой изображений и подобными процессами». Включение Origin Shield для загруженного live-стрима – один из самых эффективных способов снизить затраты в команде стриминга.

VOD тоже выигрывает от обеих техник, но может обойтись без них; live – нет.

Цифры из прода: счёт на $40 000 превращается в счёт на $4 000

Рабочий пример, основанный на классе проектов, которые мы выпускали. Региональный спортивный стриминг-сервис обслуживает 50 000 одновременных зрителей вечером в субботу при среднем битрейте 3 Мбит/с. Каданс – один четырёхсекундный сегмент в секунду программы, то есть каждый зритель запрашивает один HLS-сегмент каждые 4 секунды: 12 500 запросов в секунду.

Запускаем без origin shield, на CDN, у которого перед origin стоят только edge POP. Измеренный edge cache hit ratio – 88%; live-природа контента не позволяет поднять этот показатель выше 95%, как ни настраивай остальное. 12 500 фетчей в секунду × 12% misses = 1 500 фетчей в секунду напрямую в origin. На уровне пропускной способности origin отдаёт в CDN 4,5 Гбит/с данных сегментов – около 2 ПБ исходящего трафика в месяц при такой нагрузке. По стандартной цене AWS на egress EC2 в CDN ($0,09 за ГБ) это примерно $180 000 в месяц. Большинство команд эту цифру обсуждают и пытаются снизить, но в чистой арифметике она остаётся именно такой.

Теперь активируем Origin Shield в одном регионе – например, eu-west-1 – и настроим CDN так, чтобы каждый edge-miss направлялся через shield. Hit ratio shield по полученным miss-запросам остаётся на уровне около 92% при той же нагрузке. 1 500 origin-BOUND запросов в секунду × 8% shield-miss = 120 запросов в секунду к origin. Origin теперь отдаёт 360 Мбит/с данных вместо 4,5 Гбит/с. Трафик с origin (egress) снижается в 12,5 раз. Счёт за CDN не меняется; стоимость origin egress падает с $180 000 до ~$14 400 в месяц. Сам shield обходится недорого – обычно это фиксированная региональная плата или ставка за гигабайт, значительно ниже, чем стоимость транзитного egress. Чистая экономия в этом примере – более $150 000 в месяц, при этом конфигурация, которую один инженер может развернуть за один день.

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

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

Типичная ошибка – воспринимать CDN как чёрный ящик

Самая дорогая ошибка, которую мы видим в стриминговых проектах, – команда покупает CDN, настраивает DNS на вендора и забывает про всё остальное: никто не отслеживает коэффициент попаданий в кэш, не включает origin shield, не измеряет пропускную способность по регионам. Sales engineer установил разумные значения по умолчанию для первого запуска – и с тех пор никто их не менял.

Через полгода стриминговый продукт приносит в три–пять раз больше дохода, чем ожидалось, производительность в одном регионе вдвое хуже, чем в другом, а команда не понимает, почему. Лечение всегда одно: посмотреть четыре стандартных дашборда, которые CDN предоставляет по умолчанию – объём запросов на edge-группу, cache hit ratio по слоям, исходящий трафик с origin в байтах, TTFB по регионам – и действовать на основе полученных данных. Каждый коммерческий CDN отдаёт эти панели автоматически; провал – на стороне оператора, который их не использует.

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

Рынок CDN в 2026 году

Короткая обзорная справка, достаточная для разговора с вендорами. Akamai по-прежнему остаётся оператором крупнейшей единой сети в публичном интернете – 345 000+ edge-серверов в 4 200+ локациях во втором квартале 2026 по собственным данным Akamai – и доминирует в премиальном стриминговом вещании, где клиент платит за white-glove-обслуживание. По публичным оценкам, Akamai контролирует около 20% мирового рынка CDN. AWS CloudFront – стандартный выбор для стриминговых решений на базе AWS, предлагает хорошо интегрированный Origin Shield с управлением на уровне региона. Cloudflare работает в 330+ городах, предлагает сильный бесплатный тариф для старта и самые низкие листовые цены за гигабайт среди крупных коммерческих CDN. Fastly демонстрирует самые низкие абсолютные задержки в Северной Америке и Западной Европе, и его выбирают команды, которым нужен программируемый VCL на edge. Google Media CDN – стриминг-специфичное решение Google Cloud – объединяет пиринг Google с eyeball-сетями и shield-подобный уровень защиты и обычно используется в стеке рядом с YouTube. Ниже верхнего эшелона – Bunny.net, CacheFly, BlazingCDN, EdgeCast (Edgio), CDN77, KeyCDN, G-Core Labs и 5centsCDN – обслуживают стриминговый трафик по конкурентным ценам за гигабайт, часто с региональным преимуществом.

Две специализированные модели заслуживают внимания. Embedded ISP appliances – такие как Netflix Open Connect, YouTube Edge Cache и различные кэши, развёрнутые Akamai NetSession, – физически размещаются внутри сетей провайдеров, отдают только контент оператора и обходят публичный интернет на последнем участке пути. Как указано в публичной партнёрской документации Netflix, Open Connect Appliances обладают теми же возможностями, что и OCA в более чем 60 глобальных дата-центрах Netflix, и направляют клиентский трафик через BGP-анонсы, согласованные с провайдером. Это золотой стандарт по производительности и соотношению цены и качества – пропускная способность, не проходящая через транзитные сети, фактически бесплатна. Однако такой подход требует достаточного масштаба, чтобы провайдер согласился разместить ваш кастомный appliance. На практике это реализовано у Netflix, YouTube, Disney+ и самих операторов Big Tech CDN.

Multi-CDN – вторая модель, и именно её используют большинство крупных стриминговых платформ. Два или более CDN с steering-слоем, который маршрутизирует трафик между ними по регионам, по рендери или по сессии. Мы посвящаем этому вопросам статьи 6.4 и 6.5, потому что операционная история там достаточно насыщенная.

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

Фора Софт строит видеоинфраструктуру с 2005 года, и слой CDN присутствует в каждом нашем проекте: live-стриминг для спортивных и киберспортивных операторов, OTT- и Internet TV-платформы, системы видеоконференцсвязи и телемедицины, соединяющие WebRTC-пиров с широковещательной аудиторией, e-learning-платформы, сочетающие VOD-лекции и live-воркшопы, AR/VR-эксперименты с более жёсткими требованиями к задержкам. Мы сотрудничаем с крупными коммерческими CDN, с региональными игроками там, где они превосходят гигантов, и с embedded-кеш-развёртываниями, когда масштаб клиента это оправдывает. Наша работа редко сводится к простому выбору CDN – это проектирование иерархии кэшей, модель затрат, multi-CDN-руление и инструментирование с точки зрения оператора, всё то, что делает стриминговый продукт финансово жизнеспособным в масштабах.

Ключевые тезисы

• Стриминговый CDN представляет собой пятиярусную иерархию: origin, shield, mid-tier, edge и плеер. Это не просто один кэш.
• Показатель cache hit ratio по каждому ярусу – ключевая метрика: 95–99% на edge – норма, а ниже 80% – признак ошибочного cache key.
• Origin shielding в сочетании с request collapsing позволяет live-эфиру выдержать резкий всплеск нагрузки при старте.
• Сокращение исходящего трафика с origin в 12 раз достигается за один день настройки shield – типичный пример: $40K → $4K.
• Live и VOD используют один и тот же CDN, но по-разному: для live нужны короткие TTL, shield и collapsing.
• Четыре дашборда, которые анализируют еженедельно: запросы на edge, hit ratio по ярусам, исходящий трафик с origin и TTFB по регионам.

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

• Origin shielding и многоуровневое кэширование – архитектура и принципы работы слоя shield.
• Multi-CDN: архитектура и стоимость – когда одного CDN недостаточно.
• Экономика CDN: 95-й перцентиль, commit, overage, transit – как формируются и согласуются счета.

CTA

• Обсудите с инженером по стримингу вашу CDN-архитектуру: связаться.
• Посмотрите наши кейсы в сфере видео-стриминга, OTT и прямых трансляций: video streaming, OTT и live.
• Скачайте CDN-чек-лист: PDF.