¿Qué es un servidor perimetral?

Un servidor perimetral atiende las solicitudes cerca de los usuarios finales en lugar de hacerlo únicamente en un origen central. Puede almacenar contenido en caché o realizar tareas de enrutamiento, transformación, autenticación y cómputo en una ubicación de una red distribuida.

En términos de HTTP, un servidor perimetral es un proxy inverso, al que RFC 9110 denomina puerta de enlace: ante el cliente actúa como servidor de origen y reenvía a otro servidor las solicitudes que no puede responder por sí mismo. Los operadores de CDN ejecutan muchos de estos servidores, agrupados en ubicaciones que Fastly denomina puntos de presencia (POP) y Cloudflare denomina centros de datos. Un cliente llega a una de esas ubicaciones porque DNS devuelve una dirección elegida para ese cliente o porque se anuncia la misma dirección anycast desde todas las ubicaciones y el enrutamiento de red elige una. El servidor perimetral responde entonces desde su caché, ejecuta la lógica configurada para las solicitudes o reenvía la solicitud hacia el origen. Una respuesta almacenada en caché en una ubicación no se almacena automáticamente en las demás, y el siguiente destino de una solicitud que no encuentra respuesta en la caché depende de la CDN y su configuración: directamente el origen o primero una caché de nivel superior, como un POP de protección de Fastly, un nivel superior de Tiered Cache de Cloudflare o una caché perimetral regional de Amazon CloudFront.

¿El servidor perimetral más cercano siempre atiende la solicitud? No. Con anycast, el sistema de enrutamiento elige la ubicación según la topología de la red, y RFC 4786 señala que la cercanía topológica no suele guardar relación con el rendimiento de ida y vuelta. Con la selección basada en DNS, el servidor DNS autoritativo de la CDN ve la dirección del resolvedor recursivo (el servidor DNS que busca nombres en nombre del usuario) en lugar de la dirección del propio usuario, a menos que el resolvedor reenvíe una subred del cliente, que es una forma truncada de la dirección del usuario. Por tanto, una persona que use un resolvedor distante puede ser enviada a una ubicación cercana al resolvedor.
¿Una respuesta almacenada en caché en una ubicación perimetral está disponible en todas? No automáticamente: una ubicación que no haya almacenado la respuesta tendrá un fallo de caché, y el siguiente destino de esa solicitud depende de la CDN y su configuración. Los POP de Fastly reenvían las solicitudes al origen de forma independiente, a menos que el mecanismo de protección de origen las envíe a través de un único POP de protección, y Tiered Cache de Cloudflare hace que un centro de datos de nivel inferior consulte a uno de nivel superior antes que al origen. Amazon CloudFront tiene un nivel de este tipo de forma predeterminada: un POP con un fallo de caché suele consultar a una caché perimetral regional, que puede tener ya el objeto. Ninguno de estos niveles garantiza qué solicitudes llegan al origen. Cloudflare aplica Tiered Cache solo a las solicitudes que pueden almacenarse en caché, CloudFront envía las solicitudes dinámicas y los métodos como POST directamente del POP al origen, y Fastly aconseja que el código de Compute recurra al origen cuando el POP de protección no esté disponible.
¿Qué código puede ejecutarse en un servidor perimetral? Depende del producto y de la etapa de la solicitud a la que esté asociado el código, así que compruébalo antes de diseñar una solución que dependa de ello. Amazon CloudFront documenta dos opciones: CloudFront Functions para tareas ligeras como normalizar claves de caché, cambiar cabeceras, realizar redirecciones y validar tokens, sin acceso a la red ni al cuerpo de la solicitud; y Lambda@Edge para funciones que necesitan acceso a la red, bibliotecas de terceros o el cuerpo de la solicitud. La organización por niveles también puede cambiar la frecuencia con la que se ejecuta el código: con el mecanismo de protección de origen de Fastly, el código perimetral suele ejecutarse dos veces, una en el primer POP y otra en el POP de protección, por lo que la lógica que reescribe una solicitud o añade una cabecera debe poder ejecutarse dos veces de forma segura.
¿Validar una URL firmada en el perímetro protege el origen? Solo para las solicitudes que pasan por el perímetro. CloudFront documenta dos controles independientes: las URL firmadas o las cookies firmadas restringen el acceso a los archivos de las cachés perimetrales, mientras que el acceso al origen debe restringirse por separado para que los clientes no puedan eludir la CDN y obtener los archivos directamente desde él. Para un origen S3, eso significa otorgar a un control de acceso al origen permiso para leer el bucket y retirar a todos los demás el permiso para leer los archivos mediante URL de S3. Para un origen personalizado, significa usar una cabecera personalizada que CloudFront añade a las solicitudes al origen y que el origen exige, con HTTPS tanto en la conexión del espectador como en la del origen para que la cabecera esté cifrada en tránsito. Las recomendaciones de AWS para orígenes con balanceadores de carga añaden que esto funciona solo mientras el nombre y el valor de la cabecera se mantengan en secreto, y recomiendan cambiarlos periódicamente. Por separado, si los clientes se autentican con una cabecera Authorization en lugar de una URL firmada, RFC 9111 prohíbe que una caché compartida reutilice la respuesta para una solicitud posterior, a menos que la respuesta lo permita mediante public, s-maxage o must-revalidate.

Los servidores perimetrales son especialmente importantes cuando muchos clientes alejados del origen solicitan la misma respuesta: un acierto de caché se responde en la ubicación perimetral y la solicitud nunca llega al origen. Una solicitud que el servidor perimetral no puede responder con una respuesta almacenada se procesa cuando llega, ya sea en el origen, en cuyo caso sigue viajando hacia él, o mediante lógica perimetral que genera la respuesta por sí misma. En ese caso, el servidor perimetral aporta enrutamiento, filtrado o lógica de solicitudes en lugar de una copia almacenada. Cuando diseñes una solución que dependa de uno, ten en cuenta la ruta que siguen las solicitudes con fallos de caché, las cachés que se llenan por separado en cada ubicación y las solicitudes que llegan al origen sin pasar por el perímetro.

Smart CDN de Transloadit sitúa el almacenamiento en caché perimetral delante del procesamiento bajo demanda. Una solicitud a una URL de tlcdn.com se responde desde el perímetro cuando existe una copia en caché. Si hay un fallo de caché, la solicitud ejecuta tu Template como una Assembly, el Robot /file/serve elige el resultado que se devolverá y establece su cabecera Cache-Control, y /tlcdn/deliver almacena en caché y entrega ese resultado cerca de tus usuarios.

Las páginas enlazadas describen el almacenamiento en caché y la entrega en el perímetro y el procesamiento en una Assembly. No documentan un entorno de ejecución para ejecutar tu propio código en el perímetro. Una URL de Smart CDN puede incluir opcionalmente una fecha de vencimiento y una firma; si después se cambia la URL o sus parámetros, la firma deja de coincidir. Eso impide que terceros modifiquen la URL solo cuando se rechazan las solicitudes sin firma, y las páginas enlazadas tampoco indican cómo se trata una solicitud sin firma al mismo Template, así que compruébalo en tu propio Workspace antes de confiar en ese comportamiento. Transloadit describe Smart CDN como una capa de transformación y entrega que no sustituye la política de autorización de tu aplicación.

Explora las capacidades de entrega de Transloadit

¿Qué es un servidor perimetral?

Cómo funcionan los servidores perimetrales

Datos clave

Cuándo son importantes los servidores perimetrales

Cómo ayuda Transloadit con los servidores perimetrales

Fuentes

Convierte tus conocimientos sobre multimedia en un pipeline funcional