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. 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.
  • As tentativas e os comportamentos de 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.
  • É 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 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.

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 descarregam dentro de 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 importantes. 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 ausências no cache quando o local padrão do escudo está geograficamente distante da origem centralizada
  • Redução do descarregamento de origem ao dispersar solicitações de preenchimento de cache em vários locais de proteção padrão global, em vez de concentrá-las

O shielding flexível ajuda você a superar essas limitações configurando uma região geográfica única e específica para o shielding de origem, normalmente 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 blindagem flexível é compatível com qualquer tipo de origem configurado 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 oferecem suporte ao recolhimento de solicitações (ou fusão) 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 global privada do Google, o que reduz a latência de preenchimento de cache e melhora a confiabilidade. Esses dois fatores são benefícios ativos para cargas de trabalho de transmissão ao vivo.
  • Os caches fazem preenchimento cruzado entre si quando é vantajoso, reduzindo ainda mais as taxas de preenchimento do cache.
  • O Media CDN 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 Com suporte 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, você poderá definir 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 seguir redirecionamento.

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 o 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 que não é de 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. Neste momento, readTimeout e responseTimeout entram em vigor.

A CDN de mídia faz no máximo quatro tentativas de origem em todas as origens, independente do maxAttempts definido por cada EdgeCacheOrigin. O Media CDN usa o valor maxAttemptsTimeout do EdgeCacheOrigin principal. Os valores de tempo limite por tentativa (connectTimeout, readTimeout e responseTimeout) são configurados para o EdgeCacheOrigin de cada tentativa.

A tabela a seguir descreve os campos de tempo limite:

Campo Padrão Descrição
connectTimeout 5 segundos

O tempo máximo que a Media CDN pode levar desde o início da solicitação até a origem até que ela determine se a resposta é utilizável. Na prática, connectTimeout cobre o tempo desde a criação da solicitação, passando por buscas DNS, handshakes de TLS, estabelecimento de conexão TCP/QUIC até a obtenção dos cabeçalhos de resposta que contêm o código de status HTTP.

O tempo limite precisa ser um valor entre 1 e 15 segundos.
maxAttemptsTimeout 15 segundos

O tempo máximo em todas as tentativas de conexão com a origem, incluindo origens de failover, antes de retornar um erro ao cliente. Um HTTP 504 será retornado se o tempo limite for atingido antes que uma resposta seja retornada.

O tempo limite precisa ser um valor entre 1 e 30 segundos.

Essa configuração define a duração total de todas as tentativas de conexão com a origem, incluindo origens de failover, para limitar o tempo total que os clientes precisam esperar para que o conteúdo comece a ser transmitido. Apenas o primeiro valor maxAttemptsTimeout é usado, em que o primeiro é definido pela origem configurada para a rota.
readTimeout 15 segundos

A duração máxima de espera entre as leituras de uma única resposta HTTP. O readTimeout é limitado pelo responseTimeout. Todas as leituras da resposta HTTP precisam ser concluídas até o prazo definido pelo responseTimeout. O tempo limite precisa ser um valor entre 1 e 30 segundos. Se esse tempo limite for atingido antes da conclusão da resposta, ela será truncada e registrada.
responseTimeout 30 segundos

A duração máxima permitida para a conclusão de uma resposta.

O tempo limite precisa ser um valor entre 1 e 120 segundos.

A duração é medida a partir do momento em que os primeiros bytes do corpo são recebidos. Se esse tempo limite for atingido antes da conclusão da resposta, ela será truncada e registrada.

Veja estes exemplos:

  • Origin A corresponde a solicitações para "/segments/" e tem um valor maxAttemptsTimeout de 5s, um valor maxAttempts de 1 e um valor failover_origin de Origin B. O valor connectTimeout está no padrão 5s. Se você tentar se conectar a Origin A e a conexão falhar em um segundo devido a um certificado TLS inválido, você terá cerca de quatro segundos para fazer uma conexão bem-sucedida com Origin B.

  • Origin C corresponde a solicitações para "/manifests/*", tem um valor maxAttemptsTimeout de 10s, um valor maxAttempts de 3 e failover_origin não configurado. O valor de connectTimeout está no padrão 5s. A Media CDN tenta se conectar a Origin C até três vezes, permitindo até 10 segundos (o limite de maxAttemptsTimeout) para fazer uma conexão bem-sucedida.

Tentar novamente solicitações de origem

A Media CDN é compatível com novas tentativas de origem, permitindo que solicitações sem êxito para a origem sejam repetidas. Você pode especificar quantas vezes a origem atual pode ser repetida antes de uma origem de failover (se configurada) ser tentada.

  • O Media CDN tenta alcançar a origem principal até o valor maxAttempts configurado, que é 1 por padrão.
  • A Media CDN tenta novamente as conexões de origem até um máximo de três vezes antes de falhar e retornar um erro HTTP 502 Bad Gateway ao usuário. Isso inclui conexões de origem de failover, que contam para o limite de três.
  • Ao configurar um recurso de origem, é possível configurar uma origem principal usando o campo originAddress e, em seguida, um failoverOrigin opcional. O failoverOrigin aponta para outro recurso de origem.

O retryConditions de cada origem especifica quais tipos de falhas acionam uma nova tentativa:

Condição Padrão Descrição
CONNECT_FAILURE ✔️ A tentativa em caso de falhas inclui roteamento, erros de handshake de DNS e TLS, e tempos limite TCP/UDP.
HTTP_5XX Repetir em qualquer código de status HTTP 5xx.
GATEWAY_ERROR Semelhante a 5xx, mas se aplica apenas aos códigos de status 502, 503 ou 504.
RETRIABLE_4XX Tente novamente para códigos de status 4xx que podem ser repetidos, incluindo 409 e 429.
NOT_FOUND Tentar novamente em um código de status HTTP 404.
FORBIDDEN Tentar novamente em um código de status HTTP 403.

Se você precisar de verificação de integridade ativa, round-robin ou direcionamento com reconhecimento de carga em várias origens, configure um balanceador de carga de aplicativo externo como a origem principal.

Comportamento de failover

A tabela a seguir descreve como o failover funciona e qual resposta um cliente observaria:

Cenário Failover configurado Status voltado ao usuário
O Media CDN tenta se conectar à sua origem e não recebe uma resposta HTTP após duas tentativas (padrão). Não HTTP 502 Bad Gateway
O Media CDN tenta se conectar à sua origem principal e não consegue (erro de handshake de TLS). Uma tentativa é feita na origem de failover configurada, que retorna um erro HTTP 404. Sim HTTP 404 Not Found
A Media CDN tenta se conectar à origem principal e de failover, mas não recebe um código de status HTTP. Sim HTTP 502 Bad Gateway

Se a Media CDN receber um código de status correspondente a qualquer retryConditions configurado, como um erro HTTP 404 Not Found ou HTTP 429 Too Many Requests, e as novas tentativas e solicitações de failover de origem subsequentes continuarem falhando, um erro HTTP 502 Bad Gateway será retornado ao cliente depois que as tentativas de origem forem esgotadas.

Práticas recomendadas para failover de origem

Ao configurar várias origens para failover ou balanceamento de carga, verifique se o conteúdo de mídia e os comportamentos de cabeçalho Vary, ETag e Last-Modified são consistentes entre as origens.

Como prática recomendada, configure o redirecionamento de origem apenas para origens confiáveis e controladas. Confie em todas as origens em uma cadeia de redirecionamento, porque cada uma delas produz conteúdo veiculado pelo seu EdgeCacheService.

A seguir