Diseño y configuración de Azure Front Door
Azure Front Door es la nube moderna de Microsoft Content Delivery Network (CDN) que proporciona acceso rápido, confiable y seguro entre los usuarios y las aplicaciones. Azure Front Door entrega el contenido mediante la red perimetral global de Microsoft con cientos de POP globales y locales distribuidos por todo el mundo cerca de los usuarios finales de empresa y consumidor.
Muchas organizaciones tienen aplicaciones que quieren poner a disposición de sus clientes, sus proveedores y, casi con certeza, sus usuarios. La parte complicada es asegurarse de que esas aplicaciones tienen alta disponibilidad. Además, deberán poder responder rápidamente mientras mantienen la protección adecuada. Azure Front Door proporciona diferentes SKU (planes de tarifa) que cumplen estos requisitos. Revisemos brevemente las características y ventajas de estos SKU para que pueda determinar qué opción se adapta mejor a sus requisitos.
Una red CDN en la nube moderna y segura proporciona una plataforma distribuida de servidores. Los servidores distribuidos minimizan la latencia cuando los usuarios acceden a páginas web. En el pasado, el personal de TI podría usar una red CDN y un firewall de aplicaciones web para controlar el flujo de tráfico HTTP y HTTPS hacia y desde las aplicaciones de destino.
Si una organización usa Azure, podría lograr estos objetivos mediante la implementación de los productos descritos en esta tabla.
| Identificador | Descripción |
|---|---|
| Azure Front Door | Habilita un punto de entrada a las aplicaciones situadas en la red perimetral global de Microsoft. Proporciona una acceso más rápido, seguro y escalable a las aplicaciones web. |
| Azure Content Delivery Network | Entrega contenido de gran ancho de banda a los usuarios mediante el almacenamiento en caché de su contenido en nodos físicos colocados estratégicamente en diferentes partes del mundo. |
| Firewall de aplicaciones web de Azure | Ayuda a proporcionar una protección centralizada y más sólida de las aplicaciones web contra las vulnerabilidades de seguridad y de otros tipos comunes. |
Comparación del nivel de Azure Front Door
Azure Front Door se ofrece en dos niveles diferentes, Azure Front Door Estándar y Azure Front Door Premium. Los niveles de Azure Front Door Estándar y Premium combinan las capacidades de Azure Front Door (clásico), Azure CDN Estándar de Microsoft (clásico) y Azure WAF en una única plataforma CDN segura en la nube con protección inteligente frente a amenazas. Azure Front Door reside en las ubicaciones perimetrales y administra las solicitudes de usuario a las aplicaciones hospedadas. Los usuarios se conectan a la aplicación mediante la red global de Microsoft. Después, Azure Front Door redirige las solicitudes de usuario al back-end de aplicación más rápido y disponible.
Para ver una comparación de las características admitidas en Azure Front Door, revise la tabla de comparación de características.
Creación de una instancia de Front Door en Azure Portal
Revise el Inicio rápido para aprender a crear un perfil de Azure Front Door mediante Azure Portal. Puede crear un perfil de Azure Front Door con configuraciones básicas mediante Creación rápida, o bien con configuraciones más avanzadas mediante Creación personalizada.
Introducción a la arquitectura de enrutamiento
El enrutamiento del tráfico de Front Door se realiza en varias fases. En primer lugar, el tráfico se enruta desde el cliente a Front Door. A continuación, Front Door usa la configuración para determinar el origen al que enviar el tráfico. El firewall de aplicaciones web de Front Door, las reglas de enrutamiento, el motor de reglas y la configuración de almacenamiento en caché afectan al proceso de enrutamiento. En el diagrama siguiente se muestra la arquitectura de enrutamiento:
Estructura de configuración de las reglas de enrutamiento de Front Door
Una configuración de regla de enrutamiento de Front Door se compone de dos partes principales.
Coincidencia entrante
Estas propiedades determinan si la solicitud entrante coincide con la regla de enrutamiento.
- Protocolos HTTP (HTTP/HTTPS)
- Hosts (por ejemplo, www.foo.com, *.bar.com)
- Rutas de acceso (por ejemplo, /, /Users/, /file.gif)
Estas propiedades se expanden de forma interna para que cada combinación de protocolo, host y ruta de acceso sea un conjunto de posible coincidencia.
Datos de ruta
Front Door acelera el procesamiento de solicitudes mediante el almacenamiento en caché. Si el almacenamiento en caché está habilitado para una ruta específica, usa la respuesta almacenada en caché. Si no hay ninguna respuesta almacenada en caché para la solicitud, Front Door reenvía la solicitud al back-end apropiado en el grupo de back-end configurado.
Búsqueda de coincidencia de ruta
Front Door intenta primero la coincidencia más específica. El algoritmo coincide primero en función del protocolo HTTP, luego el host de front-end y, a continuación, la ruta de acceso.
Coincidencia de host de front-end:
- Busque cualquier enrutamiento con una coincidencia exacta en el host.
- Si no hay una coincidencia de hosts de front-end exacta, rechace la solicitud y envíe un error 400 de solicitud incorrecta.
Coincidencia de ruta de acceso:
- Busque cualquier regla enrutamiento con una coincidencia exacta con la ruta de acceso.
- Si ninguna ruta de acceso presenta una coincidencia exacta, busque las reglas de enrutamiento con una ruta de acceso con un carácter comodín que coincida.
- Si no hay reglas de enrutamiento con una ruta coincidente, rechace la solicitud y devuelva una respuesta de error HTTP 400: solicitud incorrecta.
Si no hay ninguna regla de enrutamiento para un host de front-end con coincidencia exacta con una ruta de acceso de ruta comodín (/*), entonces no será una coincidencia.
Azure Front Door redirige el tráfico en cada uno de estos niveles: protocolo, nombre de host, ruta de acceso, cadena de consulta. Estas funcionalidades se pueden configurar para microservicios individuales, ya que el redireccionamiento está basado en la ruta de acceso.
Tipo de redireccionamiento
Un tipo de redirección establece el código de estado de respuesta para que los clientes comprendan el propósito de la redirección. Se admiten estos tipos de redireccionamiento.
| Tipo de redireccionamiento | Acción | Descripción |
|---|---|---|
| 301 | Movido permanentemente | Indica que se ha asignado un nuevo URI permanente al recurso de destino. Todas las referencias futuras a este recurso usarán uno de los identificadores URI delimitados. Use el código de estado 301 para el redireccionamiento de HTTP a HTTPS. |
| 302 | Encontrado | Indica que el recurso de destino se encuentra temporalmente en otro URI. Puesto que el redireccionamiento se puede modificar, el cliente debe seguir usando el URI de solicitud efectivo para las solicitudes futuras. |
| 307 | Redireccionamiento temporal | Indica que el recurso de destino se encuentra temporalmente en otro URI. El agente de usuario NO DEBE cambiar el método de solicitud si realiza un redireccionamiento automático a ese URI. Puesto que el redireccionamiento puede cambiar con el tiempo, el cliente debería seguir usando el URI de solicitud efectivo original para las solicitudes futuras. |
| 308 | Redireccionamiento permanente | Indica que se ha asignado un nuevo URI permanente al recurso de destino. Todas las referencias futuras a este recurso deben usar uno de los URI delimitados. |
Protocolo de redireccionamiento
Puede establecer el protocolo que se usará para el redireccionamiento. Los casos de uso más comunes de la característica de redireccionamiento consiste en establecer el redireccionamiento de HTTP a HTTPS.
- Solo HTTPS: establezca el protocolo en solo HTTPS, si busca redirigir el tráfico de HTTP a HTTPS. Azure Front Door recomienda que siempre establezca el redireccionamiento en solo HTTPS.
- Solo HTTP: se redirige la solicitud entrante a HTTP. Use este valor solo si busca mantener el tráfico HTTP tal cual, sin cifrar.
- Confrontar solicitud: esta opción conserva el protocolo usado por la solicitud entrante. Por lo tanto, una solicitud HTTP permanece HTTP, y una solicitud HTTPS permanece HTTPS después del redireccionamiento.
Host de destino
Como parte de la configuración de una ruta de redireccionamiento, también puede cambiar el nombre de host o el dominio para la solicitud de redireccionamiento. Puede establecer este campo para cambiar el nombre de host en la dirección URL para el redireccionamiento o, de lo contrario, conservar el nombre de host de la solicitud entrante. Por lo tanto, usar este campo le permite redirigir todas las solicitudes enviadas en https://www.contoso.com/* hacia https://www.fabrikam.com/*.
Ruta de acceso de destino
Para los casos en los que quiera reemplazar el segmento de ruta de acceso de una dirección URL como parte del redireccionamiento, puede establecer este campo en el nuevo valor de la ruta de acceso. En caso contrario, puede elegir conservar el valor de ruta de acceso como parte del redireccionamiento. Por lo tanto, usar este campo le permite redirigir todas las solicitudes enviadas a https://www.contoso.com/* hacia https://www.contoso.com/redirected-site.
Fragmento de destino
El fragmento de destino es la parte de la dirección URL después del signo de número (#). Puede establecer este campo para agregar un fragmento a la dirección URL de redireccionamiento.
Parámetros de cadena de consulta
También puede reemplazar los parámetros de la cadena de consulta en la dirección URL redirigida. Para reemplazar cualquier cadena de consulta existente desde la dirección URL de solicitud entrante, establezca este campo en "Replace" (Reemplazar) y, después, el valor adecuado. En caso contrario, conserve el conjunto original de las cadenas de consulta estableciendo el campo en Conservar. Por ejemplo, con este campo, puede redirigir todo el tráfico enviado a https://www.contoso.com/foo/bar a https://www.contoso.com/foo/bar?&utm_referrer=https%3A%2F%2Fwww.bing.com%2F.
Configuración de directivas de reescritura
Azure Front Door admite la reescritura de direcciones URL mediante la configuración de una ruta de acceso de reenvío personalizada opcional que se usará al construir la solicitud de reenvío al back-end. El encabezado host usado en la solicitud reenviada se configura para el back-end seleccionado. Lea Encabezado de host de back-end para más información sobre lo que hace y cómo configurarlo.
La parte eficaz de la reescritura de direcciones URL es que la ruta de reenvío personalizada copia en la ruta de reenviada cualquier parte de la ruta entrante que coincida con una ruta comodín.
Configuración de sondeos de estado, incluida la personalización de códigos de respuesta HTTP
Con el fin de determinar el estado y la proximidad de cada back-end de un entorno de Front Door especificado, cada entorno envía periódicamente una solicitud HTTP/HTTPS sintética a cada uno de los servidores back-end configurados. Front Door usa entonces las respuestas de estos sondeos para determinar los "mejores" recursos de servidor back-end a los que enrutar las solicitudes de los clientes.
Como Front Door tiene muchos entornos perimetrales en todo el mundo, el volumen de solicitudes de sondeo de estado a los back-end puede ser alto, desde 25 solicitudes por minuto hasta un máximo de 1200 solicitudes por minuto, dependiendo de la frecuencia de sondeo de estado configurada. Con la frecuencia de sondeo predeterminada de 30 segundos, el volumen de sondeo del back-end debe ser de aproximadamente 200 solicitudes por minuto.
Métodos HTTP admitidos para los sondeos de estado
Front Door admite el envío de sondeos a través de los protocolos HTTP o HTTPS. Estos sondeos se envían a través de los mismos puertos TCP configurados para enrutar las solicitudes de cliente y no se pueden reemplazar.
Front Door admite estos métodos HTTP para enviar los sondeos de estado:
GET: El método GET recupera la información de entidad en Request-URI.
HEAD: El método HEAD es idéntico a GET, excepto que el servidor NO PUEDE devolver cuerpo de mensaje en la respuesta. Dado que los back-end soportan menos carga y costos, para los nuevos perfiles de Front Door, de forma predeterminada, el método de sondeo se establece como HEAD.
Respuestas de sondeo de estado
En esta tabla se describen las respuestas al sondeo de estado:
| Respuesta | Descripción |
|---|---|
| Determinación del estado | Un código de estado 200 - Correcto indica que el back-end está en buen estado. Todo lo demás se considera un error. Si por algún motivo (incluidos los errores de red) no se recibe una respuesta HTTP válida de un sondeo, este se considera un error. |
| Medida de la latencia | La latencia es el tiempo de reloj medido desde el momento inmediatamente anterior al envío de la solicitud de sondeo hasta el momento en que se recibe el último byte de la respuesta. Se usa una nueva conexión TCP para cada solicitud, por lo que esta medida no está orientada a los servidores backend con conexiones parcialmente activas existentes. |
Para determinar el mantenimiento, Azure Front Door usa el mismo proceso de tres pasos.
Excluye los servidores back-end deshabilitados.
Se excluyen los servidores backend que tienen errores de sondeo de estado:
- Esta selección se realiza examinando las últimas n respuestas de sondeo de estado. Si al menos x están en buen estado, el back-end se considera correcto.
- Para configurar n, se cambia la propiedad SampleSize de la configuración de equilibrio de carga.
- Para configurar x, se cambia la propiedad SuccessfulSamplesRequired de la configuración de equilibrio de carga.
Para los conjuntos de servidores back-end con un estado correcto del grupo de servidores back-end, Front Door mide y mantiene también la latencia (tiempo de ida y vuelta) de cada back-end.
Si tiene un back-end único en el grupo de back-end, puede optar por deshabilitar los sondeos de estado que reducen la carga en el back-end de la aplicación. Incluso si tiene varios back-end en el grupo de back-end, pero solo uno de ellos está en estado habilitado, puede deshabilitar los sondeos de estado.
Protección de Front Door con TSL/SSL
El uso del protocolo HTTPS garantiza que los datos confidenciales se entreguen de forma segura. Cuando el explorador web se conecta a un sitio web a través de HTTPS, valida el certificado de seguridad del sitio web y comprueba que lo ha emitido una entidad de certificación legítima. Este proceso aporta seguridad y protege las aplicaciones web de posibles ataques.
Algunos de los atributos clave de la característica de HTTPS personalizado son:
- Sin costo adicional: la adquisición o renovación de certificados no tiene costos y el tráfico HTTPS no supone un costo adicional.
- Habilitación simple: El aprovisionamiento simplificado está disponible en Azure Portal. También puede utilizar la API de REST u otras herramientas de desarrollo para habilitar la característica.
- Administración de certificados completa: toda la adquisición y administración de certificados se controla de manera automática. Los certificados se aprovisionan y se renuevan automáticamente antes de la expiración, lo que elimina los riesgos de interrupción del servicio debido a la expiración de un certificado.
Para obtener más información sobre cómo configurar HTTPS en Front Door, consulte Tutorial: Configuración de HTTPS en un dominio personalizado para Azure Front Door | Microsoft Learn.