Что такое CDN и как он ускоряет загрузку сайта

Почти каждый, кто когда-нибудь работал с крупными сайтами, сталкивался с легендарной жалобой: “Почему у меня всё тормозит, а у моего коллеги – молниеносно?” И вот тут в 7 случаях из 10 вопрос даже не в вашем коде или “забитой” базе. Проблема прозаичная – физика и география. К счастью, решается она довольно элегантно, буквально за пару часов: нужен CDN.

На пальцах: откуда берётся задержка

Давайте расставим точки над i. Наш мир хоть и весь опутан оптоволокном – магии в нём нет. Свет по кабелям бежит примерно со скоростью 200 000 км/с. Между Москвой и Вирджинией — около 7 800 километров. Запрос туда-обратно – это уже минимум 78 миллисекунд только на “дорогу”. А если добавить реальные маршруты (транзитные точки, очереди и всё такое), спокойно выходит 120–150 мс.

Вот только для одной страницы браузеру таких “походов” нужно не раз-два:

• чтобы узнать IP — DNS-резолв,
• чтобы завести разговор — TCP handshake,
• договориться о шифровании — TLS handshake,
• получить HTML,
• загрузить найденные по ходу CSS/JS, картинки.

В сумме это обычно 6–8 поездок по миру. Даже если сервер отвечает практически мгновенно, счетчик крутится: при каждом круге по 140 мс набегает больше секунды просто на транспорт.

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

Концепция CDN без маркетингового глянца

CDN (Content Delivery Network) — это разветвлённая сеть серверов-посредников (их называют edge-узлами или PoP), раскиданных по всему шару. Они держат “кеш” нужных файлов вашего сайта прямо рядом с пользователем.

Ваш основной сервер теперь называется origin — он становится своеобразной мастер-копией (за ней правда), но отдаёт оригинал только когда какой-то файлик впервые понадобился где-нибудь в Чили или Сингапуре.

Как работает “гравитация запросов”

Есть два основных подхода:

• GeoDNS: DNS-сервер CDN на глаз определяет, где находится пользовательский резолвер и отдаёт ему адрес ближайшего edge-узла. Подвох — если пользователь живёт в Новосибирске, но у него прописан публичный DNS Google (8.8.8.8), сервис может вычислить его как московского или вообще европейского гостя.
• Anycast: здесь вообще хитроумно — один и тот же IP анонсируется во всех регионах сразу (“мы есть везде!”). По факту маршрутизаторы сами выбирают короткую дорогу до ближайшего узла. Бонусом тут идёт естественная защита от DDoS: в случае атаки трафик рассасывается по всем точкам мира одинаково.

У крупных провайдеров используется гибрид обоих способов вместе с мониторингом реальных задержек между областями.

Что происходит на edge

Самое простое деление: HIT (кеш попал) или MISS (не попал).

• Cache HIT — нужный файл уже лежит на узле CDN. Пользователь получает его почти мгновенно (5–20 мс). Сервер origin отдыхает.
• Cache MISS — файла нет. Узел спрашивает origin, кладёт свежую копию у себя для следующих пользователей из того же региона.

И вот тут появится первая цифра, которую стоит запоминать: cache hit ratio. На реально работающих сайтах со статикой эта метрика поднимается до 92–97%. Если там 60–70% — значит где-то прошляпили настройки кеширования (чуть ли не всегда виноваты заголовки).

Почему ускорение оказывается даже выше ожидаемого

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

• TLS-терминация на краю сети: теперь время рукопожатия TLS зависит не от далёкого сервера (150+ мс), а от ближнего узла CDN (иногда меньше 10 мс). После этого соединения между edge и origin поддерживаются постоянно.
• Торкнутые TCP-соединения: соединения между CDN и origin уже давно прогреты (“slow start” давно пройден), поэтому data льётся на полной скорости.
• HTTP/3+QUIC работает во многих CDN даже тогда, когда сам сервер их не поддерживает – QUIC серьёзно сокращает лаги при потере пакетов.
• Оптимизация проходит автоматически: изображения переконвертируются в WebP/AVIF именно тем клиентам, что просят это через Accept; тексты жмутся Brotli; css/js минифицируются сходу – ничего пилить вручную не нужно!

Типовые заблуждения админов и разработчиков

Самые частые ошибки вижу вот где:

• Кэшируют только статику – html якобы нельзя (“там же живой контент!”). На самом деле многие новости можно смело держать закэшированными хотя бы минуту-другую с директивами типа stale-while-revalidate; TTFB обрушивается с сотен до десятков миллисекунд.
• Оставляют дефолтный Cache-Control – CDN тогда ничего толком не хранит долго; правильный max-age=31536000 вместе с immutable превращает js/css/ico c версионированием названия вообще в бессмертные артефакты.
• Используют Vary по User-Agent без отбора нужды ­– кэш дробится на кучу вариантов впустую!
• Добавляют Set-Cookie даже в ответах на картинки – куча публичных CDN просто перестают такой контент кешировать вовсе!
• Про purge забывают напрочь – после деплоя старые куски висят сутками. Полная инвалидация должна быть автоматической частью CI/CD.

CDN тоже не волшебная палочка

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

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

Промежуточные итоги

Если настроить CDN нормально, то для удалённых пользователей TTFB реально сокращается сразу в разы, нагрузка на исходник падает чуть ли не в десять раз, плюс защита от массовых атак идёт встроенной “экономикой”. Всё это можно сделать буквально за вечер работы и увидеть результат к утру — достаточно просто вынести статику под защиту CDN и посмотреть недельную статистику cache hit ratio.

А дальше появляется азарт экспериментировать уже с html-кэшем или необычным поведением разных клиентов… Главное тут понятный контроль эффекта от каждого шага своим глазом.

Если увлечётесь этим процессом однажды – мало что остановит!