Mecánicas de Enrutamiento CDN

El enrutamiento CDN es el proceso de dirigir requests de usuarios al servidor edge óptimo basado en geografía, condiciones de red, salud del servidor y tipo de contenido. Las CDNs combinan enrutamiento basado en DNS, BGP anycast, monitoreo de rendimiento en tiempo real y balanceo de carga inteligente para enrutar cada request al servidor que entrega el mejor rendimiento para ese usuario específico en ese momento.

El enrutamiento CDN opera en múltiples capas: el enrutamiento DNS dirige usuarios a clústeres edge cercanos, el enrutamiento BGP anuncia prefijos IP desde múltiples ubicaciones, el enrutamiento a nivel de aplicación dentro de clústeres edge balancea carga entre servidores, y la selección de origin elige el backend óptimo para contenido dinámico. Cada capa optimiza diferentes aspectos de la entrega de requests.

El objetivo del enrutamiento: minimizar round-trip time (RTT) entre usuario y servidor edge, maximizar cache hit rate sirviendo desde servidores con el contenido solicitado, mantener disponibilidad evitando servidores sobrecargados o fallidos, y optimizar costo enrutando a ubicaciones eficientes. Las CDNs modernas enrutan tráfico en tiempo real basándose en miles de métricas por segundo.

Last updated: 2026-04-22

Cómo Funciona el Enrutamiento CDN

El enrutamiento CDN inicia cuando un usuario solicita contenido de un dominio respaldado por CDN. El proceso de enrutamiento involucra múltiples puntos de decisión:

Paso 1: Resolución DNS

El navegador del usuario consulta www.example.com mediante DNS:

1. El resolver recursivo consulta el servidor de nombres autoritativo para example.com
2. El servidor de nombres autoritativo retorna CNAME apuntando al dominio CDN: www.example.com.cdn.example.net
3. El resolver consulta la infraestructura DNS del CDN para cdn.example.net
4. El DNS del CDN retorna dirección IP del servidor edge óptimo para ese resolver

La dirección IP retornada se selecciona basándose en:

• Ubicación geográfica del resolver (geo-DNS)
• Enrutamiento IP anycast (misma IP anunciada desde múltiples ubicaciones)
• Salud y carga del servidor
• Disponibilidad de contenido (qué edge tiene el contenido en cache)
• Métricas de rendimiento en tiempo real

Paso 2: Enrutamiento BGP a Nivel de Red

El dispositivo del usuario conecta a la dirección IP retornada por DNS:

• Para IPs anycast, BGP enruta paquetes a la ubicación más cercana anunciando ese prefijo
• Para IPs unicast, el tráfico enruta a la ubicación edge específica seleccionada por DNS
• Operadores de red ajustan atributos BGP (AS path, MED, local preference) para influenciar enrutamiento
• Convergencia BGP toma segundos a minutos; enrutamiento DNS se adapta en milisegundos

Paso 3: Selección de Servidor Edge

En la ubicación edge, load balancers distribuyen requests entre servidores:

• Layer 4 load balancers (TCP/UDP) distribuyen por IP:puerto
• Layer 7 load balancers (HTTP) enrutan por URL path, headers, cookies
• Health checks remueven servidores fallidos de rotación
• Session affinity (sticky sessions) enrutan mismo usuario a mismo servidor cuando es necesario

Paso 4: Selección de Origin

Para cache misses o contenido no almacenable en cache, el servidor edge obtiene del origin:

• Múltiples servidores origin para redundancia
• Selección de origin basada en proximidad, salud, carga
• Shielding: designar ubicación edge específica como “shield” para deduplicar requests al origin
• Connection pooling a origins reduce sobrecarga de handshake TCP/TLS

Enrutamiento Basado en DNS

Geo-DNS (DNS Geográfico)

Retorna diferentes direcciones IP basándose en ubicación geográfica del resolver:

• Base de datos mapea IP del resolver a región geográfica
• Diferentes IPs de servidor edge para diferentes regiones (Américas, Europa, Asia-Pacífico)
• Reduce latencia enrutando a ubicación edge más cercana
• Limitaciones: IP del resolver puede no reflejar ubicación del usuario (resolvers públicos como 8.8.8.8), bases de datos geo-IP inexactas

Ejemplo:

Usuario en Brasil → Resolver en Brasil → DNS CDN retorna IP de servidor edge en São Paulo
Usuario en Alemania → Resolver en Alemania → DNS CDN retorna IP de servidor edge en Frankfurt

Anycast DNS

Misma dirección IP anunciada desde múltiples ubicaciones:

• BGP enruta usuario a ubicación anycast topológicamente más cercana
• Failover automático: si una ubicación falla, BGP retira ruta, tráfico fluye a la siguiente más cercana
• Simplifica gestión DNS: una sola IP en lugar de IPs específicas por ubicación
• Funciona a nivel de red; no se requiere base de datos geo-IP

Cómo funciona anycast:

1. CDN asigna misma IP (ej., 203.0.113.50) a servidores edge en 50 ubicaciones
2. Cada ubicación anuncia prefijo 203.0.113.0/24 vía BGP
3. Paquetes del usuario enrutan a ubicación más cercana vía selección normal de path BGP
4. Si ubicación São Paulo falla, retira anuncio BGP; usuarios brasileños enrutan a siguiente más cercana (Miami o Virginia)

Enrutamiento Basado en Latencia

Mide RTT desde IP del resolver a ubicaciones edge candidatas:

• CDN mantiene base de datos de latencia desde tráfico real de usuarios
• DNS responde con IP de ubicación edge con menor RTT
• Más preciso que geo-DNS (mide rendimiento de red real, no solo geografía)
• Se adapta a cambios de red: congestión, outages enrutan automáticamente alrededor

DNS Round-Robin Ponderado

Distribuye tráfico proporcionalmente entre ubicaciones:

• DNS retorna diferentes IPs con diferentes probabilidades
• Ejemplo: 40% a ubicación A, 35% a ubicación B, 25% a ubicación C
• Usado para migración gradual de tráfico, probar nuevas ubicaciones, optimización de costos
• Requiere que clientes consulten DNS frecuentemente (respetar TTL)

Enrutamiento BGP en CDNs

Anuncio de Prefijos

CDN anuncia prefijos IP (bloques de direcciones IP) vía BGP:

• CDNs grandes poseen su propio espacio de direcciones IP (Provider Independent IP space)
• Anuncian prefijos desde múltiples ubicaciones vía BGP a ISPs upstream
• ISPs propagan rutas a través del internet
• Path a IP del CDN determinado por algoritmo de AS-path más corto de BGP

Traffic Engineering

CDNs manipulan atributos BGP para influenciar enrutamiento:

Local Preference: Preferir ciertas rutas internamente

route-map PREFER-ISP1 permit 10
  set local-preference 200

Mayor local preference = ruta preferida dentro de la red del CDN.

AS Path Prepending: Hacer que path parezca más largo, reduciendo preferencia

route-map DEPREP-CATE permit 10
  set as-path prepend 64512 64512 64512

Prepending el número AS del CDN múltiples veces hace que path parezca más largo, enrutando tráfico lejos de esta ubicación.

Multi-Exit Discriminator (MED): Sugerir punto de entrada preferido a AS vecino

route-map SET-MED permit 10
  set metric 50

Menor MED = preferido cuando hay múltiples links al mismo AS vecino.

Enrutamiento Anycast

Mismo prefijo IP anunciado desde múltiples ubicaciones:

• Cada ubicación anuncia prefijo con atributos BGP similares
• Routers de internet eligen “más cercano” basándose en longitud de AS-path, costo IGP
• Failover automático cuando ubicación retira anuncio
• Dirección IP única simplifica configuración, habilita failover transparente

Balanceo de Carga en Servidores Edge

Balanceo de Carga Layer 4 (Capa de Transporte)

Distribuye conexiones TCP/UDP basándose en IP y puerto:

• Round-robin: rotar a través de servidores secuencialmente
• Least connections: enrutar a servidor con menos conexiones activas
• Source IP hash: misma IP de cliente siempre enruta a mismo servidor (session affinity sin estado)
• Health checks: TCP SYN a puerto del servidor, remover servidores no responsivos

Ventajas: Rápido, simple, funciona para todos los protocolos TCP Limitaciones: Sin visibilidad en capa HTTP, no puede enrutar por URL o headers

Balanceo de Carga Layer 7 (Capa de Aplicación)

Enruta HTTP requests basándose en datos de aplicación:

• Enrutamiento por URL path: /api/* a servidores API, /static/* a servidores de archivos estáticos
• Enrutamiento por header: Host header, headers personalizados
• Enrutamiento basado en cookies: session cookies para sticky sessions
• Enrutamiento basado en contenido: enrutar basándose en query parameters, body del request

Ventajas: Enrutamiento inteligente, health checks a nivel HTTP (GET /health retorna 200 OK) Limitaciones: Mayor latencia (debe recibir HTTP request completo), más uso de recursos

Hashing Consistente

Distribuye contenido almacenable en cache para maximizar cache hit rate:

• Hash URL del request para determinar qué servidor edge debe manejarlo
• Misma URL siempre enruta a mismo servidor (donde contenido está en cache)
• Cuando se agregan/remueven servidores, solo 1/N de URLs remapean (minimizar cache warming)
• Esencial para maximizar eficiencia de cache en clústeres edge CDN

Selección de Origin y Shielding

Balanceo de Carga Multi-Origin

Servidores edge distribuyen fetches al origin entre múltiples origins:

• Round-robin: rotar a través de servidores origin
• Least connections: enrutar a origin con menos requests activos
• Proximidad geográfica: edge en Europa prefiere origin en Europa
• Health checks: probes activos y detección pasiva de fallas

Origin Shielding

Designar ubicación edge específica como shield para protección del origin:

• Todos los edges en una región obtienen del shield, no directamente del origin
• Shield deduplica requests: 1000 edges solicitando mismo contenido = 1 request al origin
• Reduce carga del origin, mejora cache hit rate en shield
• Shield típicamente posicionado cerca del origin

Ejemplo: Edges brasileños (São Paulo, Rio) obtienen de shield en Virginia; shield de Virginia obtiene de origin en US East. Origin recibe tráfico solo de shield de Virginia, no de todos los edges brasileños.

Connection Pooling

Reutiliza conexiones TCP entre edge y origin:

• Conexiones persistentes evitan handshake TCP/TLS por request
• Pool de conexiones inactivas listas para nuevos requests
• Reduce latencia y sobrecarga del servidor
• Crítico para origins de alto tráfico

Optimización de Enrutamiento en Tiempo Real

Monitoreo de Rendimiento

CDNs miden rendimiento continuamente para informar enrutamiento:

• Monitoreo sintético: Probes activos desde edges miden RTT, ancho de banda a resolvers
• Mediciones de usuarios reales (RUM): Beacons JavaScript reportan latencia desde usuarios actuales
• Monitoreo pasivo: Tiempo de handshake TCP, tiempo de handshake TLS, first byte time desde tráfico real
• Monitoreo de salud: Health checks HTTP, probes TCP, scripts personalizados

Los datos alimentan decisiones de enrutamiento: si latencia a ubicación A incrementa, enrutar más tráfico a ubicación B.

Algoritmos de Enrutamiento Adaptativo

Machine learning y algoritmos de optimización mejoran enrutamiento:

• Aprendizaje por refuerzo: Aprender políticas de enrutamiento de resultados (latencia, errores)
• Multi-armed bandit: Explorar rutas alternativas oportunamente, explotar mejores rutas conocidas
• Optimización con restricciones: Enrutar bajo restricciones (latencia máxima, ancho de banda mínimo, presupuesto)
• Ajuste en tiempo real: Ajustar parámetros de enrutamiento basándose en condiciones actuales (picos de tráfico, outages)

CDNs actualizan tablas de enrutamiento cada pocos segundos a minutos, respondiendo a cambios de red más rápido que convergencia BGP (minutos a horas).

Enrutamiento Consciente de Costos

Optimizar enrutamiento para costo, no solo rendimiento:

• Diferentes costos de origin (servidor A más barato que servidor B)
• Diferentes costos de egress (ISP tránsito A más caro que ISP B en cierta ubicación)
• Balancear rendimiento y costo enrutando tráfico eficientemente
• Modelos de precios escalonados (primeros 10TB baratos, excedentes caros) influencian enrutamiento durante períodos de alto tráfico

Enrutamiento CDN vs Balanceo de Carga Tradicional

El enrutamiento CDN extiende principios de balanceo de carga a escala global con distribución geográfica, anycast y conciencia de contenido.

Cuándo la Optimización de Enrutamiento CDN Importa

La optimización de enrutamiento CDN importa cuando:

• Base de usuarios global requiere baja latencia worldwide
• Volúmenes de tráfico alto demandan distribución eficiente
• El contenido cambia frecuentemente (coordinación de invalidación de cache)
• Capacidad del origin limitada (origin shielding esencial)
• Múltiples origins disponibles (setups active-active, multi-cloud)
• Monitoreo de rendimiento en tiempo real necesario para QoS

Enrutamiento CDN menos crítico cuando:

• Base de usuarios en una sola región (sin distribución geográfica)
• Tráfico bajo (origin puede manejar todos los requests)
• Contenido altamente almacenable en cache con TTLs largos (edges sirven mayoría)
• Arquitectura simple sin redundancia de origin

Señales de que Necesitas Mejor Enrutamiento CDN

• Alta latencia desde ciertas regiones (pobre colocación de edge o enrutamiento)
• Origin sobrecargado (shielding ineficaz, cache misses altos)
• Distribución de carga desigual (algunos edges sobrecargados, otros subutilizados)
• Tasas de cache hit pobres (enrutamiento inconsistente previene eficiencia de cache)
• Costos incrementados del origin (excesivos fetches al origin, enrutamiento ineficiente)
• Quejas de usuarios sobre rendimiento (geo-routing incorrecto, problemas BGP)

Métricas y Medición

Métricas de Rendimiento de Enrutamiento:

• Precisión de selección de edge: Porcentaje de usuarios enrutados a edge óptimo (medir varianza de RTT)
• Tiempo de resolución DNS: Tiempo para resolver hostname del CDN (objetivo: <50ms)
• First byte time: Tiempo desde request hasta primer byte recibido (objetivo: <100ms desde edge)
• Cache hit ratio: Porcentaje de requests servidos desde cache (objetivo: >90% para contenido estático)
• Tasa de requests al origin: Requests del edge al origin (menor = mejor enrutamiento y caching)

Métricas de Eficiencia de Enrutamiento:

• Distribución geográfica: Tráfico entre regiones coincide con distribución de usuarios
• Distribución de carga: Desviación estándar de tasa de requests entre edges (bajo = balanceado)
• Ratio de atracción anycast: Tráfico a cada ubicación anycast vs. esperado
• Velocidad de failover: Tiempo para re-enrutar tráfico desde edge fallido (objetivo: <30s para DNS, <5s para anycast)
• Eficiencia de costo: Costo de egress por GB entregado (optimizar enrutamiento para costo)

Según benchmarks de rendimiento CDN (2024), enrutamiento CDN bien ajustado reduce latencia mediana en 40-60% comparado con arquitectura de origin único. Tiempo de failover de enrutamiento anycast: 10-30 segundos (convergencia BGP). Failover basado en DNS: 1-5 minutos (TTL + reintentos). Enrutamiento adaptativo en tiempo real mejora latencia en 10-20% sobre geo-routing estático.

Casos de Uso Reales

Streaming de Media Global

• Segmentos de video en cache en edges worldwide
• Enrutamiento basado en geografía envía usuarios a edge más cercana
• Hashing consistente asegura mismo segmento de video servido desde mismo edge (maximizar cache hits)
• Adaptive bitrate streaming se adapta a condiciones de red
• Origin shield deduplica requests durante releases de contenido popular (eventos de estreno)

Plataforma de E-Commerce

• Assets estáticos (imágenes de producto, CSS, JS) servidos desde cache
• Contenido dinámico (precios, carrito) enrutado a edge más cercana con fetch al origin
• Session affinity asegura consistencia del carrito del usuario entre requests
• Alta disponibilidad: failover automático durante outages del origin
• Enrutamiento geográfico: usuarios europeos enrutan a origin europeo, usuarios US a origin US

Aplicación SaaS

• API requests enrutados a edge más cercana con forward al origin
• Conexiones WebSocket enrutadas a edges específicas (stateful)
• Enrutamiento multi-tenant: diferentes clientes enrutan a diferentes origins
• Optimización de costo: enrutar tráfico a origins más baratos durante períodos de baja prioridad
• Health checks en tiempo real previenen enrutamiento a origins degradados

Arquitectura Multi-Cloud

• Origins en AWS, Google Cloud, Azure
• CDN enruta basándose en costo del origin, latencia, disponibilidad
• Failover automático entre proveedores cloud
• Enrutamiento consciente de costo durante outages de proveedor cloud o cambios de precio
• Distribución inteligente de tráfico para evitar cargos de egress cloud

Gaming y Aplicaciones en Tiempo Real

• Tráfico UDP enrutado vía anycast para path más rápido
• Servidores de estado de juego distribuidos globalmente
• Jugadores enrutados a servidor de juego más cercano (minimizar RTT para gameplay en tiempo real)
• Matchmaking enruta jugadores en misma región a mismo servidor
• Failover durante sobrecarga de servidor: distribuir a regiones cercanas

Errores Comunes y Soluciones

Error: Depender excesivamente de bases de datos geo-IP para enrutamiento Solución: Bases de datos geo-IP tienen 5-15% de tasa de error a nivel ciudad, peor para usuarios móviles. Combina geo-DNS con mediciones de latencia (RUM, probes sintéticos). Implementa ciclo de retroalimentación: medir rendimiento real, ajustar enrutamiento en consecuencia. Considera EDNS Client Subnet (ECS) para pasar prefijo IP del usuario al DNS autoritativo (tradeoff de privacidad).

Error: Establecer TTL de DNS muy alto para cambios de enrutamiento Solución: TTL más bajo para registros DNS del CDN (60-300 segundos) permite actualizaciones de enrutamiento más rápidas durante outages, rebalanceo de carga y migraciones de tráfico. Tradeoff: mayor carga de consultas DNS, ligero incremento de latencia (más lookups DNS). Usar TTL más largo para rutas estables y de buen rendimiento; TTL más corto para pruebas, migración o regiones inestables.

Error: No implementar origin shielding Solución: Habilitar origin shielding para proteger origins de thundering herd durante cache stampedes (contenido popular expira, miles de edges obtienen simultáneamente). Shield deduplica requests, reduciendo carga del origin en 10-100x para contenido popular. Posicionar shield cerca del origin para baja latencia.

Error: Ignorar hashing consistente para enrutamiento de cache Solución: Usar hashing consistente para enrutar misma URL a mismo servidor edge consistentemente. Enrutamiento random o round-robin distribuye mismo contenido entre múltiples servidores, desperdiciando espacio de cache y reduciendo hit rates. Hashing consistente asegura contenido almacenado en cache una vez por clúster, maximizando eficiencia de cache.

Error: No monitorear atracción anycast Solución: Monitorea tráfico a cada ubicación anycast. Cambios inesperados de atracción indican shifts de enrutamiento BGP, potenciales outages o problemas de traffic engineering. Configura alertas para desviación significativa de tráfico (>20% cambio). Trabaja con ISPs para ajustar atributos BGP si la distribución de tráfico es subóptima.

Error: Complejidad de enrutamiento sin observabilidad Solución: Implementa logging comprehensivo: respuesta DNS (qué IP retornada, por qué), servidor edge manejando request, decisión de enrutamiento (geo, latencia, carga), origin seleccionado. Correlaciona entre capas para resolver problemas de enrutamiento. Sin observabilidad, problemas de enrutamiento son casi imposibles de diagnosticar.

Preguntas Frecuentes

¿Cómo funciona anycast para enrutamiento CDN? Anycast asigna la misma dirección IP a servidores en múltiples ubicaciones. Cada ubicación anuncia el prefijo IP vía BGP. Routers de internet envían tráfico a la ubicación topológicamente más cercana basándose en métricas BGP. Si una ubicación falla, retira su anuncio BGP y el tráfico fluye a la siguiente más cercana. Proporciona failover automático y distribución de carga sin cambios DNS.

¿Por qué usar enrutamiento DNS en lugar de BGP anycast? Enrutamiento DNS proporciona más control: enrutar basándose en geografía, mediciones de latencia, carga del servidor, presencia de contenido. Anycast enruta basándose en métricas BGP (longitud de AS-path), que puede no reflejar rendimiento (path BGP más corto ≠ menor latencia). Muchas CDNs combinan ambos: anycast para failover y simplicidad, enrutamiento DNS para optimización inteligente.

¿Cómo manejan las CDNs la ubicación del resolver DNS vs. ubicación del usuario? Geo-DNS enruta basándose en IP del resolver, que puede no reflejar ubicación del usuario (especialmente con resolvers públicos como 8.8.8.8, 1.1.1.1). EDNS Client Subnet (ECS) pasa prefijo IP del usuario al DNS autoritativo, permitiendo enrutamiento más preciso. Tradeoff de privacidad: ECS revela subnet del usuario. Algunas CDNs usan mediciones de usuarios reales (RUM) para validar efectividad del enrutamiento.

¿Cuál es la diferencia entre balanceo de carga DNS y enrutamiento CDN? Balanceo de carga DNS retorna diferentes IPs para un dominio basándose en varios criterios. Enrutamiento CDN es balanceo de carga DNS más una red de servidores edge que almacenan contenido en cache, terminan conexiones cerca de usuarios y reenvían a origins. Enrutamiento CDN incluye BGP anycast, selección de servidor edge, selección de origin, lógica de caching—mucho más que DNS solo.

¿Qué tan rápido se adapta el enrutamiento CDN a fallas? TTL DNS + reintentos del resolver: 1-5 minutos (dependiendo de TTL y comportamiento del resolver). Retiro BGP anycast: 10-30 segundos (convergencia BGP). Remoción basada en health check: 5-30 segundos (depende de intervalo de verificación y umbral). Enrutamiento adaptivo en tiempo real: segundos a minutos (depende de frecuencia de medición). Failover multi-capa combina estos mecanismos.

¿Puede el enrutamiento CDN optimizar para costo en lugar de rendimiento? Sí. Enrutamiento consciente de costo considera costos de egress del origin, costos de tránsito, diferencias de precios regionales. Durante períodos de alto tráfico, enrutar a origins o edges más baratos. Balancear rendimiento (latencia del usuario) con costo (gasto de infraestructura). Setups multi-cloud enrutan entre AWS, Google Cloud, Azure basándose en precios actuales y descuentos de uso comprometido.

¿Cómo funciona session affinity en enrutamiento CDN? Session affinity (sticky sessions) enruta al mismo usuario al mismo servidor por la duración de la sesión. Implementado vía HTTP cookies (load balancer establece cookie, enruta basándose en cookie), hash de IP origen (hash IP del cliente a servidor), o identificador de sesión en URL. Asegura que sesiones stateful sean consistentes (carrito de compras, conexión WebSocket). Tradeoff: distribución de carga desigual si algunos usuarios generan más tráfico.

Cómo Aplica en la Práctica

El enrutamiento CDN es la capa de inteligencia que hace posible la entrega de contenido global. Entender mecanismos de enrutamiento ayuda a arquitectos a diseñar estrategias de entrega de contenido performantes, confiables y costo-efectivas.

Consideraciones de Diseño de Enrutamiento:

• Elegir enrutamiento basado en DNS para control, anycast para simplicidad y failover, o combinar ambos
• Implementar origin shielding para proteger origins de picos de tráfico
• Usar hashing consistente para contenido almacenable en cache para maximizar eficiencia de cache
• Monitorear rendimiento de enrutamiento continuamente y adaptarse a cambios de red
• Planear failover en cada capa: DNS, BGP, servidor edge, origin

Estrategias de Optimización:

• Medir latencia de usuario real, no solo probes sintéticos
• Reducir TTL DNS durante migraciones de tráfico, pruebas o períodos inestables
• Implementar health checks a múltiples capas (TCP, HTTP, personalizados)
• Usar enrutamiento consciente de costo para arquitecturas de alto tráfico, multi-origin o multi-cloud
• Ajustar atributos BGP para controlar atracción anycast

Resolución de Problemas de Enrutamiento:

• Traquear resolución DNS: dig, nslookup, herramientas de troubleshooting DNS
• Verificar rutas BGP: looking glasses, BGP route collectors
• Medir RTT desde usuario a diferentes ubicaciones edge
• Verificar cache hit rates y patrones de request al origin
• Analizar logs para decisiones de enrutamiento: qué edge, por qué, resultado de rendimiento
• Monitorear cambios de atracción anycast indicando shifts de enrutamiento

Enrutamiento CDN en Azion

Azion proporciona enrutamiento sofisticado a través de su red edge global:

• Direcciones IP anycast anunciadas desde 100+ ubicaciones edge worldwide
• Real-Time Metrics para monitorear rendimiento de enrutamiento y distribución de tráfico
• Intelligent DNS con enrutamiento geográfico y basado en latencia
• Edge Applications para enrutamiento Layer 7 basado en URL, headers, contexto geográfico
• Load Balancer para selección de origin con health checks activos
• Edge Caching con hashing consistente entre servidores edge
• Origin Shielding para proteger infraestructura backend

El enrutamiento de Azion se adapta en tiempo real a condiciones de red, salud del servidor y patrones de tráfico, asegurando rendimiento óptimo para usuarios worldwide.

Aprende más sobre Applications, Intelligent DNS y Load Balancing.

Sources

• Buyya, R., et al. “Content Delivery Networks: Status and Trends.” IEEE Internet Computing, 2008.
• Nygren, E., et al. “The Akamai Network: A Platform for High-Performance Internet Applications.” ACM SIGOPS, 2010.
• Candela, M., et al. “On the Performance of Anycast in DNS-based CDNs.” IMC ‘19.
• BGP Routing Tables. “CIDR Report.” https://www.cidr-report.org/
• RIPE NCC. “DNS Monitoring.” https://dnsmon.ripe.net/