Configurar el comportamiento del almacenamiento en caché

Media CDN sirve contenido lo más cerca posible de los usuarios mediante la infraestructura de almacenamiento en caché perimetral mundial de Google para almacenar contenido en caché y reducir la carga de la infraestructura de origen.

Puedes controlar cómo se almacena en caché el contenido de cada ruta. De esta forma, puedes optimizar el comportamiento en función del tipo de contenido, los atributos de la solicitud del cliente y tus requisitos de actualización.

Almacenabilidad en caché

En las siguientes secciones se describe qué respuestas almacena en caché Media CDN y cómo mejorar la descarga de la caché.

Comportamiento predeterminado del almacenamiento en caché

De forma predeterminada, los siguientes ajustes relacionados con la caché se aplican a cada servicio de caché perimetral:

• Modo de caché predeterminado de CACHE_ALL_STATIC:

  • Respeta las directivas de caché de origen, como Cache-Control o Expires, hasta un TTL máximo configurable.
  • Almacena en caché automáticamente los tipos de contenido multimedia estático con un TTL predeterminado de 3600 s si no hay directivas de caché de origen.
  • Almacena en caché los códigos de estado HTTP 200, 204 y 206 (el almacenamiento en caché negativo no está habilitado).

• No almacena en caché las respuestas que tienen directivas de control de caché no-store o private, o que no se pueden almacenar en caché por otros motivos.

Las respuestas que no son contenido estático o que no tienen directivas de caché válidas no se almacenan en caché a menos que se configure explícitamente. Para saber cómo anular el comportamiento predeterminado, consulta la documentación sobre los modos de caché .

El comportamiento predeterminado es equivalente al siguiente cdnPolicy. Las rutas sin un cdnPolicy explícito configurado se comportan como si tuvieran la siguiente configuración:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 3600s
  cacheKeyPolicy:
    includeProtocol: false
    excludeHost: false
    excludeQueryString: false
  signedRequestMode: DISABLED
  negativeCaching: false

Respuestas que se pueden almacenar en caché

Una respuesta almacenable en caché es una respuesta HTTP que Media CDN puede almacenar y recuperar rápidamente, lo que permite que los tiempos de carga sean más rápidos. No todas las respuestas HTTP se pueden almacenar en caché.

Puedes configurar modos de caché para cada ruta y anular este comportamiento (por ejemplo, usando el modo de caché CACHE_ALL_STATIC para almacenar en caché tipos de contenido multimedia comunes) aunque el origen no defina una directiva de control de caché en la respuesta.

Las solicitudes y respuestas que cumplan los criterios definidos en respuestas no almacenables en caché tienen prioridad sobre la capacidad de almacenamiento en caché.

En la siguiente tabla se describen los requisitos para almacenar en caché respuestas HTTP concretas. Tanto las respuestas de GET como las de HEAD deben cumplir estos requisitos.

El encabezado HTTP Age se define en función de cuándo almacenó en caché Media CDN por primera vez la respuesta y, por lo general, representa los segundos transcurridos desde que se almacenó en caché el objeto en una ubicación de protección del origen. Si tu origen genera un encabezado de respuesta Age, usa el modo de caché FORCE_CACHE_ALL para evitar las revalidaciones cuando Age supere el TTL de la caché.

Para obtener más información sobre cómo interpreta Media CDN las directivas de almacenamiento en caché HTTP, consulta Directivas de control de caché.

Requisitos de origen

Para permitir que Media CDN almacene en caché respuestas de origen de más de 1 MiB, un origen debe incluir lo siguiente en los encabezados de respuesta de las solicitudes HEAD y GET, a menos que se especifique lo contrario:

• Un encabezado de respuesta HTTP Last-Modified o ETag (un validador).
• Un encabezado HTTP Date válido.
• Un encabezado Content-Length válido.
• Encabezado de respuesta Content-Range en respuesta a una solicitud Range GET. El encabezado Content-Range debe tener un valor válido con el formato bytes x-y/z (donde z es el tamaño del objeto).

El protocolo de origen predeterminado es HTTP/2. Si tus orígenes solo admiten HTTP/1.1, puedes definir el campo de protocolo explícitamente para cada origen.

Respuestas que no se pueden almacenar en caché

En la siguiente tabla se detallan los atributos de solicitud y respuesta que impiden que se almacene en caché una respuesta. Las respuestas que se pueden almacenar en caché, pero que coinciden con criterios de "no se puede almacenar en caché", no se almacenan en caché.

Estas reglas se aplican además del modo de caché configurado. En concreto, este cambio afecta a las siguientes acciones:

• Si el modo de caché CACHE_ALL_STATIC está configurado, solo se almacenan en caché las respuestas que se consideran contenido estático o las respuestas con directivas de caché válidas en sus encabezados de respuesta. Las demás respuestas se envían tal cual a través de un proxy.
• El modo de caché FORCE_CACHE_ALL almacena en caché todas las respuestas incondicionalmente, de acuerdo con los requisitos de no almacenamiento en caché indicados anteriormente.
• El modo de caché USE_ORIGIN_HEADERS requiere que las respuestas definan directivas de caché válidas en sus encabezados de respuesta, además de tener un código de estado que se pueda almacenar en caché.

Notas:

• Las respuestas que no se almacenan en caché no tienen sus directivas de control de caché ni otros encabezados modificados y se proxyizan tal cual.
• Las respuestas pueden tener los encabezados Cache-Control y Expires contraídos en un solo campo Cache-Control. Por ejemplo, una respuesta con Cache-Control: public y Cache-Control: max-age=100 en líneas separadas se contraería como Cache-Control: public,max-age=100.
• Las respuestas que no se pueden almacenar en caché (respuestas que nunca se almacenarían en caché) no se contabilizan como Cache Egress desde el punto de vista de la facturación.

Usar modos de caché

Los modos de caché le permiten configurar cuándo debe respetar Media CDN las directivas de caché del origen, almacenar en caché los tipos de contenido multimedia estático y almacenar en caché todas las respuestas del origen, independientemente de las directivas definidas.

Los modos de caché se configuran a nivel de ruta y, combinados con las anulaciones de TTL, te permiten configurar el comportamiento de la caché por host, ruta, parámetros de consulta y encabezados (cualquier parámetro de solicitud que se pueda asociar).

• De forma predeterminada, Media CDN usa el modo de caché CACHE_ALL_STATIC, que almacena en caché automáticamente los tipos de contenido multimedia estático habituales durante 1 hora (3600 segundos), al tiempo que prioriza las directivas de caché especificadas por el origen para las respuestas almacenables en caché.
• Puedes aumentar o reducir el tiempo de vida en la caché aplicado a las respuestas sin un tiempo de vida en la caché explícito (una directiva max-age o s-maxage) definiendo el campo cdnPolicy.defaultTtl en una ruta.
• Para evitar que se almacenen en caché respuestas que no sean correctas durante más tiempo del previsto, los códigos de estado que no sean 2xx (es decir, que no sean correctos) no se almacenan en caché según su Content-Type (tipo MIME) y no tienen aplicado el TTL predeterminado.

Los modos de caché disponibles, que se definen en el cdnPolicy.cacheMode de cada ruta, se muestran en la siguiente tabla.

Tipos MIME de contenido estático

El modo de caché CACHE_ALL_STATIC permite a Media CDN almacenar en caché automáticamente contenido estático habitual, como vídeo, audio, imágenes y recursos web comunes, en función del tipo MIME devuelto en el encabezado de respuesta HTTP Content-Type. Sin embargo, independientemente del tipo de contenido multimedia, Media CDN prioriza los encabezados Cache-Control o Expires explícitos en la respuesta del origen.

En la siguiente tabla se enumeran los tipos MIME que se pueden almacenar en caché automáticamente con el modo de caché CACHE_ALL_STATIC.

Las respuestas no se almacenan automáticamente en caché si no tienen un encabezado de respuesta Content-Type con un valor que coincida con los siguientes valores. Debe asegurarse de que la respuesta defina una directiva de caché válida o de usar el modo de caché FORCE_CACHE_ALL para almacenar en caché las respuestas de forma incondicional.

Ten en cuenta lo siguiente:

• El software del servidor web de tu origen debe definir Content-Type para cada respuesta. Muchos servidores web definen automáticamente la cabecera Content-Type, como NGINX, Varnish y Apache.
• Cloud Storage define el encabezado Content-Type automáticamente al subir contenido cuando se usa la Google Cloud consola o la CLI de gcloud.
• Cloud Storage siempre proporciona un encabezado Cache-Control a Media CDN. Si no se elige ningún valor explícitamente, se envía un valor predeterminado. Por lo tanto, todas las respuestas correctas de Cloud Storage se almacenan en caché según los valores predeterminados de Cloud Storage, a menos que ajuste explícitamente los metadatos de control de caché de los objetos de Cloud Storage o utilice el modo FORCE_CACHE_ALL para anular los valores enviados por Cloud Storage.

Si una respuesta se puede almacenar en caché en función de su tipo MIME, pero tiene una directiva de respuesta Cache-Control de private o no-store, o un encabezado Set-Cookie, no se almacena en caché.

Otros tipos de contenido multimedia, como HTML (text/html) y JSON (application/json), no se almacenan en caché de forma predeterminada. Estos tipos de respuestas suelen ser dinámicos (por usuario) y tampoco se adaptan bien a la arquitectura de Media CDN. Te recomendamos que uses Cloud CDN para servir recursos web y almacenar en caché las respuestas de las APIs.

Configurar los TTLs de la caché

Las anulaciones del tiempo de vida (TTL) te permiten definir valores de TTL predeterminados para el contenido almacenado en caché y anular los valores de TTL definidos en las directivas de control de caché max-age y s-maxage (o en los encabezados Expires) definidos por tus orígenes.

Los TTLs, ya se definan mediante anulaciones o con una directiva de caché, son optimistas. El contenido al que se accede con poca frecuencia o que no es popular puede eliminarse de la caché antes de que se alcance el TTL.

En la siguiente tabla se muestran tres ajustes de TTL.

Si asignas el valor cero (0 segundos) a cualquier TTL, se volverá a validar cada solicitud con el origen antes de que se proporcione una respuesta, lo que aumentará la carga del origen si se asigna de forma demasiado general.

Cuando el modo de caché es Use Origin Headers, no se pueden configurar los ajustes de TTL porque Media CDN depende del origen para determinar el comportamiento.

Notas:

• El valor de TTL máximo siempre debe ser mayor (o igual) que el valor de TTL predeterminado.
• El valor de TTL del cliente siempre debe ser inferior (o igual) al valor de TTL máximo.
• Cuando Media CDN anula un valor de TTL de origen, el encabezado Cache-Control del cliente también refleja ese valor.
• Si el origen define un encabezado Expires y Media CDN anula el TTL efectivo (en función de la marca de tiempo), el encabezado Expires se sustituye por un encabezado Cache-Control en la respuesta de nivel inferior al cliente.

Almacenamiento en caché negativo

El almacenamiento en caché negativo define cómo Media CDN almacena en caché los códigos de estado HTTP que no son correctos (es decir, los que no pertenecen a la categoría 2xx).

Esto le permite almacenar en caché las respuestas de error, como las redirecciones (HTTP 301 y 308) y las respuestas de no encontrado (HTTP 404), más cerca de los usuarios, así como reducir la carga del origen de forma más general si es poco probable que la respuesta cambie y se pueda almacenar en caché.

De forma predeterminada, el almacenamiento en caché negativo está inhabilitado. En la siguiente tabla se muestran los valores predeterminados de cada código de estado cuando se habilita el almacenamiento en caché negativo y no se usa negativeCachingPolicy.

El conjunto predeterminado de códigos de almacenamiento en caché negativo coincide con los códigos de estado que se pueden almacenar en caché de forma heurística y que se describen en HTTP RFC 9110, con las siguientes excepciones:

• No se admite el código HTTP 414 (URI demasiado largo) para el almacenamiento en caché, con el fin de evitar el envenenamiento de la caché.
• Se admite el código HTTP 451 (Unavailable for Legal Reasons) para el almacenamiento en caché, tal como se describe en HTTP RFC 7725.

Si necesitas configurar tus propios TTLs por código de estado y anular el comportamiento predeterminado, puedes configurar un cdnPolicy.negativeCachingPolicy. Esto le permite definir el TTL de cualquiera de los códigos de estado permitidos por Media CDN: 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451, 500, 501, 502, 503 y 504.

Por ejemplo, para definir un TTL corto de 5 segundos para las respuestas HTTP 404 (No encontrado) y un TTL de 10 segundos para las respuestas HTTP 405 (Método no permitido), usa la siguiente definición de YAML en cada ruta aplicable:

cdnPolicy:
  negativeCaching: true
  negativeCachingPolicy:
    "404": 5s
    "405": 10s
  # other status codes to apply TTLs for

Para evitar el envenenamiento de caché, no recomendamos habilitar el almacenamiento en caché para los códigos de estado 400 (Solicitud incorrecta) o 403 (Prohibido). Asegúrate de que tu servidor de origen devuelva uno de los dos códigos como resultado de examinar solo los componentes de la solicitud que se incluyen en la clave de caché. El envenenamiento de caché puede producirse, por ejemplo, cuando el servidor de origen responde con un error 403 si no hay una cabecera Authorization correcta. En este caso, si se almacena en caché la respuesta de error 403, Media CDN servirá la respuesta de error 403 a todas las solicitudes posteriores hasta que caduque el TTL, aunque las solicitudes tengan un encabezado Authorization correcto.

Para inhabilitar el almacenamiento en caché negativo, sigue estos pasos:

• Para inhabilitar el comportamiento predeterminado del almacenamiento en caché negativo, asigna el valor cdnPolicy.negativeCaching: false a una ruta. Ten en cuenta que las respuestas de origen con directivas de caché válidas y códigos de estado almacenables en caché se siguen almacenando en caché.
• Para evitar el almacenamiento en caché negativo de un código de estado específico, pero seguir respetando las directivas de caché de origen, omite el código de estado (cdnPolicy.negativeCachingPolicy[].code) en tu definición de negativeCachingPolicy.
• Para ignorar explícitamente las directivas de la caché de origen de un código de estado específico, asigna el valor 0 (cero) a cdnPolicy.negativeCachingPolicy[].ttl para ese código de estado.

Notas:

• Si negativeCaching está habilitado en una ruta y una respuesta define directivas de caché válidas, las directivas de caché de la respuesta tienen prioridad.
• Si configura un negativeCachingPolicy explícito y hay un TTL definido para el código de estado en cuestión, siempre se usará el TTL definido en la política.
• El valor máximo de un TTL definido por negativeCachingPolicy es de 1800 segundos (30 minutos), pero se respetan las directivas de caché de origen con un TTL superior.
• Si el modo de caché se configura como FORCE_CACHE_ALL, las directivas de origen se ignoran en todos los casos.

Directivas de control de caché

Aquí se define el comportamiento de Media CDN con respecto a las directivas Cache-Control.

Si la directiva no se aplica a una solicitud o respuesta, como only-if-cached (una directiva solo para clientes), se marca "N/A" en esa columna.

Siempre que sea posible, Media CDN cumple el RFC (HTTP RFC 7234), pero prioriza la optimización de la descarga de la caché y minimiza el impacto que pueden tener los clientes en la tasa de aciertos y en la carga general del origen.

En las respuestas que usan el encabezado Expires de HTTP/1.1:

• El valor del encabezado Expires debe ser una fecha HTTP válida, tal como se define en RFC 7231.
• Si se indica una fecha pasada, una fecha no válida o el valor 0, significa que el contenido ya ha caducado y debe volver a validarse.
• Media CDN ignora el encabezado Expires si hay un encabezado Cache-Control en la respuesta.

El encabezado Pragma de HTTP/1.0, si está presente en una respuesta, se ignora y se envía tal cual al cliente.

Claves de caché

Para reducir el número de veces que Media CDN necesita ponerse en contacto con su origen, puede determinar qué identifica de forma única una solicitud y eliminar los componentes que suelen cambiar entre solicitudes. El conjunto de componentes de la solicitud se suele denominar "clave de caché".

En las siguientes secciones se describe cómo configurar las claves de caché.

Componentes de clave de caché

Una clave de caché es el conjunto de parámetros de solicitud (como el host, la ruta y los parámetros de consulta) por el que se hace referencia a un objeto almacenado en caché.

De forma predeterminada, las claves de caché de los servicios de caché perimetral incluyen el host, la ruta y los parámetros de consulta de la solicitud, y se limitan a un EdgeCacheService específico.

Ten en cuenta lo siguiente:

• Las claves de caché no están asociadas a un origen configurado, lo que le permite actualizar una configuración de origen (o sustituir el origen por completo) sin riesgo de "purgar" la caché (por ejemplo, al migrar el almacenamiento de origen entre proveedores).
• Las claves de caché están restringidas a un EdgeCacheService. Los distintos EdgeCacheServices tienen espacios de nombres de caché diferentes, lo que evita que almacenes en caché objetos por error entre los entornos de producción, de staging y otros entornos de prueba, aunque coincidan el host, la ruta u otros componentes de la clave de caché. Al eliminar un EdgeCacheService, se invalidan todos los objetos almacenados en caché de ese servicio.
• Las claves de caché no se limitan a una ruta concreta. Es posible que varias rutas hagan referencia a la misma clave de caché, sobre todo si esas rutas coinciden en componentes que no se incluyen en la clave de caché, como los encabezados de solicitud o los parámetros excluidos. Esto puede ser útil si quieres que varias rutas compartan la misma caché, pero que devuelvan encabezados de respuesta o una configuración de CORS diferentes.
• Las claves de caché no incluyen la configuración de reescritura de URLs. Por ejemplo, una clave de caché se basa en la solicitud visible para el usuario y no en la solicitud "reescrita" final.
• Cuando se configuran solicitudes firmadas en una ruta, los atributos firmados no se incluyen en la clave de caché. La solicitud se trata como si los parámetros de consulta (firmados) o el componente de ruta, que empiezan por edge-cache-token y terminan en el siguiente separador de ruta ("/"), no formaran parte de la URL.

Incluir o excluir parámetros de consulta

Puedes incluir o excluir parámetros de consulta específicos de una clave de caché añadiendo el nombre del parámetro a la configuración de la clave de caché includedQueryParameters o excludedQueryParameters de una ruta determinada.

Por ejemplo, para incluir los parámetros de consulta contentID y country e ignorar todos los demás de la clave de caché, haga lo siguiente:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 86400s
  cacheKeyPolicy:
    includedQueryParameters: ["contentID", "country"]

Asegúrate de incluir los parámetros de consulta que identifiquen el contenido de forma única y de excluir los que no lo hagan. Por ejemplo, excluya los parámetros de consulta de analíticas, los IDs de sesión de reproducción u otros parámetros que solo sean únicos para el cliente. Si incluye más parámetros de consulta de los necesarios, puede reducir los porcentajes de aciertos de caché.

También puede elegir qué parámetros quiere excluir de la clave de caché en lugar de especificar cuáles quiere incluir. Por ejemplo, para excluir el ID de reproducción y la información de la marca de tiempo específicos del cliente de la clave de caché, configura lo siguiente:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 86400s
  cacheKeyPolicy:
    excludedQueryParameters: ["playback-id", "timestamp"]

En una ruta determinada, puedes especificar includedQueryParameters o excludedQueryParameters.

Si los parámetros de consulta nunca se usan para identificar contenido de forma única en las solicitudes, puede quitar todos los parámetros de consulta de la clave de caché de una ruta. Para ello, define excludeQueryString como true, tal como se indica a continuación:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 3600s
  cacheKeyPolicy:
    excludeQueryString: true

Si la opción Solicitudes firmadas está habilitada en una ruta, los parámetros de consulta que se usan para firmar no se incluyen en la cadena de consulta y se ignoran si se incluyen. Al incluir los parámetros firmados en la clave de caché, cada solicitud de usuario es única y requiere que cada solicitud se sirva desde el origen.

Ordenación por parámetro de consulta

Los parámetros de consulta (cadenas de consulta) se ordenan de forma predeterminada para mejorar las tasas de aciertos de caché, ya que los clientes pueden reordenar o solicitar el mismo objeto almacenado en caché con un orden diferente de parámetros de consulta.

Por ejemplo, los parámetros de consulta b=world&a=hello&z=zulu&p=paris y p=paris&a=hello&z=zulu&b=world se ordenan como a=hello&b=world&p=paris&z=zulu antes de obtener la clave de caché. De esta forma, ambas solicitudes se asignan al mismo objeto almacenado en caché, lo que evita una solicitud innecesaria al origen (y una respuesta innecesaria del origen).

Si hay varias instancias de una clave de parámetro de consulta, cada una con valores distintos, los parámetros se ordenan por su valor completo (por ejemplo, a=hello se ordena antes que a=world). No se puede inhabilitar la ordenación.

Incluir encabezados

Los nombres de los encabezados no distinguen entre mayúsculas y minúsculas, y Media CDN los convierte a minúsculas.

Los siguientes encabezados no se pueden incluir en la clave de caché:

• Cualquier encabezado que empiece por access-control-
• Cualquier encabezado que empiece por sec-fetch-
• accept-encoding
• accept
• authorization
• connection
• content-md5
• content-type
• cookie
• date
• forwarded
• from
• host
• if-match
• if-modified-since
• if-none-match
• origin
• proxy-authorization
• range
• referer
• referrer
• user-agent
• want-digest
• x-csrf-token
• x-csrftoken
• x-forwarded-for

Para incluir el método HTTP en la clave de caché, usa el nombre de encabezado especial :method.

Incluir cookies

En los nombres de las cookies se distingue entre mayúsculas y minúsculas.

Las cookies que empiecen por edge-cache- en cualquier variación de letras mayúsculas o minúsculas no se pueden usar en la clave de caché.

Revalidación, expulsión y caducidad

Las redes de distribución de contenido, incluida Media CDN, almacenan en caché el contenido más popular lo más cerca posible de los usuarios.

El amplio almacenamiento de Media CDN, así como el blindaje de origen, limita la necesidad de desalojar incluso el contenido poco popular. El contenido al que se accede un número reducido de veces al día podría eliminarse con el tiempo.

• Es posible que las respuestas almacenadas en caché que alcancen el TTL configurado no se eliminen inmediatamente. En el caso del contenido popular, Media CDN vuelve a validar que la respuesta almacenada en caché es la versión más reciente enviando una solicitud HEAD al origen para confirmar que los encabezados no han cambiado. En algunos casos, Media CDN envía una solicitud al origen con uno o ambos de estos encabezados de solicitud: If-None-Match y If-Modified-Since. En este caso, los orígenes configurados correctamente deberían devolver una respuesta HTTP 304 (No modificado), sin los bytes del cuerpo, si la caché tiene la copia más reciente de esa respuesta.
• Las respuestas que definan una max-age o una s-maxage directiva de caché o que usen una sustitución de TTL para especificar un valor de TTL alto (por ejemplo, 30 días) podrían no almacenarse en la caché durante todo el TTL. No se garantiza que un objeto se almacene en la caché durante todo el periodo, sobre todo si se accede a él con poca frecuencia.

Si observa una tasa de desalojos alta, debe asegurarse de que ha configurado sus claves de caché para excluir los parámetros que no identifican de forma única una respuesta.

Otras cuestiones:

También se pueden aplicar las siguientes consideraciones en relación con el almacenamiento en caché.

Vary encabezados

El encabezado Vary indica que la respuesta varía en función de los encabezados de solicitud del cliente. Si hay un encabezado Vary en la respuesta, Media CDN no lo almacena en caché, a menos que el encabezado especifique uno de los encabezados configurados como ajuste de clave de caché o uno de los siguientes valores:

• Accept: se usa para indicar qué tipos de contenido multimedia acepta el cliente.
• Accept-Encoding: se usa para indicar qué tipos de compresión acepta el cliente.
• Available-Dictionary: se usa para proporcionar el hash de un diccionario disponible para la compresión.
• Origen/X-Origen: se suele usar para el uso compartido de recursos entre dominios.
• X-Goog-Allowed-Resources: admite la restricción de organización de Google Cloud
• Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site: se usan para obtener encabezados de solicitud de metadatos.

Media CDN almacena en caché las respuestas con un encabezado Vary en la respuesta usando el valor del encabezado como parte de la clave de caché. Si el encabezado Vary de la respuesta tiene varios valores, se ordenan lexicográficamente para asegurarse de que la clave de caché sea determinista.

Media CDN almacena en caché hasta 100 variantes de una clave de caché determinada y elimina aleatoriamente las variantes de la caché que superen ese límite. Cuando se invalida explícitamente la caché de una URL o una etiqueta de caché concretas, se invalidan todas las variantes.

Omitir la caché

Puedes configurar el modo de caché BYPASS_CACHE en una ruta para omitir intencionadamente la caché en las solicitudes coincidentes. Esto puede ser útil si necesitas saltarte la caché para una pequeña parte del tráfico no crítico o depurar la conectividad de origen.

En los casos en los que necesites servir respuestas dinámicas, como los backends de APIs, te recomendamos que configures un balanceador de carga de aplicaciones externo.

Te recomendamos que limites el uso de esta función a escenarios de depuración para evitar que se cargue el origen por error. El tráfico de salida cuando se omite la caché se cobra según las tarifas de salida de Internet.

Invalidación de caché

Consulta Invalidación de caché.

Solicitudes de intervalo de bytes

Media CDN admite solicitudes de intervalo HTTP de una sola parte, tal como se definen en RFC 7233.

Además, Media CDN también usa solicitudes de intervalo para obtener respuestas más grandes del origen. De esta forma, Media CDN puede almacenar en caché los fragmentos de forma individual y no requiere que se obtenga todo el objeto a la vez para almacenarlo en caché.

• Los objetos de más de 1 MiB se obtienen como solicitudes de intervalo de bytes ("fragmentos") de hasta 2 MiB cada uno.
• Las respuestas de hasta 1 MiB se pueden obtener sin compatibilidad con intervalos de bytes en el origen.
• Las respuestas de mayor tamaño no se sirven si no se admiten los intervalos de bytes en el origen.

La compatibilidad de los orígenes con las solicitudes de intervalo de bytes se determina de la siguiente manera:

• Un código de estado HTTP 200 (OK) o 206 (Contenido parcial).
• Un encabezado de respuesta Content-Length o Content-Range válido.
• Un validador de respuestas (ETag o Last-Modified).

Las solicitudes de relleno de origen individuales de cada "fragmento" (intervalo de bytes) se registran como entradas de registro independientes y se asocian a su solicitud de cliente principal. Puedes agrupar estas solicitudes por solicitudes coincidentes en la jsonPayload.cacheKeyFingerprint.

Para obtener más información sobre lo que se registra, consulta la documentación de Cloud Logging.

Solicitudes de intervalo abierto

Media CDN admite solicitudes Range "abiertas"Range: bytes=0- (por ejemplo, una solicitud con Range: bytes=0-) que mantienen una solicitud abierta en el origen hasta que este cierra la respuesta (por ejemplo, el origen escribe todos los bytes en el cable) o se agota el tiempo de espera.

Los clientes que solicitan segmentos HLS de baja latencia de Apple suelen usar intervalos de bytes abiertos: a medida que se escribe cada fragmento CMAF en el cable, la CDN puede almacenar en caché y enviar ese fragmento a los clientes.

En otros casos, como cuando no se requiere interoperabilidad con DASH, la lista de reproducción multimedia indica al reproductor qué bytes representan cada fragmento:

  #EXTINF:4.08,
  fs270.mp4
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=20000@0
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=23000@20000
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=18000@43000
  #EXT-X-PRELOAD-HINT:TYPE=PART,URI="fs271.mp4",BYTERANGE-START=61000

Puedes configurar el tiempo que espera Media CDN entre lecturas mediante el valor de configuración EdgeCacheOrigin.timeouts.readTimeout. Normalmente, este valor debe ser un múltiplo (por ejemplo, 2x) de la duración objetivo.

Siguientes pasos

• Consulta el enrutamiento avanzado.
• Consulta cómo conectarte a diferentes orígenes.
• Configura certificados TLS (SSL) para tu servicio.
• Configura las solicitudes firmadas para autenticar el acceso al contenido.
• Para obtener más información sobre cómo configurar recursos de EdgeCacheService con Terraform, consulta la documentación del registro de Terraform.