Práticas recomendadas de envio de conteúdo

Esta página fornece as práticas recomendadas para otimizar e acelerar o envio de conteúdo com o Cloud CDN. As seções são divididas em várias áreas principais.

O Cloud CDN usa um balanceador de carga de aplicativo externo como a origem de conteúdos armazenáveis em cache. Um balanceador de carga de aplicativo externo pode veicular uma combinação de conteúdo estático e dinamicamente criado para os usuários usando um endereço IP global dos seguintes tipos de back-ends:

Devido à integração total com o Google Cloud, existem várias opções para implantar o Cloud CDN e gerenciar conteúdo. Use as práticas recomendadas listadas aqui para planejar e refinar a implantação. Para mais informações, consulte Configurar o Cloud CDN.

Otimizar a proporção de ocorrência em cache

As práticas recomendadas a seguir ajudam a otimizar a proporção de ocorrência em cache.

Armazenar em cache conteúdo estático

Como prática recomendada para melhorar o desempenho, ao ativar o Cloud CDN, é preciso escolher o modo de cache correto para o aplicativo.

O método mais flexível e geralmente preferível para gerenciar regras de cache é usar o cabeçalho de controle de cache. Se você não conhecer bem o uso de cabeçalhos de controle de cache de origem, a prática recomendada é permitir que o Cloud CDN armazene conteúdo estático em cache automaticamente.

Para armazenar em cache automaticamente respostas estáticas da origem, use a configuração --cache-mode=CACHE_ALL_STATIC (padrão). Essa configuração permite que o Cloud CDN armazene em cache os tipos de conteúdo estático comuns quando a origem não especifica diretivas de armazenamento em cache nos cabeçalhos de resposta. Verifique se o conteúdo corresponde às categorias descritas. Caso contrário, ele não será armazenado em cache.

Não armazene em cache conteúdo específico do usuário

Em alguns casos, os navegadores podem armazenar em cache conteúdo específico do usuário. Não use o Cloud CDN para armazenar em cache conteúdo específico do usuário.

Usar chaves de cache personalizadas para melhorar a proporção de ocorrência em cache

Para desempenho e escalabilidade, é importante otimizar a proporção de ocorrência em cache. Por padrão, o Cloud CDN usa o URL de solicitação completo para criar a chave de cache. Para ajudar a otimizar a proporção de ocorrência em cache, use chaves de cache personalizadas para que o Cloud CDN não fragmente o cache desnecessariamente.

Armazenamento de chave-valor do Cloud CDN (clique para ampliar).

As chaves de cache personalizadas permitem a inclusão ou a omissão de qualquer combinação de protocolo, host e string de consulta. Veja a seguir alguns exemplos de quando usar chaves de cache personalizadas:

  • Existem dois hosts resolvidos para o mesmo endereço IP e acessando o mesmo serviço. Neste exemplo, todo o site é o mesmo nos dois hosts. Por padrão, o Cloud CDN armazena em cache duas cópias devido ao cabeçalho Host: diferente nas solicitações HTTP. Com uma chave de cache personalizada é possível fazer com que o Cloud CDN ignore a parte do host da solicitação e compartilhe as entradas do cache.

  • Em um exemplo mais específico, é possível ter dois sites em domínios diferentes que usam o mesmo logotipo. O conteúdo do site é diferente, mas é usado o mesmo logotipo de empresa nos dois domínios e existe um serviço de back-end dedicado que contém conteúdo compartilhado. Ao ativar o Cloud CDN e personalizar as chaves de cache do serviço de back-end que contém o logotipo, desmarque a caixa de seleção Host para que o cache ignore o domínio, mas armazene o logotipo.

  • É preciso que um logotipo seja armazenado em cache ao ser exibido por HTTP ou por HTTPS. Ao serem personalizadas as chaves de cache para o serviço de back-end que contém o logotipo, limpe a caixa de seleção Protocolo para que as solicitações por HTTP e HTTPS contem como correspondências para a entrada de cache do logotipo.

Para saber como personalizar chaves de cache, consulte Como usar chaves de cache.

Otimizar o desempenho

As práticas recomendadas a seguir ajudam a otimizar o desempenho.

Verificar se o suporte ao protocolo HTTP/3 e QUIC está ativado

O HTTP/3 é um protocolo de Internet de última geração. Ele é baseado no QUIC, um protocolo desenvolvido com base no protocolo Google QUIC (gQUIC) original. O HTTP/3 é compatível entre o balanceador de carga HTTP(S) externo, o Cloud CDN e os clientes.

Para aumentar o desempenho com o Cloud CDN, verifique se o HTTP/3 está ativado.

Usar armazenamento em cache negativo

O Armazenamento em cache negativo fornece controle detalhado do armazenamento em cache para erros ou redirecionamentos comuns. Quando o Cloud CDN encontra códigos de resposta específicos, ele mantém essa resposta no cache para um TTL definido. Isso pode diminuir a carga nas origens e melhorar a experiência do usuário final ao reduzir a latência da resposta.

Ativar dados iniciais do TLS

O uso de dados iniciais do TLS melhora a taxa de conexões retomadas em 30 % a 50 %. Para ativar os dados iniciais do TLS, use o comando gcloud compute target-https-proxies update com a opção tls-early-data. Para mais informações, consulte Configurar dados iniciais do TLS.

É possível ativar dados iniciais do TLS nos modos STRICT ou PERMISSIVE.

  • STRICT: permite dados iniciais para métodos idempotentes (GET, HEAD, OPTIONS e TRACE), que não têm outros parâmetros de consulta. Esse é o método mais seguro e aplicável na maioria dos casos.
  • PERMISSIVE: ativa os dados iniciais para métodos idempotentes que podem incluir parâmetros de consulta. Ao usar esse modo, monitore de perto o comportamento e a postura de segurança do aplicativo.

As solicitações de dados iniciais que usam métodos HTTP não idempotentes ou que têm parâmetros de consulta são rejeitadas com um código de status HTTP 425.

Otimizar a segurança

As práticas recomendadas a seguir ajudam a otimizar a segurança.

Usar o Google Cloud Armor

O Cloud Armor se integra ao Cloud CDN para conteúdo em cache e conteúdo sem cache ou ausente no cache. Uma prática recomendada é usar o Google Cloud Armor em conjunto com o Cloud CDN sempre que possível para aumentar a segurança dos aplicativos da Web.

Usar URLs assinados

Se você estiver usando URLs assinados, observe o seguinte:

Autenticar origens particulares

A autenticação de origem oferece uma forte garantia de que a solicitação vem apenas do seu próprio serviço de back-end configurado. Ela também oferece proteção de dados em trânsito para a solicitação e oferece proteção contra a reutilização da parte assinada da solicitação.

Recomendamos o uso da autenticação de origem particular para buckets do Amazon S3 ou repositórios de objetos compatíveis. A autenticação de origem particular ajuda a garantir que apenas conexões confiáveis acessem o conteúdo nas origens particulares e que os usuários não as acessem diretamente.

Além disso, se os firewalls de origem impedirem o acesso à origem, use a lista de permissões de IP para garantir que a solicitação seja proveniente do Cloud CDN ou do balanceador de carga de aplicativo externo. No entanto, isso não impede que outros clientes do Media CDN tentem acessar seu conteúdo ao especificar sua origem na configuração deles.

Otimizar o cache

As práticas recomendadas a seguir ajudam a otimizar o cache.

Otimizar TTLs de cache

É possível definir ou substituir os TTLs para ajuste fino do tempo em que o Cloud CDN armazena em cache as respostas e quando o Cloud CDN revalida as respostas.

Também é possível definir um TTL voltado para o cliente para aproveitar ao máximo o processo de cache do navegador

Para mais informações, consulte Como usar configurações e substituições de TTL.

Definir a expiração de conteúdo sensível ao tempo

Cada conteúdo de um cache do Cloud CDN tem um prazo de validade específico e é importante definir um prazo adequado para seu caso de uso. Você precisa escolher a expiração com cuidado, já que os servidores de origem reenviam o conteúdo que expira nos servidores de cache.

Uma maneira de escolher a expiração é classificar o conteúdo com base na frequência com que você o atualiza, por exemplo:

  • Atualizações quase em tempo real, como feeds ao vivo de eventos esportivos ou tráfego
  • Atualizações frequentes, como informações meteorológicas semanais, diárias ou por hora, ou imagens de notícias de primeira página.
  • Atualizações não frequentes, como um logotipo de um site ou arquivos CSS ou JavaScript.

Em seguida, escolha a expiração por categoria de conteúdo. Por exemplo, um prazo de expiração de cinco segundos pode ser apropriado para placares de esportes quase em tempo real. Já um prazo de expiração de uma hora pode ser usado para atualizações do clima. Para conteúdo armazenado no Cloud Storage, defina os prazos de validade usando os metadados Cache-Control. Quando o conteúdo é disponibilizado pelo Compute Engine, é possível controlar os prazos de validade com a configuração do software servidor da Web.

Os prazos de validade são especificados pelos valores max-age e s-maxage no cabeçalho Cache-Control. Esse cabeçalho é definido pela especificação HTTP (em inglês). Por exemplo, o seguinte cabeçalho Cache-Control torna o conteúdo associado publicamente legível e armazenado em cache com uma expiração de cache de 72 horas (259.200 segundos):

  Cache-Control: public, max-age=259200

Para maximizar o armazenamento em cache, siga as diretrizes na Visão geral do armazenamento em cache. Lembre-se de que os valores max-age e s-maxage no campo de metadados Cache-Control funcionam juntos das seguintes maneiras:

  • Os valores max-age e s-maxage são medidos em segundos.
  • O valor s-maxage se aplica somente a caches compartilhados, não a caches do navegador.
  • O valor max-age se aplica a todos os caches, a menos que s-maxage o substitua.

Para conteúdo que é alterado com baixa frequência ou que muda com o conteúdo relacionado, muitas vezes é adequado usar um prazo de validade mais longo em combinação com URLs com controle de versões.

Usar URLs com controle de versões para atualizar o conteúdo

O conteúdo do controle de versões disponibiliza uma versão diferente do mesmo conteúdo, removendo-o de forma eficaz ao mostrar novo conteúdo aos usuários antes que a entrada do cache expire. Como o controle de versões não tem custo financeiro, recomendamos que ele seja usado como a abordagem padrão para atualizar o conteúdo armazenável em cache.

Para conteúdo de versão, adicione um parâmetro ao URL, como um número de versão. Existem várias maneiras de incluir parâmetros em URLs:

  • Adicionar uma string de consulta: file.ext?v=100

    Para buckets de back-end, quaisquer strings de consulta usadas no controle de versões precisam ser especificadas na configuração do bucket de back-end. Para mais informações, consulte Lista de inclusão de strings de consulta para chaves de cache do Cloud Storage.

  • Alterar o nome de arquivo: file.1.0.0.ext ou file_v100.ext.

  • Alterar o caminho: /v100/file.ext.

Ao adicionar o parâmetro, o nome do arquivo e o URL são alterados. Essa alteração força o cache a ignorar qualquer entrada de cache atual.

Usar a invalidação com moderação para remover conteúdo

A invalidação remove o conteúdo dos servidores de cache distribuídos do Cloud CDN antes da expiração do cache. A invalidação tem consistência eventual.

Use a invalidação com moderação e apenas como último recurso. Por exemplo, a invalidação é ideal para quando você precisa remover conteúdo por motivos legais ou por conta de um envio acidental. Caso contrário, use o controle de versão sempre que possível ou aguarde até que o conteúdo expire normalmente. Os servidores de cache do Cloud CDN despejam rotineiramente conteúdo acessado com pouca frequência para criar espaço para novos conteúdos. O conteúdo que não é acessado por 30 dias é removido incondicionalmente.

As invalidações de cache são limitadas por taxa.

Para saber mais sobre invalidação, consulte a Visão geral da invalidação de cache.

Otimizar a consistência de arquivos enviados

As práticas recomendadas a seguir ajudam a otimizar a consistência dos uploads de arquivos.

Evitar atualizar arquivos

Em vez de atualizar arquivos, faça upload de novas versões.

Em arquivos novos, use nomes exclusivos que possam incluir números de versão ou datas. Adicionar um número de versão (por exemplo, file_v2.css) ou uma data (por exemplo, file_20230806.js) ao nome de arquivo ajuda a garantir que o Cloud CDN busque a versão correta e atualizada. Não é recomendável anexar um parâmetro ao URL do arquivo (por exemplo, file.css?v=2) para forçar a busca de uma nova versão porque esta abordagem não lida com o risco de armazenar em cache uma atualização não atômica do arquivo de origem, em que arquivos parciais ou incompletos ainda podem ser armazenados em cache.

É fundamental fazer upload de novas versões das dependências antes do upload dos arquivos que as referenciam. Essa prática ajuda a garantir que todas as referências sejam de arquivos completos e atualizados, reduzindo o risco de disponibilizar arquivos parcialmente atualizados ou truncados.

Fazer atualizações atômicas em arquivos

Quando for necessário atualizar arquivos, faça isso de forma atômica.

Se um arquivo for acessado e armazenado em cache antes da conclusão de um upload, talvez ele seja armazenado em cache como um arquivo incompleto ou truncado. Por exemplo, um arquivo, como /index.html, não pode ter um nome exclusivo, mas pode apontar para outros arquivos que têm nomes exclusivos.

O upload de um arquivo com o nome de destino pode resultar no armazenamento em cache de arquivos incompletos quando eles são acessados durante o upload. Em vez disso, faça upload do arquivo com um nome temporário e renomeie-o para o nome de destino só após a conclusão do upload. Essa prática ajuda a garantir que o arquivo esteja totalmente e imediatamente disponível quando referenciado.

Quando os arquivos são atualizados, o armazenamento em cache de intervalo de bytes pode fazer com que o Cloud CDN mantenha intervalos do arquivo anterior depois do upload do novo arquivo. Se o Cloud CDN tiver armazenado em cache intervalos do arquivo anterior, as solicitações de blocos ausentes poderão gerar respostas parciais. Isso acontece porque o Cloud CDN detecta que o arquivo de origem foi alterado (porque etag ou last-modified mudou), exclui qualquer conteúdo desatualizado, desconecta downloads em andamento e gera um erro, o que faz com que o cliente tente novamente. Para mitigar esse problema, emita invalidações para arquivos armazenados em cache de intervalo de bytes que estejam sido atualizados.

Otimizar o Monitoring e o Logging

As práticas recomendadas a seguir ajudam a otimizar o Monitoring e o Logging.

Verificar se a geração de registros está ativada para o Cloud CDN

Uma prática recomendada para gerenciar o Cloud CDN é garantir que a geração de registros esteja ativada para todos os back-ends ativados do Cloud CDN.

Usar o painel de monitoramento personalizado do Cloud CDN

Para garantir maior confiabilidade e desempenho, uma prática recomendada é analisar regularmente as métricas de monitoramento relacionadas ao Cloud CDN. Um ótimo lugar para começar é o painel de monitoramento personalizado do Cloud CDN.

Analisar testes de desempenho de terceiros

Analise os relatórios de provedores terceirizados, como a disponibilidade, a latência e os relatórios da capacidade de processamento fornecidos pelo Citrix Radar.