¿Qué es un servidor perimetral de CDN?

Un servidor perimetral de CDN es un nodo de una red distribuida que sirve contenido almacenado en caché o retransmitido mediante un proxy desde una ubicación relativamente cercana a quien lo solicita. También puede aplicar políticas de enrutamiento, acceso o transformación en el perímetro de la red.

Un servidor perimetral es el punto de atención de solicitudes que se selecciona entre las ubicaciones distribuidas de una CDN para un cliente y un momento determinados. Actúa como punto de terminación de la conexión, evalúa la configuración perimetral, comprueba el estado de la caché local o jerárquica y responde o contacta con un nivel superior. Como el enrutamiento y los objetos almacenados en caché dependen de la ubicación, las URL idénticas pueden presentar distintas latencias, antigüedades o comportamientos ante fallos según la región.

El enrutamiento determina qué nodo perimetral gestiona una solicitud, no la distancia en un mapa. Amazon CloudFront utiliza DNS para dirigir al usuario a la ubicación que mejor puede atender la solicitud, normalmente la más cercana en términos de latencia. Cloudflare responde a las consultas DNS con una dirección anycast y, con anycast, el sistema de enrutamiento de Internet elige el nodo según la topología de la red y el punto por el que entra la solicitud. La selección basada en DNS suele ver la dirección del resolvedor recursivo del usuario, que, como señala el RFC 7871, puede estar lejos del usuario cuando se utiliza un resolvedor centralizado. Por tanto, una solicitud puede llegar a una ciudad o un país distintos de los esperados, y dos usuarios que están en el mismo lugar pero en redes distintas pueden llegar a nodos perimetrales diferentes.
Un fallo de caché en un nodo perimetral no siempre genera una solicitud al origen. Las ubicaciones perimetrales de CloudFront suelen consultar una caché perimetral regional antes de recurrir al origen, y Origin Shield añade otra capa; la caché por niveles de Cloudflare permite que solo los centros de datos del nivel superior contacten con el origen; la protección mediante un nodo de resguardo de Fastly canaliza las solicitudes a través de una ubicación de resguardo designada. Estos niveles son condicionales. Es necesario habilitar Origin Shield, la caché por niveles y la protección mediante un nodo de resguardo. CloudFront encamina las solicitudes dinámicas y las que usan métodos como POST sin pasar por las cachés perimetrales regionales, aunque AWS indica que, cuando Origin Shield está habilitado, sigue estando en la ruta de las solicitudes dinámicas. Cloudflare aplica la caché por niveles solo a las solicitudes que cumplen los requisitos para usar la caché en el momento de la solicitud. Cuando una solicitud pasa por un nivel superior, el origen ve ese nivel y no el nodo perimetral al que llegó el usuario, por lo que los registros del origen por sí solos no muestran qué nodo perimetral atendió al usuario. En Cloudflare, por ejemplo, el valor de Cf-Ray enviado al origen identifica entonces el centro de datos que se conectó al origen.
Los encabezados de respuesta y los registros pueden mostrar qué nodo perimetral respondió y si se produjo un acierto de caché, pero los nombres dependen del proveedor. El encabezado de respuesta Cf-Ray de Cloudflare termina con un código de centro de datos de tres letras, y CF-Cache-Status indica el resultado de la caché. En Fastly, X-Served-By identifica los servidores de caché y X-Cache informa HIT o MISS. Con la protección mediante un nodo de resguardo habilitada, la respuesta habitual muestra dos entradas, primero la del nodo de resguardo y después la del nodo perimetral que atiende al usuario. Cuando hay un acierto en el nodo perimetral, la entrada del nodo de resguardo corresponde al momento en que el objeto se almacenó en caché por primera vez, no a la solicitud actual. Los registros de CloudFront incluyen x-edge-location y x-edge-result-type, y su encabezado de respuesta opcional Server-Timing contiene cdn-pop y un resultado de caché: cdn-cache-hit, cdn-cache-miss o cdn-cache-refresh (una copia almacenada en caché que se sirve después de que CloudFront verifica con el origen que sigue siendo válida). Los significados también difieren: Fastly informa un paso directo sin usar la caché como MISS, y Cloudflare señala que, con la caché por niveles, el valor de Age de un acierto local puede heredarse de un nivel superior. El RFC 9211 define un encabezado común Cache-Status para este fin, pero cada caché decide si lo envía, así que normaliza los datos por proveedor antes de compararlos.
Cada ubicación tiene su propio contenido de caché y, durante un tiempo después de un cambio, posiblemente también su propia configuración. Un objeto se añade a la caché de la ubicación que atendió la solicitud, y una ubicación puede eliminar de su caché los objetos menos populares antes que otra. La frescura es independiente de la configuración: el almacenamiento en caché HTTP permite que una caché responda con una copia almacenada que aún está fresca sin contactar con el origen. Por tanto, después de que un archivo cambie en el origen, una ubicación puede seguir sirviendo la copia anterior hasta que caduque o se invalide, y el contenido de la caché no tiene por qué coincidir entre ubicaciones. Tras una actualización de la configuración, CloudFront indica que los cambios no llegan a todas las ubicaciones perimetrales al mismo tiempo y que, durante la propagación, no se puede determinar si una ubicación concreta utiliza la configuración anterior o la nueva. Por tanto, una prueba realizada desde una ubicación no muestra qué sirve otra.

Examina el comportamiento de los nodos perimetrales cuando los usuarios de una región experimentan latencia, fallos de caché o respuestas inconsistentes. Los resultados pueden diferir según la ubicación porque el enrutamiento, el estado de la caché y la propagación de la configuración varían.

Smart CDN de Transloadit sirve resultados almacenados en caché desde ubicaciones perimetrales mediante el Robot /tlcdn/deliver, que se utiliza de forma implícita para las solicitudes al dominio tlcdn.com. Cuando hay un acierto de caché, el nodo perimetral responde sin ejecutar el Template; cuando se produce un fallo de caché, primero se ejecuta la Assembly del Template, por lo que la primera solicitud de una URL que no está en caché incluye el tiempo de obtención y procesamiento del contenido de origen.

Las páginas enlazadas no enumeran las ubicaciones perimetrales ni indican los nombres de los encabezados de respuesta que identifican el nodo perimetral que sirve el contenido o el estado de su caché.

Explora las capacidades de entrega de Transloadit

¿Qué es un servidor perimetral de CDN?

Cómo funcionan los servidores perimetrales de CDN

Datos clave

Cuándo son importantes los servidores perimetrales de CDN

Cómo ayuda Transloadit con los servidores perimetrales de CDN

Fuentes

Convierte tus conocimientos sobre multimedia en un pipeline funcional