Configure o comportamento de colocação em cache

A RFC de conteúdo multimédia publica conteúdo o mais próximo possível dos utilizadores através da infraestrutura de colocação em cache na extremidade global da Google para colocar conteúdo em cache e reduzir a carga na infraestrutura de origem.

Pode controlar a forma como o conteúdo é colocado em cache para cada trajeto. Isto permite-lhe otimizar o comportamento com base no tipo de conteúdo, nos atributos do pedido do cliente e nos seus requisitos de atualidade.

Capacidade de colocação em cache

As secções seguintes descrevem as respostas que a RFC de conteúdo multimédia armazena em cache e como melhorar o descarregamento da cache.

Comportamento de colocação em cache predefinido

Por predefinição, as seguintes definições relacionadas com a cache aplicam-se a cada serviço de cache na extremidade:

• Modo de cache predefinido de CACHE_ALL_STATIC:

  • Respeita as diretivas de cache de origem, como Cache-Control ou Expires, até um TTL máximo configurável.
  • Coloca automaticamente em cache tipos de suportes estáticos com um TTL predefinido de 3600 s, se não estiverem presentes diretivas de cache de origem.
  • Coloca em cache os códigos de estado HTTP 200, 204 e 206 (a colocação em cache negativa não está ativada).

• Não coloca em cache respostas que tenham diretivas de controlo de cache no-store ou private ou que não sejam colocá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 colocadas em cache, a menos que a colocação em cache esteja explicitamente configurada. Para saber como substituir o comportamento predefinido, consulte a documentação sobre os modos de cache .

O comportamento predefinido é equivalente ao seguinte cdnPolicy. As rotas sem um cdnPolicy explícito configurado comportam-se 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 compatíveis com a cache

Uma resposta memorizável em cache é uma resposta HTTP que a RFC pode armazenar e obter rapidamente, o que permite tempos de carregamento mais rápidos. Nem todas as respostas HTTP são armazenáveis em cache.

Pode configurar modos de cache para cada rota de modo a substituir este comportamento (por exemplo, usando o modo de cache CACHE_ALL_STATIC para colocar em cache tipos de multimédia comuns), mesmo que a origem não defina uma diretiva de controlo de cache na resposta.

Os pedidos e as respostas que cumprem os critérios definidos nas respostas não armazenáveis em cache substituem a capacidade de armazenamento em cache.

A tabela seguinte descreve os requisitos para colocar em cache respostas HTTP específicas. Ambas as respostas GET e HEAD têm de cumprir estes requisitos.

O cabeçalho HTTP Age é definido com base no momento em que a RFC de multimédia colocou a resposta em cache pela primeira vez e representa normalmente os segundos desde que o objeto foi colocado em cache numa localização de proteção de origem. Se a sua origem gerar um cabeçalho de resposta Age, use o FORCE_CACHE_ALLcache mode para evitar revalidações quando a idade exceder o TTL da cache.

Para mais informações sobre como a RFC interpreta as diretivas de colocação em cache HTTP, consulte o artigo Diretivas de controlo da cache.

Requisitos de origem

Para permitir que a RFC de multimédia na nuvem armazene em cache respostas de origem com mais de 1 MiB, uma origem tem de incluir o seguinte nos cabeçalhos das respostas para pedidos GET, salvo indicação em contrário:

• 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 da resposta Content-Range, em resposta a um pedido Range GET. O cabeçalho Content-Range tem de ter um valor válido no formato bytes x-y/z (em que z é o tamanho do objeto).

O protocolo de origem predefinido é HTTP/2. Se as suas origens apenas suportarem HTTP/1.1, pode definir o campo de protocolo explicitamente para cada origem.

Respostas não armazenáveis em cache

A tabela seguinte detalha os atributos de pedido e resposta que impedem que uma resposta seja colocada em cache. As respostas que podem ser colocadas em cache, mas que correspondem a critérios "não colocáveis em cache", não são colocadas em cache.

Estas regras aplicam-se além do modo de cache configurado. Em concreto:

• Com o modo de cache CACHE_ALL_STATIC configurado, apenas as respostas consideradas conteúdo estático ou respostas com diretivas de cache válidas nos respetivos cabeçalhos de resposta são colocadas em cache. Outras respostas são enviadas através de proxy tal como estão.
• O modo de cache FORCE_CACHE_ALL armazena em cache todas as respostas incondicionalmente, sujeito aos requisitos de não armazenabilidade em cache indicados anteriormente.
• O modo de cache USE_ORIGIN_HEADERS requer que as respostas definam diretivas de cache válidas nos respetivos cabeçalhos de resposta, além de serem um código de estado armazenável em cache.

Notas:

• As respostas que não estão em cache não têm as respetivas diretivas de controlo de cache nem outros cabeçalhos alterados e são encaminhadas por proxy tal como estão.
• As respostas podem ter os cabeçalhos Cache-Control e Expires reduzidos num único campo Cache-Control. Por exemplo, uma resposta com Cache-Control: public e Cache-Control: max-age=100 em linhas separadas seria reduzida a Cache-Control: public,max-age=100.
• As respostas não memorizáveis em cache (respostas que nunca seriam memorizadas em cache) não são contabilizadas do ponto de vista da faturação.Cache Egress

Usar modos de cache

Os modos de cache permitem-lhe configurar quando a RFC de multimédia deve respeitar as diretivas de cache de origem, colocar em cache tipos de multimédia estáticos e colocar em cache todas as respostas da origem, independentemente das diretivas definidas.

Os modos de cache são configurados ao nível da rota e, quando combinados com substituições de TTL, permitem-lhe configurar o comportamento da cache por anfitrião, caminho, parâmetros de consulta e cabeçalhos (quaisquer parâmetros de pedido correspondentes).

• Por predefinição, a RFC usa o modo de cache CACHE_ALL_STATIC, que coloca automaticamente em cache tipos de multimédia estáticos comuns durante 1 hora (3600 segundos), ao mesmo tempo que dá prioridade a quaisquer diretivas de cache especificadas pela origem para respostas colocáveis em cache.
• Pode aumentar ou diminuir o TTL da cache aplicado às respostas sem um TTL da cache explícito definido (uma diretiva max-age ou s-maxage) definindo o campo cdnPolicy.defaultTtl numa rota.
• Para evitar o armazenamento em cache de respostas sem êxito durante mais tempo do que o pretendido, os códigos de estado não 2xx (sem êxito) não são armazenados em cache de acordo com o respetivo Content-Type (tipo MIME) e não têm o TTL predefinido aplicado.

Os modos de cache disponíveis, que são definidos no cdnPolicy.cacheMode de cada rota, são apresentados na tabela seguinte.

Tipos MIME de conteúdo estático

O modo de cache CACHE_ALL_STATIC permite que a CDN de multimédia coloque automaticamente em cache conteúdo estático comum, como vídeo, áudio, imagens e recursos Web comuns, com base no tipo MIME devolvido no cabeçalho de resposta HTTP Content-Type. No entanto, independentemente do tipo de suporte, a RFC prioriza todos os cabeçalhos Cache-Control ou Expires explícitos na resposta de origem.

A tabela seguinte lista os tipos MIME que podem ser colocados automaticamente em cache com o modo de cache CACHE_ALL_STATIC.

As respostas não são automaticamente colocadas em cache se não tiverem um Content-Type cabeçalho de resposta com um valor que corresponda aos seguintes valores. Tem de garantir que a resposta define uma diretiva de cache válida ou tem de usar o modo de cache FORCE_CACHE_ALL para colocar em cache incondicionalmente as respostas.

Tenha em conta o seguinte:

• O software do servidor Web da sua origem tem de definir o Content-Type para cada resposta. Muitos servidores Web definem automaticamente o cabeçalho Content-Type, incluindo NGINX, Varnish e Apache.
• O Cloud Storage define o cabeçalho Content-Type automaticamente no carregamento quando usa a Google Cloud consola ou a CLI gcloud para carregar conteúdo.
• O Cloud Storage envia sempre um cabeçalho Cache-Control para a RFC de multimédia. Se não for escolhido explicitamente nenhum valor, é enviado um valor predefinido. Como resultado, todas as respostas bem-sucedidas do Cloud Storage são colocadas em cache de acordo com os valores predefinidos do Cloud Storage, a menos que ajuste explicitamente os metadados de controlo da cache para objetos no Cloud Storage ou use o modo FORCE_CACHE_ALL para substituir os valores enviados pelo Cloud Storage.

Se uma resposta for armazenável em cache com base no respetivo tipo MIME, mas tiver uma diretiva de resposta Cache-Control de private ou no-store, ou um cabeçalho Set-Cookie, não é armazenada em cache.

Outros tipos de suportes, como HTML (text/html) e JSON (application/json), não são colocados em cache por predefinição. Estes tipos de respostas são normalmente dinâmicos (por utilizador) e também não são adequados para a arquitetura da rede de distribuição de conteúdos multimédia. Recomendamos a utilização da CDN da nuvem para publicar recursos Web e para colocar em cache as respostas da API.

Configure os TTLs da cache

As substituições do tempo de vida (TTL) permitem-lhe definir valores de TTL predefinidos para conteúdo em cache e substituir os valores de TTL definidos nas diretivas de controlo de cache max-age e s-maxage (ou cabeçalhos Expires) definidos pelas suas origens.

Os TTLs, quer sejam definidos por substituições ou através de uma diretiva de cache, são otimistas. O conteúdo ao qual se acede raramente ou que é impopular pode ser removido da cache antes de o TTL ser alcançado.

A tabela seguinte mostra três definições de TTL.