Configurar o comportamento de armazenamento em cache

A Media CDN veicula conteúdo o mais próximo possível dos usuários usando a infraestrutura global de armazenamento em cache de borda do Google para armazenar conteúdo em cache e reduzir a carga na infraestrutura de origem.

É possível controlar como o conteúdo é armazenado em cache para cada rota. Isso permite otimizar o comportamento com base no tipo de conteúdo, nos atributos da solicitação do cliente e nos seus requisitos de atualização.

Capacidade de armazenamento em cache

As seções a seguir descrevem quais respostas a Media CDN armazena em cache e como melhorar o descarregamento de cache.

Comportamento de armazenamento em cache padrão

Por padrão, as seguintes configurações relacionadas ao cache são aplicadas a cada serviço do Edge Cache:

• Modo de cache padrão de CACHE_ALL_STATIC:

  • Respeita as diretivas de cache de origem, como Cache-Control ou Expires, até um TTL máximo configurável.
  • Armazena automaticamente em cache tipos de mídia estática com um TTL padrão de 3.600 segundos, se não houver diretivas de cache de origem.
  • Armazena em cache os códigos de status HTTP 200, 204 e 206 (o cache negativo não está ativado).

• Não armazena em cache respostas com diretivas no-store ou private de controle de cache ou que não podem ser armazenadas em cache.

As respostas que não são conteúdo estático ou que não têm diretivas de cache válidas não são armazenadas em cache, a menos que o armazenamento em cache seja configurado explicitamente. Para saber como substituir o comportamento padrão, consulte a documentação sobre modos de cache .

O comportamento padrão é equivalente ao seguinte cdnPolicy. As rotas sem um cdnPolicy explícito configurado se comportam como se tivessem a seguinte configuração:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 3600s
  cacheKeyPolicy:
    includeProtocol: false
    excludeHost: false
    excludeQueryString: false
  signedRequestMode: DISABLED
  negativeCaching: false

Respostas armazenáveis em cache

Uma resposta armazenável em cache é uma resposta HTTP que o Media CDN pode armazenar e recuperar rapidamente, possibilitando tempos de carregamento mais rápidos. Nem todas as respostas HTTP são armazenáveis em cache.

É possível configurar modos de cache para cada rota e substituir esse comportamento. Por exemplo, use o modo de cache CACHE_ALL_STATIC para armazenar em cache tipos de mídia comuns, mesmo que a origem não defina uma diretiva de controle de cache na resposta.

As solicitações e respostas que atendem aos critérios definidos em respostas não armazenáveis em cache substituem a capacidade de armazenamento em cache.

A tabela a seguir descreve os requisitos para armazenar em cache respostas HTTP específicas. As respostas GET e HEAD precisam obedecer a esses requisitos.

O cabeçalho HTTP Age é definido com base em quando o Media CDN armazenou em cache a resposta pela primeira vez e geralmente representa os segundos desde que o objeto foi armazenado em cache em um local de proteção de origem. Se a origem gerar um cabeçalho de resposta "Age", use o modo de cache FORCE_CACHE_ALL para evitar revalidações quando a idade exceder o TTL do cache.

Para mais informações sobre como a Media CDN interpreta as diretivas de armazenamento em cache HTTP, consulte Diretivas de controle de cache.

Requisitos de origem

Para permitir que o Media CDN armazene em cache respostas de origem maiores que 1 MiB, uma origem precisa incluir o seguinte nos cabeçalhos de resposta para solicitações HEAD e GET, a menos que especificado de outra forma:

• Um cabeçalho de resposta HTTP Last-Modified ou ETag (um validador).
• Um cabeçalho HTTP Date válido.
• Um cabeçalho Content-Length válido.
• O cabeçalho de resposta Content-Range, em resposta a uma solicitação Range GET. O cabeçalho Content-Range precisa ter um valor válido na forma de bytes x-y/z, em que z é o tamanho do objeto.

O protocolo de origem padrão é HTTP/2. Se as origens forem compatíveis apenas com HTTP/1.1, defina o campo de protocolo explicitamente para cada uma delas.

Respostas não armazenáveis em cache

A tabela a seguir detalha os atributos de solicitação e resposta que impedem o armazenamento em cache de uma resposta. As respostas que podem ser armazenadas em cache, mas que correspondem a critérios "não armazenáveis em cache", não são armazenadas em cache.

Essas regras são aplicadas além do modo de cache configurado. Especificamente:

• Com o modo de cache CACHE_ALL_STATIC configurado, somente as respostas consideradas conteúdo estático ou com diretivas de cache válidas nos cabeçalhos de resposta são armazenadas em cache. Outras respostas são transmitidas por proxy como estão.
• O modo de cache FORCE_CACHE_ALL armazena todas as respostas incondicionalmente, sujeito aos requisitos de não armazenabilidade declarados anteriormente.
• O modo de cache USE_ORIGIN_HEADERS exige que as respostas definam diretivas de cache válidas nos cabeçalhos de resposta, além de serem um código de status armazenável em cache.

Observações:

• As respostas que não são armazenadas em cache não têm as diretivas de controle de cache ou outros cabeçalhos alterados e são encaminhadas por proxy como estão.
• Os cabeçalhos Cache-Control e Expires das respostas podem ser recolhidos em um único campo Cache-Control. Por exemplo, uma resposta com Cache-Control: public e Cache-Control: max-age=100 em linhas separadas seria recolhida como Cache-Control: public,max-age=100.
• Respostas não armazenáveis em cache (que nunca seriam armazenadas em cache) não são contadas como Cache Egress do ponto de vista do faturamento.

Como usar modos de cache

Com os modos de cache, é possível configurar quando a Media CDN deve respeitar as diretivas de cache de origem, armazenar em cache tipos de mídia estática e todas as respostas da origem, independente das diretivas definidas.

Os modos de cache são configurados no nível da rota e, combinados com substituições de TTL, permitem configurar o comportamento do cache por host, caminho, parâmetros de consulta e cabeçalhos (qualquer parâmetro de solicitação correspondente).

• Por padrão, a Media CDN usa o modo de cache CACHE_ALL_STATIC, que armazena automaticamente em cache os tipos de mídia estática comuns por uma hora (3.600 segundos), priorizando as diretivas de cache especificadas pela origem para respostas armazenáveis em cache.
• É possível aumentar ou diminuir o TTL do cache aplicado a respostas sem um TTL explícito definido (uma diretiva max-age ou s-maxage) definindo o campo cdnPolicy.defaultTtl em uma rota.
• Para evitar o armazenamento em cache de respostas não bem-sucedidas por mais tempo do que o pretendido, os códigos de status não 2xx (não bem-sucedidos) não são armazenados em cache de acordo com o Content-Type (tipo MIME) e não têm o TTL padrão aplicado.

Os modos de cache disponíveis, que são definidos no cdnPolicy.cacheMode de cada rota, são mostrados na tabela a seguir.

Tipos MIME de conteúdo estático

O modo de cache CACHE_ALL_STATIC permite que o Media CDN armazene automaticamente em cache conteúdo estático comum, como vídeo, áudio, imagens e recursos da Web comuns, com base no tipo MIME retornado no cabeçalho de resposta HTTP Content-Type. No entanto, independente do tipo de mídia, a Media CDN prioriza cabeçalhos Cache-Control ou Expires explícitos na resposta da origem.

A tabela a seguir lista os tipos MIME que podem ser armazenados em cache automaticamente com o modo de cache CACHE_ALL_STATIC.

As respostas não são armazenadas em cache automaticamente se não tiverem um cabeçalho de resposta Content-Type com um valor que corresponda aos seguintes valores. Verifique se a resposta define uma diretiva de cache válida ou use o modo de cache FORCE_CACHE_ALL para armazenar em cache as respostas incondicionalmente.

Observe o seguinte:

• O software servidor da Web de origem precisa definir o Content-Type de cada resposta. Muitos servidores da Web definem automaticamente o cabeçalho Content-Type, incluindo NGINX, Varnish e Apache.
• O Cloud Storage define o cabeçalho Content-Type automaticamente no upload quando você usa o console Google Cloud ou a CLI gcloud para fazer upload de conteúdo.
• O Cloud Storage sempre fornece um cabeçalho Cache-Control para a Media CDN. Se nenhum valor for escolhido de maneira explícita, ele enviará um valor padrão. Como resultado, todas as respostas bem-sucedidas do Cloud Storage são armazenadas em cache de acordo com os valores padrão do Cloud Storage, a menos que você ajuste explicitamente os metadados de controle de cache para objetos no Cloud Storage ou use o modo FORCE_CACHE_ALL para substituir os valores enviados pelo Cloud Storage.

Se uma resposta puder ser armazenada em cache com base no tipo MIME, mas tiver uma diretiva de resposta Cache-Control de private ou no-store ou um cabeçalho Set-Cookie, ela não será armazenada em cache.

Outros tipos de mídia, como HTML (text/html) e JSON (application/json), não são armazenados em cache por padrão. Esses tipos de respostas costumam ser dinâmicos (por usuário) e não são adequados para a arquitetura da Media CDN. Recomendamos usar o Cloud CDN para veicular recursos da Web e armazenar em cache respostas da API.

Configurar TTLs de cache

As substituições de time to live (TTL) permitem definir valores padrão de TTL para conteúdo armazenado em cache e substituir os valores de TTL definidos nas diretivas de controle de cache max-age e s-maxage (ou cabeçalhos Expires) definidas pelas origens.

Os TTLs, definidos por modificações ou usando uma diretiva de cache, são otimistas. O conteúdo que é raramente acessado ou não é popular pode ser removido do cache antes de atingir o TTL.

A tabela a seguir mostra três configurações de TTL.

Definir qualquer valor de TTL como zero (0 segundos) faz com que cada solicitação seja revalidada com a origem antes de uma resposta ser veiculada e aumenta a carga na origem se definido de forma muito ampla.

Quando o modo de cache é definido como Use Origin Headers, não é possível configurar as configurações de TTL porque o CDN de mídia depende da origem para direcionar o comportamento.

Observações:

• O valor do TTL máximo precisa ser sempre maior ou igual ao valor do TTL padrão.
• O valor do TTL do cliente precisa ser sempre menor ou igual ao valor do TTL máximo.
• Quando a Media CDN substitui um valor de TTL de origem, o cabeçalho Cache-Control para o cliente também reflete esse valor.
• Se a origem definir um cabeçalho Expires e o Media CDN substituir o TTL efetivo (com base no carimbo de data/hora), o cabeçalho Expires será substituído por um cabeçalho Cache-Control na resposta downstream ao cliente.

Armazenamento em cache negativo

O cache negativo define como os códigos de status HTTP que não são de sucesso (diferentes de 2xx) são armazenados em cache pela Media CDN.

Isso permite armazenar em cache respostas de erro, como redirecionamentos (HTTP 301 e 308) e respostas não encontradas (HTTP 404), mais perto dos usuários, além de reduzir a carga de origem de maneira mais ampla se a resposta não mudar e puder ser armazenada em cache.

Por padrão, o armazenamento em cache negativo fica desativado. A tabela a seguir mostra os valores padrão para cada código de status quando o cache negativo está ativado e negativeCachingPolicy não é usado.

O conjunto padrão de códigos de armazenamento em cache negativo corresponde aos códigos de status heurísticos armazenáveis em cache descritos na RFC 9110 do HTTP, com as seguintes exceções:

• O código HTTP 414 (URI muito longo) não é compatível com o armazenamento em cache para evitar envenenamento do cache.
• O código HTTP 451 (Indisponível por motivos legais) é compatível com o armazenamento em cache, conforme descrito na RFC 7725 do HTTP.

Se você precisar configurar seus próprios TTLs por código de status e substituir o comportamento padrão, configure um cdnPolicy.negativeCachingPolicy. Isso permite definir o TTL para qualquer um dos códigos de status permitidos pela Media CDN: 300, 301, 302, 307, 308, 400, 403, 404, 405, 410, 451, 500, 501, 502, 503 e 504.

Por exemplo, para definir um TTL curto de 5 segundos para respostas HTTP 404 (Não encontrado) e um TTL de 10 segundos para respostas HTTP 405 (Método não permitido), use a seguinte definição YAML em cada rota aplicável:

cdnPolicy:
  negativeCaching: true
  negativeCachingPolicy:
    "404": 5s
    "405": 10s
  # other status codes to apply TTLs for

Para evitar o envenenamento de cache, não recomendamos ativar o armazenamento em cache para os códigos de status 400 (solicitação inválida) ou 403 (proibido). Verifique se o servidor de origem retorna o código como resultado da análise apenas dos componentes da solicitação incluídos na chave de cache. A contaminação de cache pode ocorrer, por exemplo, quando o servidor de origem responde com um erro 403 na ausência de um cabeçalho Authorization correto. Nesse caso, o armazenamento em cache da resposta de erro 403 faz com que a Media CDN veicule a resposta de erro 403 para todas as solicitações subsequentes até que o TTL expire, mesmo que as solicitações tenham um cabeçalho Authorization correto.

Para desativar o armazenamento em cache negativo:

• Para desativar o comportamento padrão de armazenamento em cache negativo, defina cdnPolicy.negativeCaching: false em uma rota. As respostas de origem com diretivas de cache válidas e códigos de status armazenáveis em cache ainda são armazenadas em cache.
• Para evitar o armazenamento em cache negativo de um código de status específico, mas ainda respeitar as diretivas de cache de origem, omita o código de status (cdnPolicy.negativeCachingPolicy[].code) na definição de negativeCachingPolicy.
• Para ignorar explicitamente as diretivas de cache de origem para um código de status específico, defina cdnPolicy.negativeCachingPolicy[].ttl como 0 (zero) para esse código de status.

Observações:

• Quando negativeCaching está ativado em uma rota e uma resposta define diretivas de cache válidas, as diretivas de cache na resposta têm precedência.
• Se você configurar um negativeCachingPolicy explícito e houver um TTL definido para o código de status, o TTL definido na política será sempre usado.
• O valor máximo para um TTL definido por negativeCachingPolicy é de 1.800 segundos (30 minutos), mas as diretivas de cache de origem com um TTL maior são respeitadas.
• Se o modo de cache estiver configurado como FORCE_CACHE_ALL, as diretivas de origem serão ignoradas em todos os casos.

Diretivas de controle de cache

O comportamento da Media CDN em relação às diretivas Cache-Control é definido aqui.

Se a diretiva não for aplicável a uma solicitação ou resposta, como only-if-cached (uma diretiva somente do cliente), "N/A" será marcado nessa coluna.

Sempre que possível, o Media CDN está em conformidade com a RFC (HTTP RFC 7234), mas prefere otimizar o descarregamento do cache e minimizar o impacto que os clientes podem ter na taxa de ocorrência e na carga de origem geral.

Em respostas que usam o cabeçalho HTTP/1.1 Expires:

• O valor do cabeçalho Expires precisa ser uma data de HTTP válida, conforme definido na norma RFC 7231.
• Uma data no passado, uma data inválida ou um valor de 0 indica que o conteúdo já expirou e requer revalidação.
• A Media CDN ignora o cabeçalho Expires se um cabeçalho Cache-Control estiver presente na resposta.

O cabeçalho HTTP/1.0 Pragma, se presente em uma resposta, será ignorado e transmitido como está para o cliente.

Chaves de cache

Para reduzir o número de vezes que a Media CDN precisa entrar em contato com sua origem, considere o que identifica exclusivamente uma solicitação e remova os componentes que podem mudar com frequência entre as solicitações. O conjunto de componentes de solicitação é geralmente chamado de "chave de cache".

As seções a seguir descrevem como configurar chaves de cache.

Componentes da chave de cache

Uma chave de cache é o conjunto de parâmetros de solicitação (como host, caminho e parâmetros de consulta) que um objeto armazenado em cache usa como referência.

Por padrão, as chaves de cache para serviços de cache de borda incluem o host, o caminho e os parâmetros de consulta da solicitação e são limitadas a um EdgeCacheService específico.

Observe o seguinte:

• As chaves de cache não são anexadas a uma origem configurada, permitindo que você atualize uma configuração de origem (ou substitua a origem completamente) sem o risco de "limpar" o cache (por exemplo, ao migrar o armazenamento de origem entre provedores).
• As chaves de cache são restritas a um EdgeCacheService. Diferentes EdgeCacheServices têm namespaces de cache diferentes, o que impede o armazenamento em cache acidental de objetos entre ambientes de produção, preparo e outros de teste, mesmo que o host, o caminho ou outros componentes da chave de cache correspondam. A exclusão de um EdgeCacheService invalida todos os objetos armazenados em cache para esse serviço.
• As chaves de cache não são definidas para uma rota individual. Várias rotas podem se referir à mesma chave de cache, principalmente se elas corresponderem a componentes que não estão incluídos na chave de cache, como cabeçalhos de solicitação ou parâmetros excluídos. Isso pode ser útil se você quiser que várias rotas compartilhem o mesmo cache, mas retornem cabeçalhos de resposta ou configuração do CORS diferentes.
• As chaves de cache não incluem a configuração de reescrita de URL. Por exemplo, uma chave de cache é baseada na solicitação voltada ao usuário, não na solicitação final "reescrita".
• Quando as solicitações assinadas são configuradas em uma rota, os atributos assinados não são incluídos na chave de cache. A solicitação é tratada como se os parâmetros de consulta ou o componente de caminho (assinados), começando com edge-cache-token e terminando no próximo separador de caminho ("/"), não fizessem parte do URL.

Incluir ou excluir parâmetros de consulta

É possível incluir ou excluir parâmetros de consulta específicos de uma chave de cache adicionando o nome do parâmetro à configuração de chave de cache includedQueryParameters ou excludedQueryParameters em uma determinada rota.

Por exemplo, para incluir os parâmetros de consulta contentID e country e ignorar todos os outros da chave de cache:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 86400s
  cacheKeyPolicy:
    includedQueryParameters: ["contentID", "country"]

Inclua os parâmetros de consulta que identificam o conteúdo de forma exclusiva e exclua os que não fazem isso. Por exemplo, exclua parâmetros de consulta do Google Analytics, IDs de sessão de reprodução ou outros parâmetros exclusivos do cliente. Incluir mais parâmetros de consulta do que o necessário pode diminuir as taxas de ocorrência em cache.

Em vez de especificar quais parâmetros incluir na chave de cache, você pode escolher quais excluir. Por exemplo, para excluir o ID de reprodução específico do cliente e as informações de carimbo de data/hora da chave de cache, configure o seguinte:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 86400s
  cacheKeyPolicy:
    excludedQueryParameters: ["playback-id", "timestamp"]

Para uma determinada rota, é possível especificar includedQueryParameters ou excludedQueryParameters.

Se os parâmetros de consulta nunca forem usados para identificar conteúdo de maneira exclusiva em todas as solicitações, remova todos os parâmetros de consulta da chave de cache de uma rota. Para isso, defina excludeQueryString como true, da seguinte forma:

cdnPolicy:
  cacheMode: CACHE_ALL_STATIC
  defaultTtl: 3600s
  cacheKeyPolicy:
    excludeQueryString: true

Se as solicitações assinadas estiverem ativadas em uma rota, os parâmetros de consulta usados para assinatura não serão incluídos na string de consulta e serão ignorados se forem incluídos. Incluir os parâmetros assinados na chave de cache torna cada solicitação do usuário única e exige que cada solicitação seja servida da origem.

Classificação de parâmetros de consulta

Os parâmetros de consulta (strings de consulta) são classificados por padrão para melhorar as taxas de ocorrência em cache, porque os clientes podem reordenar ou solicitar o mesmo objeto em cache com uma ordem diferente de parâmetros de consulta.

Por exemplo, os parâmetros de consulta b=world&a=hello&z=zulu&p=paris e p=paris&a=hello&z=zulu&b=world são classificados como a=hello&b=world&p=paris&z=zulu antes da derivação da chave de cache. Isso permite que ambas as solicitações sejam mapeadas para o mesmo objeto em cache, evitando uma solicitação (e resposta) desnecessária da origem.

Se houver várias instâncias de uma chave de parâmetro de consulta, cada uma com valores distintos, os parâmetros serão classificados pelo valor completo. Por exemplo, a=hello é classificado antes de a=world. Não é possível desativar a classificação.

Incluir cabeçalhos

Os nomes de cabeçalho não diferenciam maiúsculas de minúsculas e são convertidos para letras minúsculas pela Media CDN.

Os cabeçalhos a seguir não podem ser incluídos na chave de cache:

• Qualquer cabeçalho que comece com access-control-
• Qualquer cabeçalho que comece com sec-fetch-
• accept-encoding
• accept
• authorization
• connection
• content-md5
• content-type
• cookie
• date
• forwarded
• from
• host
• if-match
• if-modified-since
• if-none-match
• origin
• proxy-authorization
• range
• referer
• referrer
• user-agent
• want-digest
• x-csrf-token
• x-csrftoken
• x-forwarded-for

Para incluir o método HTTP na chave de cache, use o nome de cabeçalho especial :method.

Incluir cookies

Os nomes de cookies diferenciam maiúsculas de minúsculas.

Cookies que começam com edge-cache- em qualquer variação de letras maiúsculas ou minúsculas não podem ser usados na chave de cache.

Revalidação, remoção e expiração

As redes de fornecimento de conteúdo, incluindo o Media CDN, funcionam armazenando em cache o conteúdo mais popular o mais próximo possível dos usuários.

O amplo armazenamento do Media CDN, bem como a proteção de origem, limitam a necessidade de remover até mesmo conteúdo impopular. O conteúdo que é acessado poucas vezes por dia pode ser removido.

• As respostas armazenadas em cache que atingem o TTL configurado podem não ser despejadas imediatamente. Para conteúdo popular, a Media CDN revalida se a resposta armazenada em cache é a versão mais recente emitindo uma solicitação HEAD à origem para confirmar que os cabeçalhos não foram alterados.
• As respostas que definem uma max-age ou uma s-maxage diretiva de cache ou que usam uma substituição de TTL para especificar um valor de TTL alto (por exemplo, 30 dias) podem não ser armazenadas em cache durante todo o TTL. Não há garantia de que um objeto será armazenado em cache durante todo o período, especialmente se ele for acessado com pouca frequência.

Se você estiver vendo uma alta taxa de remoções, verifique se configurou as chaves de cache para excluir parâmetros que não identificam de forma exclusiva uma resposta.

Outras considerações

As considerações a seguir também podem se aplicar ao cache.

Cabeçalhos Vary

O cabeçalho Vary indica que a resposta varia de acordo com os cabeçalhos de solicitação do cliente. Se um cabeçalho Vary estiver presente na resposta, a Media CDN não vai armazená-la em cache, a menos que o cabeçalho especifique uma das opções configuradas como uma configuração de chave de cache ou um dos seguintes valores:

• Accept:usado para indicar quais tipos de mídia o cliente aceita.
• Accept-Encoding:usado para indicar quais tipos de compactação o cliente aceita.
• Available-Dictionary:usado para fornecer o hash de um dicionário disponível para compactação.
• Origem/X-Origem:geralmente usado para compartilhamento de recursos entre origens.
• X-Goog-Allowed-Resources::oferece suporte à restrição da organização do Google Cloud
• Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site::usado para buscar cabeçalhos de solicitação de metadados.

A Media CDN armazena em cache respostas com um cabeçalho Vary na resposta usando o valor do cabeçalho como parte da chave de cache. Se o cabeçalho Vary na resposta tiver vários valores, eles serão classificados lexicograficamente para garantir que a chave de cache seja determinista.

O Media CDN armazena em cache até 100 variantes para uma determinada chave de cache e remove aleatoriamente as variantes do cache além desse limite. Ao invalidar explicitamente o cache de um determinado URL ou tag de cache, todas as variantes são invalidadas.

Ignorar o cache

É possível configurar o modo de cache BYPASS_CACHE em uma rota para ignorar intencionalmente o cache em solicitações correspondentes. Isso pode ser útil se você precisar ignorar o cache para uma pequena fração do tráfego não crítico ou depurar a conectividade de origem.

Para casos em que é necessário veicular respostas dinâmicas, como back-ends de API, recomendamos configurar um balanceador de carga de aplicativo externo.

Recomendamos limitar o uso desse recurso a cenários de depuração para evitar o carregamento não intencional da origem. O tráfego de saída ao ignorar o cache é cobrado de acordo com as taxas de saída da Internet.

Invalidação de cache

Consulte invalidação de cache.

Solicitações de intervalo de bytes

A Media CDN é compatível com solicitações de intervalo HTTP conforme definido na RFC 9110.

Além disso, o Media CDN usa solicitações de intervalo para buscar respostas maiores da origem. Isso permite que a Media CDN armazene em cache intervalos de bytes individuais e não exige que o objeto inteiro seja buscado de uma só vez para ser armazenado em cache.

• Objetos maiores que 1 MiB são buscados como solicitações de intervalo de bytes de até 2 MiB cada.
• Respostas de até 1 MiB podem ser buscadas sem suporte a intervalos de bytes na origem.
• Respostas maiores que 1 MiB não são veiculadas se intervalos de bytes não forem compatíveis com a origem.

O suporte de origem para solicitações de intervalo de bytes é determinado pelo seguinte:

• Um código de status HTTP 200 (OK) ou 206 (Conteúdo parcial).
• Um cabeçalho de resposta Content-Length ou Content-Range válido.
• Um validador de resposta (ETag ou Last-Modified).

As solicitações de preenchimento de origem individuais para cada intervalo de bytes são registradas como entradas de registro discretas e associadas à solicitação do cliente principal. É possível agrupar essas solicitações correspondendo ao valor de jsonPayload.cacheKeyFingerprint para cada uma delas.

Para mais detalhes sobre o que é registrado, consulte a documentação do Cloud Logging.

Solicitações de intervalo multipartes

A CDN para mídias é compatível com solicitações de intervalo de várias partes, que permitem aos usuários solicitar vários segmentos não contíguos de um arquivo em uma única solicitação HTTP, por exemplo, Range: bytes=0-499, 1000-1499.

Para maximizar o desempenho do cliente e o descarregamento da origem, a Media CDN pode fornecer os intervalos de bytes individuais solicitados do cache, consolidando-os em uma única resposta com um código de status HTTP 206 Partial Response para o cliente com o Content-Type definido como multipart/byteranges.

Para respostas armazenáveis em cache, quando um cliente solicita um intervalo de várias partes, a Media CDN otimiza o processo convertendo a solicitação em um conjunto de solicitações de intervalo de uma única parte. Cada solicitação tem 2 MB para cobrir todas as partes dos intervalos de bytes solicitados pelo cliente. Em seguida, a Media CDN usa as respostas para gerar uma única resposta multipart na borda. Essa abordagem permite o uso eficiente do cache, reduz buscas redundantes na origem e oferece suporte a casos de uso de alto volume, como downloads da app store e atualizações do SO.

Para conteúdo não armazenável em cache, a Media CDN encaminha a solicitação diretamente para a origem.

Solicitações de intervalo aberto

A Media CDN é compatível com solicitações Range "abertas" (por exemplo, uma solicitação com Range: bytes=0-) que mantêm uma solicitação aberta na origem até que a resposta seja fechada por ela (por exemplo, a origem grava todos os bytes no fio) ou expire.

Intervalos de bytes abertos são usados normalmente por clientes que solicitam segmentos de HLS de baixa latência da Apple: à medida que cada bloco CMAF é gravado no fio, a CDN pode armazenar em cache e entregar esse bloco aos clientes.

Em outros casos, como quando a interoperabilidade com DASH não é necessária, a playlist de mídia indica ao player quais bytes representam cada parte:

  #EXTINF:4.08,
  fs270.mp4
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=20000@0
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=23000@20000
  #EXT-X-PART:DURATION=1.02,URI="fs271.mp4",BYTERANGE=18000@43000
  #EXT-X-PRELOAD-HINT:TYPE=PART,URI="fs271.mp4",BYTERANGE-START=61000

É possível configurar por quanto tempo o Media CDN espera entre as leituras usando o valor de configuração EdgeCacheOrigin.timeouts.readTimeout. Normalmente, ele é configurado como um múltiplo (por exemplo, 2x) da duração desejada.

A seguir

• Confira o roteamento avançado.
• Entenda como se conectar a origens diferentes.
• Configure certificados TLS (SSL) para seu serviço.
• Configure solicitações assinadas para autenticar o acesso ao conteúdo.
• Para mais detalhes sobre como configurar recursos EdgeCacheService usando o Terraform, consulte a documentação do registro do Terraform.