Visão geral das origens

O Media CDN permite buscar conteúdo da sua infraestrutura de origem, seja 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 à infraestrutura, quando e como fazer failover, repetição e tempo limite e 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.
  • As origens podem ser alcançadas por HTTP/2, HTTPS e HTTP/1.1 não criptografado.
  • As novas 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 nas respostas HTTP 404 Not Found ou HTTP 429 Too Many Requests.
  • É possível acessar recursos particulares no Google Cloud ou localmente configurando um balanceador de carga de aplicativo externo como uma origem por trás do Media CDN.
  • O comportamento de redirecionamento é configurado por origem. É possível ativar o Media CDN para seguir redirecionamentos para 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 no formato bytes x-y/z (em que z é o tamanho do objeto).

O protocolo de origem padrão é HTTP/2. Se as origens só oferecem suporte a HTTP/1.1, defina o campo de protocolo explicitamente para cada origem.

Proteção de origem

O 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. Os caches de borda profunda, que atendem a maioria do tráfego e descarregam 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 fan-in significativo, têm capacidade de armazenamento de cache substancial e funcionam como um escudo de origem.

Confira uma visão geral dessa topologia:

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

Todas as camadas de cache oferecem suporte ao recolhimento de solicitações (ou coalescência) para reduzir ainda mais a carga de origem. Com base em cargas de trabalho reais observadas em escala:

  • > 95% do preenchimento de cache usa um nó de cache de cauda longa dedicado na região para reduzir os custos e a latência do preenchimento de cache.
  • O preenchimento de cache entre a origem e a infraestrutura de borda do Google é feito totalmente na rede de backbone particular global do Google, o que reduz a latência de preenchimento de cache e melhora a confiabilidade. Ambos são benefícios ativos para cargas de trabalho de streaming ao vivo.
  • Os caches são preenchidos entre si quando é vantajoso, reduzindo ainda mais as taxas de preenchimento do cache.
  • O Media CDN tem capacidade de armazenamento significativa em caches, o que minimiza as taxas de expulsão, mesmo para conteúdo de cauda longa e menos popular.

Os clientes podem ter taxas de transferência diferentes, dependendo da configuração do cache, da carga de usuários, das cargas de trabalho (como ao vivo e sob demanda), da distribuição de usuários e da quantidade de conteúdo de cauda longa (tamanho total do corpus) que eles veiculam para os usuários em diferentes regiões.

Recolhimento de solicitações

O recolhimento de solicitações agrupa 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.

Combinado com a proteção de origem, isso reduz ainda mais as necessidades de largura de banda de saída e de origem, além de ser o comportamento padrão do Media CDN.

As solicitações recolhidas têm a solicitação voltada para o cliente e a solicitação de preenchimento do cache (recolhida) registradas. 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 o Media CDN se conecta às origens, como as solicitações HTTP são feitas e como autenticar solicitações.

Origem e protocolos compatíveis

O Media CDN oferece suporte direto a qualquer endpoint HTTP acessível publicamente 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 AWS Signature versão 4.
  • 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 às origens é feita por túneis seguros e pela rede backbone global do Google.

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

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

O Media CDN usa o HTTP/2 (h2) para se conectar a uma origem por padrão. 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 está expirado, assinado por uma autoridade de certificação pública e tem um nome alternativo do assunto que corresponde ao nome de host enviado à origem.

Observações:

  • Se a origem não oferecer suporte a HTTP/2, defina explicitamente o protocolo (por origem) como HTTP (HTTP/1.1) ou HTTPS (HTTP/1.1 sobre TLS).
  • Ao configurar HTTPS ou HTTP/1.1 como o protocolo de origem, o Media CDN não negocia um protocolo alternativo (como HTTP/2). Da mesma forma, ao configurar o HTTP/2, a conexão não recorre ao HTTP/1.1 para explicitar o comportamento de conectividade de origem.
  • A CDN de mídia 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, o 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 de 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 origens de failover vão acessar o mesmo cabeçalho de host se compartilhadas com 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 de cabeçalho de host alternativos não têm suporte a buckets do Cloud Storage. O cabeçalho do host é definido automaticamente com base no nome do bucket.

O valor de SNI (indicação do nome do servidor) do 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 a configuração por rota, consulte Configurar rotas de serviço. Para saber como definir ações de substituição por origem, consulte Failover de origem sem 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 espera para se conectar à origem ou para responder a uma solicitação.
  • Novas tentativas: determina se o Media CDN tenta novamente uma solicitação HTTP de origem e em quais condições.
  • Failover: determina se o 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.

Tempo limite da origem

Os tempos limite permitem configurar quando os comportamentos de repetição e failover da origem são acionados e quando o failover do cliente subsequente pode ser acionado.

Confira a seguir os tempos limite configuráveis com suporte do Media CDN:

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

    Ambos os tempos limite incluem o tempo que a origem leva para retornar cabeçalhos e determinar se é necessário usar um failover ou redirecionamento. O connectTimeout é aplicado de forma independente para cada tentativa de origem, enquanto o 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 conexão à origem e conta para o conjunto maxAttempts da origem configurada.

    Quando o Media CDN encontra uma resposta que não é de redirecionamento, como de uma origem de redirecionamento ou de 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 por quanto tempo uma resposta transmitida por streaming pode levar. Depois que o Media CDN determina que vai usar uma resposta upstream, nem connectTimeout nem maxAttemptsTimeout importam. Nesse ponto, readTimeout e responseTimeout entram em vigor.

O Media CDN 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

Tempo máximo que o Media CDN pode levar desde o início da solicitação à origem até determinar se a resposta é utilizável. Na prática, connectTimeout abrange o tempo desde a criação da solicitação, passando pelas 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 é 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 da origem, incluindo origens de failover, para limitar o tempo total que os clientes precisam esperar para que o conteúdo comece a ser transmitido. Somente o primeiro valor de 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 que a resposta seja concluída, ela será truncada e registrada.
responseTimeout 30 segundos

A duração máxima 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 que a resposta seja concluída, 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 falhar em 1 segundo devido a um certificado TLS inválido, você terá cerca de 4 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 connectTimeout está no padrão 5s. A CDN de mídia tenta se conectar a Origin C até três vezes, permitindo até 10 segundos (o limite de maxAttemptsTimeout) para fazer uma conexão.

Tentar novamente as solicitações de origem

A Media CDN oferece suporte a novas tentativas de origem, permitindo que as solicitações para a origem sejam repetidas. É possível especificar quantas vezes a origem atual pode ser repetida antes que uma origem de failover (se configurada) seja tentada.

  • O Media CDN tenta alcançar a origem principal até o valor maxAttempts configurado, que é padrão 1.
  • A CDN de mídia tenta novamente as conexões de origem até três vezes antes de falhar e retornar um erro HTTP 502 Bad Gateway ao usuário. Isso inclui todas as 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 Tente novamente 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 tentados novamente, incluindo 409 e 429.
NOT_FOUND Tente novamente em um código de status HTTP 404.
FORBIDDEN Tente novamente em um código de status HTTP 403.

Se você precisar de verificação de integridade ativa, round-robin ou direcionamento sensível à carga em várias origens, poderá configurar 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 à origem e não recebe nenhuma resposta HTTP após duas tentativas (padrão). Não HTTP 502 Bad Gateway
O Media CDN tenta se conectar à origem principal, mas não consegue (erro de handshake TLS). Uma tentativa é feita contra a origem de failover configurada, que retorna um erro HTTP 404. Sim HTTP 404 Not Found
O 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 o 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 solicitações de origem de nova tentativa e failover 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 dos cabeçalhos Vary, ETag e Last-Modified são consistentes entre as origens.

Como prática recomendada, configure o redirecionamento de origem apenas para origens em que você confia e controla. Confie em todas as origens em uma cadeia de redirecionamento, porque cada origem produz conteúdo que é veiculado pelo EdgeCacheService.

A seguir