Как работает CDN и зачем он нужен для быстрого сайта

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

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

Зачем нужен CDN

Задержка. Скорость света конечна: запрос из Владивостока к серверу во Франкфурте идёт около 100 мс в одну сторону, и это без учёта TLS-рукопожатия. Страница с полусотней ресурсов набирает такими задержками секунды. Узел CDN в том же регионе сокращает путь до единиц миллисекунд.

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

Устойчивость к пикам. Всплеск трафика после рассылки или публикации в СМИ гасится сетью узлов, а не одним сервером. Многие CDN заодно фильтруют DDoS.

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

Как CDN находит ближайший узел

Есть два механизма, и работают они по-разному:

1) DNS-балансировка. Домен указывает на CDN, и его DNS-сервер отдаёт разный IP-адрес в зависимости от того, откуда пришёл запрос. Просто в реализации, но точность зависит от расположения резолвера, а не пользователя: если клиент использует публичный DNS, узел может оказаться не ближайшим.

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

Дальше узел проверяет, есть ли ресурс в кэше. Если есть — отдаёт сразу (cache hit), если нет — идёт за ним к вашему серверу (origin), кэширует и отдаёт (cache miss). Крупные CDN добавляют промежуточный слой origin shield: узлы ходят за контентом не напрямую к вам, а через один региональный кэш, чтобы после сброса кэша сервер не получил лавину одинаковых запросов.

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

Главный инструмент — HTTP-заголовки ответа, которые отдаёт ваш сервер:

• Cache-Control: public, max-age=31536000 — файл можно кэшировать год. Так помечают статику с хэшем в имени (app.4f2a1b.js): при изменении меняется имя, а не содержимое по старому адресу.
• Cache-Control: no-store — не кэшировать никогда. Для персональных страниц и ответов API с данными пользователя.
• s-maxage — отдельное время жизни для CDN, не затрагивающее браузер.
• stale-while-revalidate — разрешает отдать слегка устаревшую копию, пока в фоне обновляется свежая. Полезно, чтобы посетитель никогда не ждал похода к origin.
• ETag и Last-Modified — позволяют узлу переспросить сервер «изменилось ли» и получить 304 вместо полного тела.

Подробный разбор этих заголовков — в статье про HTTP-кэширование.

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

Что кэшировать, а что нельзя

Хорошо кэшируются: изображения, шрифты, CSS и JS, видео, файлы для скачивания, а также редко меняющиеся HTML-страницы вроде блога или документации.

Опасная зона — персонализированные ответы. Классическая авария выглядит так: страница личного кабинета случайно попадает под правило кэширования, и следующий посетитель видит чужие данные. Причина обычно в том, что приложение не поставило Cache-Control: private или no-store, а на CDN включено агрессивное правило «кэшировать всё». Проверяйте это до включения кэша для HTML, а не после.

Отдельный нюанс — cookie и заголовки: если ответ зависит от них, кэш должен различать варианты через Vary, иначе всем достанется первая попавшая в кэш версия.

Что меняется в инфраструктуре после подключения CDN

Вы перестаёте видеть реальные IP посетителей. Для сервера все запросы приходят от узлов CDN. Настоящий адрес передаётся в заголовке (X-Forwarded-For, CF-Connecting-IP), и веб-сервер надо научить ему доверять — иначе в логах, аналитике и блокировках по IP окажется бессмыслица.

Появляется вторая точка отказа со своей диагностикой. Ошибка теперь может возникнуть и между посетителем и CDN, и между CDN и вашим сервером. У Cloudflare это отдельная серия кодов — 520, 521, 522, 523, 524, каждый со своим смыслом; их разбор есть в статье про ошибки Cloudflare 52x.

Меняется картина мониторинга. Проверка доступности начинает измерять здоровье CDN, а не вашего сервера: origin может лежать, а закэшированная главная страница продолжит отдаваться. Поэтому полезно мониторить и origin напрямую — по отдельному адресу или служебному эндпоинту, минуя кэш.

TLS терминируется на стороне CDN. Сертификат для посетителей выдаёт CDN, а до вашего сервера идёт отдельное соединение — его тоже нужно шифровать и держать валидный сертификат на origin, иначе получите те самые ошибки 52x.

Когда CDN не нужен

• Аудитория в одном городе или регионе, а сервер рядом. Выигрыш по задержке будет в пределах погрешности.
• Почти весь контент персонализирован. Кэшировать нечего, а слой сложности добавится.
• Внутренние сервисы. Админкам и корпоративным системам CDN обычно только мешает.
• Проблема не в доставке. Если страница генерируется три секунды из-за тяжёлых запросов к базе, CDN этого не исправит — искать узкое место нужно на стороне приложения.

Как выбрать и проверить

Из популярных вариантов: Cloudflare — самый распространённый, есть бесплатный тариф и встроенная защита от DDoS; AWS CloudFront — если инфраструктура уже в AWS; Fastly — тонкая настройка логики на границе; BunnyCDN — недорогой вариант с понятным ценообразованием. Для российской аудитории отдельно смотрите, есть ли у сети узлы в России и как обстоят дела с оплатой.

После подключения проверьте три вещи:

1. Попадания в кэш. В заголовках ответа ищите CF-Cache-Status: HIT, X-Cache: Hit from cloudfront или аналог. Низкая доля попаданий обычно означает, что origin отдаёт запрещающие кэш заголовки.
2. Что отдаётся из кэша. Убедитесь, что туда не попали персональные страницы: curl -I с разными cookie покажет, различает ли CDN варианты.
3. Поведение при недоступности origin. Остановите сервер на минуту и посмотрите, что увидит посетитель: закэшированную страницу или ошибку.

FAQ

CDN и хостинг — это одно и то же? Нет. Хостинг хранит и генерирует сайт, CDN только раздаёт копии его контента. Без исходного сервера CDN нечего кэшировать.

Ускорит ли CDN сайт, если все посетители из одной страны? Немного — за счёт разгрузки сервера и оптимизаций на узлах. Но основной выигрыш CDN даёт именно на дальних расстояниях.

Влияет ли CDN на SEO? Косвенно: он ускоряет загрузку, а скорость учитывается в ранжировании. Прямого бонуса за факт использования CDN нет.

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