Блог ДоверьсяСервису

CDN: как устроена система доставки контента

CDN, или Content Delivery Network, — распределенная сеть узлов, которая принимает запросы пользователей ближе к ним и доставляет контент от имени исходного сервера. Кешируемые файлы edge-узел может отдать без обращения к origin, а остальные запросы передает дальше как reverse proxy. Это сокращает сетевой путь, разгружает источник и дает единую точку для TLS, правил кеширования и фильтрации трафика.

02.09.2026 Обновлено 02.09.2026 11 мин чтения Редакция ДоверьсяСервису

Главная мысль: CDN ускоряет не «сайт вообще», а конкретные ответы при конкретных правилах. Результат зависит от географии аудитории, размера объектов, доли cache hit, cache key, TTL, скорости origin и поведения приложения.

Что означает CDN

Сеть доставки контента состоит из точек присутствия, или PoP, размещенных в разных сетях и регионах. В каждой точке работают edge-серверы. Пользователь обращается к привычному домену, но DNS и маршрутизация приводят запрос к подходящему узлу провайдера.

CDN не заменяет исходное хранилище или приложение. Origin остается источником актуальной версии: это может быть веб-сервер, объектное хранилище, load balancer или API. Edge хранит копии разрешенных ответов и обновляет их по заданным правилам.

Как проходит запрос

Браузер определяет адрес домена через DNS.
Сеть направляет запрос в доступную edge-точку с подходящим маршрутом.
Узел вычисляет cache key и ищет соответствующий объект.
При cache hit готовый ответ отправляется пользователю.
При miss edge запрашивает объект у origin или промежуточного regional cache.
Origin формирует ответ и передает headers и body.
CDN возвращает ответ клиенту и, если правила разрешают, сохраняет копию.

Ближайшая точка не обязательно определяется километрами. На выбор влияют сетевые связи, задержка, доступность, нагрузка и политика провайдера. Поэтому физически близкий узел иногда уступает более удаленному по фактическому маршруту.

Hit, miss и повторное использование

HIT означает, что подходящий свежий объект уже был на edge. MISS — что за ним пришлось обратиться к следующему уровню или origin. STALE, REVALIDATED, BYPASS и другие статусы зависят от реализации, но помогают понять судьбу ответа.

Первый запрос к редкому файлу может не стать быстрее. Польза появляется на повторных запросах и при shared cache между пользователями. Для длинного «хвоста» уникальных URL cache hit ratio бывает низким даже при правильной инфраструктуре.

Какие данные обычно кешируют

Тип ответа	Типичная стратегия	Главный риск
CSS, JS, шрифты	Долгий TTL и версия в имени файла	Старая сборка без versioning
Изображения и видео	Edge cache, range requests	Большой miss и дорогой origin egress
Публичный HTML	Короткий TTL или revalidation	Устаревшая страница
Публичный API	Только явно выбранные GET-ответы	Смешение вариантов ответа
Личный кабинет	Обычно bypass/private/no-store	Выдача чужих персональных данных

Расширение файла само по себе не гарантирует безопасность кеширования. Решение принимают по методу, status code, headers, cookies, авторизации, содержимому и правилам конкретного CDN.

Cache-Control и TTL

Origin сообщает политику через HTTP headers. Cache-Control: public, max-age=300 разрешает shared cache и задает срок свежести. s-maxage может отдельно управлять общим кешем, а private и no-store ограничивают хранение. Точная обработка directives зависит от конфигурации CDN.

TTL — компромисс между свежестью и числом обращений к origin. Для immutable asset с hash в имени допустим долгий срок, потому что новая версия получает новый URL. Для страницы с меняющейся ценой нужен короткий TTL, revalidation или целевой purge.

Cache key: почему один URL дает много копий

Cache key идентифицирует вариант объекта. Базово в него входят scheme, host, path и query string, но правила могут учитывать отдельные headers, cookies, язык, устройство и другие признаки. Чем больше вариантов, тем меньше повторное использование кеша.

Нельзя просто отбросить все query parameters: один параметр может быть рекламной меткой, а другой — менять страницу или подпись доступа. Сначала классифицируйте параметры на функциональные, аналитические и неизвестные, затем тестируйте нормализацию.

Практическая матрица TTL

Четыре вопроса для каждого маршрута

Одинаков ли ответ для разных пользователей?
Как быстро допустимо показать обновление?
Есть ли версия в URL или надежный purge?
Что произойдет, если edge временно отдаст stale?

Если ответ общий, версия встроена в URL, а задержка обновления неопасна, используйте долгий TTL. Если ответ персональный или зависит от прав доступа, не кешируйте его без специально спроектированного key и проверки. Промежуточные случаи начинают с малого TTL и наблюдения.

Обновление и invalidation

Объект исчезает из кеша после expiration, eviction или принудительной invalidation. Массовая очистка всего кеша проста, но после нее множество одновременных miss создают всплеск нагрузки на origin. Предпочтительнее удалять конкретные paths, tags или группы зависимых объектов.

Надежная схема для assets — content fingerprinting: например, имя файла содержит hash содержимого. Деплой публикует новый URL, HTML начинает ссылаться на него, а старый объект спокойно доживает TTL. Purge остается аварийным инструментом, а не обязательным шагом каждой публикации.

Revalidation и stale-контент

Вместо полной загрузки кеш может проверить актуальность через ETag или Last-Modified. Если объект не изменился, origin возвращает короткий ответ без body. Это экономит трафик, хотя запрос до источника все равно выполняется.

Директивы вроде stale-while-revalidate и stale-if-error позволяют временно использовать устаревшую копию при обновлении или сбое. Применять их нужно по бизнес-смыслу: старая статья приемлема, старая персональная информация или остаток товара может быть опасен.

Статический и динамический контент

Статические объекты проще кешировать, но CDN работает и с динамическими запросами: держит соединения к origin, оптимизирует TLS, выбирает маршрут, выполняет edge logic и фильтрует трафик. Такой ответ может проходить через edge без сохранения body.

Динамический HTML иногда делят на публичную кешируемую оболочку и персональные данные, которые приложение загружает отдельно. Архитектура требует аккуратной авторизации и не должна раскрывать закрытую информацию в общем кеше.

Изображения, видео и большие файлы

Для media важны поддержка byte-range, корректный Content-Type, compression, responsive variants и ограничения размера. CDN может сократить путь до пользователя, но не исправляет изображение, которое в десять раз тяжелее нужного.

Генерацию вариантов лучше контролировать: фиксировать допустимые dimensions и formats, защищать transformation endpoint от произвольных комбинаций и учитывать, что каждый вариант создает отдельный объект кеша.

Зачем CDN небольшому сайту

Польза зависит не только от масштаба. Небольшой проект с аудиторией далеко от origin, тяжелыми изображениями или резкими всплесками может выиграть заметнее крупного локального приложения с персональными ответами. CDN также упрощает единый внешний TLS-контур и скрытие origin, если конфигурация завершена.

Если аудитория и сервер находятся в одном регионе, страницы легкие, а кешировать почти нечего, эффект может быть скромным. Подключение оценивают измерениями, а не самим фактом наличия CDN.

Калькулятор нагрузки на origin

Быстрая модель экономии

Для кешируемого трафика оцените origin bytes = requests × average object size × (1 − hit ratio). Если за период было 2 000 000 запросов к объектам по 150 КБ, а hit ratio равен 0,80, источник передаст примерно 2 000 000 × 150 КБ × 0,20 = 60 000 000 КБ, то есть около 60 ГБ в десятичном исчислении.

Без edge-кеша модель дает около 300 ГБ. Это ориентир, а не счет: добавьте revalidation, range, compression, misses разных размеров, shield, retries, динамические ответы и служебный трафик. Считать лучше по логам CDN и origin отдельно.

Метрики, которые показывают результат

cache hit ratio по requests и bytes;
p50, p75, p95 latency по регионам;
time to first byte на hit и miss;
origin requests, bandwidth и error rate;
доля bypass, stale и revalidated;
стоимость delivery, requests, purge и origin egress;
Core Web Vitals для реальных пользователей;
время распространения новой версии.

Среднее значение скрывает проблемные регионы и редкие тяжелые объекты. Сегментируйте данные по стране, ASN, route, content type, status и cache status.

CDN и безопасность

Edge может завершать TLS, применять WAF, rate limiting, bot rules и поглощать часть атак. Но CDN не исправляет уязвимости приложения и не защищает origin, если его адрес доступен напрямую. Разрешайте production traffic от ожидаемой сети провайдера или используйте аутентифицированное соединение, если архитектура это поддерживает.

Не кешируйте ответы с сессией, персональными данными или авторизацией без явной модели вариантов. Проверяйте влияние cookies, headers и error pages: случайный публичный кеш приватного ответа — критическая ошибка.

DNS, TLS и origin

Подключение обычно меняет DNS так, чтобы публичный домен указывал на сеть CDN. На внешнем контуре нужен сертификат для пользовательского host, а между edge и origin — отдельное защищенное и проверяемое соединение. Режим, при котором edge принимает HTTPS, но обращается к origin без проверки сертификата, оставляет слабый участок.

Перед переключением уменьшите DNS TTL, подготовьте сертификаты, origin host header и health checks. Сохраните план отката и не выключайте старый маршрут до проверки реального трафика.

Multi-CDN и origin shield

Origin shield добавляет общий уровень кеша между edge-точками и источником. Несколько PoP запрашивают редкий объект у shield, поэтому origin получает меньше дублирующих miss. Это полезно при широкой географии, но добавляет hop и требует измерения.

Multi-CDN распределяет delivery между провайдерами ради доступности, охвата или цены. Вместе с устойчивостью появляются разные cache semantics, logs, purge API, TLS и правила безопасности. Такой подход оправдан только с автоматизированным управлением и регулярными failover tests.

Как выбрать CDN

Критерий	Что проверить
География	Latency из стран и сетей вашей аудитории
Кеширование	Headers, custom key, tags, purge, stale
Origin	Shield, failover, private access, timeouts
Media	Range, streaming, transformations, limits
Безопасность	TLS, WAF, DDoS, rate limiting, logs
Наблюдаемость	Real-time logs, metrics, export, retention
Стоимость	Traffic, requests, regions, purge, support
Выход	DNS rollback, API portability, export

Для первичного списка можно открыть категорию CDN-хостинг. Карточки Cloudflare и CDN77 показывают примеры отдельных сервисов; фактический выбор делайте после теста на своей географии, объектах и профиле нагрузки.

План безопасного подключения

Снимите baseline latency, TTFB, traffic и errors.
Разделите routes на public cache, private и bypass.
Зафиксируйте cache key, TTL и invalidation для каждой группы.
Подключите тестовый hostname и production-like origin.
Проверьте TLS, redirects, compression, CORS и range.
Сравните body и headers при hit, miss и bypass.
Проведите тест публикации, purge и rollback.
Переведите малую долю трафика или один безопасный route.
Контролируйте cache status, latency и origin load.
Закройте прямой доступ к origin после подтверждения схемы.

Типичные ошибки

кешировать все ответы по одному правилу;
включать cookie или случайные параметры в каждый cache key;
игнорировать Vary и content negotiation;
очищать весь кеш после каждого изменения;
не версионировать статические assets;
измерять только среднюю скорость из офиса;
считать CDN резервной копией origin;
оставлять origin доступным в обход защиты;
не проверять персонализированные и error responses;
забывать о стоимости requests и исходящего трафика;
менять DNS без плана отката;
считать высокий hit ratio единственной целью.

Чек-лист перед запуском

список hostnames и origins утвержден;
сертификаты действуют на обоих участках;
public и private routes разделены;
cache key документирован;
TTL соответствует допустимой давности;
assets имеют versioned URLs;
purge проверен на тестовом объекте;
cookies, auth и CORS протестированы;
range и media playback работают;
logs доступны команде эксплуатации;
alerts покрывают edge и origin errors;
origin защищен от обхода;
rollback не зависит от панели одного человека.

Частые вопросы

CDN и хостинг — одно и то же?

Нет. Хостинг размещает исходные файлы или приложение, а CDN доставляет ответы через распределенные edge-узлы. Некоторые платформы объединяют обе услуги, но роли остаются разными.

Ускорит ли CDN базу данных?

Напрямую нет. Он может уменьшить число запросов к приложению за счет кеша, но медленные queries, locks и неверные indexes нужно исправлять на уровне системы.

Можно ли кешировать HTML?

Да, если ответ публичный и правила учитывают все значимые варианты. Для авторизованных пользователей, корзины и персональных данных обычно нужен bypass или специально спроектированный механизм.

Что лучше: длинный TTL или purge?

Для versioned immutable assets удобен длинный TTL. Для изменяемых URL сочетайте допустимый TTL, revalidation и точечную invalidation. Массовый purge не должен быть обычным процессом.

Почему после подключения сайт не стал быстрее?

Возможны низкий hit ratio, фрагментированный cache key, медленный origin на miss, близкая аудитория, тяжелый frontend или неверные измерения. Сравните hit и miss по регионам и типам объектов.

Итог

CDN полезен как управляемый слой между пользователем и origin: сокращает путь к повторно используемому контенту, уменьшает нагрузку и добавляет сетевые средства защиты. Начните с карты маршрутов, cache key и допустимой свежести, затем проверьте конфигурацию на малой доле трафика. Решение оценивайте по latency, hit ratio, origin load, ошибкам, стоимости и корректности данных, а не по числу edge-точек в рекламном описании.

Редакция ДоверьсяСервису

Эксперты по онлайн-сервисам. Команда проекта проверяет материалы о сервисах, тарифах и задачах, обновляет данные и помогает сравнивать сервисы по фактам.