Visão geral das origens

Com a Media CDN, é possível buscar conteúdo da sua infraestrutura de origem, seja ele hospedado no Google Cloud, em outra nuvem ou no local.

Cada configuração pode ter uma ou mais origens associadas a ela. As configurações de origem informam ao Media CDN como se conectar à sua infraestrutura, quando e como fazer failover, novas tentativas e tempo limite, além de qual protocolo usar ao se conectar.

As origens têm os seguintes recursos:

  • As origens podem ser definidas por host e por rota, o que permite que um único recurso EdgeCacheService seja mapeado para várias origens que contêm, por exemplo, manifestos, segmentos de vídeo e outros conteúdos estáticos.
  • É possível acessar origens por HTTP/2, HTTPS e HTTP/1.1 não criptografado.
  • É possível configurar regras de firewall para permitir apenas endereços IP específicos do Google. Assim, somente a Media CDN poderá acessar suas origens.
  • Os comportamentos de novas tentativas e failover são configurados por origem e podem permitir que o serviço faça failover em erros graves (como falha de conectividade) ou tente novamente com base em respostas HTTP 404 Not Found ou HTTP 429 Too Many Requests. Essas operações são realizadas apenas para os métodos HTTP mais seguros, incluindo GET, HEAD e OPTIONS. Para mais informações sobre métodos HTTP seguros, consulte a RFC 9110.
  • É possível acessar recursos particulares dentro do Google Cloud ou no local configurando um balanceador de carga de aplicativo externo como uma origem por trás da Media CDN.
  • O comportamento de acompanhamento de redirecionamento é configurado por origem. Você pode ativar a Media CDN para seguir redirecionamentos a outros servidores de origem.

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 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.

Proteção de origem

A Media CDN oferece uma infraestrutura de borda em camadas projetada para minimizar ativamente o preenchimento de cache sempre que possível.

Há três camadas principais de infraestrutura de cache:

  1. Caches de borda avançados, que atendem à maioria do tráfego e fazem o descarregamento em uma rede de provedores de serviços.
  2. A borda de peering do Google, que está conectada a milhares de ISPs e atua como o cache de nível intermediário para caches de borda e, nos casos em que eles não estão presentes em um determinado ISP, o cache voltado ao usuário.
  3. Caches de cauda longa na rede do Google que outros caches downstream preenchem antes da origem. Esses caches oferecem suporte a um fan-in significativo, têm uma capacidade substancial de armazenamento em cache e atuam como um shield de origem.

Confira uma visão geral dessa topologia:

Visão geral da topologia.
Visão geral da topologia (clique para ampliar).

Por padrão, o Media CDN oferece proteção de origem usando um conjunto limitado de locais globais e chaves. O shielding de origem padrão opera com base no local do usuário final, não da origem. Isso funciona bem e oferece benefícios de descarregamento significativos quando os usuários finais e os servidores de origem estão na mesma região e quando os servidores de origem globais estão localizados em várias regiões.

Proteção flexível

Em cenários em que sua origem está centralizada em uma região, mas seus usuários estão distribuídos globalmente, o comportamento padrão de proteção de origem, que se baseia na localização do usuário, pode ser inadequado das seguintes maneiras:

  • Aumentar a latência para erros de cache quando a localização padrão do escudo é geograficamente distante da origem centralizada
  • Redução do descarregamento da origem ao dispersar as solicitações de preenchimento de cache em vários locais de proteção padrão globais em vez de concentrá-las

A proteção flexível ajuda você a superar essas limitações configurando uma região geográfica única e específica para a proteção de origem, geralmente selecionada para ficar perto da sua origem centralizada. O shielding flexível então encaminha todas as solicitações de preenchimento de cache por caches de proteção localizados na região configurada ou perto dela. Isso consolida a carga na origem por meio desses caches regionais.

Ao configurar uma região de proteção flexível na mesma região geográfica da sua origem centralizada, é possível otimizar o seguinte:

  • Taxa de ocorrência em cache na camada de proteção
  • Descarregamento de origem
  • Latência para ausências no cache e conteúdo não armazenável em cache
  • Estabilidade de desempenho

A proteção flexível é compatível com qualquer tipo de origem configurada no Media CDN.

Recolhimento de solicitações

O recolhimento de solicitações recolhe ativamente várias solicitações de preenchimento de cache orientadas pelo usuário para a mesma chave de cache em uma única solicitação de origem por nó de borda.

Todas as camadas de cache são compatíveis com o recolhimento (ou agrupamento) de solicitações para reduzir ainda mais a carga de origem. Com base em cargas de trabalho observadas e reais em grande escala:

  • > 95% do preenchimento de cache usa um nó de cache dedicado de cauda longa na região para reduzir os custos e a latência.
  • O preenchimento de cache entre a origem e a infraestrutura de borda do Google é feito inteiramente pela rede de backbone privada global do Google, o que reduz a latência de preenchimento de cache e melhora a confiabilidade. Esses são benefícios ativos para cargas de trabalho de transmissão ao vivo.
  • Os caches fazem preenchimento cruzado entre si quando isso é vantajoso, reduzindo ainda mais as taxas de preenchimento do cache.
  • A CDN de mídia tem uma capacidade de armazenamento significativa em todos os caches, o que minimiza as taxas de remoção, mesmo para conteúdo de cauda longa e menos popular.

Os clientes podem ver taxas de descarregamento diferentes dependendo da configuração do cache, da carga de usuários, das cargas de trabalho (como ao vivo x sob demanda), da distribuição de usuários e da quantidade de conteúdo de cauda longa (tamanho total do corpus) que eles oferecem aos usuários em todas as regiões.

Combinado com a proteção de origem, o recolhimento de solicitações reduz ainda mais a carga de origem e as necessidades de largura de banda de saída, sendo o comportamento padrão da Media CDN.

As solicitações recolhidas registram a solicitação voltada para o cliente e a solicitação de preenchimento do cache (recolhida). O líder da sessão recolhida é usado para fazer a solicitação de preenchimento de origem, o que significa que a origem vê os cabeçalhos (incluindo o User-Agent) apenas desse cliente.

Não é possível recolher as solicitações que não compartilham a mesma chave de cache.

Conectividade de origem

As seções a seguir descrevem como a Media CDN se conecta às origens, como as solicitações HTTP são feitas e como você pode autenticar solicitações.

Origens e protocolos compatíveis

O Media CDN oferece suporte direto a qualquer endpoint HTTP de acesso público como uma origem, incluindo:

  • Buckets do Cloud Storage, incluindo buckets particulares por meio de contas de serviço do Identity and Access Management
  • Balanceadores de carga de aplicativo externos
  • Buckets compatíveis com o Amazon S3, incluindo buckets particulares que usam a versão 4 da assinatura da AWS
  • Outro armazenamento de objetos disponível publicamente, como o Armazenamento de Blobs do Azure
  • Servidores da Web disponíveis publicamente, como VMs públicas ou hosts locais

A conectividade com as origens é feita por túneis seguros e pela rede global de backbone do Google.

A tabela a seguir detalha os protocolos de origem compatíveis.

Protocolo Sim SSL (TLS) obrigatório
HTTP/2 Sim (padrão) Sim
HTTPS (HTTP/1.1 sobre TLS) Sim Sim
HTTP/1.1 Sim Não

Por padrão, o Media CDN usa HTTP/2 (h2) para se conectar a uma origem. O HTTP/2 e o HTTPS exigem um certificado TLS (SSL) válido e confiável publicamente. Um certificado válido é aquele que não expirou, foi assinado por uma autoridade de certificação pública e tem um nome alternativo do assunto que corresponde ao nome do host enviado à origem.

Observações:

  • Se a origem não for compatível com HTTP/2, defina explicitamente o protocolo (por origem) como HTTP (HTTP/1.1) ou HTTPS (HTTP/1.1 por TLS).
  • Ao configurar HTTPS ou HTTP/1.1 como o protocolo de origem, a Media CDN não negocia um protocolo alternativo, como HTTP/2. Da mesma forma, ao configurar o HTTP/2, a conexão não reverte para HTTP/1.1, para ser explícita sobre o comportamento da conectividade de origem.
  • A Media CDN usa automaticamente a porta correta com base no protocolo: porta 80 para HTTP ou porta 443 para HTTPS e HTTP/2.

Cabeçalhos de solicitação de origem

Ao se conectar a uma origem, a Media CDN usa o cabeçalho Host da solicitação do cliente por padrão.

A tabela a seguir documenta o que a origem vê na solicitação recebida em diferentes cenários de configuração:

Solicitação do cliente EdgeCacheService.hostRewrite EdgeCacheOrigin.hostRewrite originAddress Cabeçalho Host /
SNI TLS na origem
media.example.com Nenhum Nenhum backend.example.com media.example.com
media.example.com service.example.com Nenhum backend.example.com service.example.com
media.example.com Nenhum origin.example.com backend.example.com origin.example.com
media.example.com service.example.com origin.example.com backend.example.com origin.example.com
media.example.com service.example.com origin.example.com gs://vod-content-bucket definido automaticamente com base no nome do bucket

A origem principal e as de failover veem o mesmo cabeçalho de host se compartilharem a mesma configuração routeRule ou hostRewrite.

Todas as configurações de hostRewrite são ignoradas ao usar um bucket do Cloud Storage como origem, porque os valores alternativos de cabeçalho do host não são compatíveis com buckets do Cloud Storage. O cabeçalho do host é definido automaticamente com base no nome do bucket.

O valor do SNI (indicação do nome do servidor) de TLS na solicitação (para solicitações HTTP/3, HTTP/2 e HTTPS) é definido como o mesmo valor do cabeçalho do host enviado à origem.

Para informações sobre como reescrever cabeçalhos de host para configuração por rota, consulte Configurar rotas de serviço. Para informações sobre como definir ações de substituição por origem, consulte Failover de origem sem redirecionamento seguido.

Permitir que a origem receba tráfego da Media CDN

Para reduzir o risco de acesso não autorizado ao seu conteúdo, use uma lista de permissões de IP na origem para bloquear o acesso a todos os endereços IP, exceto os intervalos específicos que o Google usa para enviar solicitações a origens externas. Assim, apenas o Media CDN pode se conectar aos seus servidores de origem.

A tabela a seguir resume os intervalos de endereços IP de origem obrigatórios para regras de firewall:

Tipo de endereço IP Solicitar intervalo de IP de origem
IPv4 136.124.4.0/22
IPv6 2001:4860:4864:a::/64

Use o seguinte URL para acessar o arquivo JSON que contém os intervalos de endereços IP atualizados atribuídos pelo Google.

https://www.gstatic.com/ipranges/mediacdn.json

Failover e tempos limite

As seções a seguir descrevem essas opções de configuração:

  • Tempos limite: determine quanto tempo o Media CDN aguarda para se conectar à sua origem ou para responder a uma solicitação.
  • Tentativas: determine se o Media CDN tenta novamente uma solicitação HTTP de origem para sua origem e em quais condições.
  • Failover: determine se a Media CDN tenta se conectar a uma origem de failover se a primeira estiver indisponível ou retornar um código de status específico.

Tempos limite de origem

Com os tempos limite, é possível configurar quando os comportamentos de nova tentativa e failover de origem são acionados e quando o failover subsequente do cliente pode ser acionado.

A seguir, descrevemos os tempos limite configuráveis compatíveis com a Media CDN:

  • connectTimeout e maxAttemptsTimeout limitam o tempo que a Media CDN leva para encontrar uma resposta utilizável.

    Os dois tempos limite incluem o tempo que a origem leva para retornar cabeçalhos e determinar se é necessário usar um failover ou redirecionamento. connectTimeout é aplicado de forma independente para cada tentativa de origem, enquanto maxAttemptsTimeout inclui o tempo necessário para se conectar em todas as tentativas de origem, incluindo failovers e redirecionamentos. Seguir um redirecionamento conta como uma tentativa adicional de se conectar à origem e contribui para o maxAttempts definido para a origem configurada.

    Quando a Media CDN encontra uma resposta sem redirecionamento, como de uma origem de redirecionamento ou failover, os valores readTimeout e responseTimeout são aplicados. As origens redirecionadas usam os valores connectTimeout, readTimeout e responseTimeout configurados para o EdgeCacheOrigin que encontrou o redirecionamento.

  • responseTimeout e readTimeout controlam quanto tempo uma resposta transmitida pode levar. Depois que a Media CDN determina que vai usar uma resposta de upstream, nem connectTimeout nem maxAttemptsTimeout importam. Nesse momento,