← Справочные архитектуры / reference-architecture / architectures

Эталонная архитектура сети доставки контента (CDN)

Каждый день пользователи интернета пользуются преимуществами производительности и надёжности, которые обеспечивает сети доставки контента ↗ (CDN). CDN стали обязательным элементом для борьбы с задержками и требованием для любой крупной компании, доставляющей контент пользователям в интернете. Обеспечивая производительность и надёжность для клиентов, CDN также позволяют компаниям дополнительно защищать свои приложения и снижать расходы. В этом документе рассматриваются типичные проблемы, с которыми сталкиваются клиенты при работе с веб-приложениями, то, как CDN Cloudflare решает эти проблемы, а также архитектура и устройство CDN.

Эта эталонная архитектура предназначена для ИТ- и сетевых специалистов, которые отвечают за существующую инфраструктуру организации или знакомы с ней. Полезно иметь опыт работы с технологиями и понятиями, важными для доставки контента: кэшированием, DNS и межсетевыми экранами.

Чтобы лучше разобраться в Cloudflare, рекомендуем следующие материалы:

• Что такое Cloudflare? | Сайт ↗ (5 минут на чтение) или видео ↗ (2 минуты)

• Что такое CDN? | Сайт ↗ (5 минут на чтение)
• Отчёт аналитика: Cloudflare названа лидером в отчете 2024 GigaOm Radar for Content Delivery Networks ↗ (20 минут на чтение)

Прочитав эту эталонную архитектуру, вы узнаете:

• Как Cloudflare CDN значительно улучшает доставку контента вашим клиентам
• Почему маршрутизация anycast IP важна для надежной работы CDN
• Диапазон вариантов многоуровневого кеширования и как выбрать подходящий для ваших задач

За последние несколько лет, особенно с началом пандемии COVID-19 и переходом на удалённую работу, объём интернет-трафика значительно вырос, что ещё больше усилило потребность в эффективном управлении сетевым трафиком, снижении задержек и повышении производительности.

Компании, которые размещают приложения в облаке или локально (on-premise), сталкиваются со следующими задачами:

1. Внедрение решений для повышения производительности
2. По мере роста спроса масштабирование архитектуры вширь для решения задач доступности и избыточности
3. Защита своей инфраструктуры и приложений от растущих интернет-угроз
4. Сдерживание растущих затрат, связанных со всем вышеперечисленным

Поскольку компании обслуживают клиентов по всему миру, решение перечисленных выше задач требует серьезных усилий. Традиционно сайт или приложение размещают централизованно и реплицируют в другой регион для обеспечения доступности, либо разворачивают на нескольких серверах, иногда в разных дата-центрах, для повышения отказоустойчивости.

Серверы, на которых размещены веб-сайты, называются исходными серверами. При обращении к веб-сайту клиенты отправляют серверу запросы на получение ресурсов. Переход на один веб-сайт может создать сотни запросов от браузера на HTML, CSS, изображения, видео и так далее. В версиях HTTP до HTTP/2 каждый такой запрос HTTP также требовал нового соединения TCP.

Улучшения в HTTP/2 и HTTP/3 позволяют мультиплексировать несколько запросов к одному серверу через одно TCP-соединение, что экономит серверные ресурсы. Тем не менее вычислительные и сетевые ресурсы по-прежнему расходуются, пока серверы отвечают на эти запросы. По мере роста числа клиентов, обращающихся к сайту, может произойти следующее:

• Исходный сервер начинает испытывать перегрузку от запросов, что влияет на доступность; компании начинают рассматривать горизонтальное масштабирование для обработки дополнительной нагрузки
• Поскольку каждый запрос должен дойти до исходного сервера, задержка снижает производительность и ухудшает пользовательский опыт
• Задержка для конечных пользователей становится пропорциональной расстоянию между клиентом и исходным сервером, поэтому качество работы зависит от местоположения клиента. Это особенно заметно для отдельных стран, где трафик в страну или из неё может вызывать повышенную задержку, например в Китае.
• По мере того как исходные серверы отвечают на растущее число запросов, резко возрастают затраты на пропускную способность, исходящий трафик и вычислительные ресурсы
• Даже когда клиенты масштабируются для обработки возросшего трафика, они остаются уязвимы как для распределенных атак типа "отказ в обслуживании" (DDoS) на уровне инфраструктуры, так и на уровне приложений

На рисунке 1 ниже CDN отсутствует, а сервер источника расположен в США. Когда клиенты обращаются к сайту, первым шагом становится DNS-резолвинг, который обычно выполняет интернет-провайдер пользователя. Следующий шаг: HTTP-запрос отправляется напрямую на сервер источника. Опыт пользователя будет различаться в зависимости от его местоположения. Например, для пользователей в США, где расположен сервер источника, задержка заметно ниже. Для пользователей за пределами США задержка растёт, что приводит к увеличению времени кругового обхода (RTT).

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

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

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

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

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

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

• Повышенная доступность и избыточность контента: Поскольку не каждый запрос клиента нужно отправлять на исходный сервер, CDN обеспечивает не только прирост производительности, но и повышенную доступность и отказоустойчивость. Запросы распределяются между локальными серверами с кешированным контентом; эти серверы отвечают на локальные запросы, значительно снижая общую нагрузку на исходный сервер. К исходному серверу обращаются только при необходимости (когда контент не закеширован или для динамического некешируемого контента).

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

• Снижение затрат на пропускную способность: Поскольку CDN отвечает на запросы с помощью кешированного контента, количество запросов к исходному серверу снижается, что также сокращает связанные расходы на трафик.

Важное различие между некоторыми реализациями CDN заключается в том, как они маршрутизируют трафик к соответствующим локальным узлам CDN. Маршрутизация запросов к узлам CDN может выполняться двумя способами:

Юникаст-маршрутизация DNS

В этом методе рекурсивные DNS запросы перенаправляют запросы на узлы CDN: DNS резолвер клиента пересылает запросы на авторитетный неймсервер CDN. CDN на основе DNS unicast маршрутизации не идеальны, поскольку клиенты могут быть географически удалены от своего DNS резолвера. Выбор ближайшего узла CDN основывается на DNS сервере клиента, а не на его IP адресе. Кроме того, любые изменения в DNS ответе зависят от истечения времени жизни записи (TTL).

Поскольку DNS-маршрутизация использует unicast-адреса, трафик направляется непосредственно на конкретный узел, что может создавать проблемы при резких всплесках трафика, например при DDoS-атаке.

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

Anycast-маршрутизация

CDN Cloudflare, о которой подробнее рассказано в следующем разделе, использует anycast-маршрутизацию. Anycast позволяет нескольким узлам сети иметь один и тот же IP-адрес. Один и тот же IP-адрес анонсируется с нескольких узлов в разных местах, а перенаправление клиентов обеспечивается протоколом маршрутизации интернета, BGP.

Использование CDN на базе anycast дает несколько преимуществ:

• Входящий трафик направляется в ближайший дата-центр, обладающий достаточной мощностью для эффективной обработки запросов.
• Доступность и отказоустойчивость обеспечиваются по умолчанию. Поскольку несколько узлов используют один и тот же IP адрес, при отказе одного из них запросы просто перенаправляются на ближайший узел.
• Поскольку anycast распределяет трафик по нескольким дата центрам, это увеличивает общую площадь покрытия, не позволяя ни одному из узлов оказаться перегруженным запросами. Поэтому сети anycast очень устойчивы к DDoS атакам.

Cloudflare предоставляет CDN по модели Software as a Service (SaaS). Благодаря такой модели клиенты пользуются CDN Cloudflare, не занимаясь управлением и обслуживанием какой-либо инфраструктуры или ПО.

Преимущества Cloudflare CDN сводятся к двум пунктам, которые подробнее рассматриваются в этом разделе.

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

Рисунок 2 показывает упрощённую схему CDN Cloudflare. Клиенты получают ответ от сервера в глобальной anycast-сети Cloudflare, ближайшего к их местоположению, что резко снижает задержку и RTT. Схема демонстрирует стабильный пользовательский опыт независимо от физического расположения клиентов и origin-сервера.

Рисунок 3 показывает CDN Cloudflare в глобальной anycast-сети. Помимо использования anycast для повышения производительности сети и отказоустойчивости, CDN Cloudflare применяет Tiered Cache, чтобы обеспечивать оптимальные результаты и снижать затраты для клиентов. Клиенты также могут включите Argo Smart Routing чтобы находить самый быстрый сетевой маршрут для запросов к серверу-источнику. Эти возможности подробно рассматриваются в остальной части документа.

На диаграмме выше стоит обратить внимание на несколько важных моментов, касающихся CDN Cloudflare и глобальной anycast сети, на которой она работает:

• Важное отличие Cloudflare в том, что компания использует единую глобальную сеть и запускает каждый сервис на каждом сервере в каждом дата-центре Cloudflare, тем самым обеспечивая конечным пользователям максимальную близость к сервисам Cloudflare с наивысшим масштабом, отказоустойчивостью и производительностью.
• Cloudflare работает как обратный прокси: он принимает запросы от клиентов и перенаправляет их к исходным серверам клиента. Таким образом, каждый запрос проходит через сеть Cloudflare, прежде чем попасть в сеть клиента. Поскольку Cloudflare укрепила и защитила свою инфраструктуру на границе сети (при входе трафика), все клиенты автоматически получают защиту от DDoS-атак на уровне инфраструктуры и объемных атак. Запросы и трафик обязательно проходят через защищенную сеть Cloudflare, прежде чем достичь исходного сервера клиента.
• CDN Cloudflare использует глобальную anycast-сеть Cloudflare. Благодаря этому входящий запрос направляется к ближайшему к пользователю узлу и обрабатывается им.
• Технология anycast обеспечивает такие преимущества, как снижение задержки, устойчивость сети, более высокую доступность и повышенную безопасность за счет большей площади поглощения как легитимной нагрузки, так и DDoS атак. Глобальная сеть anycast Cloudflare охватывает сотни городов по всему миру ↗, охватывая 95% населения мира, подключённого к интернету, в пределах 50 миллисекунд, при этом обеспечивая пропускную способность сети свыше 405 Тбит/с и защиту от DDoS-атак.
• Граничные узлы (edge nodes) сети Cloudflare кэшируют контент с исходного сервера и могут отвечать на запросы, используя кэшированную копию. Cloudflare также предоставляет DNS, Защита от DDoS, WAF, а также других сервисов производительности, надежности и безопасности, построенных на той же edge-архитектуре.
• Argo использует оптимизированную маршрутизацию и технологию кеширования в сети Cloudflare, чтобы доставлять ответы пользователям быстрее, надежнее и безопаснее. Argo включает Smart Routing и Tiered Cache. Cloudflare использует Argo для расширенного CDN-решения.

После подключения сайта по умолчанию настраивается стандартное кеширование. При стандартном кешировании каждый дата-центр выступает прямым обратным прокси для исходных серверов. Если в каком-либо дата-центре происходит промах кеша, запрос отправляется на исходный сервер из входного дата-центра.

Хотя стандартное кэширование работает, оно не является оптимальным решением: закэшированный контент, расположенный ближе к клиенту, может уже находиться в других дата-центрах Cloudflare, из-за чего исходные серверы иногда испытывают лишнюю нагрузку. Поэтому лучше включить Tiered Cache, которая входит во все планы Cloudflare. При использовании Tiered Cache некоторые дата-центры выступают в роли обратных прокси к источнику для других дата-центров, что увеличивает число попаданий в кэш и ускоряет время отклика.

Tiered Cache использует масштаб сети Cloudflare, чтобы минимизировать число запросов к источникам клиента. Когда запрос поступает в дата-центр Cloudflare и запрошенный контент отсутствует в локальном кэше, наличие кэшированного контента проверяется в других дата-центрах Cloudflare.

Дата-центры Cloudflare расположены ближе друг к другу и связаны более быстрыми маршрутами, чем каналы между дата-центрами и исходными серверами клиента, поэтому ответ клиенту формируется быстрее, а доля попаданий в кэш заметно растет. CDN Cloudflare использует данные Argo Smart Routing, чтобы определить оптимальные дата-центры верхнего уровня для Tiered Cache. Argo Smart Routing также можно подключить как дополнение: он обеспечивает самые быстрые маршруты между дата-центрами и исходными серверами при промахах кэша и других видах динамического трафика.

CDN Cloudflare позволяет клиентам настраивать многоуровневое кэширование. Обратите внимание, что в зависимости от тарифного плана Cloudflare доступны разные топологии для Tiered Cache. По умолчанию многоуровневое кэширование отключено, и его можно включить на вкладке кэширования главного меню.

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

На рисунке 4 многоуровневое кэширование включено с топологией Smart Tiered Cache Topology. На диаграмме показаны два отдельных потока трафика, кратко описанных ниже. Первый поток трафика (клиент 1) это запрос от клиента, поступающий в дата-центр 1. Второй поток трафика (клиент 2) это последующий запрос того же ресурса, поступающий в другой дата-центр, дата-центр 2.

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

Обратите внимание: когда новый запрос того же контента поступает в другой дата-центр (нижний поток трафика конечного пользователя на схеме), Data Center 3, контент не кешируется локально. Однако он загружается из дата-центра верхнего уровня, где был кеширован при первом запросе этого же контента.

Поскольку дата-центр верхнего уровня отдает закешированный контент уже на второй запрос, обращение к origin-серверу не требуется. Это повышает cache hit ratio, ускоряет ответ, экономит расходы на трафик между сетью Cloudflare и origin-сервером и снижает нагрузку на origin-сервер.

Основное различие между Smart Tiered Cache и Global tiered cache заключается в количестве верхних уровней, которые могут обращаться к исходным серверам. В Smart Tiered Cache ближайший к источнику верхний уровень выбирается с использованием данных о производительности и маршрутизации Argo. Это означает, что для всех запросов, для которых происходит кеш MISS на более низком уровне будут проходить через этот единственный верхний уровень и получат более высокую вероятность статуса кэша HIT чтобы избежать отправки трафика на origin-сервер. Однако недостаток такой архитектуры в том, что нижний уровень может находиться в другой точке земного шара относительно верхнего уровня. Даже если верхний уровень может обработать запрос из своего кеша, расстояние между верхним и нижним уровнями всё равно может добавить задержку к ответу в зависимости от пройденного расстояния. Подводя итог, Smart Tiered Cache обеспечивает прохождение всех запросов к кешу через единую локацию верхнего уровня кеша, что повышает HIT процентные показатели и снижает количество запросов к исходному серверу, однако это может привести к увеличению задержки при обработке этих запросов, поскольку верхний уровень может находиться далеко от нижнего уровня, откуда исходил запрос.

При использовании Generic Global Tiered Cache Cloudflare задействует свои крупнейшие дата-центры по всему миру в качестве верхнего уровня кэша, а это, как правило, означает, что верхний уровень кэша расположен гораздо ближе к нижнему уровню кэша. Это может значительно снизить задержки, когда нижним уровням нужно передавать запросы верхним. Однако в конечном счёте это увеличивает количество запросов, обрабатываемых исходным сервером, поскольку каждому верхнему уровню кэша нужно заполняться из исходного сервера. Подводя итог, Generic Global Tiered Cache может сокращать время отклика при заполненном кэше, но также увеличивает нагрузку на исходные серверы.

Regional Tiered Cache сочетает в себе преимущества обеих стратегий, добавляя в архитектуру дополнительный уровень кеширования. При использовании опции Regional Tiered Cache вместе со Smart Tiered Caching один верхний уровень кеша по-прежнему располагается ближе всего к источнику, но между верхним и нижним уровнями добавляется региональный уровень, географически более близкий к нижнему уровню. Теперь запросы от нижних уровней сначала проверяют наличие кеша на региональном уровне, прежде чем отправляться на верхний уровень. Один региональный уровень может принимать запросы от нескольких нижних уровней кеша и благодаря этому значительно повышает производительность и снижает задержки для приложений, доступных по всему миру.

Regional Tiered Caching рекомендуется использовать вместе со Smart Tiered Caching и Custom Tiered Caching. Однако Regional Tiered Cache не приносит пользы клиентам с большим количеством верхних уровней во многих регионах, в отличие от Generic Global Tiered Cache.

На рисунке 5 многоуровневое кэширование включено с топологией Smart Tiered Cache Topology. На диаграмме показана топология Smart Tiered Cache с включённым Regional Tiered Cache. Кэши нижнего уровня, когда происходит кэш MISS сначала отправит эти запросы в более локальный региональный узловой дата-центр, чтобы проверить, можно ли обработать запрос из кеша. Если нет, запрос будет передан на верхний уровень, а затем, при необходимости, на сервер-источник.

Сервис Argo Smart Routing находит оптимальные маршруты в сети Cloudflare, чтобы ответы доставлялись пользователям быстрее. Как уже говорилось ранее, Cloudflare CDN использует Argo Smart Routing для определения лучших дата-центров верхнего уровня для Tiered Cache.

Кроме того, можно включить Argo Smart Routing, чтобы гарантировать использование самых быстрых маршрутов по сети Cloudflare между дата-центрами верхнего уровня и серверами источника. Без Argo Smart Routing связь между дата-центрами верхнего уровня и серверами источника всё равно интеллектуально обходит проблемы в интернете, обеспечивая доступность источника.

Argo Smart Routing ускоряет трафик, используя данные в реальном времени и аналитику сети, полученную при маршрутизации почти 50 миллионов HTTP-запросов в секунду. Это гарантирует прохождение трафика по самым быстрым и надёжным маршрутам сети Cloudflare до исходного сервера. В среднем Argo Smart Routing обеспечивает прирост производительности веб-ресурсов на 30%.

Рисунок 6 подробно показывает поток трафика при отключённых Tiered Cache и Argo Smart Routing. Запрос поступает в ближайший дата-центр, и, поскольку контент не закеширован локально, а Tiered Cache отключён, запрос отправляется напрямую к origin-серверу. Кроме того, поскольку Argo Smart Routing отключён, для связи с origin-сервером используется надёжный, но не всегда самый быстрый путь.

Рисунок 7 показывает поток трафика при включённых Tiered Cache и Argo Smart Routing. Когда запрос поступает в Data Center 1 и происходит cache miss, проверяется кеш дата-центра верхнего уровня, Data Center 6. Если контент не найден в кеше дата-центра верхнего уровня, то при включённом Argo Smart Routing запрос отправляется к origin-серверу по самому быстрому пути от дата-центра верхнего уровня.

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

При использовании Cloudflare CDN Argo Smart Routing применяется в следующих случаях:

1. Происходит промах кеша, и запрос необходимо отправить на исходный сервер для получения контента.
2. Поступает запрос на некешируемый контент, например динамический контент (например, API), и запрос должен быть направлен на исходный сервер.

Развивая идею Tiered Cache, Cache Reserve дополнительно использует масштаб и скорость сети Cloudflare, а также R2, постоянное объектное хранилище Cloudflare, чтобы кэшировать контент ещё дольше. Cache Reserve помогает клиентам снижать расходы за счёт отказа от платы за исходящий трафик с источников, а также обеспечивает несколько уровней отказоустойчивости и защиты для надёжной доступности контента, что повышает производительность сайта благодаря более быстрой загрузке. По сути, Cache Reserve представляет собой дополнительный более высокий уровень кэша с более длительным сроком хранения.

Cache Reserve может работать и без включённого Tiered Cache, но рекомендуется включать Tiered Cache вместе с Cache Reserve. Tiered Cache объединяет запросы к Cache Reserve и потенциально исключает их вовсе, что устраняет повторные операции чтения и избыточное хранение кэшированного контента, снижая расходы на исходящий трафик и хранение. При включении Cache Reserve через Cloudflare Dashboard система проверит настройки и выдаст предупреждение, если вы попытаетесь использовать Cache Reserve без включённого Tiered Cache.

Cache Reserve хранит кэшированный контент в течение 30 дней, то есть удерживает его независимо от заголовков кэширования или политики TTL. При этом политика TTL по-прежнему определяет актуальность контента: когда TTL кэша контента в Cache Reserve истекает, содержимое необходимо повторно проверить на источнике на предмет обновлений. Политику TTL можно задать разными способами, например с помощью заголовков ответа Cache-Control, CDN-Cache-Control, параметра Edge Cache TTL, TTL кэша по коду состояния или правил Cache Rules. При каждом чтении кэша из Cache Reserve таймер хранения сбрасывается до 30 дней. Если по истечении 30 дней кэшированный контент так и не был прочитан из Cache Reserve, он удаляется.

Чтобы контент считался пригодным для кеширования через Cache Reserve, он должен соответствовать трем основным критериям:

1. Контент должен поддерживать кеширование. См. раздел Документация по кешированию подробнее о кэшируемом содержимом.
2. TTL должен быть установлен на значение не менее 10 часов. Это можно сделать любым из способов, описанных в предыдущем абзаце.
3. Заголовок Content-Length должен использоваться в заголовке ответа. Обратите внимание, что это означает следующее: [Transfer-Method «chunked» не позволит заполнить Cache Reserve.

В сочетании с Tiered Cache и Argo Smart Routing Cache Reserve становится мощным инструментом для увеличения числа попаданий в кэш, что снижает нагрузку на исходные серверы и одновременно повышает производительность за счёт приближения контента к конечному пользователю.

Рисунок 8 иллюстрирует, как Cache Reserve помогает снизить нагрузку на origin-сервер и одновременно способствует повторному заполнению кеша в дата-центрах верхнего и нижнего уровней.

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

1. China Network обеспечивает кеширование внутри Китая для конечных пользователей, находящихся в Китае, независимо от расположения исходного сервера. Это решение реализовано в сотрудничестве с JD Cloud и использует их центры обработки данных, чтобы обеспечить самую быструю и надёжную работу кеша для пользователей в Китае по сравнению с центрами обработки данных за пределами Китая.
2. Глобальное ускорение обеспечивает надёжное и безопасное соединение для доставки контента от исходных серверов к центрам обработки данных JD Cloud в Китае. Это особенно полезно для динамического контента, такого как веб приложения и вызовы API.

Подытожим: Cloudflare CDN представляет собой SaaS-сервис, который помогает клиентам решать проблемы с задержкой, производительностью, доступностью, отказоустойчивостью, безопасностью и затратами. Cloudflare CDN использует глобальную anycast-сеть Cloudflare и Tiered Cache, чтобы обеспечивать оптимальные результаты и одновременно снижать затраты клиентов. Клиенты также могут (enable Argo Smart)[argo-smart-routing/get-started/] Routing, чтобы запросы к серверу-источнику всегда шли по самому быстрому сетевому пути, а также включить Cache Reserve, чтобы увеличить долю попаданий в кеш, дополнительно снизить затраты и повысить производительность сайта или приложения.