Вы открываете интернет-магазин, основной сервер которого находится в Сингапуре. По идее, каждая фотография должна проделать долгий путь до вашего компьютера. Но картинки могут приехать с сервера в Москве, а оформление страницы вообще загрузиться из памяти браузера. Противоречия нет. Современный сайт часто собирается из ответов нескольких систем, и адрес в строке браузера не раскрывает географию каждой загрузки.
За доставку файлов поближе к посетителю отвечает CDN, или сеть доставки контента. Серверы в разных точках сети сохраняют копии подходящих материалов и выдают посетителям без постоянного обращения к основному серверу. Поэтому удалённый сайт может открываться быстро, а наплыв читателей не обязательно перегружает хостинг. Я бы объяснил главный принцип так. Вместо многократной перевозки одинакового файла через полмира CDN позволяет получать копию рядом. Однако корзину покупателя, оплату и работу базы данных одним копированием не ускорить.
Как запрос попадает на сервер рядом с вами
Для начала достаточно разобраться в четырёх терминах. Origin означает сервер-источник, откуда CDN получает оригинальный ответ. Источником может быть обычный веб-сервер, группа серверов приложения или объектное хранилище с фотографиями. Edge называют пограничный сервер, который принимает запросы посетителей на краю инфраструктуры CDN. PoP, или точка присутствия, обозначает площадку с оборудованием сети. На одной площадке может работать множество пограничных серверов. Наконец, кеш хранит ответы, которые разрешено использовать повторно.
Владелец сайта заранее подключает CDN и настраивает домены. Например, основной сайт остаётся на shop.example, а фотографии загружаются с static.shop.example, связанного с сетью доставки. Другой вариант предполагает, что CDN принимает запросы ко всему сайту и передаёт источнику лишь те, на которые не может ответить самостоятельно. Пользователю не требуется устанавливать приложение или выбирать сервер вручную.
Служба DNS, которая помогает получить IP-адрес по имени сайта, и сетевая маршрутизация направляют соединение к подходящему узлу. Некоторые сети используют Anycast, при котором один IP-адрес объявляют из нескольких мест. Маршрутизаторы выбирают путь согласно сетевым правилам. Поэтому «ближайший сервер» не обязательно стоит ближе по карте. На выбор влияют связи между операторами, доступность площадок, задержка и архитектура конкретной CDN.
Сценарий с Москвой и Сингапуром вполне возможен, если выбранная CDN располагает доступной московской площадкой и направляет туда посетителя. Но обещать московский сервер каждому жителю Москвы нельзя. Запрос может попасть в другой город или страну, если маршрутизация и состояние сети сложились иначе.
| Что произошло | Как проходит запрос | Что получает посетитель |
|---|---|---|
| Подходящая копия есть | Браузер → пограничный сервер CDN | Готовый ответ из кеша без обращения к источнику |
| Копии нет | Браузер → пограничный сервер → источник, иногда через дополнительный кеш CDN | Ответ источника, который CDN может сохранить |
| Ответ нельзя кешировать | Браузер → пограничный сервер → приложение | Ответ, подготовленный для конкретного запроса |
Пограничный сервер уже входит в CDN, поэтому рисовать сеть отдельным обязательным звеном после edge не совсем точно. Внутри действительно могут работать дополнительные уровни кеша. Например, несколько площадок получают редкий файл из общего регионального хранилища копий, а не запрашивают оригинал каждая отдельно. Но такая многоступенчатая схема зависит от провайдера.
Увидеть следы CDN можно прямо в браузере. Откройте инструменты разработчика клавишей F12, выберите вкладку «Сеть» или Network и перезагрузите страницу. Нажмите на запрос фотографии или файла JavaScript, затем посмотрите адрес запроса и заголовки ответа. Иногда домен сразу указывает на отдельную инфраструктуру доставки. Но CDN может работать и за обычным доменом сайта.
У Cloudflare заголовок CF-Cache-Status помогает различать ответы кеша. Значение HIT означает, что файл нашли в кеше, MISS сообщает о промахе, а DYNAMIC указывает, что ресурс не считался подходящим для кеширования. Другие провайдеры могут показывать X-Cache или Cache-Status. Отсутствие подобных заголовков не доказывает отсутствие CDN, а наличие Age само по себе не определяет поставщика услуги.
Для проверки конкретного общедоступного файла можно выполнить команду ниже, заменив пример своим адресом. В Windows вызывайте curl.exe, в Linux и macOS обычно достаточно curl. Команда выполнит обычный GET-запрос, покажет заголовки и отбросит содержимое файла.
curl.exe -sS -D - -o NUL https://static.example.com/image.webpВ Linux и macOS аналогичная команда выглядит так.
curl -sS -D - -o /dev/null https://static.example.com/image.webpПовторный запрос иногда меняет MISS на HIT, но такой результат не гарантирован. Файл могут не кешировать, а запросы могут обслужить разные узлы. Проверка одного изображения также ничего не говорит о кешировании личного кабинета. Примеры предназначены для законной диагностики общедоступных ресурсов и собственных сайтов. Соблюдайте законодательство своей страны, в том числе России, и правила сервисов, не применяйте материал для несанкционированного доступа, слежки или незаконного обхода ограничений.
Почему копия ускоряет сайт, но не заменяет приложение
У скорости загрузки есть два разных ограничения. Первое связано с пропускной способностью, то есть количеством данных, которое соединение передаёт за секунду. Второе связано с задержкой, временем ожидания ответа. Гигабитный домашний тариф не отменяет расстояние до другого континента. Перед загрузкой браузеру приходится устанавливать соединения и получать ответы, а некоторые запросы возникают только после обработки предыдущих.
CDN сокращает путь до сохранённого контента и снижает число обращений к источнику. Дополнительно провайдер может сжимать ответы, оптимизировать изображения и повторно использовать соединения с основным сервером. Но десятимегабайтная фотография остаётся тяжёлой, а перегруженный JavaScript продолжит тормозить на слабом телефоне даже после мгновенной доставки. Я всегда разделяю скорость передачи файлов и скорость работы самой страницы. CDN в первую очередь помогает с передачей.
Особенно хорошо копируются одинаковые для множества посетителей материалы. Фотографии товаров, таблицы стилей, шрифты, установщики программ и видеофрагменты не нужно создавать заново для каждого человека. Публичную HTML-страницу тоже можно кешировать, если правила сайта позволяют отдавать одинаковую версию разным читателям. Поэтому утверждение «CDN хранит только картинки» давно слишком узкое.
С видео масштаб виден лучше всего. Когда тысячи зрителей смотрят один фильм, раздача каждого потока из единственного дата-центра создаёт огромный исходящий трафик. Netflix использует собственную сеть Open Connect и размещает серверы доставки в том числе внутри сетей интернет-провайдеров. Так видеоданные оказываются ближе к зрителю, а нагрузка на внешние каналы уменьшается. При этом сервер с видеофрагментами не обязан обслуживать регистрацию, подписку и рекомендации.
У магазина похожее разделение. Фотографию чайника можно показать десяти тысячам покупателей из кеша. Но содержимое корзины, персональную скидку и результат оплаты приложение должно определить для конкретного клиента. CDN способна передать такие запросы, отфильтровать часть вредоносного трафика и иногда улучшить сетевой маршрут. Исправлять медленный запрос к базе данных вместо разработчика сеть доставки не будет.
При всплеске посещаемости решает доля запросов, которые CDN обслуживает самостоятельно. Если условные 95% запросов к картинкам попадают в кеш, до источника дойдёт примерно 5% запросов этой категории. Но переносить такую экономию на весь сайт нельзя. Посетители могут активно искать товары и оформлять заказы, а эти операции продолжат нагружать приложение.
Есть и проблема пустого, или «холодного», кеша. После публикации нового файла его ещё нет на площадках. Современные CDN могут объединять одновременные запросы к одному объекту и использовать промежуточный кеш, сокращая число загрузок с источника. Однако сама покупка услуги не гарантирует, что новый релиз или рекламная кампания пройдут без перегрузки. Нужно знать поведение конкретной конфигурации.
Что кеш запоминает и почему иногда показывает старое
CDN не должна угадывать, какие ответы разрешено хранить. Сервер сообщает правила через HTTP-заголовки, а владелец сайта дополняет их настройками провайдера. В Cache-Control директива max-age задаёт срок свежести ответа, а s-maxage позволяет отдельно указать срок для общих кешей, которыми пользуются разные посетители. Подробная семантика директив полезна, когда требуется разобраться, почему браузер и CDN обновляют файл в разное время.
Свежесть не равна гарантированному сроку хранения. Даже если копию разрешено использовать час, узел может удалить непопулярный объект раньше ради освобождения места. После истечения срока кеш иногда проверяет у источника, изменился ли файл, и продолжает использовать прежнюю копию после подтверждения. Поэтому схема «каждый час все файлы обязательно скачиваются заново» тоже неверна.
Отсюда знакомая ситуация. Редактор заменил картинку, а часть читателей продолжает видеть прежнюю. Очистка кеша браузера не обязательно поможет, потому что старая копия может лежать у CDN. Для обновления владелец выполняет инвалидацию, то есть делает сохранённую версию недействительной, либо публикует файл под новым именем. Например, после изменения app.a1b2.js сайт начинает ссылаться на app.c3d4.js. Версии получают разные адреса и не спорят за одну запись кеша.
Гораздо опаснее случайно сохранить общий ответ с персональными данными. Если принудительно кешировать весь HTML и не учитывать авторизацию, чужой личный кабинет может попасть в общий кеш. Директива private запрещает хранить ответ в общем кеше, но допускает кеш браузера. Директива no-store запрещает сохранение ответа кешами. А no-cache, несмотря на название, допускает хранение, но требует проверки перед повторным использованием.
Риск зависит и от ключа кеша, набора признаков, по которым CDN различает ответы. Если страница меняется в зависимости от языка, параметров адреса или cookie, правила должны учитывать нужные различия либо исключать такой ответ из общего кеширования. Я бы никогда не включал «кешировать всё» на магазине без проверки корзины, входа, выхода и персональных страниц. Выигрыш в скорости не оправдывает смешивание чужих данных.
CDN также не равна резервной копии сайта. При аварии источника уже сохранённые изображения могут продолжать открываться. Некоторые конфигурации разрешают временно выдавать даже устаревшие ответы при ошибке источника. Но отсутствующий в кеше документ получить будет неоткуда, а оформление заказа без работающего приложения не восстановится. Для аварий нужны отдельные резервные копии и план восстановления.
Как CDN защищает сайт и сама становится причиной сбоя
При DDoS-атаке злоумышленник пытается исчерпать доступные ресурсы множеством запросов или большим объёмом трафика. Распределённая сеть принимает нагрузку на разных площадках, а кеш избавляет источник от части повторных обращений. Если провайдер добавляет фильтрацию атак, ограничение частоты запросов и межсетевой экран веб-приложений, вредоносный поток можно отсекать до основного сервера.
Однако CDN и полноценная защита от DDoS не синонимы. Возможности зависят от продукта, тарифа и типа атаки. Поток запросов к дорогому поиску или другому некешируемому обработчику способен нагрузить приложение даже при отлично работающей доставке картинок. Причины, по которым сервисы зависают, вообще редко сводятся к одному лишь объёму канала.
Здесь становится понятным, зачем скрывают реальный IP-адрес источника. Если сайт принимает трафик через защищённую CDN, но основной сервер доступен напрямую, атакующий может направить нагрузку сразу на источник. Публичный DNS в такой схеме обычно показывает адреса CDN. Но неизвестность адреса сама по себе не защита. На стороне источника ограничивают допустимые подключения и проверяют, что запрос пришёл от доверенной инфраструктуры.
Cloudflare часто воспринимают просто как экран с проверкой браузера, хотя компания предлагает CDN, DNS, защитные функции и другие сервисы. Проверка появляется из-за настроек защиты, а не из-за самого принципа кеширования. При обычном HTTPS-проксировании соединение браузера заканчивается на узле CDN, а дальше провайдер устанавливает отдельное соединение с источником. Поэтому CDN становится участником обработки трафика, которому владелец сайта доверяет содержимое запросов. Шифрование и проверку сертификата на участке до источника тоже нужно настроить корректно.
Распределённая инфраструктура хорошо переживает поломку отдельной машины, но множество площадок может зависеть от общего программного обеспечения и настроек. Ошибка, разошедшаяся по сети, заденет клиентов одновременно. Так, 8 июня 2021 года Fastly пережила массовый сбой из-за программной ошибки, которую активировало допустимое изменение клиентской конфигурации.
Поэтому выражение «сломалась половина интернета» описывает впечатление пользователя, а не точную долю сети. Тысячи независимых сайтов могут пользоваться одним поставщиком доставки. При этом достаточно отказа CDN с общим JavaScript, чтобы страницы перестали нормально работать, хотя серверы владельцев доступны. Несколько CDN способны уменьшить зависимость от одного поставщика, но только при заранее настроенном и проверенном переключении. Запасной договор сам по себе трафик не перенаправит.
Что меняется для сайтов и посетителей в России
Глобальное покрытие не гарантирует одинаковую доступность из каждой страны. На результат влияют связи операторов, ограничения доступа, состояние международных маршрутов и правила самих поставщиков. Cloudflare сообщала о проблемах доступа из российских сетей, начавшихся в июне 2025 года. Такой случай показывает, почему быстрая загрузка за рубежом ничего не доказывает о работе сайта у российских посетителей. Конкретную доступность нужно проверять из сетей аудитории, а не переносить старую картину на всех операторов.
На международном рынке работают Cloudflare, Akamai, Fastly и Amazon CloudFront. В России услуги доставки контента предлагают, в частности, CDNvideo, NGENIX, Selectel и Yandex Cloud CDN. Перечень не означает, что набор функций одинаков. Один продукт прежде всего раздаёт статические файлы, другой отдельно предлагает защиту веб-приложений, третий делает акцент на видео. Даже у одного поставщика CDN и защита сайта могут подключаться как разные услуги.
Для российского проекта я бы смотрел на доступность у нужных операторов, задержку в регионах аудитории, работу поддержки и возможность быстро обновлять кеш. Дальше проверял бы стоимость исходящего трафика, запросов и дополнительных функций. Число точек на мировой карте менее полезно, чем измерения из городов, где живут читатели и покупатели. При работе с персональными данными отдельно оценивают, какие сведения получает поставщик и соответствуют ли обработка и размещение применимым требованиям.
Обычному посетителю знание CDN помогает точнее понимать поломки. Если текст появился, а картинки и кнопки нет, возможно, недоступен отдельный домен доставки. Если после исправления страницы сохраняется старая версия, причина может находиться за пределами браузера. Такие симптомы помогают сузить поиск, но не доказывают конкретную неисправность без проверки запросов.
Мой вывод простой. CDN приближает повторно используемые данные к читателю и разгружает источник, но не переносит автоматически весь сайт вместе с бизнес-логикой. Владельцу стоит начать с публичных файлов, проверить реальные попадания в кеш и отдельно убедиться, что персональные ответы туда не попадают. Затем оценить доступность из сетей аудитории и подготовить действия на случай отказа провайдера. Быстрая копия полезна ровно до той границы, за которой посетителю требуется свежий ответ работающего приложения.
