¿Qué son los servidores de origen?

Los servidores de origen almacenan o generan la versión autoritativa del contenido. Las cachés y las redes de entrega de contenido recuperan ese contenido del origen cuando no pueden satisfacer una solicitud localmente.

HTTP define un servidor de origen como un programa que puede generar respuestas autoritativas para un recurso de destino determinado. En una arquitectura de entrega, es el componente situado más arriba al que contacta una CDN o un proxy inverso cuando no tiene una respuesta almacenada que pueda reutilizar: un almacén de objetos, un servidor web, un empaquetador que ensambla manifiestos o un servicio que genera derivados bajo demanda. Para el cliente, la propia CDN parece ser el servidor de origen; HTTP llama a ese intermediario pasarela o proxy inverso. Los períodos de vigencia, los validadores, las claves de caché y la compatibilidad con rangos determinan cuántas solicitudes llegan al origen, y un objeto muy solicitado que vence o que nunca se ha almacenado en caché puede concentrar allí esas solicitudes. El término no está relacionado con un origen web, la combinación de esquema, host y puerto que los navegadores utilizan para la política de mismo origen y CORS.

¿Todo objeto vencido tiene que descargarse de nuevo del origen? No si el origen envía validadores. Una caché que conserva una respuesta vencida puede realizar una solicitud condicional usando el ETag almacenado (en If-None-Match) o la fecha Last-Modified (en If-Modified-Since), y un origen cuyo contenido no ha cambiado responde con 304 (Not Modified) sin enviar la representación de nuevo. El origen sigue teniendo que recibir y responder cada solicitud de validación que se le reenvía, por lo que los validadores reducen los bytes transferidos, pero no reducen por sí solos el número de solicitudes.
¿Cómo evito que muchas ubicaciones de borde recuperen cada una el mismo objeto? Enruta sus solicitudes sin acierto de caché a través de una capa de caché compartida delante del origen. Sin ella, cada ubicación de caché que no encuentre el contenido puede enviar su propia solicitud para obtenerlo. Amazon CloudFront Origin Shield, la protección del origen mediante caché de Fastly y Cloudflare Smart Tiered Cache dirigen esas solicitudes a través de una capa superior designada; la topología Generic Global de Cloudflare, en cambio, selecciona capas superiores de grupos regionales. CloudFront y Fastly también combinan solicitudes concurrentes del mismo objeto no almacenado en caché en tan solo una solicitud al origen. Fastly señala un límite: si resulta que la respuesta no se puede almacenar en caché, por ejemplo, porque es privada de un usuario, cada solicitud en espera debe enviarse entonces al origen de forma independiente. AWS indica que Origin Shield puede no ser adecuado para contenido dinámico que se envía al origen mediante un proxy, contenido con poca capacidad de almacenamiento en caché o contenido que se solicita con poca frecuencia, y que se cobra por separado.
¿Qué reciben los espectadores mientras el origen no está disponible? Las respuestas que siguen vigentes en una caché se continúan sirviendo. Para las vencidas, la regla de HTTP establece que una caché no debe servirlas a menos que esté desconectada o tenga permiso explícito para hacerlo, y en ningún caso cuando la respuesta incluya no-cache o must-revalidate o, para una caché compartida como una CDN, proxy-revalidate o s-maxage. Cuando no se aplica ninguna de esas directivas, la directiva stale-if-error de la RFC 5861 concede el permiso cuando el origen devuelve un 500, 502, 503 o 504, o no se puede contactar con él. Su valor limita cuánto tiempo puede llevar vencida la respuesta, contado desde el momento en que venció y no desde el inicio de la interrupción: con max-age=600, stale-if-error=1200, la respuesta puede usarse en caso de error hasta que tenga una antigüedad total de 1800 segundos. Para cubrir un mantenimiento planificado, el valor tiene que abarcar el tiempo transcurrido desde el vencimiento más la interrupción. El comportamiento de las CDN difiere en los detalles: CloudFront documenta que aplica stale-if-error cuando no se puede contactar con el origen o este devuelve un estado 5xx, hasta el valor de la directiva o su TTL máximo, lo que sea menor, y que, sin la directiva, sigue sirviendo un objeto vencido que conserva cuando el origen devuelve un estado 5xx. Ningún ajuste ayuda con un objeto que nunca se almacenó en caché o que ya no está almacenado, y CloudFront indica que podría expulsar de la caché un objeto poco solicitado mientras el origen sigue fallando.
¿Puede un origen que funciona correctamente entregar la variante equivocada a través de una CDN? Sí, cuando la respuesta depende de algo que la caché no incluye en su clave. HTTP establece dos reglas: una respuesta almacenada con un encabezado Vary solo puede reutilizarse para solicitudes cuyos campos de encabezado indicados coincidan, y una caché compartida no debe reutilizar la respuesta a una solicitud que incluía Authorization a menos que la respuesta lo permita explícitamente. Una CDN no necesariamente aplica la regla de Vary tal como está escrita: Cloudflare documenta que, de forma predeterminada, no considera los valores de Vary en las decisiones de almacenamiento en caché y solo los respeta para Vary: Accept-Encoding o cuando se ha configurado un ajuste de Vary. Así que confirma que tu CDN respeta los encabezados nombrados en Vary, o añádelos tú a su clave de caché. Lo mismo se aplica a cualquier otra entrada que cambie la respuesta, como una cookie o un parámetro de consulta que la CDN esté configurada para ignorar: añádela a la clave de caché o marca la respuesta como no almacenable en caché.
¿Los clientes pueden omitir la CDN y enviar solicitudes directamente al origen? Pueden hacerlo si el origen es accesible públicamente y su dirección llega a conocerse, lo que evita la caché y las protecciones de la CDN. La guía de Cloudflare enumera las opciones: permitir solo los rangos de IP de la CDN (que considera moderadamente seguros y vulnerables a la suplantación de IP), exigir un encabezado de solicitud secreto, autenticar la CDN con un certificado de cliente TLS (Authenticated Origin Pulls) o conectarse a través de un túnel exclusivamente saliente para que el origen no tenga una dirección enrutable públicamente. Para los orígenes de Amazon S3, AWS enumera tres tareas: crear un control de acceso al origen de CloudFront, que firma las solicitudes de CloudFront al bucket, y asociarlo con la distribución; darle permiso para leer los archivos, algo que la documentación hace con una política de bucket limitada a esa distribución; y eliminar el permiso para que cualquier otra persona lea los archivos mediante URL de Amazon S3. La firma por sí sola deja accesible un bucket con lectura pública.

Configura un origen para exponer solo los activos y las operaciones que requiere la CDN. La lentitud o las interrupciones del origen retrasan las respuestas a solicitudes cuyo contenido no está en caché, las revalidaciones y la entrega de contenido que no puede almacenarse en caché, porque las cachés perimetrales no pueden responder a esas solicitudes localmente. Los objetos que siguen vigentes en la caché perimetral pueden seguir sirviéndose.

Con Smart CDN de Transloadit hay dos capas anteriores a la CDN. Tus archivos originales permanecen en tu propio almacenamiento, como un bucket de Amazon S3, y un Template los importa desde allí. Cuando la CDN no tiene una copia en caché para una URL solicitada, Transloadit ejecuta el Template y el Robot /file/serve entrega el resultado a la CDN, de modo que la ejecución del Template cumple la función de origen para tlcdn.com y tu bucket es la fuente que está detrás. /file/serve establece el encabezado Cache-Control en esa respuesta; su parámetro cache_duration establece tanto max-age como s-maxage, lo que determina con qué frecuencia las solicitudes vuelven al Template y a tu almacenamiento.

La documentación de /file/serve desaconseja usarlo sin una CDN delante, porque cada solicitud no almacenada en caché volvería a ejecutar la transformación. Las páginas enlazadas aquí no describen qué se sirve si tu almacenamiento no está disponible cuando el contenido no se encuentra en la caché, ni si se puede seguir sirviendo un resultado caducado.

Explora las capacidades de entrega de Transloadit

¿Qué son los servidores de origen?

Cómo funcionan los servidores de origen

Datos clave

Cuándo son importantes los servidores de origen

Cómo ayuda Transloadit con los servidores de origen

Fuentes

Convierte tus conocimientos sobre multimedia en un pipeline funcional