Resolva problemas do Cloud CDN

Saiba mais sobre os passos de resolução de problemas que podem ser úteis se tiver os seguintes problemas ao usar o Cloud CDN.

Se o problema que está a ver estiver relacionado com backends externos, consulte também o artigo Resolução de problemas de backends externos e NEG da Internet.

Problemas e soluções gerais

Esta secção descreve alguns problemas comuns e as respetivas soluções.

As respostas não estão a ser colocadas em cache

Se as respostas não estiverem a ser colocadas em cache, primeiro, verifique se o Cloud CDN está ativado para o seu serviço de back-end ou contentor de back-end. Quando ativa a CDN na nuvem, podem demorar alguns minutos até que as respostas comecem a ser colocadas em cache.

O Cloud CDN coloca em cache apenas respostas com conteúdo colocável em cache. Estas informações são transmitidas nos cabeçalhos de resposta HTTP, em combinação com a configuração de back-end. Quando configura um cabeçalho de resposta personalizado com cdn_cache_status, pode observar o estado da cache nos registos do Cloud CDN e determinar se uma resposta foi publicada como resultado de uma falha de cache.

Se as respostas para um URL não estiverem a ser colocadas em cache, verifique que cabeçalhos estão a ser devolvidos para esse URL e como a capacidade de colocação em cache está configurada para o seu back-end.

Existem várias formas de verificar os cabeçalhos de resposta:

O exemplo seguinte demonstra a utilização de curl para verificar os cabeçalhos de resposta HTTP de http://example.com/style.css:

curl -s -D - -o /dev/null http://example.com/style.css

Saída:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:00 GMT
Content-Type: text/css
Content-Length: 1977
Via: 1.1 google

A comparação destes cabeçalhos com os requisitos de conteúdo em cache revela que a resposta não tem o cabeçalho Cache-Control necessário (partindo do princípio de que o modo de cache está definido como USE_ORIGIN_HEADERS).

O método de definição dos cabeçalhos depende do tipo de servidor de origem. Se estiver a executar um servidor Web no Compute Engine, consulte a documentação do software do servidor Web para obter detalhes sobre a configuração dos cabeçalhos de resposta. Para o Cloud Storage, marcar o objeto como partilhado publicamente faz com que os cabeçalhos adequados sejam enviados.

Depois de reconfigurar o servidor de origem para adicionar o cabeçalho necessário, pode usar curl novamente para verificar o resultado:

curl -s -D - -o /dev/null http://example.com/style.css

Saída:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:30 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google

curl -s -D - -o /dev/null http://example.com/style.css

Saída:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:31 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google

curl -s -D - -o /dev/null http://example.com/style.css

Saída:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:30 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google
Age: 2

A última resposta neste exemplo inclui um cabeçalho Age. A RFC adiciona um cabeçalho Age às respostas que serve a partir da cache. Aqui, o cabeçalho indica que a resposta foi publicada com êxito a partir da cache através de uma entrada de cache criada há dois segundos.

Além disso, se os ETags estiverem ativados nas instâncias de back-end, o Cloud CDN baseia-se nos ETags para confirmar a atualidade do objeto. Se as instâncias de back-end disponibilizarem diferentes ETags no mesmo objeto, o Cloud CDN contabiliza as incompatibilidades como um erro de cache e atualiza o objeto. Para evitar esta situação, as instâncias de back-end têm de publicar o mesmo ETag ou os ETags têm de ser desativados.

Para verificar isto, execute curl repetidamente e procure alterações no valor de ETag:

curl -s -D - -o /dev/null http://example.com/image.png

Saída:

HTTP/2 200
date: Fri, 20 Mar 2020 15:02:30 GMT
server: Apache
strict-transport-security: max-age=31536000; includeSubDomains
last-modified: Mon, 16 Mar 2020 04:20:59 GMT
etag: "10f-5a0f1256f1402"
accept-ranges: bytes
content-length: 271
cache-control: public, max-age=864000
expires: Mon, 30 Mar 2020 15:02:30 GMT
vary: Accept-Encoding
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
content-type: image/png
via: 1.1 google
alt-svc: clear

curl -s -D - -o /dev/null http://example.com/image.png

Saída:

HTTP/2 200
date: Fri, 20 Mar 2020 15:03:11 GMT
server: Apache
strict-transport-security: max-age=31536000; includeSubDomains
last-modified: Mon, 16 Mar 2020 04:18:31 GMT
etag: "10f-5a0f11ca09b7a"
accept-ranges: bytes
content-length: 271
cache-control: public, max-age=864000
expires: Mon, 30 Mar 2020 15:03:11 GMT
vary: Accept-Encoding
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
content-type: image/png
via: 1.1 google
alt-svc: clear

Não é possível aceder aos objetos do Cloud Storage

Para conceder acesso a objetos no Cloud Storage, tem de configurar URLs assinados ou conceder acesso público ao contentor e a todos os respetivos objetos para o allUsers.

Se decidir conceder acesso allUsers, pode validar o acesso ao nível do objeto da seguinte forma.

Consola

  1. Na Google Cloud consola, abra o navegador do Cloud Storage.

    Abra o navegador de armazenamento

  2. Clique num grupo para ver a página Detalhes do grupo.

  3. Na coluna Acesso público, passe o cursor do rato sobre o ícone de ponto de exclamação e clique em Editar acesso.

    Para cada objeto no contentor, certifique-se de que a seguinte autorização está definida:

    • Entidade: utilizador
    • Nome: allUsers
    • Acesso: leitor

Para saber mais sobre o controlo de acesso para o Cloud Storage, consulte a documentação da gestão de identidade e acesso (IAM) para o Cloud Storage.

Para saber mais sobre os URLs assinados, consulte o artigo Usar URLs assinados.

Se os objetos estiverem acessíveis, mas não estiverem a ser colocados em cache, consulte o artigo As respostas não estão a ser colocadas em cache.

O conteúdo privado foi colocado em cache ou o conteúdo em cache está incorreto

Se souber por que motivo o servidor de origem publicou o conteúdo privado ou incorreto e puder corrigir o problema, pode invalidar as caches da CDN da Google Cloud através do seguinte processo:

  1. Certifique-se de que o servidor de origem já não devolve conteúdo privado ou incorreto.
  2. Peça uma anulação da cache para indicar ao Cloud CDN que pare de publicar o conteúdo em cache.

Para mais informações, consulte a Vista geral da invalidação de cache.

A RFC armazena em cache apenas respostas com conteúdo armazenável em cache e publica respostas da cache apenas até ao prazo de validade especificado na resposta. Se não souber por que motivo o conteúdo foi colocado em cache ou não conseguir corrigir o problema rapidamente, recomendamos que desative o Cloud CDN até conseguir compreender e corrigir o problema e, em seguida, reative-o. Para mais informações sobre o conteúdo que é colocado em cache e durante quanto tempo, consulte a Vista geral da colocação em cache.

A relação de resultados da cache é baixa

Para o desempenho e a escalabilidade, é importante otimizar as taxas de acerto da cache. Se estiver a ter taxas de acertos da cache inferiores ao esperado, certifique-se de que está a seguir as práticas recomendadas para otimizar a taxa de acertos da cache.

Use a tabela seguinte para compreender alguns dos possíveis motivos para uma baixa taxa de acertos da cache e as potenciais correções.

Motivos Comentários Correções
O seu conteúdo não é armazenável em cache. Uma resposta colocável em cache é uma resposta HTTP que a RFC pode armazenar. Certifique-se de que o seu conteúdo é armazenável em cache.
O modo de cache não é ideal para a sua aplicação. A RFC na nuvem tem vários modos de cache. Se não estiver a usar cabeçalhos de controlo da cache para controlar o comportamento da colocação em cache, a prática recomendada é permitir que o Cloud CDN coloque em cache todo o conteúdo estático.
Existe uma pequena quantidade de tráfego. Durante os testes e as experiências, é provável que a quantidade de tráfego que está a gerar seja baixa. A Google tem uma cache distribuída global e as solicitações de diferentes localizações geográficas são encaminhadas para diferentes localizações do front-end da Google. Em cada localização de front-end, a Google pode ter várias instâncias discretas da cache.
  • Certifique-se de que está a enviar um volume de tráfego suficiente para a Google para preencher todas as caches relevantes.
  • Durante os testes, certifique-se de que fragmenta o tráfego por URL para que todo o tráfego de cada conjunto de pedidos seja enviado para a Google. Não divida aleatoriamente cada pedido num fornecedor de RFC diferente.
As respostas para URLs específicos não são colocadas em cache. A RFC de multimédia na nuvem incorpora o URI do pedido completo nas respetivas chaves de cache, pelo que http://example.com/cat.jpg?color=orange e http://example.com/cat.jpg?color=gray têm entradas de cache separadas. Use sempre um único URL para um determinado recurso.

Se precisar de transmitir parâmetros para o JavaScript em execução numa página que, de resto, é armazenável em cache, considere usar identificadores de fragmentos em vez de strings de consulta.
A cache está desnecessariamente dividida devido ao campo do cabeçalho Vary. O campo do cabeçalho Vary numa resposta descreve que partes de uma mensagem de pedido (além do método, do campo do cabeçalho Host e do destino do pedido) podem influenciar o processo do servidor de origem para selecionar e representar uma resposta. Por exemplo, pode querer usar o cabeçalho Vary: Accept-Encoding se publicar conteúdo diferente para clientes que podem processar respostas comprimidas e clientes que não podem. Use o cabeçalho de resposta Vary apenas quando for necessário.
Não está a usar chaves de cache personalizadas. Por predefinição, a RFC usa o URL do pedido completo para criar a chave da cache. Pode personalizar as chaves da cache para incluir ou omitir qualquer combinação de protocolo, anfitrião e string de consulta. Por exemplo, se dois domínios usarem o mesmo conteúdo estático, pode criar uma chave de cache personalizada que omita o campo de anfitrião. Use chaves de cache personalizadas, quando necessário.

Existem vários preenchimentos da cache para o mesmo conteúdo

Em geral, pode reduzir o número de preenchimentos da cache aumentando os tempos de expiração das respostas memorizáveis em cache. Sendo tudo o resto igual, vê menos preenchimentos da cache para uma resposta com Cache-Control: public, max-age=86400 do que uma com Cache-Control: public, max-age=1.

Para mais informações sobre os prazos de validade, consulte o artigo Prazos de validade e pedidos de validação. Para informações sobre a configuração dos cabeçalhos de resposta adequados, consulte a documentação do software do seu servidor Web.

A RFC opera várias caches em todo o mundo e as entradas de cache antigas são removidas rotineiramente para dar lugar a novo conteúdo. Como resultado, são esperados vários preenchimentos da cache por recurso como parte do funcionamento normal.

A compressão não está a funcionar

A RFC do Google Cloud oferece compressão dinâmica para origens que não conseguem comprimir as respetivas respostas. Sempre que possível, recomendamos que use a compressão na origem, uma vez que reduz os custos de preenchimento da cache.

Se as respostas publicadas pela RFC do Google Cloud não estiverem comprimidas, mas deveriam estar, verifique se o software do servidor Web em execução nas suas instâncias está configurado para comprimir as respostas. Por predefinição, alguns softwares de servidor Web desativam automaticamente a compressão para pedidos que incluem um cabeçalho Via. A presença de um cabeçalho Via indica que o pedido foi encaminhado por um proxy. Os proxies HTTP, como o balanceador de carga de aplicações externo, adicionam um cabeçalho Via a cada pedido, conforme exigido pela especificação HTTP. Para ativar a compressão, pode ter de substituir a configuração predefinida do servidor Web para lhe indicar que comprima as respostas, mesmo que o pedido tenha um cabeçalho Via.

Se estiver a usar o software do servidor Web nginx, modifique o ficheiro de configuração nginx.conf para ativar a compressão. A localização deste ficheiro depende do local onde o nginx está instalado. Em muitas distribuições Linux, o ficheiro é armazenado em /etc/nginx/nginx.conf.

Para permitir que a compressão nginx funcione com o seu Application Load Balancer externo, adicione as seguintes duas linhas à secção http de nginx.conf:

gzip_proxied any;
gzip_vary on;

  • A primeira linha ativa a compressão mesmo para pedidos encaminhados por um proxy, como o Application Load Balancer externo.

  • A segunda linha adiciona um cabeçalho Vary: Accept-Encoding às respostas. Vary: Accept-Encoding notifica os proxies de colocação em cache, como a rede de fornecimento de conteúdos (CDN) na nuvem, de que devem manter entradas de cache separadas para variantes comprimidas e não comprimidas de recursos comprimíveis.

Depois de modificar o ficheiro nginx.conf, tem de reiniciar o nginx antes de usar a nova configuração. Em muitas distribuições Linux, pode reiniciar o nginx executando sudo service nginx restart ou /etc/init.d/nginx restart.

As respostas terminam com erros byte_range_caching_aborted

Quando a RFC monta uma resposta a partir de vários pedidos de intervalo de bytes, verifica se esses intervalos são da mesma versão do recurso comparando os cabeçalhos de resposta ETag e Last-Modified. Se o Cloud CDN determinar que o valor de qualquer um dos cabeçalhos é inconsistente com os intervalos que já publicou para o cliente, aborta a resposta.

Se notar respostas terminadas inesperadamente, entradas de registo do Cloud Logging com byte_range_caching_aborted statusDetails ou as suas instâncias a devolverem respostas 412 Precondition Failed, certifique-se de que o software do servidor Web em execução em todas as instâncias de máquinas virtuais (VM) devolve os mesmos valores ETag e Last-Modified para um determinado recurso.

Quando serve ficheiros a partir do disco, é comum o software do servidor Web derivar os valores ETag e Last-Modified da hora de modificação do ficheiro. Neste caso, pode garantir que as suas instâncias de VM comunicam valores consistentes usando a mesma imagem para todas as instâncias. Para ver detalhes sobre como o software do servidor Web determina os valores ETag e Last-Modified, consulte a documentação do software do servidor Web.

Resolução de problemas com cookies assinados

Os seguintes problemas podem ocorrer quando está a usar cookies assinados.

Codificação

Quando gera uma assinatura, o pedido é inesperadamente rejeitado devido a uma incompatibilidade de assinatura.

Ao codificar os valores URL e Signature, certifique-se de que está a usar a variante segura para URL da base64. O base64 padrão falha quando os carateres gerados não são seguros para URLs. O preenchimento é aceite.

Assinatura

O seu pedido é rejeitado pela CDN da nuvem.

  • Certifique-se de que está a usar o HMAC-SHA-1 como algoritmo de assinatura e não outra variante do HMAC.

  • Confirme que o parâmetro KeyName (sensível a maiúsculas e minúsculas) corresponde a um nome de chave válido para o serviço de back-end ou o contentor de back-end) usado pelo Cloud CDN.

  • Não assine os parâmetros de consulta quando gerar e assinar um URLPrefix. Certifique-se de que URLPrefix contém apenas os componentes de esquema, anfitrião e (parciais) de caminho do URL.

  • Certifique-se de que o bloco de assinatura (URLPrefix, Expires, KeyName e o próprio Signature) são as últimas secções delimitadas por : do cookie.

  • Certifique-se de que URLPrefix, Expires, KeyName e Signature ocorrem por esta ordem.

  • Não inclua um caráter de asterisco (*) no final de um URLPrefix num cookie assinado.

Cookies

  • Normalmente, os navegadores limitam os cookies a 4 KB por domínio, com um limite de 50 cookies por domínio no total. Tenha em atenção outros cookies que está a emitir e a exigir que os seus clientes enviem, porque muitos servidores Web também têm limites máximos de cabeçalhos de pedidos.

  • Certifique-se de que está a usar o caráter dois pontos (:), o ponto de código Unicode U+003A, como delimitador para os parâmetros com nome num cookie assinado, e não o caráter comercial (&) (&).

  • Certifique-se de que a data/hora Expires nos cookies que está a emitir não é desnecessariamente curta. Os períodos de validade inferiores a um a dois minutos podem ser propensos a problemas de desvio de tempo entre a app de emissão e a infraestrutura da CDN na nuvem.

  • Certifique-se de que não está a definir vários cookies para o mesmo Domain e Path com valores diferentes. Defina um único cookie por utilizador com um valor de prefixo de URL que abranja todo o conteúdo ao qual o utilizador precisa de aceder.

Mensagens de erro

Esta secção fornece informações sobre algumas mensagens de erro comuns e como as resolver.

Erros de invalidação de cache

Código de erro Notas
Invalid value for field 'resource.path'

O valor do caminho tinha um formato inválido. Os caminhos têm de começar com um /, não podem conter um ? nem um # e têm de ter apenas um *, que tem de ser um caráter final após um /.

Os caminhos não podem ter mais de 1024 carateres. Se receber este erro, verifique o valor do caminho e corrija quaisquer erros de formato.

Este erro aborda apenas o formato do caminho. Um caminho com um formato válido, mas que não existe, continua a ser tratado como válido.
Rate Limit Exceeded A CDN da nuvem restringe a taxa à qual as operações de invalidação da cache podem ser realizadas. Só é permitida uma invalidação por minuto. No entanto, cada operação pode especificar um padrão de caminho que corresponda a qualquer número de objetos.

Problemas conhecidos

  • As invalidações da cache estão limitadas a uma invalidação por mapa de URLs por minuto.

    Resolução: aguarde, pelo menos, um minuto antes de tentar invalidar outro mapa de URLs.

    Para mais informações sobre a limitação da taxa de invalidação de cache, consulte as limitações.