Что такое CDN: как работает сеть доставки контента и когда она нужна бизнесу

Автор: Василий Сошников, заместитель технического директора EdgeЦентр.

CDN (Content Delivery Network, сеть доставки контента) — это распределённая сеть серверов, которые хранят копии файлов вашего сайта и отдают их пользователю с ближайшей к нему точки. Вместо того чтобы каждый запрос шёл до вашего сервера, картинки, скрипты, стили и видео приходят с сервера в том же городе или регионе. Результат — быстрее загрузка, меньше нагрузка на ваш сервер, устойчивость к скачкам трафика.

Разберём, как это устроено технически, какие задачи бизнеса CDN закрывает, а какие нет, и как выбрать провайдера, не переплатив за то, что вам не нужно. Но сначала определимся с терминологией.

Ключевые термины: origin, edge, PoP и всё остальное

Терминология CDN компактная. Без неё дальше читать бессмысленно, поэтому разберём её один раз и таблицей.

Как работает CDN: путь запроса от пользователя до сервера

Чтобы понять преимущества сети доставки контента, нужно сначала посмотреть, что происходит без CDN.

Что происходит без CDN

Пользователь из Владивостока открывает интернет-магазин, сервер которого стоит в Москве. Браузер делает следующее:

1. DNS-резолвинг. Браузер выясняет IP-адрес домена. Если ответа нет в кэше, запрос идёт до авторитативного DNS-сервера.
2. TCP-соединение. Три пакета данных туда-обратно (SYN → SYN-ACK → ACK), каждый проходит около 6 500 км.
3. TLS-рукопожатие. Ещё один-два раунда обмена для TLS 1.3 или два-три для TLS 1.2, чтобы установить безопасное соединение.
4. HTTP-запрос и ответ. Только теперь сервер начинает отдавать HTML.
5. Загрузка ресурсов. Браузер разбирает HTML и запрашивает ещё 40–120 файлов: изображения, шрифты, CSS, JS. Каждый — с того же московского сервера.

Ключевая величина здесь — RTT (round-trip time), время полного оборота пакета. На маршруте Москва — Владивосток это обычно 60–90 мс по оптическому кабелю. Умножьте на количество раундов до первого байта, и получите 250–400 мс, потраченных до того, как пользователь увидел хоть что-то. Дальше — десятки параллельных запросов за ресурсами, каждый с той же задержкой.

Что происходит с CDN

Домен статического контента (или весь сайт) делегирован на CDN. Когда тот же пользователь из Владивостока заходит на сайт, браузер делает вот что:

• DNS отдаёт адрес ближайшего узла CDN — точки присутствия во Владивостоке или Хабаровске.
• TCP и TLS устанавливаются до этого узла. RTT падает с 70 мс до 5–15 мс.
• Узел проверяет свой кэш. Если файл есть — отдаёт немедленно. Ваш сервер об этом запросе даже не узнаёт.
• Если файла нет — узел идёт за ним к вашему серверу, отдаёт пользователю и сохраняет копию у себя. Следующий пользователь из этого региона получит файл уже локально.

Экономия складывается из двух частей: сокращения физического расстояния и разгрузки сервера-источника. Вторая часть важнее, чем кажется: при cache hit ratio 90% ваш сервер обрабатывает в десять раз меньше запросов, а значит, выдерживает в десять раз больший наплыв посетителей на том же железе.

Как пользователь попадает на ближайший узел

Само по себе наличие узла во Владивостоке ничего не даёт, если запрос всё равно уйдёт в Москву. За то, чтобы пользователь попал именно на ближайший сервер, отвечает механизм маршрутизации. Их два, и они принципиально разные.

GeoDNS (маршрутизация на уровне DNS). Провайдер держит собственные DNS-серверы, которые отдают разный IP-адрес в зависимости от того, откуда пришёл запрос. Пользователь из Хабаровска получает адрес хабаровского узла, из Москвы — московского.

Плюс подхода — простота и полный контроль над логикой распределения. Но есть и серьёзные минусы:

• Провайдер видит не адрес пользователя, а адрес его DNS-резолвера. Если человек использует публичный DNS, резолвер может физически находиться в другой стране, и пользователь уедет на неоптимальный узел. Частично это лечится расширением EDNS Client Subnet, но поддерживают его не все резолверы.
• Переключение при отказе узла ограничено TTL DNS-записи и кэшами промежуточных резолверов. Даже при TTL в 60 секунд часть трафика будет идти на упавший узел ещё несколько минут.

Anycast (маршрутизация на уровне сети). Один и тот же IP-адрес анонсируется по BGP одновременно из десятков точек. Сеть сама доставляет пакет в ближайшую по метрикам маршрутизации точку — решение принимают магистральные операторы, а не CDN.

Плюсы:

• Переключение при отказе узла происходит на уровне маршрутизации за секунды, без участия DNS
• Адрес пользователя виден напрямую, а не через резолвер
• Объёмная DDoS-атака автоматически размазывается по всем точкам анонса

Минус: «ближайший по BGP» не всегда означает «ближайший географически» — маршрутные политики операторов иногда дают неожиданный результат.

На практике зрелые сети используют комбинацию: Anycast как базовый механизм плюс дополнительная логика распределения нагрузки внутри региона.

Cache hit и cache miss

Два состояния, вокруг которых крутится вся экономика CDN:

• Cache hit — файл нашёлся в кэше узла и отдан сразу. Быстро, дёшево, origin (источник) не потревожен.
• Cache miss — файла в кэше нет, узел запрашивает его у origin. Медленнее исходного варианта на величину одного дополнительного плеча, зато следующий запрос будет hit.

Cache hit ratio — доля попаданий от общего числа запросов. Это главная метрика здоровья вашей CDN-конфигурации. Значение ниже 80% для статики почти всегда означает ошибку в заголовках кэширования, а не особенность проекта. О том, как её чинить, мы расскажем в отдельном материале про настройку кэширования.

Push и Pull: две модели наполнения кэша

Есть два способа положить файл на узлы сети, и разница между ними определяет, как вы будете работать с CDN каждый день.

Pull CDN (реактивная модель). Узел ничего не хранит заранее. Первый пользователь, запросивший файл в этом регионе, инициирует загрузку с origin. Узел скачивает файл, отдаёт его пользователю и сохраняет копию. Все последующие получают её из кэша.

Эту модель используют по умолчанию большинство провайдеров. Ничего не нужно выкладывать вручную. Вы кладёте файл на свой сервер, и он автоматически расходится по сети по мере обращений. Плата — те самые первые запросы в каждом регионе, которые проходят полный путь.

Push CDN (проактивная модель). Вы сами загружаете файлы в хранилище провайдера, и они распространяются по узлам до того, как их кто-то запросил. Origin в классическом смысле не нужен вообще.

Этот подход имеет смысл в двух случаях:

1. Файлы очень крупные и первая загрузка недопустимо долгая (дистрибутивы, обновления игр).
2. Вы точно знаете момент пика. Например, релиз в 12:00, к которому контент должен быть уже разложен по сети.

Практический совет: начинайте с Pull. Переход на Push оправдан, когда вы упёрлись в конкретную проблему, которую Pull не решает. «На всякий случай» его использовать не стоит.

Что CDN даёт бизнесу: шесть задач и метрики к ним

CDN — инфраструктурный инструмент, но покупают его под бизнес-задачи. Ниже — соответствие одного другому.

Обратите внимание, чего в этой таблице нет: CDN не ускоряет генерацию страницы вашим бэкендом, не чинит тяжёлые SQL-запросы и не компенсирует раздутый JavaScript. Об этом — ниже, в разделе о том, кому CDN не нужен.

Какой контент CDN ускоряет, а какой нет

Разделение по типам контента — то место, где чаще всего возникают завышенные ожидания.

Статика — идеальный случай. Изображения, шрифты, CSS, JS-бандлы, PDF, архивы. Файл не меняется между запросами, кэшируется на месяцы, cache hit ratio легко доводится до 95%+. Здесь CDN даёт максимум при минимуме настройки.

Видео и аудио — тоже отлично. Потоковое видео разбито на сегменты по 2–10 секунд, каждый сегмент — обычный статический файл. Плюс объёмы такие, что без распределённой доставки задача не решается вообще: один сервер физически не отдаст 200 ТБ в месяц на приемлемой скорости.

Динамический HTML — сложнее, но выигрыш есть. Страницу с персонализацией (корзина, имя пользователя, рекомендации) закэшировать целиком нельзя. Но ускорение всё равно происходит: TLS терминируется на edge, соединение до origin переиспользуется через keep-alive, маршрут оптимизирован. Экономия на первом байте обычно 30–60% от RTT, даже если ответ каждый раз генерируется заново.

API — зависит от природы ответов. Справочники, каталоги, курсы валют кэшируются на секунды или минуты и дают огромный выигрыш. Персональные данные пользователя не кэшируются никогда, но выигрывают от оптимизированного транспорта.

Что CDN не ускорит: долгие вычисления на бэкенде, медленную базу данных, синхронные обращения к внешним сервисам внутри вашего кода, тяжёлый рендеринг на клиенте. Если LCP страницы 6 секунд из-за того, что фронтенд грузит 4 МБ JavaScript, CDN снизит эту цифру до 5 секунд, но не до 2.

Кому CDN действительно нужен

Признаки, по которым можно уверенно принимать решение:

• География аудитории шире одного региона. Если 30% посетителей приходят из-за Урала, а сервер в Москве, вы теряете этих людей на скорости.
• Много статики или медиа. Интернет-магазин с каталогом на десятки тысяч изображений, медиапортал, онлайн-школа с видеоуроками.
• Резкие пики нагрузки. Распродажи, рассылки, эфиры, релизы, сезонность. CDN сглаживает пик, не доводя его до origin.
• Видео в любом виде. Здесь вопрос не в оптимизации, а в принципиальной осуществимости.
• Требования к доступности. Когда простой стоит денег, распределённая доставка — часть отказоустойчивости.
• Международная аудитория. Без CDN пользователь из другой страны получает задержку в сотни миллисекунд.

Что именно даёт CDN в разных типах проектов:

Кому CDN не нужен

Сайт с локальной аудиторией и небольшим трафиком. Корпоративный сайт на 300 визитов в сутки, все посетители из одного города, сервер там же. Выигрыш будет измеряться единицами миллисекунд, а конфигурация усложнится.

Проект, где узкое место — бэкенд. Если сервер генерирует HTML за 3 секунды, начинать нужно с профилирования кода и базы, а не с CDN. Иначе вы заплатите за инструмент, который ускорит второстепенную часть.

Полностью персонализированное приложение без статики. Внутренний SaaS-интерфейс, где каждый байт ответа уникален для пользователя, а весь фронтенд загружается один раз при входе. Выигрыш будет, но небольшой.

Ресурс, у которого не решены базовые вещи. Не сжаты изображения, нет gzip или brotli, отсутствует кэширование в браузере, страница тянет 60 сторонних скриптов. Эти работы дешевле и дают больший эффект. CDN стоит подключать после них, а не вместо них.
CDN сокращает расстояние и разгружает источник. Всё, что не сводится к расстоянию и нагрузке, решается в другом месте.

CDN и SEO: как скорость влияет на позиции

Связь есть, но она не такая прямая, как обычно преподносят.

Прямое влияние. Скорость — подтверждённый фактор ранжирования у Google (Page Experience и Core Web Vitals) и учитывается Яндексом в оценке качества сайта. Вес этого фактора невелик: он проявляется как дополнительный показатель в сравнении похожих страниц, и не вытянет слабый контент в топ.

Целевые значения Core Web Vitals, на которые опирается Google:

CDN напрямую влияет на TTFB и на ту часть LCP, которая приходится на загрузку ресурса. На INP и CLS он не влияет никак — это зона фронтенда.

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

Краулинговый бюджет — недооценённый эффект. Поисковый робот выделяет на сайт ограниченное время. Если сервер отвечает за 900 мс, робот успевает обойти в разы меньше страниц, чем при ответе за 150 мс. На сайте с сотнями тысяч URL это критичнее прямого фактора ранжирования: страницы, до которых робот не дошёл, не ранжируются вообще.

CDN и защита: что закрывается, а что нет

CDN часто продают как средство защиты. Это правда, но есть ограничения. Давайте их разберём.

Что CDN даёт по умолчанию:

• Скрывает реальный IP-адрес origin-сервера. Атаковать напрямую становится сложнее.
• Размазывает объёмную атаку по десяткам узлов вместо одного канала.
• Поглощает паразитный трафик к кэшируемым URL, не пропуская его к источнику.

Чего CDN сама по себе не делает:

• Не фильтрует атаки на уровне приложения (L7) — для этого нужен отдельный WAF.
• Не отличает бота от человека без модуля бот-менеджмента.
• Не защитит origin, если его IP уже утёк и доступен напрямую. Поэтому обязательно нужно закрыть origin файрволом, разрешив входящие соединения только с сетей вашего CDN-провайдера.

CDN — полезный, но не достаточный элемент защиты. Полноценный контур — это CDN плюс специализированная защита от DDoS-атак на L3-L4 и L7 плюс WAF.

Как правильно закрыть origin

Шаг, который пропускают чаще всего, — и из-за этого теряется половина смысла подключения. Если после переключения на CDN ваш сервер по-прежнему принимает соединения с любого адреса, атакующему достаточно узнать его IP, чтобы обойти всю защиту.

Через что утекает IP:

• Старые DNS-записи в исторических базах
• Заголовки исходящей почты с того же сервера
• SSL-сертификат, засветившийся в публичных логах Certificate Transparency до подключения CDN
• Поддомены вроде mail. или ftp., оставленные с прямыми записями
• Страницы ошибок, раскрывающие адрес

Как защититься от этого:

1. Разрешите на файрволе входящие соединения на 80 и 443 порты только с сетей вашего CDN-провайдера. Актуальный список префиксов провайдеры публикуют и обновляют.
2. Проверьте поддомены. Всё, что не должно быть доступно напрямую, уводите за CDN или переносите на отдельный адрес.
3. Смените IP origin после подключения, если он уже засветился. Иначе старый адрес останется в базах сканеров навсегда.
4. Настройте проверку на стороне origin, что запрос действительно пришёл от CDN. Это можно сделать по секретному заголовку или по клиентскому сертификату.

Первого пункта достаточно в 90% случаев, без него остальные меры бессмысленны.

Что умеет современная CDN кроме кэширования

Представление о CDN как о «распределённом кэше» отстало лет на десять. Узел — это программируемая точка на пути трафика, и большая часть работы, которую раньше делал бэкенд, сегодня выносится туда.

Преобразование изображений на лету. Один исходный файл в высоком разрешении, а узел отдаёт нужный формат и размер по параметрам URL или по заголовку Accept. Браузер с поддержкой AVIF получит AVIF, старый Safari — JPEG. Экономия веса на изображениях обычно 30–60% без потери видимого качества, а вам не нужно хранить пять вариантов каждого файла.

Сжатие. Gzip и Brotli на лету. Brotli на статических текстовых ресурсах даёт на 15–25% меньший размер, чем gzip, при сопоставимой скорости распаковки.

Терминация TLS и современные протоколы. HTTP/3 и QUIC включаются на стороне CDN одной галочкой, без обновления вашего веб-сервера. Для мобильных пользователей с нестабильной сетью выигрыш ощутимый.

Правила на узлах. Узел берёт на себя множество задач: редиректы, переписывание URL, подстановка и удаление заголовков, ограничение доступа по IP, стране или Referer, распределение трафика между версиями для A/B-тестов. Всё это не стоит вам ни одного такта CPU.

Signer URLs и токены. URL с ограниченным сроком жизни и криптографической подписью. Базовый механизм для защиты платного контента: ссылка, утёкшая в мессенджер, перестаёт работать через заданное время.

Ограничение частоты запросов. Rate limiting по IP, по сессии или по произвольному ключу. Это первая линия защиты от перебора паролей, парсинга и простых ботов.

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

WAF и бот-менеджмент. Обычно отдельные модули поверх CDN, но работают на той же точке, что делает контур цельным.

Конечно, не факт, что вам понадобится всё сразу. Но часть задач, которые вы решаете кодом на бэкенде, модет быть дешевле и быстрее решать на узлах сети.

Как измерить эффект: методика замера до и после

Утверждение «сайт стал быстрее» без цифр не стоит ничего. Ниже — минимальная воспроизводимая методика, которая позволит доказать эффект внутри компании и вовремя заметить неправильную настройку.

Шаг 1. Зафиксируйте базу до подключения. Снимите показатели минимум за две недели, чтобы отсечь суточные и недельные колебания:

• TTFB и полное время ответа по ключевым URL, в разбивке по регионам
• Полевые Core Web Vitals из Search Console и Яндекс.Вебмастера
• Число запросов к origin и исходящий трафик с него
• Пиковую нагрузку на сервер (load average, потребление CPU и памяти)

Шаг 2. Разделите синтетические данные и реальных пользователей. Это разные инструменты для разных задач, и путаница между ними — источник неверных выводов.

Работает связка: синтетика для быстрой проверки гипотез, полевые данные для оценки итога.

Шаг 3. Проверьте, что CDN вообще работает. Самый быстрый способ — посмотреть заголовки ответа:

curl -sSI https://example.ru/static/logo.svg

В ответе должны быть: заголовок с признаком попадания в кэш от провайдера (обычно X-Cache: HIT или аналог), корректный Cache-Control, а IP в выводе curl -v должен принадлежать сети CDN, а не вашему серверу. Полезно повторить запрос дважды: первый может дать MISS, второй обязан дать HIT.

Проверка времени по этапам соединения:

curl -o /dev/null -sS -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.ru/

Шаг 4. Следите за cache hit ratio первые две недели. Это главный индикатор корректности настройки. Если после стабилизации трафика значение по статике не поднялось выше 85–90%, ищите ошибку в заголовках — почти всегда дело в них.

Шаг 5. Считайте деньги, а не только миллисекунды. Сопоставьте счёт за CDN с тем, насколько сократился исходящий трафик и нагрузка на собственные серверы. На проектах с большим объёмом медиа CDN нередко не увеличивает совокупные расходы, а перераспределяет их — и одновременно снимает необходимость держать запас мощности под пики.

Как выбрать CDN-провайдера в России: восемь критериев

Отдельно — то, что нельзя оценить по сайту провайдера: скорость и компетентность техподдержки. Проверяется только на тесте. Запросите триал, задайте технический вопрос средней сложности и посмотрите на время и качество ответа. Это единственный способ узнать заранее.

Развёрнутое сравнение российских провайдеров с методикой замера мы проведём в отдельном материале о выборе CDN.

Сколько стоит CDN

Цена складывается из нескольких компонентов, и их соотношение сильно зависит от профиля проекта.

• Объём отданного трафика. Основная статья для медиа и видео.
• Количество запросов. Основная статья для проектов с множеством мелких файлов.
• Регионы отдачи. Трафик в разных географических зонах может тарифицироваться по-разному.
• Дополнительные функции. WAF, бот-менеджмент, ресайз изображений на лету, расширенные логи.
• Модель оплаты. Pay-as-you-go гибче, commit-тариф дешевле за единицу при предсказуемом объёме.

Скрытые статьи, о которых стоит спросить до подписания:

• Тарифицируется ли midgress-трафик между узлами и origin
• Входят ли операции инвалидации в тариф
• Платные ли сырые логи
• Есть ли минимальный ежемесячный платёж.

Посчитайте средний объём отдаваемых данных за месяц и число запросов. И сравните это с тем, во что вам уже обходится исходящий трафик с собственных серверов. Подробную калькуляцию разберём отдельно в материале о стоимости CDN.

Две схемы подключения: поддомен статики или весь сайт

Схема 1. Отдельный поддомен для статики. Вы создаёте static.example.ru или cdn.example.ru, направляете его на CDN и переписываете в шаблонах пути к изображениям, скриптам и стилям. HTML продолжает отдаваться напрямую с вашего сервера.

Схема 2. Весь трафик через CDN. Домен целиком делегируется на CDN, весь входящий трафик проходит через узлы сети, а кэшируется только то, что вы разрешили правилами.

Если цель — только скорость, и вы хотите минимальный риск, начните с первой схемы. Если в задачах есть защита, скрытие origin или правила на границе, сразу берите схему 2, иначе придётся переделывать. Есть и промежуточный вариант: запустить статику на поддомене, убедиться в корректности кэширования, затем перевести на CDN весь домен.

Отдельно про поддомен: вынос статики на другой домен создаёт дополнительный DNS-резолвинг и новое TLS-соединение. На современных протоколах это почти не заметно, но для сайтов с малым числом ресурсов выигрыш может быть меньше, чем накладные расходы.

Как подключить CDN: общая схема

Порядок одинаков почти у всех провайдеров и не требует изменений в коде.

1. Выберите схему подключения по таблице выше.
2. Создайте CDN-ресурс в панели провайдера, указав origin — IP-адрес или домен вашего сервера.
3. Настройте заголовки кэширования на origin. Это делается до переключения трафика. Здесь определяется будущий cache hit ratio.
4. Привяжите домен. Для поддомена статики — CNAME на выданный адрес CDN. Для всего сайта — смена NS или A-записи.
5. Выпустите TLS-сертификат. Обычно сделать это можно бесплатно и автоматически через ACME. Либо загрузите свой.
6. Проверьте до переключения. Откройте ресурс по временному адресу CDN или через файл hosts, убедитесь, что сайт работает целиком.
7. Снизьте TTL DNS-записи за сутки до переключения, чтобы откат был быстрым.
8. Переключите трафик и проверьте заголовки ответа. В ответе должен появиться заголовок с признаком кэширования от провайдера, а curl -I должен показывать корректные Cache-Control и статус попадания в кэш.
9. Закройте origin файрволом. Иначе смысл сокрытия IP теряется.

Семь типичных ошибок при внедрении CDN

1. Не настроены заголовки кэширования. Origin отдаёт Cache-Control: no-cache для всей статики, cache hit ratio держится около нуля, счёт растёт, ускорения нет. Самая частая ошибка.
2. Неправильный Vary. Заголовок Vary: User-Agent заставляет узел хранить отдельную копию файла под каждую вариацию строки браузера. Кэш фрагментируется, hit ratio падает в разы.
3. Кэширование персонализированных страниц. Личный кабинет или корзина, закэшированные без учёта cookie, приводят к тому, что один пользователь видит данные другого. Критичная ошибка, которую нужно исключать на этапе настройки правил.
4. Origin остался доступен напрямую. IP не скрыт файрволом, атака идёт мимо CDN.
5. Смешанный контент. Часть ресурсов осталась на http:// — браузер их блокирует, вёрстка ломается.
6. Забытый CORS. Шрифты и файлы, запрашиваемые с другого домена, перестают загружаться, потому что origin не отдаёт Access-Control-Allow-Origin.
7. Нет процедуры инвалидации. Файлы обновлены на сервере, но пользователи месяц видят старую версию. Решается либо purge при деплое, либо версионированием имён файлов через хеш содержимого. Второе надёжнее.

Часто задаваемые вопросы

Что такое CDN простыми словами? CDN — сеть серверов в разных городах и странах, которая хранит копии файлов вашего сайта и отдаёт их посетителю с ближайшего к нему сервера. Это сокращает расстояние, которое проходят данные, и снижает нагрузку на ваш основной сервер.

Как CDN ускоряет сайт? Двумя механизмами. Первый — географический: данные идут до ближайшего узла, а не до вашего сервера, и время оборота пакета падает с десятков миллисекунд до единиц. Второй — разгрузочный: большая часть запросов обслуживается из кэша, ваш сервер обрабатывает меньше нагрузки и отвечает быстрее на оставшиеся.

Нужен ли CDN небольшому сайту? Если аудитория сосредоточена в одном регионе, трафик небольшой, а сервер расположен там же — практического выигрыша почти не будет. CDN становится оправданным, когда аудитория распределена географически, есть заметный объём статики или медиа, либо случаются пики нагрузки.

Влияет ли CDN на SEO? Влияет, в основном косвенно. Скорость — подтверждённый, но не решающий фактор ранжирования. Гораздо важнее два эффекта: улучшение поведенческих факторов за счёт быстрой загрузки и рост краулингового бюджета. Робот успевает обойти больше страниц, когда сервер отвечает быстро.

Защищает ли CDN от DDoS-атак? Частично. CDN скрывает IP origin-сервера, распределяет объёмную атаку по множеству узлов и поглощает паразитные запросы к кэшируемым адресам. Но атаки на уровне приложения требуют отдельного WAF, а отличать ботов от людей умеет только специализированный модуль бот-менеджмента.

Что такое cache hit ratio и какое значение считать нормальным? Это доля запросов, обслуженных из кэша, без обращения к вашему серверу. Для статических файлов нормой считается 90–95% и выше. Значение ниже 80% почти всегда указывает на ошибку в заголовках кэширования, а не на особенность проекта.

Можно ли использовать CDN для видео? Да, и для видео это чаще всего единственный работоспособный вариант. Потоковое видео разбивается на короткие сегменты, каждый из которых кэшируется как обычный файл. Без распределённой доставки один сервер не выдержит объёмы, характерные для видеосервисов.

Чем CDN отличается от хостинга? Хостинг — это место, где сайт физически живёт: там лежат файлы, работает код, стоит база данных. CDN ничего не выполняет и не хранит оригиналы — он только кэширует копии и раздаёт их. CDN не заменяет хостинг, а работает поверх него.

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

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

Мы предоставляем собственную CDN. На момент публикации у нас 75+ точек присутствия по всей России, и мы продолжаем расширяться. Подробнее можно узнать на странице нашей сети.