Práticas recomendadas para o envio de conteúdo

Esta página fornece práticas recomendadas para otimizar e acelerar a entrega de conteúdo com a RFC de multimédia na nuvem. As secções estão divididas em várias áreas principais.

O Cloud CDN usa um Application Load Balancer externo como origem para conteúdo colocável em cache. Um Application Load Balancer externo pode fornecer uma combinação de conteúdo estático e criado dinamicamente aos utilizadores através de um endereço IP global dos seguintes tipos de back-ends:

Devido à integração perfeita com o Google Cloud, tem várias opções para implementar o Cloud CDN e gerir conteúdo. Use as práticas recomendadas aqui apresentadas para planear e otimizar a sua implementação. Para mais informações, consulte o artigo Configure o Cloud CDN.

Otimize a relação de resultados da cache

As seguintes práticas recomendadas ajudam a otimizar a taxa de acertos da cache.

Conteúdo estático da cache

Como prática recomendada para melhorar o desempenho, quando ativa a CDN da nuvem, tem de escolher o modo de cache adequado para a sua aplicação.

O método mais flexível e geralmente preferido para gerir regras de cache é usar o cabeçalho de controlo de cache. Se não estiver familiarizado com a utilização de cabeçalhos cache-control de origem, a prática recomendada é permitir que o Cloud CDN coloque automaticamente conteúdo estático em cache.

Para colocar automaticamente em cache as respostas estáticas da sua origem, pode usar a definição --cache-mode=CACHE_ALL_STATIC (predefinição). Esta definição permite que a cache da CDN da Google Cloud armazene em cache tipos de conteúdo estático comuns quando a origem não especifica nenhuma diretiva de armazenamento em cache nos cabeçalhos de resposta. Certifique-se de que o seu conteúdo corresponde às categorias descritas. Caso contrário, o conteúdo não é colocado em cache.

Não colocar em cache conteúdo específico do utilizador

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

Use chaves de cache personalizadas para melhorar a taxa de acertos da cache

Para o desempenho e a escalabilidade, é importante otimizar a taxa de acertos da cache. Por predefinição, a RFC usa o URL do pedido completo para criar a chave da cache. Para ajudar a otimizar a taxa de acertos da cache, pode usar chaves de cache personalizadas para que o Cloud CDN não divida desnecessariamente a cache.

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

As chaves de cache personalizadas permitem-lhe incluir ou omitir qualquer combinação de protocolo, anfitrião e string de consulta. Seguem-se alguns exemplos de quando pode usar chaves de cache personalizadas:

  • Tem dois anfitriões que resolvem para o mesmo endereço IP e acedem ao mesmo serviço. Neste exemplo, todo o Website é igual nos dois anfitriões. Por predefinição, a RFC de multimédia na nuvem armazena em cache duas cópias devido ao cabeçalho Host: diferente nos pedidos HTTP. Com uma chave de cache personalizada, pode fazer com que a RFC ignore a parte do anfitrião do pedido e partilhe as entradas de cache.

  • Num exemplo mais específico, pode ter dois Websites em domínios diferentes que usam o mesmo logótipo. O conteúdo do Website é diferente, mas usa o mesmo logótipo da empresa em ambos os domínios e tem um serviço de back-end dedicado que contém conteúdo partilhado. Quando ativa o Cloud CDN e personaliza as chaves de cache para o serviço de back-end que contém o logótipo, desmarque a caixa de verificação Anfitrião para que a cache ignore o domínio, mas coloque o logótipo em cache.

  • Um logótipo tem de ser colocado em cache, quer seja apresentado através de HTTP ou HTTPS. Quando personaliza as chaves da cache para o serviço de back-end que contém o logótipo, desmarque a caixa de verificação Protocolo para que os pedidos através de HTTP e HTTPS contem como correspondências para a entrada da cache do logótipo.

Para saber como personalizar as chaves de cache, consulte o artigo Usar chaves de cache.

Otimize o desempenho

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

Certifique-se de que o suporte do protocolo HTTP/3 e QUIC está ativado

O HTTP/3 é um protocolo de Internet de próxima geração. É criado com base no QUIC, um protocolo desenvolvido a partir do protocolo Google QUIC ) (gQUIC) original. O HTTP/3 é suportado entre o balanceador de carga HTTP(S) externo, o Cloud CDN e os clientes.

Para aumentar o desempenho com a CDN da Google Cloud, certifique-se de que o HTTP/3 está ativado.

Use a colocação em cache negativa

A colocação em cache negativa oferece um controlo detalhado sobre a colocação em cache para erros ou redirecionamentos comuns. Quando a CDN na nuvem encontra códigos de resposta específicos, mantém essa resposta na cache durante um TTL definido. Isto pode reduzir a carga nas suas origens e melhorar a experiência do utilizador final através da redução da latência de resposta.

Ative os dados antecipados do TLS

A utilização de dados iniciais do TLS melhora a taxa de ligaçõ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 o artigo Configure os dados antecipados do TLS.

Pode ativar os dados antecipados do TLS nos modos STRICT ou PERMISSIVE.

  • STRICT: ativa os dados antecipados para métodos idempotentes (GET, HEAD, OPTIONS e TRACE) que não têm outros parâmetros de consulta. Este é o método mais seguro e aplicável na maioria dos casos.
  • PERMISSIVE: ativa os dados antecipados para métodos idempotentes que podem incluir parâmetros de consulta. Quando usar este modo, tem de monitorizar atentamente o comportamento da sua aplicação e a postura de segurança.

Os pedidos de dados iniciais que usam métodos HTTP não idempotentes ou têm parâmetros de consulta são rejeitados com um código de estado HTTP 425.

Otimize a segurança

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

Use o Google Cloud Armor

O Cloud Armor integra-se com o Cloud CDN para conteúdo em cache e não em cache ou com falhas de cache. Uma recomendação de prática recomendada é usar o Cloud Armor em conjunto com o Cloud CDN sempre que possível para aumentar a segurança das aplicações Web.

Use URLs assinados

Se estiver a usar URLs assinados, tenha em atenção o seguinte:

Autentique origens privadas

A autenticação de origem oferece uma forte garantia de que o pedido é proveniente apenas do serviço de back-end configurado por si. Também oferece proteção de dados em trânsito para o pedido e protege contra a reutilização da parte assinada do pedido.

Recomendamos a utilização da autenticação de origem privada para contentores do Amazon S3 ou armazenamentos de objetos compatíveis. A autenticação de origem privada ajuda a garantir que apenas as ligações fidedignas acedem ao conteúdo nas suas origens privadas e que os utilizadores não acedem diretamente a elas.

Além disso, se as firewalls de origem impedirem o acesso à origem, use a lista de autorizações de IP para garantir que um pedido é do Cloud CDN ou do Application Load Balancer externo. No entanto, isto não impede que outros clientes da CDN de multimédia tentem aceder ao seu conteúdo especificando a sua origem na respetiva configuração.

Otimize a cache

As seguintes práticas recomendadas ajudam a otimizar a cache.

Otimize os TTLs da cache

Pode definir ou substituir os TTLs para ajustar o tempo durante o qual o Cloud CDN armazena em cache as suas respostas e quando o Cloud CDN revalida as suas respostas.

Também pode definir um TTL orientado para o cliente para tirar o máximo partido das caches do navegador.

Para mais informações, consulte o artigo Usar definições e substituições de TTL.

Defina a validade do conteúdo sensível ao tempo

Cada parte do conteúdo numa cache da RFC do Google Cloud tem um tempo de validade associado e é importante definir uma validade adequada ao seu exemplo de utilização. Uma vez que os servidores de origem têm de reenviar o conteúdo que expira nos servidores de cache, tem de escolher cuidadosamente a expiração.

Um método para escolher a data de validade é categorizar o conteúdo com base na frequência com que o atualiza. Por exemplo:

  • Atualizações quase em tempo real, como feeds em direto de eventos desportivos ou trânsito
  • Atualizações frequentes, como informações meteorológicas semanais, diárias ou de hora em hora, ou imagens de notícias da página inicial
  • Atualizações pouco frequentes, como um logótipo do Website ou ficheiros CSS ou JavaScript

Em seguida, escolha o prazo de validade por categoria de conteúdo. Por exemplo, uma expiração de cinco segundos pode ser adequada para resultados desportivos quase em tempo real, e uma expiração de uma hora pode ser usada para atualizações meteorológicas. Para conteúdo armazenado no Cloud Storage, defina os prazos de validade através dos metadados Cache-Control. Quando o conteúdo é publicado pelo Compute Engine, controla os prazos de validade configurando o software do servidor Web.

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

  Cache-Control: public, max-age=259200

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

  • Os valores max-age e s-maxage são medidos em segundos.
  • O valor s-maxage aplica-se apenas a caches partilhadas e não a caches do navegador.
  • O valor max-age aplica-se a todas as caches, a menos que seja substituído por s-maxage.

Para conteúdo que muda com pouca frequência ou que tem de mudar juntamente com conteúdo relacionado, é frequentemente adequado usar um prazo de validade longo em combinação com URLs com versões.

Use URLs com versões para atualizar conteúdo

A gestão de versões de conteúdo disponibiliza uma versão diferente do mesmo conteúdo, removendo-o efetivamente, ao mostrar aos utilizadores novo conteúdo antes de a entrada na cache expirar. Uma vez que a gestão de versões é gratuita, recomendamos que a use como a abordagem predefinida para atualizar conteúdo memorizável em cache.

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

  • Adicione uma sequência de carateres de consulta: file.ext?v=100.

    Para os contentores de back-end, todas as strings de consulta usadas para o controlo de versões têm de ser especificadas na configuração do contentor de back-end. Para mais informações, consulte a lista de inclusão de strings de consulta para chaves da cache do Cloud Storage.

  • Altere o nome do ficheiro: file.1.0.0.ext ou file_v100.ext.

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

Quando adiciona o parâmetro, altera o nome do ficheiro e o URL. Esta alteração força a cache a ignorar qualquer entrada de cache existente.

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

A invalidação remove conteúdo dos servidores de cache distribuídos do Cloud CDN antes de a entrada de cache expirar. A invalidação acaba por ser consistente.

Recomendamos que use a invalidação com moderação e apenas como último recurso. Por exemplo, a invalidação é útil quando tem de remover conteúdo por motivos legais ou devido a um carregamento acidental. Caso contrário, recomendamos que use o controlo de versões sempre que possível ou aguarde até o conteúdo expirar normalmente. Os servidores de cache da RFC na nuvem desalojam rotineiramente conteúdo acedido com pouca frequência para dar lugar a novo conteúdo. O conteúdo que não é acedido durante 30 dias é removido incondicionalmente.

As invalidações da cache estão limitadas por taxa.

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

Otimize a consistência dos ficheiros carregados

As seguintes práticas recomendadas ajudam a otimizar a consistência dos carregamentos de ficheiros.

Evite atualizar ficheiros existentes

Em vez de atualizar os ficheiros existentes, carregue novas versões.

Para novos ficheiros, use nomes exclusivos que podem incluir números de versão ou datas. Anexar um número de versão (por exemplo, file_v2.css) ou uma data (por exemplo, file_20230806.js) ao nome do ficheiro ajuda a garantir que o Cloud CDN obtém a versão correta e atualizada. Não é recomendável anexar um parâmetro ao URL do ficheiro (por exemplo, file.css?v=2) para forçar a obtenção de uma nova versão, porque esta abordagem não resolve o risco de colocar em cache uma atualização de ficheiro de origem não atómica, em que os ficheiros parciais ou incompletos podem continuar a ser colocados em cache.

É fundamental carregar novas versões das dependências antes de carregar os ficheiros que fazem referência às mesmas. Esta prática ajuda a garantir que todas as referências são a ficheiros completos e atualizados, o que reduz o risco de publicar ficheiros parcialmente atualizados ou truncados.

Faça atualizações atómicas aos ficheiros

Quando for necessário atualizar ficheiros existentes, faça-o de forma atómica.

Se um ficheiro for acedido e colocado em cache antes de um carregamento estar concluído, pode ser colocado em cache como um ficheiro incompleto ou truncado. Por exemplo, um ficheiro, como /index.html, não pode ter um nome exclusivo, mas pode apontar para outros ficheiros que tenham nomes exclusivos.

O carregamento de um ficheiro com o nome de destino pode resultar na colocação em cache de ficheiros incompletos quando estes são acedidos durante o carregamento. Em alternativa, carregue o ficheiro com um nome temporário e mude-lhe o nome para o nome de destino apenas após a conclusão do carregamento. Esta prática ajuda a garantir que o ficheiro está totalmente e imediatamente disponível quando é referenciado.

Quando os ficheiros existentes são atualizados, o armazenamento em cache de intervalos de bytes pode fazer com que o Cloud CDN mantenha intervalos do ficheiro anterior depois de o novo ficheiro ter sido carregado. Se a RFC tiver intervalos em cache do ficheiro anterior, os pedidos de partes em falta podem originar respostas parciais. Isto acontece porque o Cloud CDN deteta que o ficheiro de origem foi alterado (devido a alterações de etag ou last-modified), elimina qualquer conteúdo desatualizado, desliga as transferências em curso e gera um erro, o que leva o cliente a tentar novamente. Para mitigar este problema, emita invalidações para ficheiros em cache de intervalo de bytes que estão a ser atualizados.

Otimize a monitorização e o registo

As seguintes práticas recomendadas ajudam a otimizar a monitorização e o registo.

Certifique-se de que o registo está ativado para o Cloud CDN

Uma prática recomendada para gerir o Cloud CDN é garantir que o registo está ativado para todos os back-ends ativados para o Cloud CDN.

Use o painel de controlo de monitorização personalizado para o Cloud CDN

Para garantir uma maior fiabilidade e desempenho, uma prática recomendada é rever regularmente as métricas de monitorização relacionadas com a CDN da Google Cloud. Um ótimo ponto de partida é o painel de controlo de monitorização personalizado do Cloud CDN.

Reveja os testes de desempenho de terceiros

Reveja os relatórios de fornecedores externos, como os relatórios de disponibilidade, latência e taxa de transferência fornecidos pela Citrix Radar.