Часто задаваемые вопросы об Azure Front Door

Azure Front Door — это облачная служба, которая обеспечивает более быструю и надежную работу приложений. Он использует балансировку нагрузки уровня 7 для распределения трафика между несколькими регионами и конечными точками. Он также предлагает динамическое ускорение сайта (DSA) для оптимизации производительности веб-сайтов и почти в режиме реального времени отработки отказа, чтобы обеспечить высокий уровень доступности. Azure Front Door — это полностью управляемая служба, поэтому вам не нужно беспокоиться о масштабировании или обслуживании.

Azure Front Door — это служба, которая предлагает множество преимуществ для веб-приложений, таких как динамическое ускорение сайта (DSA), что повышает производительность и взаимодействие с пользователями ваших сайтов. Azure Front Door также обрабатывает разгрузку TLS/SSL и завершение tls, что повышает безопасность и шифрование веб-трафика. Кроме того, Azure Front Door предоставляет Брандмауэр веб-приложений, сходство сеансов на основе файлов cookie, маршрутизацию на основе URL-адресов, бесплатные сертификаты и несколько управления доменами и многое другое. Дополнительные сведения о функциях и возможностях Azure Front Door см . в сравнении уровней.

Azure Front Door и Шлюз приложений Azure — это подсистемы балансировки нагрузки для трафика HTTP/HTTPS, но они имеют разные области. Front Door — это глобальная служба, которая может распределять запросы между регионами, а Шлюз приложений — это региональная служба, которая может сбалансировать запросы в пределах региона. Azure Front Door работает с единицами масштабирования, кластерами или единицами меток, а Шлюз приложений Azure работает с виртуальными машинами, контейнерами или другими ресурсами в одной единице масштабирования.

Шлюз приложений за Front Door полезно в следующих ситуациях:

• Вы хотите сбалансировать трафик не только глобально, но и в виртуальной сети. Front Door может выполнять балансировку нагрузки только на основе путей на глобальном уровне, но Шлюз приложений это можно сделать в виртуальной сети.
• Требуется очистка подключений, которая не поддерживает Front Door. Шлюз приложений может включить очистку подключений для виртуальных машин или контейнеров.
• Вы хотите выгрузить всю обработку TLS/SSL и использовать только HTTP-запросы в виртуальной сети. Шлюз приложений за Front Door может достичь этой настройки.
• Вы хотите использовать сходство сеансов как на региональном, так и на уровне сервера. Front Door может отправлять трафик из сеанса пользователя в ту же серверную часть в регионе, но Шлюз приложений может отправлять его на тот же сервер в серверной части.

Цепочка двух CDN, как правило, не рекомендуется, но она будет работать, но поставляется со следующими минусами.

1. Ускорение последней мили CDN использует сохранение потока подключения с источником и поиск оптимального пути к источнику для достижения наилучших результатов. Цепочка двух CDN вместе обычно отрицает некоторые преимущества от ускорения последней мили.
2. Элементы управления безопасностью становятся менее эффективными во второй сети CDN. Любой IP-адрес на основе ACLing клиента не будет работать во второй сети CDN, так как второй CDN увидит первый узел выхода CDN в качестве IP-адресов клиента. Полезные данные содержимого по-прежнему будут проверяться.
3. Многие организации не могут справиться с сложностью устранения неполадок, связанных с двумя сетями CDN, и когда проблема становится трудно выяснить, какая сеть CDN имеет проблему.

Чтобы использовать Azure Front Door, необходимо иметь общедоступный ВИРТУАЛЬНЫЙ IP-адрес или DNS-имя, доступное для общедоступного доступа. Azure Front Door использует общедоступный IP-адрес для маршрутизации трафика в источник. Распространенный сценарий — развертывание Azure Load Balancer за Front Door. Вы также можете использовать Приватный канал с Azure Front Door Premium для подключения к внутренней подсистеме балансировки нагрузки. Дополнительные сведения см. в разделе "Включение Приватный канал с внутренней подсистемой балансировки нагрузки".

Azure Front Door поддерживает протоколы HTTP, HTTPS и HTTP/2.

Azure Front Door поддерживает протокол HTTP/2 для клиентских подключений. Однако взаимодействие внутреннего пула использует протокол HTTP/1.1. Поддержка HTTP/2 включена по умолчанию.

Вы можете использовать различные типы источников для Azure Front Door, например:

• Хранилище (BLOB-объекты Azure, классические, статические веб-сайты)
• Облачная служба
• Служба приложений
• Статическое веб-приложение
• Управление API
• Шлюз приложений
• Общедоступный IP-адрес
• Azure Spring Apps
• Экземпляры контейнеров
• Контейнеры приложений
• Любое пользовательское имя узла с общедоступным доступом.

Источник должен иметь общедоступный IP-адрес или dns-имя узла, которое можно разрешить публично. Вы можете смешивать серверные серверы из разных зон, регионов или даже за пределами Azure, если они общедоступны.

Azure Front Door не ограничивается любым регионом Azure, но работает глобально. Единственное расположение, которое необходимо выбрать при создании Front Door, — это расположение группы ресурсов, определяющее, где хранятся метаданные группы ресурсов. Профиль Front Door — это глобальный ресурс, который распространяется на все пограничные расположения по всему миру.

Полный список точек присутствия (POP), которые обеспечивают глобальную балансировку нагрузки и доставку содержимого для Azure Front Door, см. в статьях о расположениях POP Azure Front Door. Этот список регулярно обновляется по мере добавления или удаления новых ПОСТАВЩИКов. Api Azure Resource Manager можно также использовать для программного запроса текущего списка POP.

Azure Front Door — это служба, которая распределяет приложение глобально между несколькими регионами. Она использует общую инфраструктуру, которая предоставляет общий доступ всем своим клиентам, но вы можете настроить собственный профиль Front Door для настройки конкретных требований приложения. Конфигурации других клиентов не могут повлиять на конфигурацию Front Door, которая изолирована от их.

Вы можете перенаправить компоненты строки узла, пути и запроса URL-адреса с помощью Azure Front Door. Чтобы узнать, как настроить перенаправление URL-адресов, обратитесь к url-перенаправлению.

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

Чтобы обеспечить оптимальную производительность функций Front Door, следует разрешить только трафик, поступающий из Azure Front Door, чтобы достичь вашего источника. В результате несанкционированные или вредоносные запросы сталкиваются с политиками безопасности и маршрутизации Front Door и отказано в доступе. Чтобы узнать, как защитить источник, ознакомьтесь с разделом "Безопасный трафик" в источники Azure Front Door.

IP-адрес интерфейсной рассылки Front Door исправлен и может не изменяться до тех пор, пока вы используете Front Door. Однако фиксированный IP-адрес интерфейсной рассылки Front Door не является гарантией. Избегайте прямого использования IP-адреса.

Azure Front Door — это динамическая служба, которая направляет трафик к лучшей доступной серверной части. В настоящее время он не предлагает статические или выделенные ИНТЕРФЕЙСНЫЕ IP-адреса.

Да. Обратитесь к свойству MatchedRulesSetName в разделе "Журналы доступа".

Да. Дополнительные сведения см. в ответе Майкрософт на атаки DDoS на HTTP/2.

Azure Front Door поддерживает заголовки X-Forwarded-For, X-Forwarded-Host и X-Forwarded-Proto. Эти заголовки помогают Front Door определить исходный IP-адрес клиента и протокол. Если X-Forwarded-For уже присутствует, Front Door добавляет IP-адрес сокета клиента в конец списка. В противном случае он создает заголовок с IP-адресом сокета клиента в качестве значения. Для X-Forwarded-Host и X-Forwarded-Proto Front Door заменяет существующие значения собственными.

Дополнительные сведения см. в статье Front Door, поддерживаемые заголовками HTTP.

Время развертывания для новых конфигураций Front Door зависит от типа изменения. Как правило, это занимает от 3 до 20 минут для распространения изменений во всех наших пограничных расположениях по всему миру.

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

№ В настоящее время Azure Front Door поддерживает только HTTP/1.1 из края в источник. Для работы gRPC требуется HTTP/2.

• Профили Front Door уровня "Стандартный" или "Премиум" и Azure CDN можно перемещать между группами ресурсов или подписками без простоя. Чтобы выполнить перемещение, следуйте этим инструкциям.
• Front Door Classic не поддерживает перемещение между группами ресурсов или подписками. Вместо этого можно перенести классический профиль в "Стандартный" или "Премиум", а затем выполнить перемещение.
• Если у клиента есть WAF, связанный с Front Door Standard или Premium, операция перемещения завершится ошибкой. Сначала клиент должен отсоединить политики WAF, переместить и связать их.

Чтобы использовать уровень Azure Front Door Standard, Premium или (классический), вам потребуется общедоступный IP-адрес или DNS-имя, которое можно разрешить публично. Это требование общедоступного IP-адреса или DNS-имени, которое можно разрешить публично, позволяет Azure Front Door маршрутизировать трафик к вашим внутренним ресурсам. Для маршрутизации трафика к ресурсам в виртуальной сети можно использовать такие ресурсы Azure, как Шлюз приложений или Azure Load Balancers. Если вы используете уровень Front Door Premium, вы можете использовать Приватный канал для подключения к источникам за внутренней подсистемой балансировки нагрузки с частной конечной точкой. Дополнительные сведения см. в статье Защита источника с помощью Приватного канала.

Группа источников — это коллекция источников, которые могут обрабатывать аналогичные типы запросов. Вам нужна другая группа источников для каждого приложения или рабочей нагрузки, которая отличается.

В группе источников создается источник для каждого сервера или службы, которые могут обслуживать запросы. Если у источника есть подсистема балансировки нагрузки, например Шлюз приложений Azure, или размещена в PaaS с подсистемой балансировки нагрузки, то группа источников имеет только один источник. Ваш источник заботится о отработки отказа и балансировке нагрузки между источниками, которые не отображаются Front Door.

Например, если вы размещаете приложение в службе приложение Azure, настройка Front Door зависит от количества экземпляров приложений, которые у вас есть:

• Развертывание в одном регионе: сделайте одну группу источников. В этой группе источников сделайте один источник для приложения Служба приложений. Приложение Служба приложений может масштабироваться между рабочими сотрудниками, но Front Door видит один источник.
• Многорегионное активное и пассивное развертывание: сделайте одну группу источников. В этой группе источников сделайте источник для каждого приложения Служба приложений. Задайте приоритет каждого источника таким образом, чтобы основное приложение имеет более высокий приоритет, чем приложение резервного копирования.
• Многорегионное активное или активное развертывание: сделайте одну группу источников. В этой группе источников сделайте источник для каждого приложения Служба приложений. Задайте приоритет каждого источника таким же. Задайте вес каждого источника, чтобы контролировать количество запросов, которые отправляются в этот источник.

Дополнительные сведения см. в статье "Источники и группы источников" в Azure Front Door.

Azure Front Door — это служба, которая обеспечивает быструю и надежную веб-доставку для приложений. Она предлагает такие функции, как кэширование, балансировка нагрузки, безопасность и маршрутизация. Однако необходимо учитывать некоторые ограничения времени ожидания и ограничения, которые применяются к Azure Front Door. Эти интервалы времени ожидания и ограничения включают максимальный размер запроса, максимальный размер ответа, максимальный размер заголовка, максимальное число заголовков, максимальное число правил и максимальное число групп источников. Подробные сведения об этих тайм-аутах и ограничениях см. в документации по Azure Front Door.

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

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

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

Azure Front Door использует три тега службы для управления трафиком между клиентами и источниками:

• Тег службы AzureFrontDoor.Backend содержит IP-адреса, которые Front Door использует для доступа к источникам. Этот тег службы можно применить при настройке безопасности для источников.
• Тег службы AzureFrontDoor.Frontend содержит IP-адреса, используемые клиентами для доступа к Front Door. Вы можете применить тег службы, если вы хотите контролировать исходящий AzureFrontDoor.Frontend трафик, который может подключаться к службам за Azure Front Door.
• Тег службы AzureFrontDoor.FirstParty зарезервирован для группы службы Майкрософт, размещенной в Azure Front Door.

Дополнительные сведения о сценариях тегов службы Azure Front Door см . в доступных тегах службы.

Azure Front Door имеет 5-секундное время ожидания для получения заголовков от клиента. Подключение завершается, если клиент не отправляет заголовки в течение 5 секунд в Azure Front Door после установки подключения TCP/TLS. Вы не можете настроить это значение времени ожидания.

Azure Front Door имеет 90-секундное время ожидания http в режиме поддержания активности. Подключение завершается, если клиент не отправляет данные в течение 90 секунд, то есть время ожидания http-поддержания активности для Azure Front Door. Вы не можете настроить это значение времени ожидания.

Вы не можете использовать одни и те же домены для нескольких конечных точек Front Door, так как Front Door должен различать маршрут (протокол + сочетание узлов и путей) для каждого запроса. Если у вас есть повторяющиеся маршруты в разных конечных точках, Azure Front Door не может правильно обрабатывать запросы.

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

Функция Приватный канал Azure Front Door — это не зависящая от региона, и она будет работать, даже если выбрать регион, отличный от региона, в котором находится ваш источник. В таких случаях, чтобы обеспечить низкую задержку, всегда следует выбрать ближайший к источнику регион Azure при выборе включения конечной точки Приватный канал Azure Front Door. Мы в процессе включения поддержки для большего числа регионов. После поддержки нового региона вы можете следовать этим инструкциям , чтобы постепенно переместить трафик в новый регион.

Azure Front Door — это платформа, которая распределяет трафик по всему миру и может масштабироваться в соответствии с требованиями приложения. Она использует глобальную сетевую границу Майкрософт для обеспечения глобальной балансировки нагрузки, которая позволяет переключить все приложение или определенные микрослужбы в разные регионы или облака, если произошел сбой.

Чтобы избежать ошибок при доставке больших файлов, убедитесь, что сервер-источник содержит Content-Range заголовок в ответе и что значение заголовка соответствует фактическому размеру текста ответа.

Дополнительные сведения о настройке источника и Front Door для доставки больших файлов можно найти в доставке больших файлов.

Интерфейс домена — это сетевой метод, позволяющий злоумышленнику скрыть фактическое назначение вредоносного запроса с помощью другого доменного имени в подтверждении TLS и заголовке узла HTTP.

Azure Front Door (уровень "Стандартный", "Премиум" и "Классический") или azure CDN уровня "Стандартный" от Майкрософт (классическая версия), созданные после 8 ноября 2022 г., включают блокировку домена. Вместо того чтобы блокировать запрос с несовпадными заголовками SNI и узлами, мы разрешаем несоответствие, если два домена принадлежат к одной подписке и включены в правила маршрутизации и маршрутизации. Принудительное применение блокировки домена начнется 22 января 2024 г. для всех существующих доменов. Принудительное применение может потребовать до двух недель для распространения на все регионы.

Если Front Door блокирует запрос из-за несоответствия:

• Клиент получает ответ кода ошибки HTTP 421 Misdirected Request .
• Azure Front Door записывает блок в журналы диагностики в свойстве Сведений об ошибке со значением SSLMismatchedSNI.

Дополнительные сведения о интерфейсе домена см. в статье "Защита нашего подхода к интерфейсу домена в Azure" и "Запрет доменных интерфейсов" в Azure Front Door и Azure CDN Standard от Майкрософт (классическая модель).

Front Door использует TLS 1.2 в качестве минимальной версии для всех профилей, созданных после сентября 2019 года.

Вы можете использовать TLS 1.0, 1.1, 1.2 или 1.3 с Azure Front Door. Чтобы узнать больше, ознакомьтесь со статьей ПО TLS в Azure Front Door.

Azure Front Door — это служба, которая обеспечивает быструю и безопасную веб-доставку. Он позволяет определить способ маршрутизации и оптимизации веб-трафика в нескольких регионах и конечных точках. Ресурсы Azure Front Door, такие как профили Front Door и правила маршрутизации, взимается только при их включении. Однако политики и правила брандмауэра веб-приложения (WAF) взимается независимо от их состояния. Даже если вы отключите политику или правило WAF, она по-прежнему несет затраты на вас.

№

№

AFD не поддерживает динамическое сжатие содержимого, превышающее 8 МБ. Однако если содержимое уже сжато источником, Front Door поддерживает обслуживание статического сжатого содержимого более 8 МБ до тех пор, пока поддерживается запрос диапазона, а кодировка передачи с блоками не включена.

№

Сведения о журналах и других возможностях диагностики находятся в статье Мониторинг метрик и журналов для Front Door.

Журналы диагностики можно хранить в собственной учетной записи хранения и выбрать срок их хранения. Кроме того, журналы диагностики можно отправлять в центры событий или журналы Azure Monitor. Дополнительные сведения см. в диагностика Azure Front Door.

Чтобы получить доступ к журналам аудита Azure Front Door, необходимо посетить портал. Выберите Front Door на странице меню и выберите журнал действий. Журнал действий предоставляет записи операций Azure Front Door.

Оповещения для Azure Front Door можно настроить на основе метрик или журналов. Таким образом, вы можете отслеживать производительность и работоспособность внешних узлов.

Сведения о создании оповещений для Azure Front Door уровня "Стандартный" и "Премиум" см. в статье "Настройка оповещений".

Следующие шаги

• Узнайте, как создать профиль Azure Front Door.
• Сведения об архитектуре Azure Front Door.