Руководство по CDN

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

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

В Azure Azure Front Door — это глобальное решение CDN для доставки содержимого с высокой пропускной способностью, размещенного в Azure или любом другом расположении. Вы можете настроить ценовые категории Azure Front Door Standard и Premium для кэширования контента на периферии сети. Можно кэшировать объекты, загруженные из Хранилище BLOB-объектов Azure, веб-приложения, виртуальной машины или даже любого общедоступного веб-сервера.

В этой статье описываются некоторые общие рекомендации и рекомендации по использованию CDN. Дополнительные сведения см. в документации по кэшированию с помощью Azure Front Door.

Как и для чего используется CDN

К типичным случаям использования CDN относятся:

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

• Доставка общедоступного статического и общего содержимого на устройства, например мобильные телефоны и планшетные компьютеры. Само приложение является веб-службой, которая предоставляет доступ к API клиентам, запущенным на разных устройствах. CDN также может доставлять статические наборы данных (через веб-службу) для использования клиентами, в том числе для создания пользовательского интерфейса клиента. Например, CDN можно использовать для распределения документов JSON или XML.

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

• Стриминг видеофайлов на клиента по запросу. Видео выигрывает от низкой задержки и надежного подключения, доступного из центров обработки данных, расположенных по всему миру, которые предлагают соединения с CDN.

• Оптимизация взаимодействия для пользователей, особенно для тех, кто находится далеко от центра обработки, в котором размещено приложение. Эти пользователи могут в противном случае столкнуться с более высокой задержкой. Большой объем содержимого в веб-приложении часто является статическим, а использование CDN поможет поддерживать производительность и общее качество взаимодействия с пользователями на нужном уровне, исключая при этом необходимость развертывания приложения в нескольких центрах обработки данных. Список точек присутствия (POP) Azure Front Door по регионам см. в разделе Точки присутствия (POP) Azure Front Door по регионам.

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

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

Сложности

Если вы намерены применить CDN, не забудьте учесть некоторые сложности.

• Развертывание. Определите источник, из которого CDN получает содержимое, а также решите, нужно ли развертывать содержимое больше, чем в одной системе хранения данных. Рассмотрим процесс развертывания статического содержимого и ресурсов. Например, может потребоваться реализовать отдельный шаг для загрузки содержимого в Хранилище BLOB-объектов Azure.

• Управление версиями и кэшем. Рассмотрим, как обновить статическое содержимое и развернуть новые версии. Выясните, как в CDN выполняется кэширование и время жизни (TTL). Сведения о Azure Front Door см. в разделе "Кэширование с помощью Azure Front Door".

• Тестирование. Выполнение локального тестирования параметров CDN при разработке и тестировании приложения локально или в промежуточной среде может представлять сложности.

• Оптимизация для поисковых систем (SEO). Содержимое, например изображения и документы, передаются из другого домена при использовании CDN, что может повлиять на SEO для этого содержимого.

• Безопасность содержимого. Не все сети CDN предоставляют управление доступом на основе удостоверений для содержимого. WAF Azure Front Door защищает приложения от распространённых атак, а защита источника не позволяет трафику обходить Front Door. Эти функции не заменяют авторизацию на уровне приложения для частного содержимого. Дополнительные сведения см. в статье Брандмауэр веб-приложений в Azure Front Door и Защита трафика к источникам Azure Front Door.

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

• Устойчивость. CDN — это потенциальная единая точка отказа для приложения.

Сценарии, в которых CDN может оказаться менее полезным:

• Если содержимое имеет низкую скорость попадания, он может получить доступ только несколько раз, пока он действителен (определяется его временем в реальном времени).

• Если данные являются конфиденциальными, например в больших организациях или экосистемах цепочки поставок.

Общие инструкции и рекомендации

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

Развертывание

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

Оцените возможность использовать методы объединения и минификации, чтобы ускорить загрузку для клиентов. Упаковка объединяет несколько файлов в один. Минификация удаляет из скриптов и файлов CSS ненужные символы, не затрагивая их функциональность.

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

Рассмотрим, как обрабатывать локальную разработку и тестирование, если ожидается, что часть статического содержимого будет обслуживаться из CDN. Например, можно предварительно развертывать такое содержимое в CDN из скрипта сборки. Кроме того, можно воспользоваться директивами компилятора или флагами для управления процессами загрузки ресурсов в приложении. Например, в режиме отладки приложение может получать статические ресурсы из локальной папки. В режиме выпуска это же приложение будет использовать CDN.

Рассмотрите возможности для сжатия файлов, например с помощью gzip (GNU zip). Сжатие может выполняться на исходном сервере хостингом веб-приложения или непосредственно на пограничных серверах CDN. Дополнительные сведения см. в статье "Повышение производительности путем сжатия файлов в Azure Front Door".

Маршрутизация и управление версиями

Вам может потребоваться обслуживать различные версии содержимого в разное время. Например, при развертывании новой версии приложения может потребоваться обслуживать новое содержимое и сохранять старое содержимое (в старом формате) для предыдущих версий. Если в качестве источника содержимого используется Хранилище BLOB-объектов Azure, можно хранить каждую версию в отдельном контейнере хранилища BLOB-объектов. Источник Azure Front Door указывает на хост учетной записи хранения, а не на отдельный контейнер. Чтобы обслуживать содержимое из другой учетной записи хранения, укажите к нему источник. Чтобы обслуживать содержимое из другого контейнера в той же учетной записи, задайте путь к источнику маршрута или добавьте правило перезаписи URL-адресов, предназначенное для контейнера.

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

Рассмотрите возможность ограничения доступа к содержимому CDN по странам или регионам. Azure Front Door использует WAF для фильтрации запросов в зависимости от страны или региона, отправляемого запросом, и ограничения содержимого, которое он доставляет. Для получения дополнительной информации см. раздел «Геофильтрация на домене для Azure Front Door».

управление кэшем;

Выберите способ управления кэшированием в системе. Например, в Azure Front Door можно задать правила кэширования в обработчике правил и применить пользовательское поведение кэширования к определенным маршрутам. Вы также можете управлять тем, как кэширование осуществляется в CDN, отправляя заголовки с директивами кэша от источника.

Более подробные сведения см. в статье Кэширование с помощью Azure Front Door.

Чтобы предотвратить доступность объектов в CDN, их можно удалить из источника, удалить конечную точку CDN или для хранилища BLOB-объектов сделать контейнер или объект блоба закрытым. Однако элементы не удаляются из СЕТИ CDN до истечения срока действия. Если потребуется, конечную точку CDN можно очистить вручную.

Безопасность

Azure Front Door может доставлять содержимое по протоколу HTTPS с помощью сертификата TLS, управляемого Microsoft или собственного сертификата. Чтобы избежать предупреждений браузера о смешанном содержимом, используйте HTTPS для запроса статического содержимого, которое отображается на страницах, загруженных через HTTPS. Дополнительные сведения см. в статье Комплексный протокол TLS с Azure Front Door.

Если вы используете CDN для передачи статических активов, таких как файлы шрифтов, некоторые проблемы может вызвать политика одного источника, например при использовании XMLHttpRequest для получения ресурсов из другого домена. Многие веб-браузеры предотвращают общий доступ к ресурсам независимо от источника (CORS), если сервер не настроен для задания соответствующих заголовков ответов. Вы можете настроить в CDN поддержку CORS, используя любой из следующих методов.

• Настройте в CDN добавление заголовков CORS к ответам. Дополнительные сведения см. в разделе "Настройка CORS с помощью Azure Front Door".

• Если источником является Хранилище BLOB-объектов Azure, добавьте правила CORS для конечной точки хранилища. Дополнительные сведения см. в разделе Поддержка кросс-доменного совместного использования ресурсов (CORS) для служб служба хранилища Azure.

• В приложении настройте установку заголовков CORS. Например, см. статью Abling Cross-Origin Requests (CORS) в документации ASP.NET Core.

Резервный механизм CDN

Рассмотрим, как приложение справится с ошибкой или временной недоступностью CDN. Клиентские приложения могут использовать копии ресурсов, кэшированных локально (на клиенте) во время предыдущих запросов, или можно включить код, который обнаруживает сбой и вместо этого запрашивает ресурсы из источника (папка приложения или контейнер Хранилище BLOB-объектов Azure, содержащий ресурсы), если CDN недоступен.