A configuração de regras de expiração de cache permite controlar a duração do cache para recursos nos pontos de presença (POPs) da CDNDCDN, equilibrando a atualização do conteúdo, o desempenho de acesso e os custos de busca na origem. Este documento explica como configurar e validar regras de cache, oferece orientações para solução de problemas e descreve as melhores práticas.
Como funciona
Quando uma solicitação chega a um ponto de presença (POP) da CDNDCDN, o sistema utiliza o seguinte processo priorizado para decidir se deve servir uma cópia em cache ou buscar o conteúdo mais recente no servidor de origem.
A CDNDCDN não armazena recursos em cache se o servidor de origem responder com
pragma:no-cache,cache-control:no-cache(ouno-store, oumax-age=0).-
As regras de cache configuradas no console da CDNDCDN têm precedência, exceto quando o servidor de origem envia explicitamente uma diretiva de no-cache conforme descrito acima.
-
Lógica de prioridade quando várias regras de cache do console correspondem a uma solicitação:
Cenário
Lógica de prioridade
Exemplo
Pesos diferentes
A regra com o maior peso (1-99) tem precedência.
A Regra A (diretório
/image/, peso 50) e a Regra B (extensão de arquivo.jpg, peso 90) correspondem aimage/a.jpg. A Regra B entra em vigor porque possui um peso maior.Mesmo peso
A regra criada primeiro tem precedência.
Você configura uma regra de diretório (
/static/) e uma regra de extensão de arquivo (.js) para um nome de domínio, ambas com peso 60. Se a regra de diretório foi criada antes da regra de extensão de arquivo, uma solicitação para/static/app.jscorresponde à regra de diretório. Após uma solicitação corresponder a uma regra de cache, nenhuma outra regra é avaliada.
Por padrão, se o servidor de origem responder com
Pragma: no-cacheouCache-Control: no-cache/no-store/max-age=0, o POP da CDNDCDN não armazena o recurso em cache. Para forçar o armazenamento em cache, selecione Ignore Origin No-Cache Header ao configurar a regra de expiração de cache.
-
-
A CDNDCDN respeita os cabeçalhos de resposta HTTP do servidor de origem caso uma solicitação não corresponda a nenhuma regra do console da CDNDCDN, ou se a regra correspondente tiver a opção Honor Origin TTL ativada. A prioridade dos cabeçalhos, do maior para o menor, é a seguinte:
cache-control>expires>last-modified>ETag.Cabeçalho de resposta
CDN tratamento
Observações e exemplos
Cache-Control
Utiliza
s-maxage(duração do cache CDN) primeiro e, em seguida,max-age.Exemplo:
s-maxage=86400, max-age=3600Expires
Especifica o tempo de expiração. Utilizado apenas se nenhum cabeçalho
Cache-Controlestiver presente.Exemplo:
Expires: Wed, 21 Oct 2025 07:28:00 GMTLast-Modified
O cabeçalho
Last-Modifiedé um carimbo de data/hora que indica quando o recurso foi modificado pela última vez.A duração do cache é calculada da seguinte forma:
(Hora Atual -
last-modified) × 0,1. A duração calculada é então limitada entre um mínimo de 10 segundos e um máximo de 3.600 segundos.Exemplo:
Last-Modified: Wed, 21 Oct 2023 07:28:00 GMTETag
Um
ETagé um identificador exclusivo gerado pelo servidor para uma versão específica de um recurso, geralmente um hash ou número de versão.Por padrão, um recurso com um
ETagé armazenado em cache por 10 segundos.Exemplo:
ETag: "abc123" Política de no-cache da CDNDCDN: Se uma solicitação não corresponder a nenhuma regra de cache no console da CDNDCDN e o servidor de origem não retornar cabeçalhos de resposta de cache como
Cache-Control, a CDNDCDN aplica uma política de no-cache.
A CDNDCDN aplica políticas de cache apenas a solicitações para as quais o servidor de origem retorna um código de status 200, 203, 206, 300, 301, 308 ou 410. Para armazenar em cache solicitações com outros códigos de status, como 404, configure esse comportamento em Cache Configuration > Status Code Expiration.
Procedimento
Console (recomendado)
No console CDN, acesse a página Domain Names e clique em Manage ao lado do nome de domínio desejado.
-
Na página Cache > Cache Expiration, clique em Add para configurar uma regra de cache.
Parâmetro
Descrição
Padrão/exemplo
Type
Especifique o escopo da regra por Directory ou File Extension.• Directory: Define uma regra de cache uniforme para todos os recursos sob um caminho.• File Extension: Define uma regra de cache uniforme para arquivos de um tipo específico.
Directory, File Extension
Object
Insira um valor com base no tipo selecionado:• Directory: Deve começar com uma barra (
/), por exemplo,/static/. Uma única barra (/) corresponde a todos os caminhos. É possível adicionar apenas um diretório por vez.• File Extension: Insira uma ou mais extensões de arquivo, separadas por vírgulas, por exemplo,jpg,png,css. As entradas diferenciam maiúsculas de minúsculas e não suportam a barra vertical () ou outros símbolos.
/static/,jpg,png,cssExpire In
A duração do cache para recursos nos POPs. A duração máxima é de três anos.• Para recursos estáticos raramente atualizados (por exemplo, imagens, instaladores), defina uma duração ≥ 1 mês.• Para recursos estáticos frequentemente atualizados (por exemplo, arquivos JS/CSS), defina uma duração menor, como 1 a 7 dias.• Para conteúdo dinâmico (por exemplo, páginas PHP/JSP), defina a duração como 0 segundos (sem cache).
0 segundos a 3 anos
Honor Origin TTL
Desativado por padrão. Se ativado, a política de cache do servidor de origem tem precedência e substitui esta regra.
Off
Ignore Origin No-Cache Header
Se ativado, a CDN ignora as seguintes diretivas de no-cache do servidor de origem:
Cache-Control: no-store,no-cacheoumax-age=0, ePragma: no-cache. Os recursos são armazenados em cache de acordo com a regra do console.Off
Follow POP Cache Policy
Se ativado, a CDN retorna sua política de cache efetiva, como
max-age=3600, ao cliente no cabeçalho de resposta.Off
Force Revalidation
Esta configuração é efetiva apenas quando o tempo de expiração é definido como 0 segundos.• Desativado (padrão, equivalente à política de cache
no-store): O POP não armazena o arquivo em cache, e cada solicitação deve ser encaminhada ao servidor de origem para buscar o conteúdo.• Ativado (equivalente à política de cacheno-cache): O POP armazena o arquivo em cache, mas cada solicitação deve ser revalidada com o servidor de origem usando o mecanismo 304. Útil para cenários que exigem validação em tempo real, mas também precisam reduzir a pressão de largura de banda no servidor de origem.Off
Weight
A prioridade da regra. O valor pode variar de 1 a 99, onde um valor maior indica maior prioridade. Quando várias regras correspondem ao mesmo recurso, a regra com o maior peso tem precedência. Se os pesos forem iguais, a regra criada primeiro tem precedência. Recomendamos definir um peso alto para caminhos ou extensões de arquivo específicos e um peso baixo para o diretório raiz (
/) para obter um controle refinado.1 a 99
Rule Condition
Refine ainda mais o escopo da regra com base em parâmetros de solicitação, como cabeçalhos e parâmetros de URL. Não utilizado por padrão. Para configurar condições, use o Rule Engine. Quando condições de regra são referenciadas, elas são correspondidas com base na prioridade das condições associadas, e não na ordem de configuração do recurso em si.
Do not use
Lógica de correspondência de regras de cache
As regras de expiração de cache da CDN suportam dois tipos de regras com comportamentos de correspondência diferentes:
Directory: Usa correspondência de prefixo de caminho. Por exemplo, configurar
/static/corresponde a todos os recursos nesse diretório (como/static/image/1.jpge/static/css/style.css). Configurar/corresponde a todos os caminhos. O caminho do diretório deve começar com uma barra (/). Cada regra suporta apenas um diretório.-
File Extension: Usa correspondência exata de extensão. Insira extensões sem pontos e separe múltiplas extensões com vírgulas (por exemplo,
jpg,css,js). As extensões suportam apenas caracteres alfanuméricos, sem restrição quanto a tipos específicos de extensão. Os seguintes tipos podem ser configurados:Extensões comuns de recursos estáticos:
jpg,png,gif,css,js,htmlExtensões de arquivos de fonte:
ttf,otf,woff,woff2,eotExtensões de páginas dinâmicas:
php,aspx,jspQualquer outra extensão alfanumérica
Observe o seguinte sobre a correspondência de regras de cache:
Quando várias regras de cache correspondem à mesma solicitação (por exemplo, uma regra de diretório e uma regra de extensão de arquivo), a regra com o maior Weight tem precedência. Regras com pesos iguais são resolvidas pela ordem de criação (a regra anterior vence). Para detalhes, consulte a seção "Como funciona" acima.
Se você associar uma condição de regra (configurada no Rule Engine) a uma regra de cache, múltiplas condições usam lógica AND — a solicitação deve satisfazer todas as condições para haver correspondência.
Se você definir uma regra geral de no-cache para todas as extensões dinâmicas (como
aspx), certifique-se de que isso não afete os recursos estáticos que você pretende armazenar em cache. Para armazenar arquivos de fonte em cache, adicione uma regra dedicada com extensões comottf,otf,woff,woff2,eot.
API
Chame a operação da API BatchSetCdnDomainConfig para configurar vários nomes de domínio em lote. Para obter mais informações sobre como configurar parâmetros para outros recursos, consulte Funções de configuração de nome de domínio.
Aplicar alterações de regras imediatamente
Regras novas ou modificadas aplicam-se apenas a recursos recém-armazenados em cache. Recursos previamente armazenados continuam usando a política de cache antiga até expirarem.
Para aplicar novas regras em toda a rede imediatamente, limpe manualmente o cache existente. Se você alterar uma regra, execute uma operação de purga usando o recurso Purge and Prefetch resources. Se você adicionar uma nova regra, execute uma operação de pré-busca usando o recurso prefetch resource.
Verificação
Após concluir a configuração, use o comando curl ou as ferramentas de desenvolvedor do navegador para inspecionar os cabeçalhos de resposta HTTP de um recurso e verificar se o cache está funcionando conforme o esperado.
1. Execute o comando de verificação
Execute o seguinte comando no seu terminal para testar a configuração.
curl -I "https://your.domain.com/path/to/file.jpg"2. Interprete os principais cabeçalhos de resposta
|
Cabeçalho de resposta |
Descrição |
|
|
Indica se a solicitação atingiu o cache da CDNDCDN.- |
|
|
Após ativar "Client Follows CDNDCDN Cache Policy", este cabeçalho exibe a diretiva de cache que a CDNDCDN passa para o navegador, como |
|
|
A duração total de cache configurada para o recurso no POP, em segundos. |
Melhores práticas
Use nomes de arquivo versionados (recomendado): Ao atualizar um recurso estático como
style.css, utilize um novo nome de arquivo com uma versão ou hash, comostyle-v2.cssoustyle-a1b2c3d.css, e atualize a referência no seu HTML. Esse método garante que os usuários recebam o conteúdo mais recente imediatamente, sem exigir uma purga manual do cache da CDNDCDN, sendo a forma recomendada de atualizar conteúdo em cache.Implemente a separação de conteúdo dinâmico e estático: Utilize nomes de domínio ou caminhos de diretório diferentes para recursos dinâmicos e estáticos. Configure regras de cache separadas e com alto peso para cada um, evitando conflitos de política. Por exemplo, defina uma longa duração de cache para todos os recursos no diretório
/static/e nenhum cache para recursos no diretório/api/.Utilize eficazmente o cache do navegador: Ative "Client follows CDNDCDN cache policy" para reduzir solicitações repetidas à CDNDCDN, melhorar a velocidade de carregamento e economizar tráfego da CDNDCDN.
Evite durações de cache excessivamente curtas: Uma duração curta faz com que a CDNDCDN realize buscas frequentes na origem, o que anula os benefícios da aceleração e aumenta o tráfego e os custos do seu servidor de origem.
Tenha cautela com durações longas de cache: Uma duração longa pode impedir que os clientes recebam atualizações de conteúdo em tempo hábil. Para conteúdos que precisam de atualizações frequentes, certifique-se de limpar o cache ou usar nomes de arquivo versionados.
Cenários de arquivos pequenos: Para recursos de arquivos pequenos na indústria de jogos (como arquivos de configuração e pacotes de ativos) que são atualizados com pouca frequência (por exemplo, semanalmente ou quinzenalmente), defina o tempo de expiração do cache para 15 dias ou alinhe-o ao ciclo real de atualização do recurso. Isso equilibra a velocidade de atualização e o desempenho de aceleração. Uma duração de cache muito curta leva a buscas frequentes na origem e reduz os benefícios da aceleração; já uma duração muito longa pode servir conteúdo desatualizado aos jogadores. Recomendamos usar o recurso de purge and prefetch para atualizar proativamente o cache quando o conteúdo for modificado.
Mecanismos de controle de cache HTTP
O protocolo HTTP utiliza três tipos de cabeçalhos para controle de cache: