CDN в распределённых системах: архитектура, кэширование, безопасность и современные практики

Оглавление

  1. Введение
  2. Архитектура CDN
  3. Алгоритмы и стратегии кеширования
  4. Безопасность CDN
  5. Интеграция CDN с edge computing и serverless
  6. Сравнение CDN-провайдеров
  7. Примеры кода
  8. Заключение

Введение

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

CDN представляет собой распределённую сеть серверов, расположенных в различных точках мира, задача которых — кешировать и доставлять контент пользователям максимально быстро, снижая нагрузку на центральные серверы (origin). Благодаря такой архитектуре контент обслуживается с минимальными задержками, а ресурсы приложения расходуются эффективнее. Однако роль CDN не ограничивается простым кешированием статических ресурсов — современные CDN-сети активно внедряют технологии безопасности, защищают приложения от DDoS-атак и выполняют вычисления на периферии сети (edge computing).

В этой статье мы подробно рассмотрим архитектуру CDN и её компоненты, алгоритмы кеширования, взаимодействие edge-серверов с origin-серверами, а также ключевые механизмы обеспечения безопасности. Будут детально проанализированы популярные CDN-провайдеры (Cloudflare, Amazon CloudFront и Bunny.net) с описанием их сильных и слабых сторон. Кроме того, вы увидите примеры реализации программного взаимодействия с CDN на Java и Go, а также диаграммы в нотациях C4 Container и sequence, наглядно демонстрирующие внутреннее устройство и работу CDN в контексте распределённых систем.

Архитектура CDN

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

Взаимодействие пользователя с CDN: как правило, все HTTP(S)-запросы клиентов перенаправляются на CDN, который выступает в роли reverse proxy перед origin-серверами. Для этого доменные имена настраиваются через DNS: например, A-запись указывает на IP-адрес CDN, либо CNAME-записи поддоменов указывают на адреса, предоставленные провайдером CDN. После такой настройки все запросы пользователей к вашему домену будут резолвиться через DNS на ближайший edge-сервер CDN – обычно это достигается с помощью глобального anycast-маршрутизации, при которой один IP-адрес объявлен сразу во многих узлах CDN и сетевые протоколы сами направляют пользователя к ближайшему из них. Альтернативно, некоторые CDN могут применять DNS-маршрутизацию (unicast): DNS-сервер CDN возвращает IP конкретного узла на основе местоположения DNS-резолвера пользователя. Однако такой подход менее точен, так как резолвер может быть далеко от клиента, и смена узлов зависит от времени жизни DNS-записи.

Edge-сервер CDN принимает запрос пользователя и проверяет, есть ли запрошенный ресурс в его локальном кеше. Если контент уже кеширован (и актуален), CDN мгновенно возвращает его пользователю, минуя origin (это называется cache hit). Если же на edge нет нужного ресурса или срок его жизни истёк (cache miss), CDN запрашивает контент у origin-сервера, получает свежие данные и отдает их пользователю, параллельно сохраняя копию в своем кеше на заданное время. Таким образом, origin-серверы обращаются только при необходимости – для динамического или ещё не кешированного контента – тогда как повторные запросы статических ресурсов обслуживаются с edge, существенно снижая нагрузку и трафик на origin. Это распределяет нагрузку по узлам CDN и повышает устойчивость системы.

Геораспределённые узлы (PoP): CDN имеет множество точек присутствия по всему миру (Points of Presence), размещённых в датацентрах ближе к крупным узлам интернет-обмена и пользователям. Например, CDN Cloudflare развернут более чем в hundreds of cities worldwide, обслуживая 95% мировых пользователей с задержкой менее 50 мс и обладая пропускной способностью сети свыше 388 Тбит/с. Другие провайдеры также имеют широкие сети: Amazon CloudFront объявляет около 450 узлов в ~90 городах, а более новый провайдер Bunny.net – 114 точек присутствия в 113 городах и 77 странах. Для ускорения маршрутизации трафика внутри своей сети некоторые CDN используют частные магистральные каналы и оптимизации маршрутов – например, Cloudflare Argo Smart Routing или собственную глобальную сеть Amazon для CloudFront – чтобы трафик от edge к origin следовал по самым быстрым и надёжным путям.

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


Рис. 1: Архитектура взаимодействия пользователя с CDN. Запросы пользователя направляются на ближайший Edge-сервер CDN через глобальную anycast-сеть. Edge-серверы кешируют контент, обеспечивают безопасность с помощью WAF, выполняют терминацию TLS-соединений и, опционально, осуществляют вычисления с помощью edge computing (например, Cloudflare Workers или Lambda@Edge). При отсутствии нужного ресурса в кеше запросы перенаправляются на origin-сервер, где находится оригинальный контент.

Алгоритмы и стратегии кеширования

Эффективное кеширование – ядро ценности CDN. Основные механизмы кеширования включают TTL (Time To Live) для управления временем жизни контента, стратегии валидирования устаревших копий, а также принудительную инвалидацию кеша (purge). Рассмотрим ключевые алгоритмы:

  • Время жизни (TTL): каждый объект в кеше имеет срок актуальности. TTL определяет, как долго копия хранится на edge без запроса к origin. Например, TTL = 3600 секунд означает, что CDN будет использовать кешированную копию в течение часа, прежде чем снова запросить ресурс у origin-сервера. Статические ресурсы (изображения, CSS, скрипты) обычно получают большой TTL (несколько дней или недель), тогда как динамичный контент (API-ответы, страницы) – более низкий TTL (секунды или минуты). Выбор TTL должен отражать частоту обновления контента: чем чаще меняется ресурс, тем короче TTL, чтобы пользователи своевременно получали обновления. Правильно настроенное время жизни существенно повышает кеш-эффективность и скорость доставки контента.
  • Валидирование и stale content: когда срок жизни истёк, CDN может либо сразу запросить новый вариант у origin, либо попытаться провалидировать кеш. Валидирование обычно выполняется через условные запросы с заголовками If-Modified-Since или ETag к origin. Если origin ответит, что ресурс не изменился (HTTP 304 Not Modified), CDN продлевает TTL и продолжает выдавать старую копию, избежав лишней передачи данных. Если же ресурс обновился, CDN получит новую версию и обновит кеш. Многие современные CDN поддерживают директивы кеширования вроде stale-while-revalidate, позволяющие обслуживать немного устаревший контент, пока в фоне идёт обновление из origin. Например, Cloudflare при истечении TTL может по одному из параллельных запросов сходить к origin за свежими данными, а остальные запросы временно получить старую копию с пометкой UPDATING, что реализует бесшовное обновление без нагрузочного всплеска. Благодаря этому пользователи не ждут, пока контент обновится, а origin-сервер не испытывает лавины запросов при одновременном истечении кеша. Аналогично, технология request collapsing объединяет одновременные кеш-промахи: CDN блокирует повторные запросы к одному и тому же ресурсу, пропуская к origin только один запрос, а затем раздает полученный ответ сразу всем ожидающим клиентам. Это предотвращает ситуации, когда множество пользователей одновременно пробивают кеш и перегружают origin.
  • Инвалидация кеша (Cache Purge): хотя TTL автоматически ограничивает срок жизни, бывает нужно срочно удалить или обновить кешированные данные – например, после загрузки нового выпуска статей или в случае багованного изображения. CDN-провайдеры предоставляют API и инструменты для принудительной очистки кеша. Инвалидация может быть выборочной (удалить конкретный файл или путь) или полной (очистить весь кеш дистрибутива). Например, в Amazon CloudFront можно выполнить команду CreateInvalidation для отдельных файлов – после этого при следующем запросе CloudFront снова заберёт свежую версию с origin. Cloudflare позволяет удалить по списку URL или тегам; запрос к API /purge_cache с указанием {"files": ["https://example.com/path/to/file"]} мгновенно очищает указанные объекты из всех датацентров CDN. Важно помнить, что полный purge используют осторожно (так как он сбросит кеш-хиты в ноль). Часто вместо тотальной очистки применяют версионирование файлов (например, изменяя имя файла или параметр версии в URL) – это заставляет CDN считать новый URL отдельным ресурсом и брать его с origin, не задевая старый кеш. Инвалидация же удобна для точечного обновления без изменения ссылок; у разных CDN могут быть ограничения на частоту purge, либо плата за большое число операций.
  • Другие стратегии: В дополнение к TTL и purge, продвинутые CDN предлагают многоуровневое кеширование. Например, Cloudflare имеет Tiered Cache, а CloudFront – Regional Edge Caches: промежуточные региональные узлы, которые хранят копии менее востребованного контента дольше и служат буфером между основными PoP и origin. Это означает, что при кеш-промахе на ближнем edge запрос может попасть не сразу на origin, а на вышестоящий кеш в регионе (Origin Shield), где вероятность найти контент выше, и если уж и там промах – только тогда пойдёт к origin. Такая иерархия ещё сильнее уменьшает нагрузку на исходные серверы. Также внедряются механизмы вроде Perma-Cache (у Bunny.net) – возможность предварительно загрузить и постоянно держать определённые файлы во всех нужных узлах, гарантируя 100% кеш-hit для них. Этот подход особенно полезен для тяжёлого контента (например, видео), который целесообразно один раз распространить по сети CDN заранее.

Ниже приведена UML-диаграмма последовательности, демонстрирующая обработку запроса CDN в различных ситуациях кеширования:

Рис. 2: Пользователь запрашивает ресурс через CDN. Если копия свежая – CDN сразу отвечает из кеша. Если копия устарела – CDN параллельно начинает валидировать её на origin (и может сразу дать клиенту устарелую копию, stale-while-revalidate), затем обновляет кеш. Если копии нет – CDN забирает ресурс у origin и кеширует его.

Рекомендации по кешированию: задавайте разумные TTL для разных типов данных (например, API-ответы – 30-60 сек, HTML страниц – 5 минут, статические файлы – дни или недели), используйте stale-while-revalidate и stale-if-error для бесперебойности, при обновлениях контента либо версионируйте файлы, либо вызывайте API purge точечно. Такие стратегии обеспечат высокий процент кеш-хитов, быструю доставку и устойчивость вашего приложения.

Безопасность CDN: TLS, DDoS-защита, WAF и аутентификация

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

  • TLS/SSL шифрование: CDN берёт на себя терминацию TLS – шифрованное соединение устанавливается между клиентом и edge-сервером CDN. Практически все провайдеры позволяют бесплатно выдавать сертификаты для вашего домена или использовать ваши собственные. Например, Cloudflare предлагает бесплатный Universal SSL для любых доменов. CDN поддерживают новейшие версии протоколов (TLS 1.3), оптимизируют повторное использование соединений и сокращают TLS handshake для последующих запросов за счёт расположения ближе к пользователям. Кроме того, сертификаты и ключи хранятся на CDN, разгружая вас от их управления. Между CDN и вашим origin тоже можно шифровать трафик; при этом допускается использовать внутренний сертификат (Cloudflare позволяет настроить Authenticated Origin Pull – origin принимает соединения только от CDN, проверяя его сертификат). Таким образом, CDN обеспечивает сквозное или частичное шифрование без снижения производительности, и пользователи всегда видят зеленый замок, даже если ваш origin не имел собственного публичного сертификата.
  • DDoS-Protection: Благодаря распределённой архитектуре и огромной совокупной пропускной способности, CDN способен поглощать крупномасштабные атаки типа распределённого отказа в обслуживании. Anycast-маршрутизация сама по себе способствует распылению трафика атаки по разным узлам сети, не давая перегрузить один точечный сервер. Например, если злоумышленник инициирует DDoS, тысячи edge-серверов по всему миру принимают на себя часть трафика и имеют шансы отбросить вредоносные пакеты локально. Провайдеры CDN инвестируют в избыточную емкость сети и фильтры: так, инфраструктура Cloudflare способна выдерживать сотни миллионов запросов в секунду и терabit-атаки. Все запросы проходят через “защищённую” сеть CDN перед тем, как попасть к origin, поэтому атаки на уровень инфраструктуры блокируются на границе сети Cloudflare, и клиенты CDN фактически укрыты за её «щитом». AWS CloudFront аналогично включается в AWS Shield (стандартная DDoS-защита) по умолчанию, а для расширенной защиты от сложных L7 атак можно использовать AWS Shield Advanced (отдельная услуга). CDN также скрывает реальные IP-адреса ваших серверов: внешне пользователям и злоумышленникам видны только IP узлов CDN. Это маскирует origin, предотвращая прямые атаки в обход CDN. (Важно после подключения CDN сменить или тщательно защитить старые IP, чтобы их не узнали из архивов DNS и т.п.).
  • Web Application Firewall (WAF): большинство CDN-сервисов имеют встроенные межсетевые экраны веб-приложений на уровне L7. WAF на edge инспектирует входящие HTTP-запросы и фильтрует вредоносный трафик до того, как он достигнет вашего приложения. Правила WAF нацелены на типичные атаки: SQL-инъекции, XSS, включение удалённых файлов, злоупотребления API и др.. Например, CDN может автоматически блокировать запросы, содержащие подозрительные параметры, известные сигнатуры эксплойтов или приходящие с IP-адресов ботнетов. Edge WAF особенно эффективен тем, что расположен близко к пользователям, отсеивая атаки на «окраине» и снижая нагрузку на центральные узлы. Он масштабируется вместе с CDN – правила применяются глобально, и вредоносный трафик может блокироваться в реальном времени по всей сети. Cloudflare включает WAF (с набором управляемых правил OWASP) начиная с платного Pro-плана, а на уровне Enterprise позволяет тонко настраивать правила и машинное обучение для обнаружения угроз. Amazon CloudFront интегрируется с AWS WAF, где вы можете подключать управляющие правила AWS или собственные. Bunny.net запустил в 2023 году Bunny Shield – комплекс защиты, включающий WAF: базовые правила предоставляются бесплатно, а расширенные функции (кастомные правила, бот-фильтры, капчи) – за дополнительную плату. Таким образом, CDN способен автоматически отбрасывать SQLi, XSS, злоумышленные боты и др., не пропуская их до origin. Результат – ваш основной сервер видит только чистый трафик от реальных пользователей.
  • Аутентификация и контроль доступа на edge: CDN предоставляет механизмы ограничить доступ к контенту на уровне edge-сервера, не раскрывая прямых ссылок на origin. Популярный подход – это подписанные URL или cookies: вы генерируете для пользователя временную ссылку с токеном (подписанную вашим ключом или ключом ключевой группы), и CDN проверяет подпись каждого запроса. Если URL истёк или подпись неверна, CDN сразу отклонит запрос (обычно с HTTP 403), не тревожа origin. Такой механизм реализован в AWS CloudFront (Signed URLs/Cookies): вы можете ограничить срок действия ссылки, IP-адрес клиента, диапазон доступного времени и т.д., а CloudFront на своих узлах будет валидировать каждое обращение по криптографической подписи. Cloudflare предлагает аналог – Token Authentication для HLS/ видео или Cloudflare Access для защиты внутренних ресурсов, где edge проверяет токены OAuth/JWT перед выдачей контента. Кроме того, CDN может выступать как авторизационный прокси: например, Cloudflare Workers позволяет реализовать проверку JWT токена или сеансовых cookie прямо на edge, прежде чем запрос пройдет дальше. В результате, даже приватный контент можно раздавать через глобальный кеш CDN, гарантируя, что его получат только авторизованные пользователи.

В совокупности, эти меры превращают CDN в щит безопасности вашего приложения на самом «переднем крае» сети. Они повышают защиту без увеличения задержек – напротив, безопасность реализуется распределённо и масштабируемо. Важный побочный плюс: используя CDN, вы автоматически изолируете ваш origin от прямого внешнего доступа. Атакам приходится иметь дело с мощной сетью CDN, и даже в случае успеха они затронут лишь кэш-копии, а не ваш origin напрямую.

Интеграция CDN с edge computing и serverless

Грань между сетями доставки контента и вычислительными платформами постепенно стирается. Современные CDN не ограничиваются кешированием статических файлов – они позволяют выполнять пользовательский код на своих edge-серверах, то есть прямо в точках присутствия, ближе к пользователям. Эта концепция называется edge computing (вычисления на окраине сети) и часто реализуется в виде функций по запросу (FaaS) или интеграции с serverless-архитектурами.

Яркие примеры – Cloudflare Workers и AWS Lambda@Edge:

  • Cloudflare Workers – платформа, запущенная Cloudflare в 2017 году, позволяющая запускать небольшие скрипты (на JavaScript, TypeScript, Python, C++ WASM и др.) на каждом edge-сервере Cloudflare по всему миру. Код выполняется в изолированной среде (V8 isolate) с очень низким временем старта (<5 мс) и может обрабатывать запросы на лету. Каждый Worker-развертывается глобально (более 200+ датацентров) – запрос пользователя в Чикаго выполнится на узле в Чикаго, запрос из Франкфурта – на узле во Франкфурте и т.д.. В отличие от традиционного Lambda, Workers не привязаны к конкретным регионам – код живёт во всех точках, обеспечивая минимальную возможную задержку. Cloudflare Workers хорошо подходит для задач: модификация HTTP-заголовков, A/B-тестирование, персонализация контента, канаречные релизы, простые API-эндпоинты, рендеринг HTML на edge и пр. Например, можно реализовать SSR (server-side rendering) SPA-приложения на edge, генерируя HTML ближе к пользователю, или агрегацию API-ответов от нескольких бэкендов прямо в точке, уменьшая число сетевых переходов. Cloudflare дополнил Workers такими сервисами, как Workers KV (ключ-значение хранилище с глобальной репликацией, для конфигураций или кэшей), Durable Objects (примитивы для хранения состояния с консистентностью) и R2 (распределённое объектное хранилище без затрат на egress). Всё это позволяет создавать безсерверные приложения, полностью работающие на edge-платформе CDN, без собственных серверов – от статического контента до бизнес-логики.

    Примечание: поддержка языков типа Python, C++ происходит через WASM (WebAssembly), а не нативно.
  • AWS Lambda@Edge – функция Lambda, привязанная к дистрибутиву CloudFront, запускаемая в ответ на события CDN (запрос/ответ) в ближайшем к пользователю AWS-регионе. Amazon Web Services расширила свою функцию Lambda (обычно исполняемую в одном выбранном регионе) до глобальной модели: когда CloudFront получает запрос, он может запустить вашу функцию в точке CloudFront, ближайшей к месту поступления запроса. Это позволяет, например, обрабатывать запросы европейских пользователей в Европе, азиатских – в Азии и т.д., снижая время до первого байта по сравнению с выполнением логики на удалённом центральном сервере. Lambda@Edge поддерживает Node.js и Python, имеет более длительное время запуска (сотни миллисекунд) и меньше ограничений по памяти/времени выполнения, чем Workers. Частые use-case: динамическая генерация контента на edge, переписывание URL перед запросом к origin (например, канонизация путей или A/B тестирование ресурсов), обработка куков для персонализации, аудио/видео трансмутация manifest-файлов для стриминга, встраивание авторизационных проверок и пр.. Также AWS недавно добавил CloudFront Functions – более легковесный вариант, выполняющийся на самом edge PoP (а не в региональном центре, как Lambda@Edge) с крайне малым временем запуска, но ограниченный по возможностям (подходит для простых задач вроде редиректов, проверки заголовков).

    Примечание: Lambda@Edge запускается не на каждом PoP, а в ближайшем региональном edge-узле AWS, что может повлиять на задержку

Интеграция CDN с serverless дает ряд преимуществ:

  • Снижение задержек для динамики: код выполняется ближе к пользователю, обходя долгий маршрут до центра данных. Как следствие, операции, которые ранее требовали запросов к origin (например, проверка токена с обращением к базе, рендер шаблона), могут выполняться на edge с миллисекундной задержкой. Исследования Cloudflare показали, что развёртывание логики на edge может существенно ускорить отклик по сравнению с центральным облаком – в тестах Workers против Lambda (регион Вирджиния) разница во времени ответа была заметна в пользу Workers именно за счёт геораспределения. Низкие задержки улучшают UX: каждые 100 ms важны (например, Walmart отмечал +2% конверсии на каждые ?1 с загрузки страницы).
  • Разгрузка и масштабирование origin: часть запросов никогда не достигает ваших серверов, если они обработаны на edge. Например, можно кешировать API ответы в Workers KV и выдавать их из CDN без обращения к базе данных. Или валидировать пользовательские JWT в Cloudflare Worker, возвращая ошибку немедленно, вместо проксирования неавторизованного запроса глубже. Это снижает потребность в мощности центрального бэкенда и упрощает масштабирование – CDN-платформа сама масштабирует запуск edge-функций под нагрузку (Cloudflare Workers автоматически масштабируются до миллионов запросов без холодных стартов). Вы платите либо фиксированно (Cloudflare Workers включены до 100k запросов/день бесплатно, далее по запросам), либо по факту ресурсов (Lambda@Edge – по длительности выполнения и используемой памяти). Таким образом, масштабирование приложения частично переложено на CDN.
  • Новые архитектурные возможности: сочетание CDN + serverless открывает возможности для безсерверных архитектур. Можно построить приложение, где фронтенд и статика раздаются через CDN, бизнес-логика (API) – выполняется на edge-функциях, а глобальное распределённое хранилище (например, Cloudflare R2 или Workers KV, либо AWS S3+DynamoDB глобально) хранит данные. Пользователи будут обслуживаться полностью из ближайших точек, а центральный origin может и вовсе отсутствовать либо выступать лишь как мастер-сервер для редких операций. Также edge-вычисления удобны для интеграции с IoT и мобильными клиентами, требующими минимальной задержки. В целом, CDN становится не просто кеширующим прокси, а дистрибьютед-платформой для вашего кода и контента.

Применяя edge computing, важно учитывать ограничения: безстейтовость функций, ограничения времени выполнения, eventual consistency распределённых KV-хранилищ. Но при правильном дизайне (идемпотентные функции, репликация настроек и данных) эти сервисы позволяют значительно повысить производительность и геомасштабируемость систем.

Сравнение CDN-провайдеров: Cloudflare, Amazon CloudFront, Bunny.net

Рассмотрим три популярных CDN-решения – Cloudflare, Amazon CloudFront и Bunny.net – и сравним их по ключевым параметрам: архитектура и сеть, производительность, безопасность, интеграции и стоимость.

Архитектура и сеть

  • Cloudflare: работает по модели SaaS CDN (облако для всех). Имеет единую глобальную anycast-сеть из датацентров в более чем 100 странах. Особенность Cloudflare – все сервисы (WAF, DNS, Workers и т.д.) работают на каждом сервере во всех точках, нет разделения по регионам. Это означает, что любой узел Cloudflare может полностью обслужить запрос: и отдать кеш, и выполнить скрипт, и применить правила безопасности. Количество точек присутствия – свыше 285 (на начало 2025 г.), что обеспечивает охват 95% интернет-пользователей с задержкой <50мс. Маршрутизация – anycast BGP: запросы приходят на единый адрес, объявленный везде, и автоматически попадают на ближайший узел. Внутри сети Cloudflare реализованы оптимизации (Argo Smart Routing – платный сервис ускорения пути до origin). Архитектура Cloudflare также включает Tiered Cache – иерархию кешей, где отдельные датацентры могут выступать региональными хабами для менее популярных ресурсов, уменьшая запросы к origin. Cloudflare – reverse-proxy CDN, то есть требует смены DNS на себя (вы указываете свои NS на Cloudflare). Origin может быть любым веб-сервером; Cloudflare сам подтягивает контент по запросам.
  • Amazon CloudFront: децентрализованный CDN от AWS, интегрированный с остальными сервисами Amazon. Имеет крупнейшее число edge-локций – примерно 450 узлов в 90 городах по всему миру. В архитектуре CloudFront прослеживается региональность: помимо edge-локаций, есть ~13 Regional Edge Caches – крупные узлы, расположенные между origin и edge, которые держат кэш долго для менее часто запрашиваемых объектов. Когда edge-приступен, он проверяет кеш, и при отсутствии/просрочке запрашивает не напрямую origin, а сперва региональный кеш (если объект там есть – получает быстрее, если нет – тогда идёт на origin). Это Origin Shield концепция, которая снижает нагрузку на origin (вплоть до одного запроса на объект при множестве одновременных запросов из разных частей мира). Сами edge-локации CloudFront привязаны к AWS-инфраструктуре: они подключены к магистральной сети AWS, а в ряде городов располагаются на узлах Amazon Outpost/внешних датацентрах (называются CloudFront Edge POPs и CloudFront Embedded POPs). Для маршрутизации CloudFront использует комбинацию DNS (через Route53) и anycast. CloudFront обычно разворачивается клиентами AWS: вы создаёте дистрибутив, указываете origin (например, S3 bucket или свой сервер), и получаете CloudFront domain xxxx.cloudfront.net для использования. Однако возможно и подключить свой домен через CNAME. CloudFront обладает гибкими настройками поведения (Cache Behaviors) – можно задать разные правила кеширования и доставки для различных путей (например, /static/* кешировать долго, /api/* не кешировать). В сумме, архитектура CloudFront тесно связана с AWS, обеспечивая быстрый доступ для ресурсов, хранящихся в AWS (есть оптимизация: трафик из S3 в CloudFront – бесплатный и внутриamazonский).
  • Bunny.net: относительно молодой независимый CDN-провайдер, делающий упор на простоту и экономичность. Сеть Bunny.net насчитывает 114 PoP (Edge-зон) на 6 континентах. По числу городов Bunny даже превышает CloudFront (113 городов против 90), что удивительно для более малого игрока. Архитектура Bunny CDN – классический пулл-CDN: вы настраиваете Pull Zone, указываете свой origin, и BunnyNodes по всему миру будут кешировать контент. Bunny использует географический DNS: пользователю выдается IP ближайшего региона. Узлы Bunny подключены к быстрым транзитным провайдерам и интернет-обменам, с целью минимизировать маршрут до пользователей. Интересная особенность – Bunny предоставляет два режима сети: Premium Tier (полный список из 100+ узлов) и Volume Tier (урезанная сеть ~10 узлов для клиентов с очень большими объёмами, кому важнее цена чем минимальный пинг). У Bunny.net есть своя фишка – Perma-Cache: это опциональный сервис, когда CDN заранее загружает ваш файл во все регионы и гарантирует, что кеш-хит будет 100% (хранит файл постоянно во вторичном хранилище на edge). Также Bunny реализовал запросное объединение (coalescing), схожее с Cloudflare: если несколько пользователей запрашивают один и тот же не-кешированный файл, Bunny пропустит только один запрос к origin, остальные подождут и получат готовый ответ. В целом архитектура Bunny.net более проста, без сложной многоуровневой иерархии, но благодаря относительно небольшому размеру сети кеш-инвалидации и обновления распространяются очень быстро (заявляется, что глобальный purge занимает считанные секунды). Bunny поддерживает и pull, и push (есть Bunny Storage – свой объектный стор, привязанный к CDN). Это дает интегрированное решение: можно хранить файлы на серверах Bunny и раздавать их сразу через CDN, минуя внешний origin.

Производительность и задержки

Все три CDN нацелены на ускорение доставки, но их реальные показатели могут различаться:

  • Cloudflare: благодаря огромному числу узлов и оптимизированной сети, Cloudflare обеспечивает одни из лучших показателей по задержкам. Тесты показывают низкое время до первого байта (TTFB) и быстрое TLS-соединение. Cloudflare активно участвует в независимых рейтингах, таких как CDNPerf, где традиционно входит в тройку лидеров по скорости в большинстве регионов. Особенное преимущество чувствуется в удалённых регионах: Cloudflare имеет узлы даже в Африке, на Ближнем Востоке, Латинской Америке, что сокращает пинг там, где у конкурентов меньше присутствие. Кроме того, технология Argo (платная) улучшает мягкую производительность – выбирает маршрут по глобальной сети Cloudflare с меньшей потерей пакетов и задержкой для кэш-промахов, что может ускорить загрузку на ~30% для дальних пользователей. Cloudflare также внедряет HTTP/3 (QUIC) повсеместно, что снижает время установления соединения. В общем, по средним измерениям, Cloudflare – один из самых быстрых CDN, сочетающий высокие кеш-хиты и малые задержки сети.
  • Amazon CloudFront: имеет большую распределённость, но исторически слегка уступал по скорости «бесплатным» сетям вроде Cloudflare и Fastly в тестах. Независимый анализ CDNPerf показывает, что CloudFront не всегда лидирует по латентности – частично из-за того, что у AWS меньше узлов в отдельных странах (AWS охватывает 48 стран против 70+ у Cloudflare). Также CloudFront обычно развертывается с конфигурациями, оптимизированными под экономию, а не максимальную скорость (например, по умолчанию может ждать заполнения TLS-Session, медленнее инвалидировать кеш). Тем не менее, CloudFront задействует мощную AWS-инфраструктуру, и при использовании источников в AWS (S3, EC2) он очень эффективен: высокая пропускная способность, параллельное соединение к нескольким origin для HLS сегментов, TLS-сессии оптимизированы. В 2023 AWS заявил о ~20% снижении средних глобальных задержек CloudFront за счёт добавления новых узлов. Особо стоит отметить стабильность и throughput – CloudFront способен выдавать огромные объёмы трафика без просадок (недаром его используют для крупных стриминговых сервисов). Для максимальной скорости AWS предлагает включить (платно) CloudFront RTMP или левереджить многоканальный мультиконнект, но это специфично. В реальных кейсах, CloudFront может показывать время отклика чуть выше, чем Cloudflare/Bunny, особенно на первый байт, но разница не критична для большинства приложений.
  • Bunny.net: несмотря на меньший размер компании, Bunny.net славится исключительно высокой скоростью. По данным CDNPerf на 2023 год, Bunny занимал 1-е место в мире по средней скорости отклика. Это во многом благодаря агрессивной оптимизации маршрутов и наличию узлов в неожиданных местах (например, Bunny первым из небольших CDN открыл узлы на Филиппинах, в ЮАР, в Новой Зеландии и др.). Bunny активно использует протокол HTTP/2 + TLS 1.3, поддерживает HTTP/3. Их ПО написано с упором на быстроту: когда проводились синтетические тесты 100k одноновременных соединений, Bunny держался очень стабильно. Некоторые независимые обзоры отмечают, что TTFB у Bunny может быть даже ниже, чем у Cloudflare, в ряде регионов (возможно, из-за меньшей нагрузки на узлы и отсутствия функционала, добавляющего небольшую задержку, как WAF или Workers). Таким образом, Bunny – отличный выбор для приложений, требующих минимальной задержки (игры, финансовые приложения), и он опережает CloudFront по latency в большинстве сценариев. Однако стоит учитывать, что на пиковых нагрузках у Bunny меньше запас прочности – гипотетически, если сайт резко начнёт раздавать десятки Tbps, Cloudflare или AWS с их инфраструктурой выдержат легче, чем Bunny с более ограниченными ресурсами.

В целом, все трое обеспечивают подачу контента быстрее, чем без CDN. Важный показатель – кеш-хит рейты (доля запросов обслуженных из кеша). У Cloudflare и Bunny, предоставляющих неограниченный кеш и различные механизмы (tiered cache, prefetch), кеш-хит легко может превышать 95% для статических сайтов. У CloudFront хит-рейт часто ~80-90%, но его можно повысить оптимизацией (включить Origin Shield, настроить правильные TTL и политика кеша). Чем выше процент хитов, тем меньше средняя задержка ответа, так как обращение к origin (с потенциально большим RTT) нужно редко.

Функции безопасности

  • Cloudflare: изначально позиционируется как SecOps-платформа на edge. Предлагает бесплатную защиту от DDoS для всех тарифов (несколько уровней фильтрации + любая атака автоматически гасится, даже на бесплатном плане). Включает WAF начиная с Pro (20$/мес) с набором правил OWASP и автообновлений, а на Business/Enterprise доступны продвинутые вещи: WAF с машинным обучением, бот-менеджмент (обнаружение и блокировка злонамеренных ботов), защита API (специфические правила и токены), Rate Limiting (ограничение частоты запросов с отдельных IP), CAPTCHA/JS Challenge механизмы. Также Cloudflare имеет модуль Access/Zero Trust – позволяющий осуществлять на edge аутентификацию пользователей через SSO для доступа к вашим веб-приложениям (по сути, VPN-замена). Все эти функции интегрированы: например, WAF-правило может задействовать гео-IP, ASN, Threat Score от Cloudflare. Cloudflare известна своей быстрой реакцией на угрозы (у них огромная видимость трафика по клиентам, и атаки отслеживаются глобально). В 2022 Cloudflare успешно смягчила рекордную HTTPS-DDoS атаку ~26 млн запросов/с, не уронив при этом ни один из обслуживаемых сайтов. В плане шифрования, Cloudflare поддерживает современные стандарты (TLS 1.3, DNSSEC, выгодно выделяется функция Encrypted Client Hello для приватности запросов). Между CDN и origin можно включить Full (strict) TLS, используя бесплатные origin-сертификаты Cloudflare. Для дополнительных гарантий Cloudflare предоставляет бортовой Firewall (L3/L4 ACL), Spectrum (проксирование не-HTTP трафика с DDoS защитой), Content Security (в т.ч. automatic HTTPS rewrite, Email obfuscation и другие мелкие фишки для безопасности контента). Мы можем сказать, что Cloudflare предлагает самое богатое портфолио edge-защиты “из коробки”.
  • Amazon CloudFront: с точки зрения безопасности тесно интегрирован с AWS Shield и AWS WAF. AWS Shield Standard автоматически защищает CloudFront дистрибутивы от распространённых L3/L4 DDoS без доп. оплаты. Для более продвинутой DDoS защиты (например, если нужны гарантированные отчеты, быстрая поддержка при атаке) компаниям предлагается AWS Shield Advanced (платный, по подписке), который включают крупные корпорации. AWS WAF – отдельный сервис, но его очень легко подключить к CloudFront: можно создать WebACL с правилами (например, Managed Rule Groups от AWS или партнеров, или свои custom rules) и навесить на нужный CloudFront дистрибутив. Эти правила будут выполняться на edge CloudFront. AWS WAF обладает богатой логикой (выражения, поддержка Regex, и пр.), но он не бесплатен – оплата идет за каждый миллион запросов, прошедших через WAF, и за правила. Чтобы снизить расходы и упростить, AWS в 2021 выпустил CloudFront Security Savings Bundle – комбинированный план, где клиент обязуется тратить некоторую сумму в месяц, получая скидку ~30% и фактически бесплатный WAF до 10% от этой суммы. Таким образом, за безопасность на CloudFront приходится платить больше, чем у Cloudflare (где базовая защита уже есть на бесплатном плане). Тем не менее, CloudFront обеспечивает все стандартные вещи: TLS (поддержка клиентских сертификатов, TLS1.3), возможность настроить политики шифров, подписанные URL/cookie для приватного контента (в AWS это гибко – можно задать и время жизни, и IP условия), Geo-blocking (блокировка по стране), встроенный Access Control – можно белый/чёрный список IP задать прямо в настройках дистрибутива. На стороне origin AWS предлагает Origin Access Identity для S3: private-бакет, доступный только через CloudFront (закрывает прямой доступ к файлам). Для пользовательских origin можно настроить проверку заголовка или client TLS certificate. В 2023 AWS добавил поддержки OAuth/OIDC прямо через CloudFront нет, этим занимается либо ваш origin, либо AWS Cognito+Lambda@Edge. Резюмируя: CloudFront обеспечивает высокий уровень защиты, но многие функции опциональны и стоят денег; зато они глубоко кастомизируются под нужды enterprise.
  • Bunny.net: первоначально Bunny CDN был минималистичным в плане безопасности (просто HTTPS и базовые IP ACL), но сейчас у них появился комплекс Bunny Shield. В него входит WAF – с базовыми правилами (OWASP топ-10) бесплатно и возможностью создания пользовательских правил (например, свой Regex на URI). Также Bunny Shield заявляет DDoS mitigation: они фильтруют распространённые атаки, используют rate limiting. Особо отмечается Bot Protection – Bunny обучал модели для выявления бот-трафика и может блокировать вредоносные скрипты в реальном времени. Плюс есть GeoIP-фильтрация (можно не пускать определённые страны). В отличие от Cloudflare, где на бесплатном плане нет WAF, у Bunny даже бесплатные пользователи получают базовый WAF. Для продвинутых функций (более тонкий бот-менеджмент, расширенные правила) скорее всего потребуется платный пакет Bunny Shield, но цены у Bunny традиционно невысокие. Bunny поддерживает SSL: можно приносить свой сертификат или использовать автоматический Let’s Encrypt для вашего адреса (если пользуетесь их BunnyDNS). Их TLS-стек современный, хотя нет некоторых очень новых фишек типа клиентской проверки сертификата для origin. Bunny также позволяет настроить заголовки безопасности (CSP, HSTS) прямо в панели. Подписанных URL у Bunny нет как отдельной функции, но их можно эмулировать через ключ в запросе и простое правило WAF (например, разрешить запрос только если параметр X равен определённому значению и не истёк). В общем, Bunny развивает безопасность, стремясь догнать «больших», и уже предоставляет достаточный уровень защиты для большинства сценариев, хотя пока без огромных облачных AI-систем как у Cloudflare.

Интеграция и дополнительные возможности

  • Cloudflare: эволюционировал в многофункциональную Edge Platform. Помимо CDN и перечисленных security-функций, предлагает: DNS (Cloudflare DNS – один из самых быстрых публичных DNS), Load Balancing на уровне DNS с проверкой состояния origin, Serverless платформу Workers (обсуждалось ранее), Storage (R2 object storage, KV хранилище, Durable Objects), Stream (для видеохостинга), Cloudflare Images (хостинг и преобразование изображений на лету), Cloudflare Pages (статический хостинг со сборкой, аналог Netlify). Все эти сервисы легко стыкуются между собой. Например, можно написать Worker, который при кеш-промахе ходит в R2-хранилище за данными, или Worker, выступающий OAuth-прокси перед Cloudflare Access. Интеграция с DevOps тоже на высоте: Cloudflare имеет REST API и графQL API почти для каждого действия – от добавления записи DNS до настройки правил firewall. Существуют официальные библиотеки (Go, Python, JS, etc.) и Terraform провайдер для Cloudflare. Таким образом, если компания строит архитектуру на Cloudflare, она может постепенно подключать все новые компоненты, сокращая зависимость от собственных датацентров или других облаков. Cloudflare также дружит со сторонними хранилищами: например, для больших медиа можно использовать бэкэнд Backblaze B2 – трафик между Cloudflare и B2 бесплатный по соглашению (BandWidth Alliance). Иными словами, Cloudflare – это целая экосистема на edge, удобная для DevOps: логирование (Cloudflare Logs или PubSub), анализ трафика (Cloudflare Analytics), и даже CASB и Zero Trust сетевые функции.
  • Amazon CloudFront: лучше всего интегрирован с облачной средой AWS. В связке с Amazon S3 CloudFront образует полноценную CDN-систему хранения и доставки: вы можете хостить весь статический контент на S3, пометить его как private, и раздавать через CloudFront, который избавит от расходов на исходящий трафик (для S3 -> CloudFront egress = $0). Также CloudFront связывается с AWS Media Services – например, с MediaPackage для потокового видео, с AppSync для GraphQL, с SQS/Lambda для кастомных обработок. Через Lambda@Edge CloudFront взаимодействует с другими AWS сервисами: можно при запросе данные из DynamoDB читать, или валидировать токен через Cognito – всё это внутри AWS, без выхода наружу. DevOps-интеграция: AWS SDK поддерживает управление CloudFront (создать дистрибутив, инвалидировать файлы и т.п.), Terraform и CloudFormation имеют соответствующие ресурсы. CloudFront тесно интегрирован с AWS Certificate Manager – можно бесплатно выпустить SSL-сертификат для вашего сайта и назначить его дистрибутиву. Логи CloudFront можно отправлять в S3 или Kinesis, метрики автоматически идут в CloudWatch. Это удобно, если у вас уже настроен мониторинг в AWS – CloudFront впишется в общую картину (алярмы, дашборды). Кроме того, CloudFront можно использовать в связке с Route 53 (DNS) для геораспределения между несколько CDN/providers или между origin (Route53 Latency Records). В области edge-вычислений, как отмечалось, CloudFront предоставляет Lambda@Edge и Functions, что интегрируется с AWS Lambda экосистемой. Таким образом, CloudFront – естественный выбор для тех, кто развернул основную инфраструктуру на AWS: он бесшовно встраивается, использует те же IAM-роли и политики безопасности, и его можно конфигурировать теми же инструментами, что и остальной AWS.
  • Bunny.net: концентрируется на том, чтобы быть простой в использовании CDN. В отличие от Cloudflare/AWS, у Bunny нет собственного общего облака для вычислений (по крайней мере, пока). Однако Bunny предлагает ряд полезных интегрированных фич: Bunny Optimizer – автоматическое сжатие изображений на лету и конверсия форматов (WebP/AVIF) с доставки через их CDN; Bunny Image Processing – API для изменения размеров изображений и кэширования результатов; Bunny Stream – платформа видео-хостинга с HTML5 плеером, DRM, предпросмотром, работающая на их CDN. Также Bunny.net имеет собственный DNS-хостинг и бесплатный публичный DNS resolver. Главная интеграция – Bunny Storage: объектное облачное хранилище, географически расположенное в регионах (Европа, Северная Америка, Азия, Океания), которое можно использовать как origin для CDN. Причём, трафик между Bunny Storage и Bunny CDN бесплатный (вы платите только фикс за хранение + за CDN доставку). Это похоже на S3+CloudFront, но от одного провайдера и обычно дешевле. Bunny Storage позволяет загружать файлы через FTP, API или веб-интерфейс, а CDN сразу их раздаёт. Для разработчиков Bunny предоставляет неплохой REST API: можно очищать кеш, создавать зонды, получать статистику. Библиотеки под популярные языки (напрямую их официальных SDK нет, но сообщество писало обёртки). Интеграция с CI/CD: нет чего-то вроде Workers, но можно к примеру после деплоя сайта дернуть Bunny API для purge нужных ресурсов. Bunny поддерживает отдачу логов через вебхуки или в Elasticsearch (недавно ввели Real-Time логирование). С внешними сервисами Bunny дружит например с Backblaze B2: если ваш origin – бакет B2, egress из B2 в Bunny CDN бесплатен (аналогично Cloudflare). Это делает связку B2 (дешевое хранилище) + Bunny (дешевый CDN) очень экономичным вариантом для статического контента или резервных хранилищ.

Ценовая политика

  • Cloudflare: выделяется тем, что предлагает бесплатный план для массового использования. Free-план включает неограниченный трафик через CDN (Cloudflare не взимает плату за ГБ на своих тарифах), базовые функции оптимизации и DDoS-защиту. Многие сайты среднего размера могут работать годами на Cloudflare Free, заплатив $0 – это одно из ключевых преимуществ Cloudflare на рынке. Платные планы Cloudflare идут по фиксированной ежемесячной плате: Pro – $20/месяц (добавляет WAF базовый, больше правил кеширования, HTTP/3, изображения Polish, etc.), Business – $200/месяц (приоритетная поддержка, встроенный конец TLS, больше настроек) и Enterprise – от ~$5000/год (индивидуальные условия, SLA 100% uptime, полноценный WAF, сеть Argo включена и т.д.). Cloudflare не считает трафик на этих планах, однако в соглашении указано, что если вы начнёте потреблять крайне необычно много (терабайты в сутки на Free), вас могут попросить перейти на Enterprise или ограничить скорость. На практике, Cloudflare обслуживает и очень крупные объёмы без доплаты (известны случаи, когда Cloudflare успешно отражал крупные атаки (сотни Гбит/с) даже на бесплатном плане, однако при таких нагрузках рекомендуется перейти на Pro или Enterprise). Дополнительные услуги Cloudflare – некоторые платны: Workers бесплатны до ~100k запросов/сутки, выше – ~$5 за 10 млн запросов; Argo – ~$0.10 за 1 млн запросов + $0.10 за ГБ маршрутизированного трафика; потоковое видео – отдельная тарификация за минуты видеопросмотров; Registrar (домены) – по себестоимости. Но большинство сайтов нуждается только в базовом CDN+WAF, и тут Cloudflare очень выгоден. Итого: Cloudflare привлекательна фиксированной низкой ценой для малого и среднего бизнеса. Для предприятий стоимость зависит от переговоров – крупные клиенты платят за Enterprise-план, куда могут быть включены и высокие лимиты, и Dedicated IP, и SOC2 и т.п. Известно, что цена Enterprise Cloudflare в пересчёте на ГБ для больших объёмов трафика может получаться копеечной (0.005$/ГБ и ниже), но требует обязательств и объёма. Для стартапов и индивидуальных разработчиков Cloudflare – фактически бесплатный CDN с премиум-функциями.
  • Amazon CloudFront: использует модель pay-as-you-go – оплата за фактический объём трафика и запросов. Цены у AWS CloudFront варьируются по регионам и объёмным тирам. Примерно: Северная Америка/Европа первые 10 ТБ в месяц – $0.085 за ГБ, далее цена постепенно падает до $0.02/ГБ на объёмах >5PB. В регионах Азии, Австралии дороже (до $0.12-0.20/ГБ). Отдельно считается количество HTTP/HTTPS запросов (например, $0.0075 за 10k запросов после первого миллиона, в NA/EU). В итоге, мелким сайтам CloudFront может выйти бесплатно за счёт AWS Free Tier (1 год 50 ГБ трафика и 2 млн запросов/мес включено), но дальше цена становится ощутимой. CloudFront предлагает варианты экономии: Savings Bundle (как упоминалось, commit на год, даёт ~30% скидки), также можно использовать AWS Data Transfer Pricing – трафик из S3, EC2 в том же регионе в CloudFront бесплатен, поэтому выгодно хранить данные в AWS чтобы не платить двойной egress. Тем не менее, сравнения показывают, что CloudFront дороже некоторых конкурентов: например, передача 5 ТБ через CloudFront из США/Европы обойдётся ~$425, в то время как те же 5 ТБ через Bunny – около $50. Это значительная разница. AWS оправдывает цену премиальными возможностями и интеграцией, но для чисто статического хостинга клиенты иногда выбирают более дешёвые CDN. Отметим, что AWS не взимает отдельную плату за кеширование или хранения контента на edge – все включено в цену трафика. Если у вас трафик всплесками, вы платите только за фактический объем, что честно. Для крупных клиентов AWS может предоставить Custom Pricing – индивидуальные скидки, если вы тратите на CloudFront много (сотни ТБ/мес). Но порог там высокий. В итоге: CloudFront идеален, когда вы уже на AWS (экономия на внутреннем трафике) или когда нужна его функциональность, и приемлем, если трафик небольшой. Но при больших объемах и ограниченном бюджете – может оказаться дороговат.
  • Bunny.net: придерживается очень прозрачного и низкого ценника на трафик. Оплата только за ГБ, без учета запросов (никаких платежей за количество файлов или SSL-сертификат). Стоимость зависит от выбранной зоны: Основная сеть (включает Сев. Америку, Европу, Азия, Океания) – от $0.01/ГБ (первые 500 ГБ) снижаясь до $0.005/ГБ на объемах >500 ТБ. Расширенная сеть (включает также Ю.Америку, Африка) – чуть дороже, например $0.03/ГБ. Можно гибко включать/выключать континенты в своей зоне, чтобы контролировать расходы. Кроме трафика, Bunny имеет фиксированную стоимость хранения если вы используете их Bunny Storage (от $0.01/ГБ/месяц в Европе/US). Но если хранение внешнее – платите только за выдачу. Важное преимущество Bunny: нет платы за purge и за запросы – вы можете очищать кеш сколько угодно, или иметь сайт с миллионами мелких запросов, счёт будет только за суммарно выданные гигабайты. Также все функции CDN включены без доплаты: и WAF базовый, и оптимизация изображений (в некоторых тарифах), и поддержка HTTP/3. Это контрастирует с AWS, где WAF, логирование стоят отдельно. Bunny.net предлагает простой калькулятор: скажем, 5 ТБ трафика в месяц по основным регионам = $50 (очень дёшево). По мере роста вашего проекта цена падает: на десятки ТБ – $0.01, на сотни ТБ – $0.005, на Петабайты – можно обсуждать спецусловия. Минимальная ежемесячная плата отсутствует – можно завести аккаунт, закинуть $10 и использовать его по мере надобности, остаток не сгорает. Для сравнения, Cloudflare на бесплатном плане дешевле бесконечно, но если вам нужен платный функционал Cloudflare (например WAF) – это минимум $20 в месяц вне зависимости от трафика. Bunny в аналогичной ситуации (WAF базовый) бесплатен, а расширенный WAF будет стоить несколько долларов (по их сайту, WAF Advanced +$0.006 за 10k запросов проходящих через WAF, но большинство небольших сайтов до этого порога не дойдут). В итоге, Bunny.net – один из самых доступных по цене CDN. Он привлекателен для стартапов и проектов, которым Cloudflare Enterprise не по карману, а AWS CloudFront кажется дорогим. С Bunny вы платите пропорционально росту и при очень больших объёмах трафика экономите десятки тысяч долларов по сравнению с CloudFront. Конечно, если трафик маленький, разница между $1 и $5 не важна – тут на первый план выходят функциональность и удобство. Но если вы видеохостинг с 1 Петабайт трафика, то Bunny ($5k) против CloudFront ($20-40k) – выбор очевиден.

Итоговое сравнение: Cloudflare – выбор для тех, кто ценит комплексность (CDN + безопасность + edge-платформа) и хочет получить много функционала сразу, причём малым проектам – практически даром. CloudFront – предпочтителен для клиентов AWS, где прирост экосистемных удобств перевешивает расходы, и для enterprise-случаев, где нужна глубокая кастомизация и гарантии AWS. Bunny.net – отличное решение для бюджетной быстрой доставки, когда нужны базовые возможности CDN/WAF и низкая цена за гигабайт. Во многих случаях гибридный подход тоже возможен: некоторые компании используют Cloudflare для сайтов и API, а Bunny для большого медиа-трафика, или CloudFront для защищённых внутренних приложений, а Cloudflare Free для маркетинговых сайтов и т.д. Выбор зависит от требований проекта и бюджета, но здоровая конкуренция на рынке CDN означает, что для каждой задачи можно найти оптимального провайдера.

Примеры кода: взаимодействие с API CDN (Java & Go)

Чтобы продемонстрировать работу с CDN программно, рассмотрим несколько сценариев – загрузка/инвалидция контента через API CDN. Ниже приведены фрагменты кода на Java и Go.

Пример 1: Инвалидация (purge) кэша CloudFront на Java

Amazon CloudFront предоставляет API для программного сброса кеша – это операция CreateInvalidation. В AWS SDK for Java (v2) это реализовано через клиент CloudFrontClient. В примере мы отправим запрос на инвалидцию двух объектов (путей) в дистрибутиве CloudFront:

import software.amazon.awssdk.services.cloudfront.CloudFrontClient;
import software.amazon.awssdk.services.cloudfront.model.*;

CloudFrontClient cloudFront = CloudFrontClient.create();

// Укажем пути, которые хотим инвалидировать
Paths invalidationPaths = Paths.builder()
        .items("/images/logo.png", "/css/*")   // можно указать конкретные файлы или маски
        .quantity(2)
        .build();

// Формируем запрос на инвалидцию с уникальным CallerReference
InvalidationBatch batch = InvalidationBatch.builder()
        .paths(invalidationPaths)
        .callerReference("ref-" + System.currentTimeMillis())
        .build();

CreateInvalidationRequest request = CreateInvalidationRequest.builder()
        .distributionId("E3MBCEXAMPLE")  // ID вашего CloudFront distribution
        .invalidationBatch(batch)
        .build();

// Отправляем запрос на создание инвалидции
CreateInvalidationResponse response = cloudFront.createInvalidation(request);
System.out.println("Invalidation created: " + response.invalidation().id());

Этот код использует AWS SDK to Java. Мы создаем список путей (Paths), включая, например, конкретный файл /images/logo.png и все файлы в каталоге /css/ (маска *). CallerReference – произвольная уникальная строка для идентификации запроса (AWS требует, чтобы повторный запрос с тем же CallerReference не дублировал действие). После вызова createInvalidation(...) CloudFront асинхронно пометит указанные объекты как устаревшие во всех своих edge-локциях. Обычно через ~1-2 минуты новые запросы начнут доходить до origin. Проверяя response.invalidation().status(), можно увидеть статус (InProgress или Completed). Для упрощения, AWS CLI тоже умеет делать инвалидцию, но показан код для иллюстрации интеграции в приложение.

Пример 2: Очистка кеша Cloudflare через API (Go)

Для Cloudflare очистка кеша доступна через REST API вызов к эндпоинту /zones/<ZONE_ID>/purge_cache. Будем использовать Go и стандартную библиотеку net/http для отправки запроса на удаление конкретных файлов из кеша Cloudflare:

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "net/http"
)

func main() {
    zoneID := "abcd1234efgh5678ijkl"  // Замените на ваш Cloudflare Zone ID
    apiToken := "CFAPITOKEN123456789" // API токен с правами Cache Purge

    // Формируем JSON тело запроса с списком файлов для purge
    purgeRequest := map[string][]string{
        "files": {
            "https://example.com/images/logo.png",
            "https://example.com/css/style.css",
        },
    }
    bodyData, _ := json.Marshal(purgeRequest)

    url := fmt.Sprintf("https://api.cloudflare.com/client/v4/zones/%s/purge_cache", zoneID)
    req, err := http.NewRequest("POST", url, bytes.NewReader(bodyData))
    if err != nil {
        panic(err)
    }
    // Добавляем заголовки авторизации и контента
    req.Header.Set("Authorization", "Bearer "+apiToken)
    req.Header.Set("Content-Type", "application/json")

    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()

    fmt.Println("Cloudflare API response status:", resp.Status)
}

Здесь мы отправляем POST-запрос к Cloudflare API. В теле запроса – JSON с ключом "files", перечисляющим полные URL ресурсов, которые хотим удалить из кеша. Cloudflare API ожидает именно такой формат. В заголовках аутентификации используем Bearer API Token – предпочтительный способ, более безопасный, чем глобальный ключ (токен можно ограничить конкретной зоной и операцией purge). При успешном выполнении Cloudflare вернёт статус 200 и тело с {"success": true}. Все edge-серверы по всему миру мгновенно удалят указанные объекты из кеша (Instant Purge – особенность Cloudflare, задержка обычно < 30 секунд). Следующие запросы пользователей за этими URL получат свежие версии с origin. Этот подход можно встроить, например, в CI/CD: после деплоя новой версии сайта вызвать подобный код, чтобы сбросить кеш важных файлов (или использовать более гранулярный purge по тегам, если вы помечали ресурсы тегами кеша при кеше).

Пример 3: Загрузка контента в Bunny CDN (Go)

Напоследок, пример интеграции с Bunny.net: загрузка файла напрямую в Bunny Storage через HTTP API, что сразу сделает файл доступным по CDN URL. Bunny Storage – объектное хранилище, в котором каждый файл доступен по адресу https://<Region>.storage.bunnycdn.com/<StorageZone>/<Path> и автоматически раздается через CDN. Для загрузки используется обычный HTTP PUT с указанием AccessKey (секретный ключ хранилища) в заголовке.

package main

import (
    "fmt"
    "io/ioutil"
    "net/http"
    "os"
)

func main() {
    storageZone := "my-storage"           // имя вашего Storage Zone
    apiKey := "your_storage_api_key_here" // секретный ключ Storage Zone
    region := "" // регион хранилища: "" для основной (пуcтой = автоматически основной регион), либо "ny" / "la" / "sg" / "syd" и т.д.

    localFilePath := "./images/newlogo.png"
    targetPath := "assets/newlogo.png" // путь в Storage (внутри Storage Zone)

    // Читаем локальный файл
    data, err := ioutil.ReadFile(localFilePath)
    if err != nil {
        panic(err)
    }
    // Формируем URL для загрузки: учитываем регион, если указан
    baseHost := "storage.bunnycdn.com"
    if region != "" {
        baseHost = region + "." + baseHost
    }
    url := fmt.Sprintf("https://%s/%s/%s", baseHost, storageZone, targetPath)

    // Создаем PUT запрос с бинарными данными файла
    req, err := http.NewRequest("PUT", url, bytes.NewReader(data))
    if err != nil {
        panic(err)
    }
    req.Header.Set("AccessKey", apiKey)
    req.Header.Set("Content-Type", "application/octet-stream")

    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()

    fmt.Printf("Upload status: %d\n", resp.StatusCode)
    if resp.StatusCode != 201 {
        body, _ := ioutil.ReadAll(resp.Body)
        fmt.Println("Error response:", string(body))
        os.Exit(1)
    }
    fmt.Println("File uploaded to Bunny Storage and CDN.")
}

В этом коде мы берем файл newlogo.png и загружаем его в Storage Zone с именем my-storage по пути assets/newlogo.png. Ключ AccessKey (выдается при создании Storage Zone) даёт право на запись. После выполнения запроса (ожидается статус 201 Created), файл будет сохранён в хранилище Bunny. Он сразу же доступен через CDN по URL: https://<ВашPullZone>.b-cdn.net/assets/newlogo.png (если у вас настроена привязка Pull Zone к Storage Zone), либо напрямую по URL хранилища. Обычно Pull Zone для Storage создается автоматически с таким же названием, или вы можете привязать свой кастомный домен к ней.

Преимущество этого подхода – вы можете автоматизировать загрузку контента: например, генерируете изображения или отчёты и через API размещаете их на edge-хранилище для мгновенной раздачи с CDN. Bunny Storage+CDN часто используют как более простую альтернативу S3+CloudFront за меньшую цену.

Заключение

CDN сегодня играет ключевую роль в построении распределённых систем – от элементарного кеширования статики до запуска кода на глобальных узлах. Понимание архитектуры CDN (взаимодействие edge и origin, маршрутизация трафика) позволяет эффективно внедрить сеть доставки в свою инфраструктуру. Применяя грамотные политики кеширования (TTL, revalidate, purge), можно достичь высокого быстродействия и снизить нагрузку на центральные сервисы. Инструменты безопасности CDN (TLS, WAF, DDoS-защита, ограничение доступа) усиливают общую защиту приложения, а интеграция с edge computing и serverless дает новые горизонты по размещению логики ближе к пользователям.

Сравнение популярных провайдеров показывает, что нет универсально «лучшего» CDN – каждый предлагает свой баланс возможностей и стоимости. Cloudflare привлекает всеобъемлющим набором функций и простотой подключения, CloudFront – глубокой интеграцией с AWS и гибкостью, Bunny.net – экономичностью и фокусом на скорости. Выбор зависит от конкретных требований вашего проекта, географии аудитории и бюджета.

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

Loading