Visão geral das origens

O Media CDN permite buscar conteúdo da sua infraestrutura de origem, esteja o conteúdo 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 à infraestrutura, quando e como fazer o failover, a repetição e o tempo limite, além do protocolo a ser usado 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 outro conteúdo estático.
• As origens podem ser acessadas 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 faça novas tentativas com base em respostas HTTP 404 Not Found ou HTTP 429 Too Many Requests.
• É possível acessar recursos privados dentro do Google Cloud ou no local 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 os 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 das 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. Caso suas origens aceitem apenas HTTP/1.1, defina o campo de protocolo explicitamente para cada origem.

Observação: respostas pequenas (menos de 1 MiB) que não têm o conjunto completo de cabeçalhos listados anteriormente podem ser removidas do cache mais rapidamente do que respostas maiores.

Proteção de origem

O Media CDN fornece uma infraestrutura de borda profundamente em camadas, projetada para minimizar ativamente o preenchimento do cache sempre que possível.

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

1. Caches de borda profunda, que disponibilizam a maior parte do tráfego e descarga dentro de uma rede de provedores de serviços.
2. A borda de peering do Google, que é conectada a milhares de ISPs e atua como o cache de nível intermediário para caches de borda e, para 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 são preenchidos antes da origem. Esses caches aceitam fan-in significativa, têm capacidade substancial de armazenamento em cache e atuam como uma proteção de origem.

Confira uma visão geral dessa topologia:

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

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

• Mais de 95% do preenchimento de cache usa um nó de cache de cauda longa dedicado na região, a fim de reduzir os custos e a latência do preenchimento de cache.
• O preenchimento do cache entre a origem e a própria infraestrutura de borda do Google é inteiramente por meio da rede de backbone privada global do Google, o que reduz a latência de preenchimento do cache e melhora a confiabilidade. Ambos são benefícios ativos para cargas de trabalho de transmissão ao vivo.
• Os caches são preenchidos de forma cruzada uns com os outros quando vantajoso para isso, reduzindo ainda mais as taxas de preenchimento do cache.
• O Media CDN tem uma capacidade de armazenamento significativa em caches, o que minimiza as taxas de remoção mesmo para conteúdos de cauda longa e menos populares.

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

Recolhimento da solicitação

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.

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

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

As solicitações que não compartilham a mesma chave de cache não podem ser recolhidas.

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 você pode autenticar solicitações.

Origens e protocolos compatíveis

O Media CDN é compatível diretamente com qualquer endpoint HTTP acessível publicamente como uma origem, incluindo o seguinte:

• 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 o AWS Signature versão 4
• Outro armazenamento de objetos publicamente disponível, 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 ocorre por meio de túneis seguros e da rede de 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	No

O Media CDN usa 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 publicamente confiável. Um certificado válido é aquele que não está expirado, é assinado por uma autoridade de certificação pública e tem um nome alternativo da entidade correspondente ao nome do host enviado à origem.

Observações:

• Se a origem não oferecer suporte a HTTP/2, será possível definir 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 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 retorna para HTTP/1.1, para ser explícito sobre o comportamento da conectividade de origem.
• O 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, 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 do host / SNI de TLS na origem
media.example.com	Nenhuma	Nenhuma	backend.example.com	media.example.com
media.example.com	service.example.com	Nenhuma	backend.example.com	service.example.com
media.example.com	Nenhuma	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	são definidos automaticamente com base no nome do bucket

A origem primária e todas as origens de failover verão o mesmo cabeçalho de host se compartilharem a mesma configuração de 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 os buckets do Cloud Storage. O cabeçalho do host é definido automaticamente com base no nome do bucket.

O valor da indicação de nome do servidor (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 seguinte.

Failover e tempos limite

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

• Tempos limite: determine quanto tempo o Media CDN espera para se conectar à origem ou responder a uma solicitação.
• Novas tentativas: determine se o Media CDN tenta fazer uma nova solicitação HTTP de origem para sua origem e em quais condições.
• Failover: determina se o Media CDN tenta se conectar a uma origem de failover caso a primeira não esteja disponível ou retorna um código de status específico.

Observação: tentativas de repetição ou failover são feitas apenas para solicitações GET, HEAD e OPTIONS.

Tempos limite de origem

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

Veja a seguir a descrição dos tempos limite configuráveis que o Media CDN oferece suporte:

• connectTimeout e maxAttemptsTimeout limitam o tempo que o 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 se aplica independentemente 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. Um redirecionamento conta como uma tentativa extra de conexão com a origem e conta para o maxAttempts definido para a origem configurada.

  Quando o 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 o Media CDN determina que ele usará uma resposta upstream, connectTimeout ou maxAttemptsTimeout não importam. 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	O tempo máximo que o Media CDN pode levar para iniciar a solicitação até a origem até que o Media CDN determine se a resposta é utilizável. Na prática, connectTimeout abrange o tempo que começa com a criação da solicitação, passa pelas buscas DNS e depois realiza os handshakes de TLS, o estabelecimento de conexões TCP/QUIC e a coleta 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 de origem, incluindo origens de failover, para limitar o tempo total que os clientes precisam esperar pelo conteúdo para iniciar o streaming. Somente o primeiro valor maxAttemptsTimeout é usado, em que o primeiro é definido pela origem configurada para a rota especificada.
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 por 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, a resposta será truncada e registrada.
responseTimeout	30 segundos	A duração máxima para permitir 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, a resposta será truncada e registrada.

Confira 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 de 5s. Se você tentar se conectar a Origin A e ela 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 connectTimeout está no padrão de 5s. O 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.

Repetir solicitações de origem

O Media CDN oferece suporte a novas tentativas de origem, permitindo que solicitações malsucedidas à origem sejam repetidas. Especifique quantas vezes a origem atual pode ser repetida antes de ocorrer uma tentativa de uma origem de failover (se configurada).

• O Media CDN tenta alcançar a origem principal até o valor maxAttempts configurado, que tem como padrão 1.
• O Media CDN tenta conectar 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 todas as conexões de origem de failover, que são contabilizadas no limite de três.
• Ao configurar um recurso de origem, defina uma origem primária 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 falha 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 de TCP/UDP.
HTTP_5XX		Tente novamente em qualquer código de status HTTP 5xx.
GATEWAY_ERROR		Semelhante a 5xx, mas se aplica somente aos códigos de status 502, 503 ou 504.
RETRIABLE_4XX		Tente de novo para os códigos de status 4xx que podem ser repetidos, 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 com reconhecimento de carga entre origens, configure um balanceador de carga de aplicativo externo como a origem principal.

Comportamento de failover

Na tabela a seguir, descrevemos como o failover funciona e qual resposta um cliente observaria:

Cenário	Failover configurado	Status voltado para o usuário
O Media CDN tenta se conectar à sua origem e não recebe resposta HTTP após duas tentativas (padrão).	No	HTTP 502 Bad Gateway
O Media CDN tenta se conectar à sua origem primária, mas não consegue (erro de handshake de TLS). É feita uma tentativa na 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 o 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 subsequentes de novas tentativas e origem de failover continuarem falhando, um erro HTTP 502 Bad Gateway será retornado ao cliente depois que as tentativas de origem terminarem.

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.

Aviso: a configuração de redirecionamentos de um serviço de origem não confiável ou controlado por um invasor pode expor sua configuração do Media CDN a vulnerabilidades de redirecionamento aberto.

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

A seguir

• Configurar uma origem
• Usar um bucket particular compatível com o Amazon S3 como origem
• Configurar rotas de serviço