Configurar o comportamento de armazenamento em cache

O Media CDN serve 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.

É possível controlar como o conteúdo é armazenado em cache para cada rota. Isso permite otimizar com base no tipo de conteúdo, nos atributos de solicitação do cliente e nas suas 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 armazenamento em cache de borda serviço:

  • Modo de cache padrão de CACHE_ALL_STATIC:

    • Respeita as diretivas do cache de origem, como Cache-Control ou Expires. até um TTL máximo configurável.
    • Armazena em cache tipos de mídia estática automaticamente com uma TTL padrão de 3.600 s, se nenhuma diretiva de cache de origem estiver presente.
    • Armazena em cache os códigos de status HTTP 200 e 206. O armazenamento em cache negativo não está ativado.

  • Não armazena em cache respostas com controle de cache no-store ou private diretivas ou que não podem ser armazenadas em cache.

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 armazenados em cache, a menos que ele esteja explicitamente configurado. 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 comporta como se tivesse o 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 todos os recursos HTTP as respostas são armazenáveis em cache.

Você pode configurar os modos de cache para cada rota para substituir esse (por exemplo, usar o modo de cache CACHE_ALL_STATIC para armazenar em cache de mídia, mesmo se a origem não definir um diretiva de controle de cache na resposta.

Solicitações e respostas que atendem aos critérios definidos no respostas não armazenáveis em cache substitui 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, 503 ou 504.
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 um armazenamento em cache HTTP válido diretiva, como Cache-Control: max-age=3600, public.

tem um modo de cache que armazena esse conteúdo em cache ou tem um Cabeçalho Expires com uma data no futuro.
Tamanho da resposta Até 100 GiB.

O cabeçalho HTTP Age está definido com base em quando o Media CDN armazenar em cache a resposta pela primeira vez e, normalmente, representa os segundos desde que o objeto foi armazenado em cache local de proteção de origem. Se as origem gera um cabeçalho de resposta de idade, use o modo de cache FORCE_CACHE_ALL para evitar revalidação quando a idade excede o TTL do cache.

Para mais informações sobre como o Media CDN interpreta o armazenamento em cache HTTP diretivas de controle de cache, 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 precisará incluir o seguinte nos cabeçalhos de resposta para solicitações HEAD e GET, a menos que especificado de outra forma:

  • Um cabeçalho de resposta HTTP Last-Modified ou ETag (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ção Range GET. O cabeçalho Content-Range precisa ter um valor válido no formato bytes x-y/z (em que z é o tamanho do objeto).

O protocolo de origem padrão é HTTP/2. Se as origens só oferecem suporte a HTTP/1.1, defina o campo de protocolo explicitamente para cada origem.

Respostas não armazenáveis em cache

A tabela a seguir detalha os atributos de solicitação e resposta que impedem uma resposta seja armazenada em cache. As respostas que podem ser armazenadas em cache, mas que correspondem aos critérios "não armazenáveis", não são armazenadas em cache.

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 problemas do cliente, e não o status de origem. Armazenar essas respostas em cache pode levar a envenenamento" cenários em que um usuário considerou resposta é armazenada em cache para todos os usuários.
Cabeçalhos de solicitação

Para solicitações com uma solicitação Authorization cabeçalho, as respostas devem incluir um controle de cache public a ser armazenada em cache.

Uma diretiva no-store na solicitação faz com que a resposta não seja armazenada em cache. Para mais informações, consulte Diretivas de controle de cache.
Cabeçalhos de resposta

Tem um cabeçalho Set-Cookie.

Tem um cabeçalho Vary diferente de Accept, Accept-Encoding, Origin, X-Origin, X-Goog-Allowed-Resources, Sec-Fetch-Dest, Sec-Fetch-Mode ou Sec-Fetch-Site.

Em CACHE_ALL_STATIC ou O modo USE_ORIGIN_HEADERS, com um no-store ou private.
Tamanho da resposta Ter mais de 100 GiB.

Essas regras são aplicadas além do modo de cache configurado. Especificamente:

  • Com o modo de cache CACHE_ALL_STATIC configurado, somente as respostas considerados um conteúdo estático ou respostas diretivas de cache válidas nos cabeçalhos de resposta. são armazenados em cache. As outras respostas são endereçadas por proxy.
  • 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 sejam definidas 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 diretivas de controle de cache ou outros cabeçalhos alterados e usados por proxy no estado em que se encontram.
  • As respostas podem ter os cabeçalhos Cache-Control e Expires recolhidos em um único campo Cache-Control. Por exemplo, uma resposta com Cache-Control: public e Cache-Control: max-age=100 em linhas separadas seria compactada como Cache-Control: public,max-age=100.
  • Respostas não armazenáveis em cache (respostas que nunca seriam armazenadas em cache) não são contadas 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 diretivas do cache de origem, armazenar em cache tipos de mídia estática 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 automaticamente armazena em cache tipos comuns de mídia estática por 1 hora (3600 segundos), enquanto prioriza quaisquer diretivas de cache especificadas pela origem para respostas armazenáveis em cache.
  • É possível aumentar ou diminuir o TTL do cache aplicado às respostas sem um TTL de cache explícito (uma diretiva max-age ou s-maxage) definindo o campo cdnPolicy.defaultTtl em uma rota.
  • Para evitar o armazenamento em cache de respostas não bem-sucedidas por mais tempo do que o esperado, os códigos de status não 2xx (não bem-sucedidos) 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 do Compute Engine, são mostrados na tabela a seguir.

Modo cache Comportamento
USE_ORIGIN_HEADERS Requer respostas de origem para definir diretivas de cache e armazenamento em cache válidos e cabeçalhos de cache válidos. Para uma lista completa dos 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 tenham uma no-store ou private diretiva. As diretivas de armazenamento em cache válidas da origem são priorizadas.

O conteúdo estático inclui vídeo, áudio, imagens e recursos comuns da Web, como definido pelo tipo MIME na resposta Content-Type cabeçalho.
FORCE_CACHE_ALL

Armazena incondicionalmente as respostas em cache, substituindo as diretivas de cache definidas pela origem.

Não veicule 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 no cache, mesmo que haja um objeto em cache que corresponda a essa chave.

Recomendamos usar esse recurso apenas para depuração, porque o Media CDN foi desenvolvido como uma infraestrutura de cache em escala global, e não como uma ferramenta proxy.

Tipos MIME de conteúdo estático

O modo de cache CACHE_ALL_STATIC permite que o Media CDN armazenar em cache automaticamente conteúdo estático comum, como vídeo, áudio, imagens e recursos da Web comuns baseados no tipo MIME retornado na solicitação HTTP Content-Type no cabeçalho da resposta. No entanto, seja qual for o tipo de mídia, o Media CDN prioriza qualquer cabeçalho Cache-Control ou Expires explícito na origem resposta.

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 são armazenadas em cache automaticamente se não tiverem um Content-Type com um valor que corresponda aos seguintes valores. Você precisa garantir que a resposta define uma diretiva de cache válida ou use o modo de cache FORCE_CACHE_ALL para armazenar em cache incondicionalmente de resposta.

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

Observe o seguinte:

  • O software servidor da Web de origem precisa definir o Content-Type como para cada resposta. Muitos servidores da Web definem automaticamente o cabeçalho Content-Type, incluindo NGINX, Varnish e Apache.
  • O Cloud Storage define o cabeçalho Content-Type. automaticamente no upload quando você usa o console do Google Cloud ou a CLI gcloud para fazer upload do conteúdo.
  • Se uma resposta puder ser armazenada em cache com base no tipo MIME, mas tiver uma diretiva de resposta Cache-Control de private ou no-store ou um cabeçalho Set-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 armazenado em cache. e modificar os valores de TTL definidos no controle de cache max-age e s-maxage diretivas (ou cabeçalhos Expires) definidas pelas origens.

Os TTLs, definidos por substituições ou usando uma diretiva de cache, são otimista. O conteúdo que raramente é acessado ou incomum pode ser removido do cache antes do TTL ser alcançado.

A tabela a seguir mostra três configurações de TTL.

Configuração Padrão Mínimo Máximo 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 especificar um cabeçalho max-age ou s-maxage.

Se a origem especificar um cabeçalho s-maxage, ele será usado em vez do valor de TTL padrão aqui.

Ao usar FORCE_CACHE_ALL para armazenar todos os itens em cache incondicionalmente o TTL padrão é usado para definir o TTL do cache. Todos os outros valores e as diretivas serão ignoradas.

CACHE_ALL_STATIC

FORCE_CACHE_ALL
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 valor é limitado ao valor de maxTtl. CACHE_ALL_STATIC
Client TTL Não definida por padrão. 0 segundo 1 dia
(86.400 segundos)		 Para respostas armazenáveis em cache, o TTL máximo permitido ao servidor (voltada para o cliente) se precisar ser diferente de outro TTL e a distribuição dos valores dos dados.

CACHE_ALL_STATIC

FORCE_CACHE_ALL

Definir qualquer valor de TTL como zero (0 segundo) faz com que todas as solicitações sejam revalidadas com a origem antes que uma resposta seja entregue e aumenta a carga para a origem se muito amplos.

Quando o modo de cache é definido como Use Origin Headers, as configurações de TTL não podem ser configurado porque o Media CDN depende da origem para gerar do seu modelo.

Observações:

  • O valor do TTL máximo sempre deve ser maior (ou igual ao) valor de o TTL padrão.
  • O valor do TTL do cliente precisa ser sempre menor (ou igual a) o valor. do TTL máximo.
  • Quando o Media CDN substitui um valor de TTL de origem, o 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çalho Expires é substituído por um cabeçalho Cache-Control na resposta downstream ao para o cliente.

Armazenamento em cache negativo

O cache negativo define como os códigos de status HTTP que não são de sucesso (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, além de reduzir a origem de carga de forma 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 valores para cada código de status quando o armazenamento em cache negativo estiver 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 cache negativo corresponde aos códigos que podem ser armazenados em cache heurísticos códigos de status 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 a contaminação do cache.
  • O código HTTP 451 (Indisponível por motivos legais) tem suporte para armazenamento em cache, como descritos em HTTP RFC 7725.

Se você precisar configurar seus próprios TTLs de código por status e substituir o padrão comportamento, configure um cdnPolicy.negativeCachingPolicy. Isso permite definir o TTL para qualquer um dos códigos de status permitidos pela CDN de mídia: 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451, 500, 501, 502, 503 e 504.

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 o a seguir 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 código de status 400 (Solicitação inválida) ou 403 (Proibido). Verifique se o servidor de origem retorna um dos códigos como resultado da análise apenas dos componentes da solicitação que estã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 uma resposta Cabeçalho Authorization. Nesse caso, o armazenamento em cache da resposta de erro 403 resulta O Media CDN que veicula a resposta de erro 403 para todos os até que o TTL expire, mesmo que as solicitações tenham um Cabeçalho Authorization.

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 em cache ainda são armazenadas em cache.
  • Para evitar o armazenamento em cache negativo para um código de status específico, mas ainda respeite diretivas do cache de origem, omitem o código de status (cdnPolicy.negativeCachingPolicy[].code) no seu negativeCachingPolicy definição.
  • Ignorar explicitamente as diretivas do cache de origem para um status específico , defina cdnPolicy.negativeCachingPolicy[].ttl como 0 (zero) para isso. .

Observações:

  • Quando o 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 é 1.800 segundos (30 minutos), mas as diretivas do cache de origem com TTL mais alto são respeitadas.
  • Se o modo de cache estiver configurado como FORCE_CACHE_ALL, a origem serão ignoradas em todos os casos.

Diretivas de controle de cache

Comportamento do Media CDN em relação ao Diretivas Cache-Control é definida aqui.

Se a diretiva não for aplicável a uma solicitação ou resposta, como only-if-cached (uma diretiva somente para cliente), depois "N/A" está marcado na 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 no-cache é armazenada em cache, mas requer validação com a origem antes de ser veiculada.

Isso pode ser substituído por trajeto com o parâmetro Modo de cache FORCE_CACHE_ALL.
no-store A resposta a uma solicitação com no-store não é armazenada em cache.

Uma resposta com no-store não é armazenada em cache.

Isso pode ser modificado por rota com o modo de cache FORCE_CACHE_ALL.
public N/A

Uma resposta com a diretiva public é armazenada em cache se for considerada armazenável em cache como um todo e se a resposta tiver uma diretiva max-age ou s-maxage.

Ao usar o cache do CACHE_ALL_STATIC ou FORCE_CACHE_ALL. Isso não é necessário.
private N/A

Uma resposta com a diretiva private não é armazenada em cache pelo CDN de mídia, mesmo que a resposta seja considerada armazenável em cache. Os clientes (como navegadores) ainda podem armazenar o resultado em cache.

Isso pode ser substituído por trajeto com o parâmetro Modo de cache FORCE_CACHE_ALL.

Use no-store para evitar todo o armazenamento em cache de respostas.
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 s-maxage é armazenada em cache até o SECONDS definido.

Se max-age e s-maxage estiverem presentes, s-maxage é usado pelo servidor.

s-max-age (dois hifens) não é válido para para fins de armazenamento em cache.
min-fresh=SECONDS A diretiva de solicitação min-fresh é ignorada. Uma resposta armazenada em cache é retornado como se esse cabeçalho não estivesse incluído na solicitação. N/A
max-stale=SECONDS

A diretiva de solicitação max-stale é ignorada.

Uma resposta em cache é retornada como se esse cabeçalho não estivesse incluído no da 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 must-revalidate é revalidada com no servidor de origem depois que ele expirar.
proxy-revalidate N/A

Uma resposta com proxy-revalidate é revalidada com a origem servidor após a expiração.
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

Quando possível, o Media CDN é compatível com RFC (HTTP RFC 7234), mas a favor. otimizar o descarregamento de cache e minimizar o impacto que os clientes podem ter taxa de hits e carga geral da 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, como definido na RFC 7231
  • Uma 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 Cache-Control cabeçalho está presente na resposta.

O cabeçalho Pragma do HTTP/1.0, se presente em uma resposta, é ignorado e transmitido. da forma como estão para o cliente.

Chaves de cache

É possível reduzir o número de vezes que o Media CDN precisa entrar em contato com seu origem considerando o que identifica exclusivamente uma solicitação e removendo componentes que podem mudar com frequência. O conjunto de solicitações componentes são muitas vezes chamados 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 consulta parâmetros) que servem de referência a um objeto armazenado em cache.

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 parâmetros de consulta da solicitação, e têm como escopo um escopo EdgeCacheService.

Componente Incluído por padrão? Detalhes
Protocolo Não

As 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 cacheKeyPolicy.includeProtocol como verdadeiro nos rotas de prioridade mais alta.
Host Sim

Os 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 estiverem exibindo o mesmo conteúdo, defina cdnPolicy.excludeHost como verdadeiro.
Caminho Sim Sempre incluído na chave de cache e não pode ser removido. O caminho é representação mínima de um objeto em cache.
Parâmetros de consulta Sim

Se os parâmetros de consulta não distinguirem entre respostas diferentes, Defina cacheKeyPolicy.excludeQueryString como verdadeiro.

Se apenas alguns parâmetros de consulta precisarem ser incluídos em uma chave de cache, defina includedQueryParameters ou excludedQueryParameters, conforme apropriado.
Cabeçalhos Não

Defina cacheKeyPolicy.includedHeaderNames com os nomes dos cabeçalhos a serem incluídos na chave de cache.

Especificar vários cabeçalhos que se combinam para ter uma grande variedade de (por exemplo, os valores do 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 Não

Definir cacheKeyPolicy.includedCookieNames com os nomes de cookies para incluir na chave de cache.

Especificar vários cookies que se combinam para ter uma grande variedade de (por exemplo, os valores de cookies 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.

Observe o seguinte:

  • As chaves de cache não estão anexadas a uma origem configurada, permitindo que você atualize uma configuração de origem (ou substituí-la totalmente) sem risco de "limpeza" 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 diferentes namespaces de cache, o que impede você de armazenar em cache acidentalmente objetos entre ambientes de produção, preparação e outros, mesmo se o host, caminho ou outros componentes da chave de cache vão corresponder. 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 específica. Várias rotas podem se referir à mesma chave de cache, especialmente se essas rotas corresponderem a componentes que não estão incluídas 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 retornam cabeçalhos de resposta ou configurações do CORS diferentes.
  • As chaves de cache não incluem a configuração de substituição de URL. Por exemplo, uma chave de cache é baseada na solicitação voltada ao usuário e não na solicitação "reescrita" final.
  • Quando as solicitações assinadas são configuradas em uma rota, os atributos assinados são não incluídos na chave de cache. A solicitação é tratada como se a sinalização parâmetros de consulta ou componente de caminho, começando com edge-cache-token e que terminam no próximo separador de caminho ("/"), não fazem parte do URL.

Incluir ou excluir parâmetros de consulta

Para incluir ou excluir parâmetros de consulta específicos de uma chave de cache, adicione o nome do parâmetro para includedQueryParameters ou excludedQueryParameters a configuração da chave de cache 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 o conteúdo de maneira exclusiva. excluir os que não têm. Por exemplo, excluir parâmetros de consulta de análise, IDs de sessão de reprodução ou outros parâmetros que são exclusivos apenas 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 no cache chave, é possível escolher quais parâmetros excluir da chave de cache. Por exemplo, para excluir o ID de reprodução específico do cliente e as informações de carimbo de data/hora da chave do cache, configure o seguinte:

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

Para um determinado trajeto, você pode especificar includedQueryParameters ou excludedQueryParameters.

Se os parâmetros de consulta nunca forem usados para identificar exclusivamente o conteúdo em todas as solicitações, você poderá remover todos os parâmetros de consulta da chave de cache de uma rota. Faça isso até definindo 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, parâmetros de consulta usados para assinatura não estão incluídos na string de consulta e são ignorada se incluída. Como incluir os parâmetros assinados na chave de cache efetivamente torna cada solicitação do usuário única e exige que cada solicitação veiculados 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 a ocorrência em cache. porque os clientes podem encomendar novamente ou solicitar as mesmas com uma ordem diferente de 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 foram classificadas como a=hello&b=world&p=paris&z=zulu antes da derivação da chave de cache. Isso permite que ambas as solicitações sejam mapeadas para o mesmo objeto em cache, evitando uma solicitação desnecessária para (e uma resposta) ao 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 completo. Por exemplo, a=hello é classificado antes de a=world. A classificação não pode ser desativada.

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 do Google Cloud.

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 ou minúsculas letras não podem ser usadas na chave de cache.

Revalidação, remoção e expiração

As redes de fornecimento de conteúdo, incluindo o Media CDN, operam pela armazenar em cache o conteúdo mais acessado e o mais próximo possível dos usuários.

O amplo armazenamento do Media CDN, assim como proteção de origem, limita a necessidade de remover até mesmo informações conteúdo. O conteúdo que é acessado um pequeno número de vezes por dia pode acabarem sendo despejados.

  • As respostas armazenadas em cache que alcançam o TTL configurado podem não ser imediatamente removido. Para conteúdo popular, o Media CDN revalida se a resposta armazenada em cache é a versão mais recente emitindo uma solicitação HEAD para a origem para confirmar se 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 e If-Modified-Since. Nesse caso, origens configuradas corretamente devem retornar um erro HTTP 304 (Não modificado) sem os bytes do corpo, caso o cache tenha a tag "latest" cópia de essa resposta.
  • Respostas que definem um cache de max-age ou s-maxage ou que usam uma TTL substituir para especificar um valor de TTL alto (por exemplo, 30 dias) podem não ser armazenadas em cache pelo TTL completo. Não há garantia que um objeto seja armazenado em cache durante todo o período, principalmente se o acesso não for frequente.

Se você observar uma alta taxa de remoções, certifique-se de ter configurou suas chaves de cache para excluir parâmetros que não identificam exclusivamente um 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 a solicitação cabeçalhos de solicitação. Se um cabeçalho Vary estiver presente na resposta, O Media CDN não o armazena em cache, a menos que o cabeçalho especifique um dos cabeçalhos configurados como configuração da 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 valor dicionário para compactação
  • Origin/X-Origin:normalmente usado para compartilhamento de recursos entre origens.
  • X-Goog-Allowed-Resources: oferece suporte à organização do Google Cloud restrição
  • Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site: usado para buscar solicitação de metadados cabeçalhos

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 no a resposta tiver diversos valores, eles serão classificados lexicograficamente para garantir se a chave de cache é determinista.

O Media CDN armazena em cache até 100 variantes para uma determinada chave de cache e remove variantes do cache que ultrapassam esse limite. Quando você invalida explicitamente o cache de um determinado URL ou tag de cache, todas as variantes são invalidadas.

Ignorar o cache

É possível configurar o modo de cache BYPASS_CACHE em uma rota para ignorar o cache em solicitações correspondentes. Isso pode ser útil se você precisar ignorar o cache para uma pequena fração do tráfego não crítico ou para depurar a origem conectividade.

Nos casos em que é necessário veicular respostas dinâmicas, como back-ends de API, nós recomendamos a configuração de um balanceador de carga de aplicativo externo.

É recomendável limitar o uso desse recurso a cenários de depuração para evitar a carga de origem não intencional. O tráfego de saída ao ignorar o cache é com as taxas de saída de 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 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 armazenar blocos em cache individualmente e não exige que todo o objeto seja buscado; sejam armazenados em cache por vez.

  • 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 essas não serão exibidas se os intervalos de bytes não forem suportados em origem.

O suporte da origem para solicitações de intervalo de bytes é determinado por:

  • Um código de status HTTP 200 (OK) ou 206 (Conteúdo parcial).
  • Um cabeçalho de resposta Content-Length ou Content-Range válido.
  • Um validador de resposta (ETag ou Last-Modified).

Solicitações de preenchimento de origem individuais para cada "bloco" (intervalo de bytes) são registrados como entradas de registro discretas e associadas à solicitação do cliente pai. Você pode agrupar essas solicitações correspondendo às solicitações 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 "abertas" Solicitações Range (por exemplo, uma solicitação com Range: bytes=0-) que mantêm uma solicitação aberta na origem até que a resposta seja encerrada pela origem (por exemplo, a origem grava todos (bytes ao fio) ou tempo limite.

Intervalos de bytes abertos geralmente são usados por clientes que solicitam HLS de baixa latência à medida que cada bloco do CMAF é gravado na rede, o CDN pode armazenar em cache entregar essa parte 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 o tempo que o Media CDN espera entre as leituras usando o valor de configuração EdgeCacheOrigin.timeouts.readTimeout. Isso deve normalmente ser configurada para um múltiplo (por exemplo, o dobro) da duração desejada.

A seguir