Edge Security Acceleration:Regras de cache padrão

Política de cache padrão

As configurações de cache aplicam-se somente a solicitações roteadas para o componente de cache do ESA. O ESA utiliza as etapas a seguir para determinar se uma solicitação entra no cache:

1. Verifique se a solicitação é do tipo GET ou HEAD.

2. Verifique se a solicitação atende às condições especificadas em uma regra de cache. Caso atenda, a regra de cache prevalece sobre as configurações globais de cache para essa solicitação. Para obter mais informações, consulte {{XREF_1}}.

3. Confira se a extensão do arquivo está listada em {{XREF_2}}. Em caso afirmativo, as configurações globais de cache serão aplicadas à solicitação.

Regras de cache para respostas bem-sucedidas e redirecionamentos

Códigos de status aplicáveis: 200, 203, 206, 300, 301 e 410.

O TTL do cache de borda possui quatro opções:

• Honor Origin TTL or Use Default Cache Rule: Se a resposta retornada pelo servidor de origem contiver os cabeçalhos Cache-Control, Expires, Last-Modified e ETag para definir uma política de cache, o ESA utiliza a política de cache do servidor de origem. Caso a resposta do servidor de origem não contenha nenhum dos cabeçalhos Cache-Control, Expires, Last-Modified e ETag, o ESA armazena os recursos em cache com base na política de cache padrão do ESA.

  Detalhes da política de cache

  

  Cache-Control na resposta

  O cabeçalho Cache-Control na resposta de origem especifica uma das seguintes políticas:

  1. Se o cabeçalho Cache-Control tiver uma das diretivas a seguir, o recurso não será armazenado em cache:

     • no-cache

     • no-store

     • max-age=0

  2. Quando o cabeçalho Cache-Control contém a diretiva max-age ou s-maxage com valor maior que 0, como 3600, utiliza-se o TTL especificado pela diretiva. Se ambas as diretivas max-age e s-maxage existirem, o valor da diretiva s-maxage prevalece.

  Ausência de Cache-Control na resposta

  Se a resposta de origem não contiver o cabeçalho Cache-Control, aplica-se a política de cache padrão do ESA. Prioridade dos cabeçalhos (do maior para o menor): Expires > Last-Modified > ETag.

  1. Caso a resposta de origem contenha o cabeçalho Expires, como Expires:Tue, 25 Nov 2031 17:25:43 GMT, o ESA usa o TTL definido no cabeçalho Expires.

  2. Quando a resposta de origem não contém o cabeçalho Expires, mas contém o cabeçalho Last-Modified, o cálculo do TTL segue estas regras:

     • TTL = (Hora atual - Valor de Last-Modifie d) × 0,1. Se o valor resultante estiver entre 10 segundos e 3.600 segundos, utiliza-se o valor real. Para valores menores que 10 segundos, o TTL será de 10 segundos. Se o valor for superior a 3.600 segundos, o TTL será de 3.600 segundos.

  3. Se a resposta de origem contiver apenas o cabeçalho ETag, o TTL será de 10 segundos.

  4. Na ausência dos cabeçalhos Cache-Control, Expires, ETag ou Last-Modified na resposta de origem, o recurso não é armazenado em cache.

• Honor Origin TTL or Do Not Cache: Se a resposta do servidor de origem contiver o cabeçalho Cache-Control para definir uma política de cache, o ESA adota a política de cache do servidor de origem. Caso a resposta não contenha o cabeçalho Cache-Control, o ESA não armazena os recursos em cache.

  Detalhes da política de cache

  

  Determinação da política de cache do servidor de origem

  Verifique se a resposta de origem contém o cabeçalho Cache-Control. Se estiver ausente, os recursos não são armazenados em cache. Se presente, aplica-se uma das seguintes políticas:

  1. Recursos não são armazenados em cache se o cabeçalho Cache-Control contiver a diretiva no-cache, no-store ou max-age=0.

  2. Caso o cabeçalho Cache-Control contenha a diretiva max-age ou s-maxage com valor maior que 0, como 3600, utiliza-se o TTL especificado pela diretiva. Se ambas as diretivas max-age e s-maxage existirem, o valor da diretiva s-maxage prevalece.

• Do Not Cache: Nenhum recurso recuperado do servidor de origem é armazenado em cache nos POPs do ESA.

• Use Custom TTL: O ESA ignora os cabeçalhos Cache-Control, Expires, Last-Modified e ETag da política de cache na resposta de origem e utiliza o TTL definido no ESA.

Regras de cache para respostas com códigos de status de erro

• Para os códigos de status 204, 305, 404, 405, 414, 424, 429, 500, 501, 502, 503 e 504, as regras de cache são:

  

  1. A resposta não é armazenada em cache se o servidor de origem retornar um cabeçalho de resposta set-cookie.

  2. Se o servidor de origem não retornar um cabeçalho de resposta set-cookie, o sistema verifica se há um TTL configurado para o código de status no console:

     1. Caso exista um TTL configurado, a resposta é armazenada em cache conforme as definições do console. Se houver múltiplas regras, prevalece aquela com o menor número ordinal.

     2. Na ausência de configuração de TTL, o armazenamento em cache da resposta baseia-se nos cabeçalhos de resposta Pragma, Cache-Control ou Expires do servidor de origem.

  3. Se o servidor de origem não retornar os cabeçalhos de resposta Pragma, Cache-Control ou Expires, a resposta é armazenada em cache por 1 segundo, por padrão.

• Para os códigos de status 302, 307 e 403, aplicam-se as seguintes regras de cache:

  

  1. A resposta não é armazenada em cache quando o servidor de origem retorna um cabeçalho de resposta set-cookie.

  2. Se o servidor de origem não retornar um cabeçalho de resposta set-cookie, o sistema verifica se há um TTL configurado para o código de status no console:

     1. Caso exista um TTL configurado, a resposta é armazenada em cache conforme as definições do console. Se houver múltiplas regras, prevalece aquela com o menor número ordinal.

     2. Na ausência de configuração de TTL, o armazenamento em cache da resposta baseia-se nos cabeçalhos de resposta Pragma, Cache-Control ou Expires do servidor de origem.

  3. A resposta não é armazenada em cache se o servidor de origem não retornar os cabeçalhos de resposta Pragma, Cache-Control ou Expires.

• Para outros códigos de status de erro, como 400, as regras de cache funcionam da seguinte forma:

  1. A resposta não é armazenada em cache se o servidor de origem retornar um cabeçalho de resposta set-cookie.

  2. Quando o servidor de origem não retorna um cabeçalho de resposta set-cookie, o sistema verifica se há um TTL configurado para o código de status no console. Se houver múltiplas regras, prevalece aquela com o menor número ordinal.

  3. Em todos os outros casos, a resposta não é armazenada em cache.

• Para solicitações que usam busca de origem por intervalo (range origin fetch), se um POP receber uma resposta com código de status diferente de 206 do servidor de origem, o POP exclui os fragmentos de arquivo em cache. Um tempo limite de busca de origem não causa a exclusão dos arquivos em cache.

  Ao usar a busca de origem por intervalo, o servidor de origem divide um arquivo grande em vários fragmentos menores e os envia ao POP. Por exemplo, se um arquivo for dividido em 10 fragmentos e o POP já tiver armazenado 5 deles em cache, ao solicitar o 6º fragmento e receber um código de status 5xx do servidor de origem, o POP excluirá todos os 5 fragmentos armazenados.

Informações de resposta de cache

ESA POPs retornam cabeçalhos de resposta relacionados ao cache com as seguintes informações:

• Ali-Swift-Global-Savetime: Momento em que o recurso entrou pela primeira vez no POP do ESA (determinado pela arquitetura de cache do site, que pode ser um POP L2 ou um POP em outra camada de cache).

  • Seu valor é um timestamp UNIX. Por exemplo: 1745053111 indica 16:58:31 on April 19, 2025.

• Date: Data em que o servidor de origem retorna o recurso ao POP do ESA.

  • A data é atualizada quando o POP do ESA inicia uma solicitação de origem contendo o cabeçalho If-Modified-Since ou If-None-Match para revalidar o recurso, e o servidor de origem retorna o código de status HTTP 304.

  • A hora está no formato GMT. Exemplo: Sat, 19 Apr 2025 08:58:31 GMT.

• X-Site-Cache-Status: Status de cache do recurso solicitado no POP do ESA. A lista a seguir descreve os estados do recurso:

  • HIT: O recurso foi encontrado no cache do POP do ESA.

  • MISS: O recurso não foi encontrado no cache do POP do ESA. O POP recupera o recurso do servidor de origem e o retorna ao cliente.

  • NONE/UNKNOWN: O recurso não é elegível para cache pelos seguintes motivos:

    • Uma função de borda gera uma resposta, mas não envia nenhuma subsolicitação. Nesse caso, a resposta não vem do cache, e o status de cache é registrado como none/unknown.

    • Quando a solicitação principal de uma função de borda inicia uma subsolicitação (fetch), o status de cache é registrado para a subsolicitação, enquanto o status de cache da solicitação principal é registrado como none/unknown. Isso ocorre porque o módulo de função de borda executa antes do módulo de cache, impedindo que a solicitação principal passe pelo cache.

    • Uma solicitação de cliente aciona uma regra personalizada do WAF e é bloqueada por ele. Como o WAF executa antes do módulo de cache, a solicitação não passa pelo cache, e o status de cache é registrado como none/unknown.

    • Uma solicitação de cliente aciona uma {{XREF_4}} ou uma {{XREF_5}}. O POP então envia uma resposta de redirecionamento para outra URL. Como essas regras executam antes do módulo de cache, o status de cache é registrado como none/unknown.

  • EXPIRED: O recurso foi encontrado no cache do POP do ESA, mas expirou. O POP recupera o recurso do servidor de origem e o retorna ao cliente. O código de status retornado pelo servidor de origem é 200 ou 206.

  • STALE:

    O recurso é servido a partir do cache do POP do ESA, mas expirou. Isso ocorre nos seguintes casos:

    • A configuração de cache é Honor Origin TTL e a resposta de origem contém Cache-Control:stale-while-revalidate=<seconds>. Dentro do tempo especificado, o ESA inicia uma solicitação ao servidor de origem para revalidar o recurso e serve o cache expirado ao cliente.

    • A configuração de cache é Honor Origin TTL e a resposta de origem contém Cache-Control:stale-if-error=<seconds>. Dentro do tempo especificado, o ESA serve o cache expirado ao cliente quando o ESA não consegue se conectar ao servidor de origem para recuperar o recurso atualizado.

    • O recurso {{XREF_6}} está ativado. Esse recurso permite que o POP do ESA sirva o cache expirado ao cliente quando a resposta de origem atingir o tempo limite ou quando o servidor de origem estiver inacessível.

  • BYPASS

    A solicitação ao recurso ignora o cache do ESA. Isso ocorre nos seguintes casos:

    • A configuração de cache não é Honor Origin TTL e o ESA define um TTL de cache personalizado como 0 segundos.

    • A configuração de cache é Honor Origin TTL, mas o valor do cabeçalho Cache-Control retornado pelo servidor de origem é no-store.

  • REVALIDATED

    O recurso é servido pelo cache do ESA, mas expirou. O ESA inicia uma solicitação de origem contendo o cabeçalho If-Modified-Since ou lf-None-Match ao servidor de origem para revalidar o recurso. O servidor de origem retorna o código de status HTTP 304.

  • DYNAMIC

    O ESA detecta que o recurso é conteúdo dinâmico e nenhuma regra de cache definida se aplica a tal solicitação. Nesse caso, o ESA recupera o recurso do servidor de origem e o retorna ao cliente.

• X-Swift-Cachetime: Especifica o TTL do recurso no POP em segundos. O valor de X-Swift-Cachetime não é igual ao TTL definido no ESA. Ele é calculado usando a seguinte fórmula: X-Swift-Cachetime = Ali-Swift-Global-Savetime + o TTL definido no ESA - X-Swift-SaveTime. Os seguintes cenários podem ocorrer:

  • O valor de X-Swift-Cachetime é igual ao TTL definido no ESA, por exemplo, 3600 segundos.

  • O valor de X-Swift-Cachetime é ligeiramente menor que o TTL definido no ESA. Por exemplo, se o TTL definido no ESA for 300 segundos, o valor de X-Swift-Cachetime poderá ser 295 segundos. Essa discrepância pode ocorrer pelos seguintes motivos:

    • Alta latência ocorre quando um nó L1 busca conteúdo de um nó L2.

    • Os relógios nos nós L1 e L2 não estão sincronizados.

  • O valor de X-Swift-Cachetime é negativo. Isso pode ocorrer se você alterar a configuração de TTL no ESA após um recurso ser armazenado em cache. Isso acontece quando uma solicitação de cliente chega após a expiração do cache do nó L1, mas enquanto o cache do nó L2 ainda é válido. Por exemplo, o TTL foi originalmente definido como 3600 segundos no ESA e posteriormente alterado para 300 segundos. Se um cliente enviar uma solicitação 600 segundos após o recurso ter sido armazenado em cache, a resposta incluirá X-Swift-Cachetime:-300. Para resolver esse problema, atualize o cache.

• X-Swift-Cachetime:

  O TTL de cache do recurso no POP do ESA. Unidade: segundos.

• X-Swift-SaveTime:

  • O momento em que o recurso entrou pela primeira vez no POP atual (POP L1) que recebe a solicitação do cliente.

  • A hora está no formato GMT. Exemplo: Sat, 19 Apr 2025 08:58:31 GMT.

Política Do Not Cache

O POP do ESA não armazena arquivos em cache e repassa todas as solicitações de arquivo nas seguintes condições:

• Edge Cache TTL na página ESA Settings está definido como Honor Origin TTL or Do Not Cache e a resposta de origem é Cache-Control: no-store.

• Edge Cache TTL na página ESA Settings está definido como Do Not Cache.

• Edge Cache TTL na página ESA Settings está definido como Use Custom TTL e o TTL de cache está definido como 0 segundos.

Revalidação de cache

Após a expiração de um arquivo em cache no POP do ESA, o POP do ESA envia uma solicitação de validação ao servidor de origem na próxima solicitação do cliente. Se o arquivo não tiver sido alterado, o servidor de origem retorna 304 not-modified, e o POP do ESA serve o arquivo em cache sem baixá-lo novamente. Isso reduz o tráfego de origem e melhora a velocidade de resposta.

• Configuração de política especial: Um arquivo é armazenado em cache por 0 segundos, e o POP do ESA redireciona cada solicitação ao servidor de origem para validação.

  • Edge Cache TTL na página ESA Settings está definido como Honor Origin TTL or Use Default Cache Rule, e a resposta de origem atende às seguintes condições:

    • Cache-Control: no-cache

    • Cache-Control: max-age=0

• Configuração de política regular: O servidor de origem responde à política relacionada à validação de cache, e o POP do ESA executa a política efetiva.

  • Edge Cache TTL na página ESA Settings está definido como Honor Origin TTL or Use Default Cache Rule, e a resposta de origem atende a uma das seguintes políticas de validação de cache:

    • must-revalidate

    • proxy-revalidate

    • stale-while-revalidate=seconds

    • stale-if-error=seconds

• Políticas de validação de cache

  Políticas de validação de cache:

  • must-revalidate

    • Descrição: Uma vez expirado, qualquer cache (proxy ou navegador) deve revalidar o recurso com o servidor de origem antes de servi-lo. O cache não pode servir conteúdo expirado mesmo se a rede estiver indisponível, a menos que o recurso tenha sido validado como inalterado.

    • Exemplo: Cache-Control: max-age=3600, must-revalidate indica que um recurso deve ser retornado ao servidor de origem para validar sua atualização após a expiração do recurso.

  • proxy-revalidate

    • Descrição: Semelhante a must-revalidate, mas aplica-se apenas a caches compartilhados (CDN, servidores proxy). Caches privados, como navegadores, não estão sujeitos a essa restrição.

    • Exemplo: Cache-Control: max-age=3600, proxy-revalidate indica que um recurso deve ser retornado ao servidor de origem para validar sua atualização após a expiração do recurso.

  • stale-while-revalidate=seconds

    • Descrição: Após a expiração, o cache serve conteúdo obsoleto pela duração especificada enquanto revalida assincronamente com a origem em segundo plano. Utilize esta opção quando a redução da latência for mais importante do que servir conteúdo brevemente obsoleto.

    • Exemplo: Cache-Control: max-age=3600, stale-while-revalidate=60 indica que um recurso é considerado atualizado por 3.600 segundos (1 hora) após sua primeira publicação. Uma vez expirado, o recurso ainda pode ser fornecido aos usuários pelos próximos 60 segundos. Ao mesmo tempo, o POP tenta obter atualizações do servidor de origem.

  • stale-if-error=seconds

    • Descrição: Quando a origem está inacessível (falha no servidor, erro de rede), o POP serve conteúdo em cache expirado pela duração especificada. Isso melhora a tolerância a falhas e mantém a disponibilidade durante interrupções na origem.

    • Exemplo: Cache-Control: max-age=86400, stale-if-error=604800 indica que um recurso é considerado atualizado por 86.400 segundos (24 horas) após sua primeira publicação. Se a revalidação após os 86.400 segundos falhar, o último recurso armazenado em cache com sucesso ainda poderá ser fornecido pelos próximos 604.800 segundos (uma semana).