Media CDN entrega contenido lo más cerca posible a los usuarios mediante la infraestructura de almacenamiento en caché perimetral global de Google para almacenar en caché el contenido y reducir la carga en la infraestructura de origen.
Puedes controlar cómo se almacena el contenido en caché para cada ruta. Esto te permite optimizar el comportamiento en función del tipo de contenido, los atributos de la solicitud del cliente y los requisitos de actualidad.
Capacidad de almacenamiento en caché
En las siguientes secciones, se describe qué respuestas almacena en caché Media CDN y cómo mejorar la descarga de caché.
Comportamiento de almacenamiento en caché predeterminado
De forma predeterminada, la siguiente configuración relacionada con la caché se aplica a cada servicio de almacenamiento en caché perimetral:
Modo de almacenamiento en caché predeterminado de
CACHE_ALL_STATIC
:- Se respetan las directivas de caché de origen, como
Cache-Control
oExpires
. - Almacena en caché tipos de contenido estático de automáticamente, con un TTL predeterminado de 3,600s.
- Almacena en caché códigos de estado HTTP 200 y 206 (el almacenamiento en caché negativo no está habilitado).
- Se respetan las directivas de caché de origen, como
No almacena en caché las respuestas con las directivas
no-cache
ono-store
, o que no pueden almacenarse en caché.
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 el almacenamiento en caché esté configurado de forma explícita. Para aprender a anular el comportamiento predeterminado, consulta la documentación sobre modos de almacenamiento en 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ápido, lo que permite tiempos de carga más rápidos. No todas las respuestas HTTP pueden almacenarse en caché.
Puedes configurar los modos de almacenamiento en caché para cada ruta a fin de anular este comportamiento (por ejemplo, usar el modo de almacenamiento en caché CACHE_ALL_STATIC
a fin de almacenar en caché tipos de medios comunes), incluso si el origen no está configurado. Una directiva de control de caché en la respuesta.
Las solicitudes y respuestas que cumplen con los criterios definidos en las respuestas que no se pueden almacenar en caché sustituyen la capacidad de almacenamiento en caché.
En la siguiente tabla, se describen los requisitos para almacenar en caché respuestas HTTP específicas:
Atributo HTTP | Requisitos |
---|---|
Código de estado | El código de estado de respuesta debe ser uno de los siguientes: 200, 203, 204, 206, 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451 o 501 |
Métodos HTTP | GET, HEAD y OPCIONES |
Encabezados de la solicitud | Los encabezados de solicitud no afectan si un elemento se debe almacenar en caché. Consulta las Directivas de control de caché para obtener más información. |
Encabezados de respuesta |
|
Tamaño de la respuesta | Hasta 50 GiB. |
El encabezado HTTP Age
se establece en función de cuándo la Media CDN obtuvo por primera vez la respuesta y, por lo general, representa los segundos desde que el objeto se almacenó en caché en un ubicación de protección contra el origen. Si tu origen genera un encabezado de respuesta de edad, usa el modo de almacenamiento en 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 Media CDN interpreta las directivas de almacenamiento en caché HTTP, consulta Directivas de control de caché.
Requisitos de origen
Para permitir que la Media CDN almacene las respuestas de origen en caché, un origen debe incluir lo siguiente en los encabezados de respuesta para las solicitudes de HEAD y GET, a menos que se especifique lo contrario:
- Un encabezado de respuesta HTTP
Last-Modified
oETag
. - Un encabezado HTTP
Date
válido. - Un encabezado
Content-Length
válido. - El encabezado de respuesta
Accept-Ranges: bytes
. - El encabezado de respuesta
Content-Range
, en respuesta a una solicitud GETRange
. El encabezadoContent-Range
debe tener un valor válido con el formatobytes x-y/z
(en el quez
es el tamaño del objeto).
El protocolo de origen predeterminado es HTTP/2. Si tus orígenes solo admiten HTTP/1.1, puedes configurar el campo del protocolo de forma explícita para cada origen.
Respuestas que no se pueden almacenar en caché
En la siguiente tabla, se detalla qué atributos de solicitud y respuesta impiden que una respuesta se almacene en caché. Las respuestas que pueden almacenarse en caché, pero que coinciden con un criterio “no almacenable en caché”, no se almacenan en caché.
Atributo HTTP | Requisito |
---|---|
Código de estado | Un código de estado distinto de los definidos como almacenables en caché, como HTTP 400, HTTP 403 o HTTP 504. Estos códigos de estado suelen representar problemas para el cliente y no un estado de origen, y el almacenamiento en caché de esas respuestas puede generar situaciones de “envenenamiento de caché” en las que Una respuesta “incorrecta” activada por el usuario se almacena en caché para todos los usuarios. |
Encabezados de la solicitud | Los encabezados de la solicitud no afectan si un elemento debe o no almacenarse en caché, a excepción del encabezado de la solicitud Authorization . Las respuestas deben incluir una directiva public de control de caché para almacenar en caché en este caso.Si deseas obtener más información, consulta Directivas de control de caché. |
Encabezados de respuesta |
|
Tamaño de la respuesta | Superior a 50 GiB. |
Estas reglas se aplican además del modo de almacenamiento en caché. En particular, haz lo siguiente:
- Con el modo de almacenamiento en caché
CACHE_ALL_STATIC
configurado, solo las respuestas que se consideran contenido estático o las respuestas con directivas de caché válidas en sus encabezados de respuesta se almacenan en caché. Las demás respuestas se envían mediante proxy “tal como están”. - El modo de almacenamiento en caché
FORCE_CACHE_ALL
almacena en caché todas las respuestas de forma incondicional, siempre que la respuesta sea un código de estado que se puede almacenar en caché. - El modo de almacenamiento en caché
USE_ORIGIN_HEADERS
requiere respuestas para establecer directivas de caché válidas en sus encabezados de respuesta, además de ser un código de estado que puede almacenarse en caché.
Notas:
- Las respuestas que no se almacenan en caché no tienen sus directivas
Cache-Control
ni otros encabezados modificados y se envían mediante proxy “tal como están”. - Las respuestas HTTP con varios campos de encabezado con el mismo nombre se contraen en un solo campo de encabezado, cuando corresponda. Por ejemplo, una respuesta con
Cache-Control: no-cache
yCache-Control: no-store
en líneas separadas se contraería comoCache-Control: no-cache, no-store
. - Las respuestas que no pueden almacenarse en caché (respuestas que nunca se almacenarían en caché) no se cuentan como salida de caché desde la perspectiva de facturación.
Usa modos de almacenamiento en caché
Los modos de almacenamiento en caché te permiten configurar cuándo Media CDN debe respetar las directivas de caché de origen, almacenar en caché tipos de contenido estático y almacenar en caché todas las respuestas del origen, sin importar las directivas configuradas.
Los modos de almacenamiento en caché se configuran a nivel de ruta y, junto con las anulaciones de TTL, te permiten configurar el comportamiento de la caché por host, ruta de acceso, parámetros de consulta y encabezados (cualquier parámetro de solicitud que coincida).
- De forma predeterminada, Media CDN usa el modo de almacenamiento en caché
CACHE_ALL_STATIC
, que almacena en caché de automáticamente los tipos de contenido estático comunes durante 1 hora (3,600 segundos), así como cualquierrespuesta almacenada en caché con directivas de caché válidas. - Si deseas aumentar o disminuir el TTL de la caché aplicado a las respuestas sin un TTL de caché explícito (una directiva
max-age
os-maxage
), configura el campocdnPolicy.defaultTtl
en una ruta. - Los códigos de estado que no son 2xx (no exitosos) no se almacenan en caché de acuerdo con su
Content-Type
(tipo de MIME) y no tienen aplicado el TTL predeterminado para evitar almacenar en caché respuestas que no sean exitosas por más tiempo del previsto.
Los modos de almacenamiento en caché disponibles, que se establecen en el cdnPolicy.cacheMode
de cada ruta, son los siguientes:
Modo de almacenamiento en caché | Comportamiento |
---|---|
USE_ORIGIN_HEADERS |
Requiere respuestas de origen para establecer directivas de caché válidas y encabezados de almacenamiento en caché válidos. Si deseas obtener una lista completa de los requisitos, consulta la documentación de respuestas que se pueden almacenar en caché. |
CACHE_ALL_STATIC |
Almacena en caché automáticamente el contenido estático que no tiene la directiva no-store , private o no-cache . Las respuestas de origen que establecen directivas de almacenamiento en caché válidas también se almacenan en caché.El contenido estático incluye videos, audio, imágenes y elementos web comunes, según lo define el tipo de MIME en el encabezado de respuesta Content-Type .
|
FORCE_CACHE_ALL |
Se almacenan en caché las respuestas correctas de forma incondicional y se anulan las directivas de caché que estableció el origen. Asegúrate de no entregar contenido privado por usuario (como HTML dinámico o respuestas de la API) con este modo configurado. |
BYPASS_CACHE | Todas las solicitudes que coinciden con una ruta que tiene configurado este modo de caché omiten la caché, incluso si hay un objeto almacenado en caché que coincida con esa clave de caché. Solo recomendamos usar esto para depurar, ya que Media CDN está diseñada como una infraestructura de caché a escala mundial y no un proxy de uso general. |
Tipos de MIME de contenido estático
El modo de almacenamiento en caché CACHE_ALL_STATIC
permite que Media CDN almacene en caché automáticamente el contenido estático común, como videos, imágenes y elementos web comunes, según el tipo de MIME que se muestra en el encabezado de respuesta HTTP Content-Type
.
En la siguiente tabla, se enumeran los tipos de MIME que se almacenan en caché automáticamente con el modo de almacenamiento en caché CACHE_ALL_STATIC
.
Las respuestas no se almacenan en caché automáticamente si les falta un encabezado de respuesta Content-Type
con un valor que coincida con los siguientes valores. Debes asegurarte de que la respuesta establezca una directiva de caché válida o usar el modo de almacenamiento en caché FORCE_CACHE_ALL
para almacenar respuestas en caché de forma incondicional.
Categoría | Tipos de MIME |
---|---|
Elementos web | text/css text/ecmascript text/javascript application/javascript |
Fuentes | Cualquier tipo de contenido que coincida con font/* |
Imágenes | Cualquier tipo de contenido que coincida con image/* |
Videos | Cualquier tipo de contenido que coincida con video/* |
Audio | Cualquier tipo de contenido que coincida con audio/* |
Tipos de documentos con formato | application/pdf and application/postscript |
Ten en cuenta lo siguiente:
- El software del servidor web de origen debe configurar el
Content-Type
para cada respuesta. Muchos servidores web configuran el encabezadoContent-Type
automáticamente, incluidos NGINX, Varnish y Apache. - Cloud Storage configura el encabezado
Content-Type
automáticamente en la carga cuando usas la consola de Google Cloud o la herramienta degsutil
para subir contenido. - Si una respuesta se puede almacenar en caché según su tipo de MIME, pero tiene un encabezado de respuesta
Cache-Control
deprivate
,no-store
ono-cache
, o un encabezadoSet-Cookie
, no se almacena en caché.
Configura los TTL para el almacenamiento en caché
Las anulaciones de tiempo de actividad (TTL) te permiten establecer valores de TTL predeterminados para el contenido almacenado en caché y anular los valores de TTL configurados en las directivas max-age
y s-maxage
de control de caché (o encabezados Expires
). según tus orígenes.
Ten en cuenta que los TTL, ya sean establecidos mediante anulaciones o a través de una directiva de caché, son optimistas. El contenido al que se accede con poca frecuencia o que es poco popular puede expulsarse de la caché antes de que se alcance el TTL.
Existen tres opciones de configuración de TTL:
Parámetro de configuración | Predeterminado | Mín. | Máx | Descripción | Modos de almacenamiento en caché aplicables |
---|---|---|---|---|---|
Default TTL | 1 hora (3,600 segundos) | 0 segundos | 1 año (31,536,000 segundos) | El TTL que se debe establecer cuando el origen no especificó un max-age o s-maxage .Si el origen especifica el encabezado s-maxage , se usa en lugar del valor de TTL predeterminado aquí.Cuando se usa FORCE_CACHE_ALL para almacenar en caché de forma incondicional todas las respuestas, se usa el TTL predeterminado a fin de establecer el TTL de la caché. Se ignoran todos los demás valores y directivas.
|
CACHE_ALL_STATIC FORCE_CACHE_ALL
|
Max TTL | 1 día (86,400 segundos) | 0 segundos | 1 año (31,536,000 segundos) | El TTL máximo que se permite. Los valores superiores se limitan al valor de maxTtl .
|
CACHE_ALL_STATIC |
Client TTL | No se establece de forma predeterminada. | 0 segundos | 1 mes (2,592,000 segundos) | El TTL que se debe establecer en la respuesta descendente (orientada al cliente) si esto debe ser diferente de otros valores de TTL. Esto solo se aplica a las respuestas exitosas (2xx). |
CACHE_ALL_STATIC FORCE_CACHE_ALL
|
Establecer cualquier valor de TTL en cero (0 segundos) hace que cada solicitud se vuelva a validar con el origen antes de que se entregue una respuesta y aumenta la carga al origen si se configura de forma demasiado amplia.
Cuando el modo de caché está configurado en Usar encabezados de origen, no se puede establecer la configuración de TTL, ya que Media CDN se basa en el origen para impulsar el comportamiento.
Notas:
- El valor del TTL máximo siempre debe ser mayor o igual que el valor de TTL predeterminado.
- El valor del TTL de cliente siempre debe ser menor que (o igual que) el valor de TTL máximo.
- Cuando Media CDN de medios anula un valor de TTL de origen, el encabezado
Cache-Control
para el cliente también refleja ese valor. - Si el origen establece un encabezado
Expires
y Media CDN anula el TTL efectivo (según la marca de tiempo), el encabezadoExpires
se reemplaza por un encabezadoCache-Control
en la respuesta descendente al cliente.
Almacenamiento en caché negativo
El almacenamiento en caché negativo define cómo los códigos de estado HTTP no exitosos (que no son 2xx) se almacenan en caché por Media CDN.
Esto te permite almacenar en caché respuestas de error, como redireccionamientos (HTTP 301 y 308) y no respuestas (HTTP 404) más cercanas a los usuarios, así como reducir la carga de origen de forma más amplia si es poco probable que la respuesta cambie y se puede almacenar en caché.
De forma predeterminada, el almacenamiento en caché negativo está inhabilitado. En la siguiente tabla, se muestran los valores predeterminados para cada código de estado cuando el almacenamiento en caché negativo está habilitado y negativeCachingPolicy
no se usa.
Códigos de estado | Reason-phrase | TTL |
---|---|---|
HTTP 300 | Opciones múltiples | 10 minutos |
HTTP 301 y HTTP 308 | Redireccionamiento permanente | 10 minutos |
HTTP 404 | No se encontró el elemento | 120 segundos |
HTTP 405 | No se encontró el método | 60 segundos |
HTTP 410 | No disponible | 120 segundos |
HTTP 451 | No disponible por motivos legales | 120 segundos |
HTTP 501 | No se implementó | 60 segundos |
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 descritos en HTTP RFC 9110, con las siguientes excepciones:
- El código HTTP 414 (URI demasiado largo) no es compatible con el almacenamiento en caché para evitar el envenenamiento de la caché.
- El código HTTP 451 (No disponible por motivos legales) es compatible con el almacenamiento en caché, como se describe en HTTP RFC 7725.
Si necesitas configurar tus propios TTL por código de estado y anular el comportamiento predeterminado, puedes configurar un cdnPolicy.negativeCachingPolicy
. Esto te permite establecer el TTL para cualquiera de los códigos de estado permitidos por Media CDN: 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451 y 501.
Por ejemplo, a fin de establecer 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 YAML en cada una ruta aplicable:
cdnPolicy: negativeCaching: true negativeCachingPolicy: "404": 5s "405": 10s # other status codes to apply TTLs for
A fin de evitar el envenenamiento de caché, no recomendamos habilitar el almacenamiento en caché para el código de estado 400 (solicitud incorrecta) o el 403 (prohibido). Asegúrate de que el servidor de origen muestre cualquiera de los 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 ocurrir, por ejemplo, cuando el servidor de origen responde con una respuesta de error 403 en ausencia de un encabezado Authorization
correcto. En este caso, almacenar en caché la respuesta de error 403 hace que Media CDN entregue la respuesta de error 403 a todas las solicitudes posteriores hasta que caduque el TTL, incluso si las solicitudes tienen un encabezado Authorization
correcto.
Para inhabilitar el almacenamiento en caché negativo, haz lo siguiente:
- Para inhabilitar el comportamiento de almacenamiento en caché negativo predeterminado, configura
cdnPolicy.negativeCaching: false
en una ruta. Ten en cuenta que las respuestas de origen con directivas de caché válidas y códigos de estado que pueden almacenarse en caché aún se almacenan en caché. - Para evitar el almacenamiento en caché negativo en un código de estado específico, pero respetar las directivas de caché de origen, omite el código de estado (
cdnPolicy.negativeCachingPolicy[].code
) en tu definición denegativeCachingPolicy
. - A fin de ignorar directivamente las directivas de caché de origen para un código de estado específico, configura
cdnPolicy.negativeCachingPolicy[].ttl
como0
(cero) para ese código de estado.
Notas:
- Cuando
negativeCaching
está habilitado en una ruta y una respuesta define directivas de caché válidas, las directivas de caché en la respuesta tienen prioridad. - Si configuras un
negativeCachingPolicy
explícito y hay un TTL definido para el código de estado determinado, siempre se usa el TTL definido en la política. - El valor máximo de un TTL establecido por
negativeCachingPolicy
es de 1,800 segundos (30 minutos), pero se respetan las directivas de caché de origen con un TTL más alto. - Si el modo de almacenamiento en caché se configura como
FORCE_CACHE_ALL
, las directivas de origen se ignoran en todos los casos.
Claves de caché
Puedes reducir la cantidad de veces que Media CDN necesita comunicarse con el origen si consideras que identifica de manera inequívoca una solicitud y quita los componentes que a menudo pueden cambiar entre las solicitudes. A menudo, el conjunto de componentes de la solicitud se conoce como “clave de caché”.
En las siguientes secciones, se describe cómo configurar las claves de caché.
Componentes de la clave de caché
Una clave de caché es el conjunto de parámetros de solicitud (como el host, la ruta de acceso y los parámetros de consulta) a los que hace referencia un objeto almacenado en caché.
De forma predeterminada, las claves de caché para los servicios de almacenamiento en caché perimetral incluyen el host de solicitud, la ruta de acceso y los parámetros de consulta de la solicitud, y se limitan a un EdgeEdgeService específico.
Componente | ¿Se incluye de forma predeterminada? | Detalles |
---|---|---|
Protocolo | No | Las solicitudes a través de HTTP y HTTPS hacen referencia al mismo objeto almacenado en caché. Si deseas mostrar las diferentes respuestas a las solicitudes http: y https:, configura |
Host | Sí | Los hosts diferentes no hacen referencia a los mismos objetos almacenados en caché. Si tienes varios nombres de host dirigidos al mismo EdgeCacheService y entregan el mismo contenido, configura |
Ruta de acceso | Sí | Siempre se incluye en la clave de caché y no se puede quitar. La ruta de acceso es la representación mínima de un objeto en caché. |
Parámetros de consulta | Sí | Si los parámetros de consulta no distinguen entre diferentes respuestas, configura Si solo algunos parámetros de consulta se deben incluir en una clave de caché, configura |
Encabezados | No | Configura Especifica varios encabezados que se combinan para tener un gran rango de valores (por ejemplo, los valores de encabezado combinados identifican a un solo usuario), reduce la tasa de aciertos de caché y puede generar una tasa de expulsión más alta y una reducción rendimiento. Si deseas obtener más detalles para incluir encabezados, consulta Incluye encabezados. |
Cookies | No | Configura Especifica varias cookies que se combinan para tener un gran rango de valores (por ejemplo, los valores de cookie combinados identifican a un solo usuario), reduce la tasa de aciertos de caché de forma significativa y puede provocar una tasa de expulsión más alta y una reducción rendimiento. Si deseas obtener más detalles para incluir cookies, consulta Incluye cookies. |
Ten en cuenta que las claves de caché tienen las siguientes características:
- No se conecta a un origen configurado, lo que te permite actualizar una configuración de origen (o reemplazar el origen por completo) sin riesgo de “limpiar” la caché (por ejemplo, cuando migras almacenamiento de origen entre proveedores).
- Limitado a un EdgeCacheService. Los diferentes EdgeCacheServices tienen diferentes espacios de nombres de caché, lo que evita que almacenes en caché objetos de manera accidental entre los entornos de producción, etapa de pruebas y otros entornos de prueba, incluso si el host, la ruta de acceso o algún otro componente de la clave de caché coincidieran.
- Si borras un EdgeCacheService, se invalidarán de forma efectiva todos los objetos almacenados en caché para ese servicio.
- No tiene alcance de una ruta individual. Varias rutas pueden hacer referencia a la misma clave de caché, en especial si esas rutas coinciden con componentes que no se incluyen en la clave de caché, como encabezados de solicitudes o parámetros excluidos. Esto puede ser útil si deseas que varias rutas compartan la misma caché, pero muestren diferentes encabezados de respuesta o configuración de CORS.
- No incluyas la configuración de reescritura de URL (por ejemplo, una clave de caché se basa en la solicitud para el usuario, no en la solicitud final “reescrita”).
- Cuando las solicitudes firmadas se configuran 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 o el componente de ruta (firmados) que comienzan con
edge-cache-token
y terminan en el siguiente separador de ruta (“/”) no son 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é si agregas el nombre del parámetro a la configuración de clave de caché includedQueryParameters
o excludedQueryParameters
en una ruta determinada.
Por ejemplo, para incluir los parámetros de consulta contentID
y country
y, también, ignorar todos los demás de la clave de caché:
cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 86400s cacheKeyPolicy: includedQueryParameters: ["contentID", "country"]
Asegúrate de incluir los parámetros de consulta que identifican el contenido de manera inequívoca y excluye los que no lo hacen. Por ejemplo, excluye los parámetros de consulta de estadísticas, los ID de sesión de reproducción o cualquier otro parámetro que solo sea único para el cliente. Incluir más parámetros de consulta de los necesarios puede disminuir las tasas de aciertos de caché.
Como alternativa, en lugar de especificar qué parámetros incluir en la clave de caché, puedes elegir qué parámetros excluir de la clave de caché. Por ejemplo, para excluir el ID de reproducción específico del cliente y la información de marca de tiempo de la clave de caché, configura lo siguiente:
cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 86400s cacheKeyPolicy: excludedQueryParameters: ["playback-id", "timestamp"]
Para una ruta determinada, puedes especificar uno de includedQueryParameters
o excludedQueryParameters
.
Si los parámetros de consulta nunca se usan a fin de identificar de manera inequívoca el contenido entre las solicitudes, puedes quitar todos los parámetros de consulta de la clave de caché para una ruta. Para ello, establece excludeQueryString
en true
de la siguiente manera:
cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 3600s cacheKeyPolicy: excludeQueryString: true
Si las solicitudes firmadas están habilitadas en una ruta, los parámetros de consulta que se usan para firmar no se incluyen en la string de consulta y se ignoran si se incluyen. Incluir los parámetros firmados en la clave de caché hace que cada solicitud del usuario sea única y requiere que cada solicitud se entregue desde el origen.
Orden de parámetros de consulta
Los parámetros de consulta (strings de consulta) se ordenan de forma predeterminada para mejorar las tasas de aciertos de caché, ya que los clientes pueden volver a ordenar 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 que se derive la clave de caché. Esto permite que ambas solicitudes se asignen al mismo objeto almacenado en caché, lo que evita una solicitud innecesaria (y una respuesta desde) de origen.
Si hay varias instancias de una clave de parámetro de consulta, cada una con valores distintos, los parámetros se ordenan según su valor completo (por ejemplo, a=hello
se ordena antes de a=world
). No se puede inhabilitar el orden.
Incluir encabezados
Los nombres de encabezado no distinguen mayúsculas de minúsculas, y la Media CDN los convierte en minúsculas.
Los siguientes encabezados no se pueden incluir en la clave de caché:
- Cualquier encabezado que comience con
access-control-
- Cualquier encabezado que comience con
sec-fetch-
- Cualquier encabezado que comience con
x-amz-
- Cualquier encabezado que comience con
x-goog-
- Cualquier encabezado que comience con
x-media-cdn-
accept-encoding
accept
authorization
cdn-loop
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
Los nombres de cookies distinguen mayúsculas de minúsculas.
Las cookies que comienzan con 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 vencimiento
Las redes de distribución de contenidos, incluida la Media CDN, operan mediante el almacenamiento en caché del contenido más popular lo más cerca posible de los usuarios.
El almacenamiento extenso de Media CDN, así como la protección de origen, limitan la necesidad de expulsar contenido incluso poco popular. El contenido al que se accede una pequeña cantidad de veces al día puede expulsarse.
- Es posible que las respuestas almacenadas en caché que alcanzan el TTL configurado no se expulsen de inmediato. Para el contenido popular, Media CDN valida que la respuesta almacenada en caché sea la versión más reciente mediante la emisión de una solicitud al origen con un encabezado de solicitud
If-None-Match
oIf-Modified-Since
. - Los orígenes configurados de forma correcta muestran una respuesta HTTP 304 (sin modificar), sin los bytes del cuerpo, si el almacenamiento en caché tiene la copia “más reciente” de esa respuesta.
- Respuestas que configuran una directiva de caché
max-age
os-maxage
o que usan una anulación de TTL para especificar un valor de TTL alto (por ejemplo, 30 días) puede que no se almacene en caché para el TTL completo. No se garantiza que un objeto se almacene en la caché todo el tiempo, en especial si se accede a él con poca frecuencia.
Si ves una tasa alta de expulsiones, debes asegurarte de haber configurado tus claves de caché para excluir parámetros que no identifiquen una respuesta de manera inequívoca.
Otras consideraciones
Encabezados Vary
El encabezado Vary
indica que la respuesta varía según los encabezados de la solicitud del cliente. Si hay un encabezado Vary
presente en la respuesta, debe especificar uno de los siguientes valores, o Media CDN no lo almacena en caché:
- Accept: Se usa para indicar qué tipos de contenido acepta el cliente
- Accept-Encoding: se usa para indicar qué tipos de compresión acepta el cliente
- Origin: Por lo general, se usa para uso compartido de recursos entre dominios
Media CDN almacena en caché las respuestas con un encabezado Vary
en la respuesta mediante el valor del encabezado como parte de la clave de caché. Si el encabezado Vary
en la respuesta tiene varios valores, se ordenan de manera lexicográfica para garantizar que la clave de caché sea determinista.
Media CDN almacena en caché hasta 100 variantes de una clave de caché determinada y expulsa variantes de la caché de forma aleatoria por encima de ese límite. Cuando invalidan la caché de forma explícita para una URL o etiqueta de caché determinada, todas las variantes se invalidan.
Omitir la caché
Puedes configurar el modo de almacenamiento en caché BYPASS_CACHE
en una ruta para omitir de forma intencional la caché en las solicitudes coincidentes. Esto puede ser útil si necesitas omitir la caché para una pequeña fracción de tráfico no crítico o la conectividad de origen de depuración.
Para los casos en los que necesites entregar respuestas dinámicas, como los backends de API, te recomendamos configurar un balanceador de cargas de HTTP(S) externo.
Por lo general, se recomienda limitar el uso a las situaciones de depuración para evitar la carga de origen involuntaria. El tráfico que sale cuando se omite la caché tiene un precio según las tarifas de salida de Internet.
Invalidación de caché
Consulta Invalidación de caché.
Solicitudes de rango de bytes
Media CDN admite solicitudes de rango HTTP, como se define en RFC 7233, incluidas las solicitudes de rango de una sola parte y varios rangos de bytes.
Además, Media CDN también usa de forma optimista las solicitudes de rango para recuperar el contenido más grande del origen. Esto permite que Media CDN almacene en caché fragmentos de forma individual y no requiera que el objeto completo se recupere a la vez para que se almacene en caché.
- Los objetos de más de 2 MB se recuperan como solicitudes de rango de bytes (“fragmentos”).
- La respuesta hasta 2 MB de bytes se pueden recuperar sin compatibilidad con rangos de bytes en el origen.
- Las respuestas más grandes no se entregan si los rangos de bytes no son compatibles con el origen.
La compatibilidad de origen para solicitudes de rango de bytes se determina mediante lo siguiente:
- Un código de estado HTTP de 200 (OK) o 206 (contenido parcial).
- Encabezado de respuesta
Accept-Ranges: bytes
. - Un encabezado de respuesta
Content-Length
oContent-Range
válido.
Las solicitudes de relleno de origen individuales para cada “fragmento” (rango de bytes) se registran como entradas de registro discretas y se asocian con la solicitud del cliente superior. Puedes agrupar estas solicitudes si haces coincidir las solicitudes en el jsonPayload.cacheKeyFingerprint
.
Consulta la documentación de Cloud Logging para obtener más detalles sobre lo que se registra.
Solicitudes de rango abierto
Media CDN admite solicitudes de rango “abiertas” (por ejemplo, una solicitud con Range: bytes=0-
) que mantienen una solicitud abierta en el origen hasta que el origen cierra la respuesta (por ejemplo, el origen escribe todos los bytes al cable) o se agota el tiempo de espera.
Por lo general, los clientes que usan los rangos de bytes abiertos son los que solicitan los segmentos de HLS de baja latencia de Apple. A medida que cada fragmento de CMAF se escribe en la línea, la CDN puede almacenar en caché y entregar y fragmentar a los clientes.
En otros casos, como cuando no se requiere interoperabilidad con DASH, la lista de reproducción de medios le indica al jugador 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 cuánto tiempo debe esperar CDN Media entre lecturas mediante el valor de configuración EdgeCacheOrigin.timeouts.readTimeout
. Por lo general, esto debe configurarse en un múltiplo (por ejemplo, 2 veces) de la duración objetivo.
Rangos de bytes multiparte
En particular, las solicitudes de rango de varias partes (por ejemplo, bytes=0-300,1200-2000
) deben cumplir con los siguientes requisitos:
- Debe cumplir con RFC 7233 de HTTP.
- Los rangos deben estar solo en orden ascendente.
- Se pueden especificar un máximo de dos rangos en una sola solicitud.
La mayoría de los almacenes de objetos, incluidos Cloud Storage y Amazon S3, no admiten directamente solicitudes de rango de varias partes y muestran un error o muestran el objeto completo de forma implícita. Muchos proxies inversos y de almacenamiento en caché populares, incluido Varnish, tampoco admiten solicitudes de rango multiparte.
¿Qué sigue?
- Revisa Enrutamiento avanzado.
- Obtén información para conectarte a diferentes orígenes.
- Configura certificados TLS (SSL) para tu servicio.
- Configura las solicitudes firmadas para autenticar el acceso al contenido.