Что такое 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 как чёрный ящик, купленный у sales engineer и управляемый кем-то ещё – именно так счёт за квартал утраивается, а архитектор не может ответить на вопрос «почему стрим ребуферился в Бразилии во вторник в 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 с 85% hit ratio на 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 – единственный региональный слой, один выбранный Region внутри сети CDN-провайдера, через который должен пройти каждый запрос от каждого edge, мимо которого промахнулся mid-tier, прежде чем достичь origin. Origin – собственный упаковщик или хранилище оператора, единственное место в мире, где живёт каноническая копия каждого сегмента.

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

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

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

Каждая работа, которую делает CDN, мапится на цифру на дашборде оператора.

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

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

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

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

Пятая работа – консолидация биллинга. Без CDN глобальному стриминговому продукту нужны транзит-контракты с десятками ISP в десятках стран, peering-соглашения с eyeball-сетями, физическое co-location в каждом регионе и финансовый отдел, способный спорить со всеми. С 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, включающий per-user-параметр или сессионный токен, и фрагментирующий то, что должно быть общим кэшем, на миллионы копий по одному зрителю. Netflix инженерил свои Open Connect Appliances до 99%+ cache hit ratio для популярных тайтлов; публично опубликованный результат показал, что эта работа дала улучшение времени старта видео на 20% и почти ноль ребуферов в середине стрима.

Покажем арифметику на одном live-эфире. Эфир на 100 000 зрителей даёт 50 000 фетчей сегментов в секунду. При 95% edge hit ratio 2 500 запросов в секунду уходят выше – на mid-tier. При mid-tier hit ratio 92% по этим уходящим запросам ещё 200 в секунду уходят на shield. При shield hit ratio 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 кэша – дни и недели; cache hit ratio на edge для популярных тайтлов рутинно доходит до 98–99%. Live-эфир пишется секунда за секундой; сегменты живут пару минут до того, как уйдут из DVR-окна; TTL коротки – 2–6 секунд, как длительность сегмента. Edge-кэш постоянно перенаполняется; вопрос не в том, закэширован ли конкретный сегмент, а в том, успел ли он закэшироваться к моменту, когда первый зритель его попросит.

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

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

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

VOD тоже выигрывает от обеих техник, но переносит их отсутствие; live – нет.

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

Рабочий пример, основанный на классе проектов, которые мы выпускали. Региональный спортивный стримеер несёт 50 000 одновременных зрителей вечером в субботу при среднем битрейте 3 Mbps. Каданс – один четырёхсекундный сегмент в секунду программы, то есть каждый зритель просит один 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 Gbps данных сегментов в секунду – около 2 PB egress в месяц на такой нагрузке. По стандартной цене AWS на egress EC2 в CDN ($0,09 за GB) это примерно $180 000 в месяц. Большинство команд эту цифру обсуждает и сбивает, но в чистой арифметике это она.

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

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

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

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

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

Через полгода стриминговый продукт платит в три-пять раз больше, чем должен, производительность в одном регионе вдвое хуже, чем в другом, и команда не знает, почему. Лечение всегда одно: прочитать четыре дашборда, которые CDN и так показывает – объём запросов на edge-группу, cache hit ratio по слоям, origin egress в байтах, per-region 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 с Region-уровнем управления. Cloudflare работает в 330+ городах, имеет сильный free-tier-onboarding и самые низкие per-GB-листовые цены среди крупных коммерческих CDN. Fastly показывает самые низкие абсолютные latency в Северной Америке и Западной Европе, и его выбирают команды, которым нужен программируемый VCL на edge. Google Media CDN – стриминг-специфичная поверхность Google Cloud – объединяет пиринг Google с eyeball-сетями и shield-подобный tier и обычно идёт в стек, соседний с YouTube. Ниже верхнего эшелона Bunny.net, CacheFly, BlazingCDN, EdgeCast (Edgio), CDN77, KeyCDN, G-Core Labs и 5centsCDN обслуживают стриминг-трафик по конкурентным per-GB-ценам, часто с региональным преимуществом.

Две специализированные модели заслуживают упоминания. Embedded ISP appliances – Netflix Open Connect, YouTube Edge Cache, разные кэши, которые Akamai NetSession разворачивал, – физически стоят внутри сетей ISP, отдают только контент оператора и обходят публичный интернет на последнем хопе. Open Connect Appliances у Netflix «имеют те же возможности, что и OCA в 60+ глобальных дата-центрах Netflix», по публичной партнёрской документации Netflix, и OCAs стерят клиентский трафик через BGP-анонсы, скоординированные с ISP. Это золотой стандарт по производительности и пол по стоимости – пропускная способность, не проходящая через транзит, на марже бесплатна, – но требует быть достаточно крупным, чтобы ISP принимал ваш кастомный 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-cache-развёртываниями, где масштаб клиента это оправдывает. Работа, которую мы делаем, редко сводится к «выберите CDN» в отрыве – это проектирование иерархии кэшей, модель затрат, multi-CDN-steering и инструментация на стороне оператора, всё то, что делает стриминговый продукт финансово возможным в масштабе.

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

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

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

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

CTA

• Поговорите со стриминг-инженером о вашей CDN-архитектуре: связаться.
• Посмотрите наши кейсы в video streaming, OTT и live.
• Скачайте CDN cheat sheet: PDF.