O Media CDN exibe conteúdo o mais próximo possível dos usuários usando a infraestrutura de armazenamento em cache de borda global do Google para armazenar conteúdo em cache e reduzir a carga na infraestrutura de origem.
Você pode controlar como o conteúdo é armazenado em cache para cada rota. Isso permite otimizar o comportamento com base no tipo de conteúdo, nos atributos de solicitação do cliente e nos requisitos de atualização.
Capacidade de armazenamento em cache
As seções a seguir descrevem quais respostas o Media CDN armazena em cache e como melhorar o descarregamento de cache.
Comportamento padrão de armazenamento em cache
Por padrão, as seguintes configurações relacionadas ao cache se aplicam a cada serviço de armazenamento em cache de borda:
Modo de cache padrão de
CACHE_ALL_STATIC
:- Respeita as diretivas do cache de origem, como
Cache-Control
ouExpires
, até um TTL máximo configurável. - Armazena em cache tipos de mídia estática automaticamente com um TTL padrão de 3.600 s, se nenhuma diretiva de cache de origem estiver presente.
- Armazena em cache códigos de status HTTP 200 e 206 (o cache negativo não está ativado).
- Respeita as diretivas do cache de origem, como
Não armazena em cache respostas que tenham diretivas de controle de cache
no-store
ouprivate
ou que não sejam armazenáveis em cache.
As respostas que não são conteúdo estático ou que não têm diretivas de cache válidas não são armazenadas em cache, a menos que o armazenamento em cache esteja configurado explicitamente. Para saber como modificar o comportamento padrão, consulte a documentação sobre modos de cache .
O comportamento padrão é equivalente ao cdnPolicy
a seguir. Rotas sem
um cdnPolicy
explícito configurado se comportam como se tivessem a seguinte
configuração:
cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 3600s cacheKeyPolicy: includeProtocol: false excludeHost: false excludeQueryString: false signedRequestMode: DISABLED negativeCaching: false
Respostas armazenáveis em cache
Uma resposta armazenável em cache é uma resposta HTTP que o Media CDN pode armazenar e recuperar rapidamente, permitindo tempos de carregamento mais rápidos. Nem todas as respostas HTTP podem ser armazenadas em cache.
É possível configurar modos de cache para cada rota para modificar esse
comportamento (por exemplo, usando o modo de cache CACHE_ALL_STATIC
para armazenar tipos de mídia
comuns), mesmo que a origem não defina uma
diretiva de controle de cache na resposta.
As solicitações e respostas que atendem aos critérios definidos nas respostas não armazenáveis em cache substituem a capacidade de armazenamento em cache.
A tabela a seguir descreve os requisitos para armazenar em cache respostas HTTP específicas. As respostas GET
e HEAD
precisam atender a esses requisitos.
Atributo HTTP | Requisitos |
---|---|
Código de status | O código de status da resposta precisa ser 200, 203, 206, 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451, 500, 501, 502 ou 503. |
Métodos HTTP | GET e HEAD |
Cabeçalhos de solicitação | A maioria das diretivas de solicitação de armazenamento em cache é ignorada. Para mais informações, consulte Diretivas de controle de cache. |
Cabeçalhos de resposta | Contém uma diretiva de armazenamento em cache HTTP válida, como tem um modo de cache que armazena esse conteúdo ou um cabeçalho |
Tamanho da resposta | Até 100 GiB. |
O cabeçalho HTTP Age
é definido
com base no momento em que o Media CDN armazena a resposta em cache pela primeira vez e geralmente
representa os segundos desde que o objeto foi armazenado em cache em um
local de proteção de origem. Se a
origem gerar um cabeçalho de resposta de idade, use o modo de cache FORCE_CACHE_ALL
para
evitar revalidação quando a idade exceder o TTL do cache.
Para mais informações sobre como o Media CDN interpreta as diretivas de armazenamento em cache HTTP, consulte Diretivas de controle de cache.
Requisitos de origem
Para permitir que o Media CDN armazene em cache respostas de origem maiores que
1 MiB, uma origem precisa incluir o seguinte nos cabeçalhos de resposta das
solicitações HEAD
e GET
, a menos que especificado de outra forma:
- Um cabeçalho de resposta HTTP
Last-Modified
ouETag
(um validador). - Um cabeçalho HTTP
Date
válido. - Um cabeçalho
Content-Length
válido. - O cabeçalho de resposta
Content-Range
, em resposta a uma solicitaçãoRange GET
. O cabeçalhoContent-Range
precisa ter um valor válido no formatobytes x-y/z
(em quez
é o tamanho do objeto).
O protocolo de origem padrão é HTTP/2. Caso suas origens aceitem apenas HTTP/1.1, defina o campo de protocolo explicitamente para cada origem.
Respostas que não podem ser armazenadas em cache
A tabela a seguir detalha os atributos de solicitação e resposta que impedem que uma resposta seja armazenada em cache. As respostas armazenáveis em cache, mas que correspondem a critérios "não armazenáveis em cache", não são armazenadas.
Atributo HTTP | Requisito |
---|---|
Código de status | Um código de status diferente dos definidos como armazenáveis em cache, como HTTP 401, HTTP 412 ou HTTP 505 Esses códigos de status geralmente representam os problemas do cliente, e não o status da origem. Armazenar essas respostas em cache pode levar a cenários de "envenenamento de cache", em que uma resposta "ruim" acionada pelo usuário é armazenada em cache para todos os usuários. |
Cabeçalhos de solicitação | Para solicitações com um cabeçalho de solicitação Uma diretiva |
Cabeçalhos de resposta | Tem um cabeçalho Tem um cabeçalho No modo |
Tamanho da resposta | Ter mais de 100 GiB. |
Essas regras se aplicam além do modo de cache configurado. Em especial:
- Com o modo de cache
CACHE_ALL_STATIC
configurado, apenas as respostas consideradas como conteúdo estático ou respostas com diretivas de cache válidas nos cabeçalhos de resposta são armazenadas em cache. Outras respostas são por proxy no estado em que se encontram. - O modo de cache
FORCE_CACHE_ALL
armazena todas as respostas incondicionalmente, sujeito aos requisitos de não armazenamento em cache mencionados anteriormente. - O modo de cache
USE_ORIGIN_HEADERS
exige que as respostas definam diretivas de cache válidas nos cabeçalhos de resposta, além de ser um código de status armazenável em cache.
Observações:
- As respostas que não são armazenadas em cache não têm as diretivas de controle de cache ou outros cabeçalhos alterados e são encaminhadas sem modificações.
- As respostas podem ter os cabeçalhos
Cache-Control
eExpires
recolhidos em um único campoCache-Control
. Por exemplo, uma resposta comCache-Control: public
eCache-Control: max-age=100
em linhas separadas seria recolhida comoCache-Control: public,max-age=100
. - As respostas que não podem ser armazenadas em cache (que nunca seriam armazenadas em cache) não são contabilizadas como
Cache Egress
do ponto de vista de faturamento.
Como usar modos de cache
Os modos de cache permitem configurar quando o Media CDN deve respeitar as diretivas de cache de origem, armazenar em cache os tipos de mídia estáticos e armazenar todas as respostas da origem, independentemente das diretivas definidas.
Os modos de cache são configurados no nível da rota e, combinados com as substituições de TTL, permitem configurar o comportamento do cache por host, caminho, parâmetros de consulta e cabeçalhos (qualquer parâmetro de solicitação correspondente).
- Por padrão, o Media CDN usa o modo de cache
CACHE_ALL_STATIC
, que armazena automaticamente tipos de mídia estática comuns por 1 hora (3.600 segundos), enquanto prioriza qualquer diretiva de cache especificada pela origem para respostas armazenáveis em cache. - É possível aumentar ou diminuir o TTL do cache aplicado a respostas sem um
TTL de cache explícito definido (uma diretiva
max-age
ous-maxage
) definindo o campocdnPolicy.defaultTtl
em uma rota. - Para evitar o armazenamento em cache de respostas sem êxito por mais tempo do que o esperado,
os códigos de status não 2xx (sem sucesso) não são armazenados em cache de acordo com o
Content-Type
(tipo MIME) e não têm o TTL padrão aplicado.
Os modos de cache disponíveis, que são definidos no cdnPolicy.cacheMode
de cada rota, são mostrados na tabela a seguir.
Modo cache | Comportamento |
---|---|
USE_ORIGIN_HEADERS |
Requer respostas de origem para definir diretivas de cache e cabeçalhos de cache válidos. Para uma lista completa de requisitos, consulte Respostas armazenáveis em cache. |
CACHE_ALL_STATIC |
Armazena automaticamente em cache respostas bem-sucedidas com conteúdo estático,
a menos que elas tenham uma diretiva
O conteúdo estático inclui vídeo, áudio, imagens e recursos comuns da Web, conforme
definido pelo tipo MIME no cabeçalho de resposta
|
FORCE_CACHE_ALL |
Armazena incondicionalmente em cache respostas bem-sucedidas, substituindo quaisquer diretivas de cache definidas pela origem. Não exiba conteúdo particular por usuário (como HTML dinâmico ou respostas da API) com esse modo configurado. |
BYPASS_CACHE | Qualquer solicitação que corresponda a uma rota com esse modo de cache configurado ignora o cache, mesmo que haja um objeto em cache que corresponda a essa chave de cache. Recomendamos usá-lo apenas para depuração, porque o Media CDN foi projetado como uma infraestrutura de cache em escala global, e não um proxy de uso geral. |
Tipos MIME de conteúdo estático
O modo de cache CACHE_ALL_STATIC
permite que o Media CDN armazene automaticamente em cache conteúdo estático comum, como vídeo, áudio, imagens e recursos da Web comuns, com base no tipo MIME retornado no cabeçalho de resposta HTTP Content-Type
. No entanto, independente do tipo de mídia, o Media CDN
prioriza qualquer cabeçalho Cache-Control
ou Expires
explícito na resposta
de origem.
A tabela a seguir lista os tipos MIME que podem ser armazenados em cache automaticamente
com o modo de cache CACHE_ALL_STATIC
.
As respostas não serão armazenadas em cache automaticamente se não tiverem um cabeçalho Content-Type
com um valor correspondente aos valores a seguir. Verifique se a resposta define uma diretiva de cache válida ou use o modo de cache FORCE_CACHE_ALL
para armazenar as respostas em cache incondicionalmente.
Categoria | Tipos MIME |
---|---|
Recursos da Web | text/css text/ecmascript text/javascript application/javascript |
Fontes | Qualquer tipo de conteúdo correspondente a font/* |
Imagens | Qualquer tipo de conteúdo correspondente a image/* |
Vídeos | Qualquer tipo de conteúdo correspondente a video/* |
Áudio | Qualquer tipo de conteúdo correspondente a audio/* |
Tipos de documento formatado | application/pdf and application/postscript |
Observações:
- O software servidor da Web da sua origem precisa definir o
Content-Type
para cada resposta. Muitos servidores da Web definem automaticamente o cabeçalhoContent-Type
, incluindo NGINX, Varink e Apache. - O Cloud Storage define o cabeçalho
Content-Type
automaticamente no upload quando você usa o console do Google Cloud ou a ferramentagsutil
para fazer upload de conteúdo. - Se uma resposta puder ser armazenada em cache com base no tipo MIME, mas tiver uma
diretiva de resposta
Cache-Control
deprivate
ouno-store
ou um cabeçalhoSet-Cookie
, ela não será armazenada.
Configurar TTLs de cache
As substituições de time to live (TTL) permitem definir valores de TTL padrão para o conteúdo em cache
e substituir os valores de TTL definidos nas diretivas de controle de cache max-age
e s-maxage
(ou cabeçalhos Expires
) definidas pelas suas origens.
Os TTLs, definidos por substituições ou usando uma diretiva de cache, são otimistas. O conteúdo que raramente é acessado ou não é conhecido pode ser removido do cache antes que o TTL seja atingido.
A tabela a seguir mostra três configurações de TTL.
Configuração | Padrão | Mínimo | Máxima | Descrição | Modos de cache aplicáveis |
---|---|---|---|---|---|
Default TTL | 1 hora (3.600 segundos) |
0 segundo | 1 ano (31.536.000 segundos) |
O TTL a ser definido quando a origem não especificou um cabeçalho Se a origem especificar um cabeçalho Ao usar |
|
Max TTL | 1 dia (86.400 segundos) |
0 segundo | 1 ano (31.536.000 segundos) |
Para respostas armazenáveis em cache, o TTL máximo permitido. Valores maiores que esse são limitados ao valor de maxTtl .
|
CACHE_ALL_STATIC |
Client TTL | Não definido por padrão. | 0 segundo | 1 dia (86.400 segundos) |
Para respostas armazenáveis em cache, o TTL máximo a ser permitido na resposta downstream (voltada para o cliente) se for diferente de outros valores de TTL. |
|
Definir qualquer valor de TTL como zero (0 segundo) faz com que cada solicitação seja revalidada com a origem antes que uma resposta seja disponibilizada e aumenta a carga para a origem se definida de maneira muito ampla.
Quando o modo de cache é definido como Use Origin Headers
, as configurações de TTL não podem ser
definidas porque o Media CDN depende da origem para o comportamento
da unidade.
Observações:
- O valor do TTL máximo precisa ser sempre maior ou igual ao valor do TTL padrão.
- O valor do TTL do cliente precisa ser sempre menor ou igual ao valor do TTL máximo.
- Quando o Media CDN modifica um valor de TTL de origem, o
cabeçalho
Cache-Control
para o cliente também reflete esse valor. - Se a origem definir um cabeçalho
Expires
e o Media CDN substitui o TTL efetivo (com base no carimbo de data/hora), o cabeçalhoExpires
será substituído por um cabeçalhoCache-Control
na resposta downstream para o cliente.
Armazenamento em cache negativo
O armazenamento em cache negativo define como os códigos de status HTTP sem sucesso (aqueles diferentes de 2xx) são armazenados em cache pelo Media CDN.
Isso permite armazenar em cache respostas de erro, como redirecionamentos (HTTP 301 e 308) e respostas não encontradas (HTTP 404) mais próximas dos usuários, bem como reduzir a carga de origem de maneira mais ampla se a resposta não for alterada e puder ser armazenada em cache.
O armazenamento em cache negativo fica desativado por padrão. A tabela a seguir mostra os valores padrão para cada código de status quando o armazenamento em cache negativo está ativado e negativeCachingPolicy
não é usado.
Códigos de status | Frase de motivo | TTL |
---|---|---|
HTTP 300 | Múltipla escolha | 10 minutos |
HTTP 301 e HTTP 308 | Redirecionamento permanente | 10 minutos |
HTTP 404 | Não encontrado | 120 segundos |
HTTP 405 | Método não encontrado | 60 segundos |
HTTP 410 | Gone (Desaparecido) | 120 segundos |
HTTP 451 | Indisponível por motivos legais | 120 segundos |
HTTP 501 | Não implementado | 60 segundos |
O conjunto padrão de códigos de armazenamento em cache negativo corresponde aos códigos de status armazenáveis em cache heurísticos descritos em HTTP RFC 9110, com as seguintes exceções:
- O código HTTP 414 (URI muito longo) não tem suporte para armazenamento em cache para evitar o envenenamento dele.
- O código HTTP 451 (Indisponível por motivos legais) tem suporte para armazenamento em cache, conforme descrito em HTTP RFC 7725.
Se você precisar configurar seus próprios TTLs de código por status e modificar o comportamento
padrão, configure um cdnPolicy.negativeCachingPolicy
. Isso permite
definir o TTL de qualquer um dos códigos de status permitidos pelo Media CDN:
300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451, 500, 501, 502, 503 e
5.
Por exemplo, para definir um TTL curto de cinco segundos para respostas HTTP 404 (não encontrado) e um TTL de 10 segundos para respostas HTTP 405 (Método não permitido), use a seguinte definição YAML em cada rota aplicável:
cdnPolicy: negativeCaching: true negativeCachingPolicy: "404": 5s "405": 10s # other status codes to apply TTLs for
Para evitar o envenenamento do cache, não recomendamos ativar o armazenamento em cache para o
código de status 400 (Solicitação inválida) ou 403 (Proibido). Verifique se o servidor de origem
retorna qualquer um dos códigos como resultado da análise apenas dos componentes da solicitação
incluídos na chave de cache. O envenenamento do cache pode ocorrer, por exemplo, quando
o servidor de origem responde com uma resposta de erro 403 na ausência de um cabeçalho
Authorization
correto. Nesse caso, o armazenamento em cache da resposta de erro 403 faz com que o
Media CDN exiba a resposta de erro 403 a todas as solicitações
subsequentes até que o TTL expire, mesmo que as solicitações tenham um cabeçalho
Authorization
correto.
Para desativar o armazenamento em cache negativo:
- Para desativar o comportamento padrão de armazenamento em cache negativo, defina
cdnPolicy.negativeCaching: false
em uma rota. As respostas de origem com diretivas de cache válidas e códigos de status armazenáveis ainda são armazenadas em cache. - Para evitar o armazenamento em cache negativo para um código de status específico, mas ainda respeitar
as diretivas do cache de origem, omita o código de status
(
cdnPolicy.negativeCachingPolicy[].code
) na sua definição denegativeCachingPolicy
. - Para ignorar explicitamente as diretivas do cache de origem de um código de status
específico, defina
cdnPolicy.negativeCachingPolicy[].ttl
como0
(zero) para esse código de status.
Observações:
- Quando
negativeCaching
está ativado em uma rota e uma resposta define diretivas de cache válidas, as diretivas de cache na resposta têm precedência. - Se você configurar um
negativeCachingPolicy
explícito e houver um TTL definido para o código de status fornecido, o TTL definido na política será sempre usado. - O valor máximo de um TTL definido por
negativeCachingPolicy
é de 1.800 segundos (30 minutos), mas as diretivas de cache de origem com um TTL mais alto são respeitadas. - Se o modo de cache estiver configurado como
FORCE_CACHE_ALL
, as diretivas de origem serão ignoradas em todos os casos.
Diretivas de controle de cache
O comportamento do Media CDN em relação às
diretivas Cache-Control
é definido aqui.
Se a diretiva não for aplicável a uma solicitação ou resposta, como only-if-cached
(uma diretiva somente para cliente), "N/A" será marcado nessa coluna.
Diretiva | Solicitação | Resposta |
---|---|---|
no-cache |
A diretiva de solicitação no-cache é ignorada para evitar que os clientes iniciem ou forçem a revalidação para a origem. |
Uma resposta com Isso pode ser substituído por rota com o modo de cache |
no-store |
A resposta a uma solicitação com no-store não é armazenada em cache. |
Uma resposta com Isso pode ser modificado por rota com o modo de cache |
public |
N/A | Uma resposta com a diretiva Ao usar o cache |
private |
N/A | Uma resposta com a diretiva Isso pode ser substituído por rota com o modo de cache Use |
max-age=SECONDS |
A diretiva da solicitação max-age é ignorada. Uma resposta em cache é retornada como se esse cabeçalho não estivesse incluído na solicitação. | Uma resposta com a diretiva max-age é armazenada em cache até
o SECONDS definido. |
s-maxage=SECONDS |
N/A | Uma resposta com a diretiva Se Observe que |
min-fresh=SECONDS |
A diretiva de solicitação min-fresh é ignorada. Uma resposta em cache
é retornada como se esse cabeçalho não estivesse incluído na solicitação. |
N/A |
max-stale=SECONDS |
A diretiva de solicitação Uma resposta em cache é retornada como se esse cabeçalho não estivesse incluído na solicitação. |
N/A |
stale-while-revalidate=SECONDS |
N/A | Nenhum efeito. Isso é passado ao cliente na resposta. |
stale-if-error=SECONDS |
A diretiva de solicitação stale-if-error é ignorada. Uma resposta em cache é retornada como se esse cabeçalho não estivesse incluído na solicitação. |
Nenhum efeito. Isso é passado ao cliente na resposta. |
must-revalidate |
N/A | Uma resposta com |
proxy-revalidate |
N/A | Uma resposta com |
immutable |
N/A | Nenhum efeito. Isso é passado ao cliente na resposta. |
no-transform |
N/A | Nenhuma transformação é aplicada pelo Media CDN. |
only-if-cached |
A diretiva de solicitação only-if-cached é ignorada. Uma resposta em cache é retornada como se esse cabeçalho não estivesse incluído na solicitação. |
N/A |
Sempre que possível, o Media CDN é compatível com RFC (HTTP RFC 7234), mas favorece a otimização para descarregamento de cache e minimiza o impacto que os clientes podem ter na taxa de hits e na carga geral de origem.
Para respostas que usam o cabeçalho Expires
HTTP/1.1:
- O valor do cabeçalho
Expires
precisa ser uma data HTTP válida, conforme definido na RFC 7231. - Um valor de data no passado, uma data inválida ou um valor de
0
indica que o conteúdo já expirou e requer revalidação. - O Media CDN ignora o cabeçalho
Expires
se um cabeçalhoCache-Control
estiver presente na resposta.
O cabeçalho Pragma
do HTTP/1.0, se presente em uma resposta, é ignorado e transmitido
como está para o cliente.
Chaves de cache
É possível reduzir o número de vezes que o Media CDN precisa entrar em contato com sua origem considerando o que identifica exclusivamente uma solicitação e removendo componentes que podem mudar com frequência entre solicitações. O conjunto de componentes de solicitação é frequentemente chamado de "chave de cache".
As seções a seguir descrevem como configurar chaves de cache.
Componentes da chave de cache
Uma chave de cache é o conjunto de parâmetros de solicitação (como host, caminho e parâmetros de consulta) pelo qual um objeto armazenado em cache é referenciado.
Por padrão, as chaves de cache para serviços de armazenamento em cache de borda incluem o host da solicitação, o caminho e os parâmetros de consulta da solicitação, e têm o escopo definido para um EdgeCacheService específico.
Componente | Incluído por padrão? | Detalhes |
---|---|---|
Protocolo | No | Solicitações por HTTP e HTTPS fazem referência ao mesmo objeto armazenado em cache. Se você quiser retornar respostas diferentes para solicitações http: e https:, defina |
Host | Sim | Hosts diferentes não fazem referência aos mesmos objetos armazenados em cache. Se você tiver vários nomes de host direcionados ao mesmo EdgeCacheService e
eles exibirem o mesmo conteúdo, defina
|
Caminho | Sim | Sempre incluída na chave de cache e não pode ser removida. O caminho é a representação mínima de um objeto no cache. |
Parâmetros de consulta | Sim | Se os parâmetros de consulta não distinguirem entre respostas diferentes,
defina Se apenas alguns parâmetros de consulta precisarem ser incluídos em uma chave de cache, defina |
Cabeçalhos | No | Defina Especificar vários cabeçalhos que se combinam para ter um grande intervalo de valores (por exemplo, os valores de cabeçalho combinados identificam um único usuário) reduz drasticamente a taxa de ocorrência em cache e pode resultar em uma taxa de remoção maior e desempenho reduzido. |
Cookies | No | Defina Especificar vários cookies que se combinam para ter um grande intervalo de valores (por exemplo, os valores de cookie combinados identificam um único usuário) reduz drasticamente a taxa de ocorrência em cache e pode resultar em uma taxa de remoção maior e desempenho reduzido. |
Observações:
- As chaves de cache não estão anexadas a uma origem configurada, permitindo atualizar uma configuração de origem (ou substituí-la totalmente) sem o risco de "liberar" o cache (por exemplo, ao migrar o armazenamento de origem entre provedores).
- As chaves de cache são restritas a um EdgeCacheService. Diferentes EdgeCacheServices têm namespaces de cache distintos, o que impede que você armazene em cache acidentalmente objetos entre ambientes de produção, preparo e outros, mesmo que o host, caminho ou outros componentes da chave de cache sejam correspondentes. A exclusão de um EdgeCacheService invalida todos os objetos armazenados em cache para esse serviço.
- As chaves de cache não têm escopo para uma rota individual. Várias rotas podem se referir à mesma chave de cache, especialmente se elas corresponderem em componentes não incluídos na chave de cache, como cabeçalhos de solicitação ou parâmetros excluídos. Isso pode ser útil se você quiser que várias rotas compartilhem o mesmo cache, mas retornem cabeçalhos de resposta ou configurações do CORS diferentes.
- As chaves de cache não incluem a configuração de regravação de URL. Por exemplo, uma chave de cache é baseada na solicitação do usuário, e não na solicitação "reescrita" final.
- Quando as solicitações assinadas são configuradas em uma rota, os atributos assinados não são incluídos na chave de cache. A solicitação é tratada como se os parâmetros de consulta (assinados)
ou o componente do caminho, começando com
edge-cache-token
e terminando no próximo separador de caminho ("/"), não fizessem parte do URL.
Incluir ou excluir parâmetros de consulta
É possível incluir ou excluir parâmetros de consulta específicos de uma chave de cache adicionando o nome do parâmetro à configuração de chave de cache includedQueryParameters
ou excludedQueryParameters
em uma determinada rota.
Por exemplo, para incluir os parâmetros de consulta contentID
e country
e ignorar todos os outros da chave de cache:
cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 86400s cacheKeyPolicy: includedQueryParameters: ["contentID", "country"]
Inclua os parâmetros de consulta que identificam conteúdo de maneira exclusiva e exclua os que não identificam. Por exemplo, exclua parâmetros de consulta de análise, IDs de sessão de reprodução ou outros parâmetros exclusivos do cliente. Incluir mais parâmetros de consulta do que o necessário pode diminuir as taxas de ocorrência em cache.
Como alternativa, em vez de especificar quais parâmetros incluir na chave de cache, você pode escolher quais parâmetros excluir da chave de cache. Por exemplo, para excluir informações de ID de reprodução e de carimbo de data/hora específicas do cliente da chave de cache, configure o seguinte:
cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 86400s cacheKeyPolicy: excludedQueryParameters: ["playback-id", "timestamp"]
Para uma determinada rota, você pode especificar includedQueryParameters
ou excludedQueryParameters
.
Se os parâmetros de consulta nunca forem usados para identificar conteúdo de maneira exclusiva nas solicitações,
será possível remover todos os parâmetros de consulta da chave de cache para uma rota. Para fazer isso,
defina excludeQueryString
como true
, da seguinte maneira:
cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 3600s cacheKeyPolicy: excludeQueryString: true
Se as solicitações assinadas estiverem ativadas em uma rota, os parâmetros de consulta usados para assinatura não serão incluídos na string de consulta e serão ignorados se forem incluídos. Incluir os parâmetros assinados na chave de cache torna cada solicitação do usuário única e exige que cada solicitação seja exibida a partir da origem.
Classificação de parâmetros de consulta
Os parâmetros de consulta (strings de consulta) são classificados por padrão para melhorar as taxas de ocorrência em cache, porque os clientes podem reordenar ou solicitar o mesmo objeto armazenado em cache com uma ordem diferente dos parâmetros de consulta.
Por exemplo, os parâmetros de consulta b=world&a=hello&z=zulu&p=paris
e
p=paris&a=hello&z=zulu&b=world
são classificados como a=hello&b=world&p=paris&z=zulu
antes da chave de cache ser derivada. Isso permite que ambas as solicitações sejam mapeadas para o mesmo
objeto armazenado em cache, evitando uma solicitação desnecessária para (e uma resposta)
à origem.
Se houver várias instâncias de uma chave de parâmetro de consulta, cada uma com valores
diferentes, os parâmetros serão classificados pelo valor total (por exemplo, a=hello
é
classificado antes de a=world
). Não é possível desativar a classificação.
Incluir cabeçalhos
Os nomes de cabeçalho não diferenciam maiúsculas de minúsculas e são convertidos em minúsculas pelo Media CDN.
Os seguintes cabeçalhos não podem ser incluídos na chave de cache:
- Qualquer cabeçalho que comece com
access-control-
- Qualquer cabeçalho que comece com
sec-fetch-
- Qualquer cabeçalho que comece com
x-amz-
- Qualquer cabeçalho que comece com
x-goog-
- Qualquer cabeçalho que comece com
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 o método HTTP na chave de cache, use o nome de cabeçalho especial
:method
.
Incluir cookies
Os nomes dos cookies diferenciam maiúsculas de minúsculas.
Cookies que começam com edge-cache-
, em qualquer variação de letras maiúsculas e minúsculas, não podem ser usados na chave de cache.
Revalidação, remoção e expiração
As redes de fornecimento de conteúdo, incluindo o Media CDN, operam armazenando em cache o conteúdo mais conhecido o mais próximo possível dos usuários.
O armazenamento extensivo do Media CDN, bem como a proteção de origem, limita a necessidade de remover até mesmo conteúdos impopulares. O conteúdo que é acessado um pequeno número de vezes por dia pode ser removido em algum momento.
- As respostas armazenadas em cache que alcançam o TTL configurado podem não ser removidas imediatamente. Para conteúdos em alta, o Media CDN
revalida que a resposta em cache é a versão mais recente emitindo uma
solicitação
HEAD
para a origem para confirmar que os cabeçalhos não foram alterados. Em algumas circunstâncias, o Media CDN envia uma solicitação para a origem com um ou ambos os cabeçalhos de solicitação:If-None-Match
eIf-Modified-Since
. Nesse caso, as origens configuradas corretamente precisam retornar uma resposta HTTP 304 (não modificado) sem os bytes do corpo, se o cache tiver a cópia "mais recente" dessa resposta. - As respostas que definem uma diretiva de
cache
max-age
ous-maxage
ou que usam uma substituição de TTL para especificar um valor de TTL alto (por exemplo, 30 dias) podem não ser armazenadas em cache para o TTL completo. Não há garantia de que um objeto será armazenado em cache durante todo o período, especialmente se ele não for acessado com frequência.
Se você observar uma alta taxa de remoções, verifique se configurou as chaves de cache para excluir parâmetros que não identifiquem exclusivamente uma resposta.
Outras considerações
As considerações a seguir também podem se aplicar ao armazenamento em cache.
Cabeçalhos Vary
O cabeçalho Vary
indica que a resposta varia de acordo com os cabeçalhos da solicitação do cliente. Se um cabeçalho Vary
estiver presente na resposta,
o Media CDN não o armazenará em cache, a menos que o cabeçalho especifique
um dos cabeçalhos configurados como uma
configuração de chave de cache ou um dos seguintes valores:
- Aceitar:usado para indicar que tipos de mídia o cliente aceita.
- Accept-Encoding:usado para indicar quais tipos de compactação o cliente aceita.
- Available-Dictionary:é usado para fornecer o hash de um dicionário disponível para compactação.
- Origin/X-Origin:normalmente usado para compartilhamento de recursos entre origens.
- X-Goog-Allowed-Resources: oferece suporte à restrição de organizações do Google Cloud
- Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site::usado para buscar cabeçalhos de solicitação de metadados.
O Media CDN armazena em cache as respostas com um cabeçalho Vary
na resposta
usando o valor do cabeçalho como parte da chave de cache. Se o cabeçalho Vary
na resposta tiver vários valores, eles serão classificados lexicograficamente para garantir que a chave de cache seja determinista.
O Media CDN armazena em cache até 100 variantes de uma determinada chave de cache e as remove aleatoriamente do cache além desse limite. Ao invalidar explicitamente o cache de um determinado URL ou tag de cache, todas as variantes serão invalidadas.
Ignorar o cache
É possível configurar o modo de cache BYPASS_CACHE
em uma rota para ignorar intencionalmente o cache em solicitações correspondentes. Isso pode ser útil se você precisar ignorar
o cache para uma pequena fração de tráfego não crítico ou depurar a conectividade
de origem.
Para casos em que você precisa exibir respostas dinâmicas, como back-ends de API, recomendamos configurar um balanceador de carga de aplicativo externo.
Em geral, recomendamos limitar o uso desse recurso a cenários de depuração para evitar uma carga de origem não intencional. O tráfego de saída ao ignorar o cache é cobrado de acordo com as taxas de saída da Internet.
Invalidação de cache
Consulte Invalidação de cache.
Solicitações de intervalo de bytes
O Media CDN é compatível com solicitações de intervalo HTTP de parte única, conforme definido na RFC 7233 (link em inglês).
Além disso, o Media CDN também usa solicitações de intervalo para buscar respostas maiores na origem. Isso permite que o Media CDN armazene os blocos em cache individualmente e não exige que todo o objeto seja buscado de uma só vez para ser armazenado em cache.
- Objetos maiores que 1 MiB são buscados como solicitações de intervalo de bytes ("blocos") de até 2 MiB cada.
- Respostas de até 1 MiB podem ser buscadas sem suporte para intervalos de bytes na origem.
- Respostas maiores que isso não serão exibidas se os intervalos de bytes não tiverem suporte na origem.
O suporte de origem para solicitações de intervalo de bytes é determinado pelo seguinte:
- Um código de status HTTP 200 (OK) ou 206 (Conteúdo parcial).
- Um cabeçalho de resposta
Content-Length
ouContent-Range
válido. - Um validador de resposta (
ETag
ouLast-Modified
).
As solicitações de preenchimento de origem individuais para cada "bloco" (intervalo de bytes) são registradas como
entradas de registro discretas e associadas à solicitação do cliente pai. É possível agrupar essas solicitações com solicitações correspondentes no jsonPayload.cacheKeyFingerprint
.
Para mais detalhes sobre o que é registrado, consulte a documentação do Cloud Logging.
Solicitações de intervalo abertas
O Media CDN oferece suporte a solicitações Range
"abertas" (por exemplo, uma
solicitação com Range: bytes=0-
) que mantêm uma solicitação aberta na origem
até que a resposta seja fechada pela origem (por exemplo, a origem grave todos
os bytes na rede) ou atinja o tempo limite.
Intervalos de bytes abertos normalmente são usados por clientes que solicitam segmentos HLS de baixa latência da Apple. Como cada bloco do CMAF é gravado na rede, a CDN pode armazenar esse bloco em cache e entregá-lo aos clientes.
Em outros casos, como quando a interoperabilidade com o DASH não é necessária, a playlist de mídia indica ao player quais bytes representam cada bloco:
#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
É possível configurar quanto tempo o Media CDN aguarda entre as leituras usando
o valor de configuração EdgeCacheOrigin.timeouts.readTimeout
. Isso
geralmente precisa ser configurado como um múltiplo (por exemplo, o dobro) da duração desejada.
A seguir
- Consulte o roteamento avançado.
- Entenda como se conectar a origens diferentes.
- Configure os certificados TLS (SSL) do serviço.
- Configure solicitações assinadas para autenticar o acesso ao conteúdo.