Vista geral das origens

A RFC de multimédia permite-lhe obter conteúdo da sua infraestrutura de origem, quer o conteúdo esteja alojado no Google Cloud, noutra nuvem ou no local.

Cada configuração pode ter uma ou mais origens associadas. As configurações de origem indicam ao CDN de multimédia como estabelecer ligação à sua infraestrutura, quando e como fazer failover, repetir e esgotar o tempo limite, e que protocolo usar ao estabelecer ligação.

As origens têm as seguintes funcionalidades:

• As origens podem ser definidas por anfitrião e por trajeto, o que permite que um único recurso EdgeCacheService seja mapeado para várias origens que contenham, por exemplo, manifestos, segmentos de vídeo e outro conteúdo estático.
• É possível aceder às origens através de HTTP/2, HTTPS e HTTP/1.1 não encriptado.
• Pode configurar regras de firewall para permitir apenas endereços IP da Google específicos, para que apenas a RFC de multimédia possa aceder às suas origens.
• Os comportamentos de repetição e de comutação por falha são configurados por origem e podem permitir que o serviço comute por falha em erros graves (como falha de conetividade) ou repita com base nas respostas HTTP 404 Not Found ou HTTP 429 Too Many Requests.
• Pode aceder a recursos privados no local ou no interior configurando um Application Load Balancer externo como uma origem atrás da RFC de conteúdo multimédia. Google Cloud
• O comportamento de seguimento de redirecionamentos é configurado por origem. Pode ativar o Media CDN para seguir redirecionamentos para outros servidores de origem.

Requisitos de origem

Para permitir que a RFC de multimédia na nuvem armazene em cache respostas de origem superiores a 1 MiB, uma origem tem de incluir o seguinte nos cabeçalhos das respostas para pedidos HEAD e GET, salvo especificação em contrário:

• 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 da resposta Content-Range, em resposta a um pedido Range GET. O cabeçalho Content-Range tem de ter um valor válido no formato bytes x-y/z (em que z é o tamanho do objeto).

O protocolo de origem predefinido é HTTP/2. Se as suas origens apenas suportarem HTTP/1.1, pode definir o campo de protocolo explicitamente para cada origem.

Nota: as respostas pequenas (inferiores a 1 MiB) que não tenham o conjunto completo de cabeçalhos indicados anteriormente podem ser removidas da cache mais rapidamente do que as respostas maiores.

Proteção de origem

A RFC de multimédia oferece uma infraestrutura de limite profundamente hierarquizada concebida para minimizar ativamente o preenchimento da cache sempre que possível.

Existem três camadas principais de infraestrutura de colocação em cache:

1. Caches de limite profundos, que servem a maioria do tráfego e descarregam na rede de um fornecedor de serviços.
2. O limite de intercâmbio da Google, que está ligado a milhares de ISPs e funciona como a cache de nível intermédio para caches de limite e, nos casos em que não estão presentes num determinado ISP, a cache virada para o utilizador.
3. Caches de cauda longa na rede da Google que outros caches a jusante preenchem antes da origem. Estas caches suportam um volume significativo de pedidos, têm uma capacidade de armazenamento em cache substancial e atuam como um escudo de origem.

Aqui é apresentada uma vista geral desta topologia:

Vista geral da topologia (clique para aumentar).

A RFC de multimédia oferece proteção de origem por predefinição através de um conjunto limitado de localizações globais importantes. A proteção de origem predefinida funciona com base na localização do utilizador final e não na origem. Isto funciona bem e oferece fortes vantagens de desvio quando os utilizadores 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

Pré-visualização

Este produto ou funcionalidade está sujeito aos "Termos das Ofertas de Pré-DG" na secção Termos Gerais de Serviço dos Termos Específicos do Serviço. Os produtos e as funcionalidades pré-GA estão disponíveis "tal como estão" e podem ter apoio técnico limitado. Para mais informações, consulte as descrições das fases de lançamento.

Importante: a proteção flexível é uma configuração avançada. A escolha de uma região de proteção inadequada pode afetar negativamente o desempenho, o que pode aumentar a latência em comparação com o comportamento predefinido. A proteção de origem predefinida é altamente recomendada, a menos que o seu exemplo de utilização principal envolva uma origem centralizada que publique conteúdo para utilizadores finais globais amplamente distribuídos.

Em cenários em que a sua origem está centralizada numa região, mas os seus utilizadores estão distribuídos globalmente, o comportamento de proteção de origem predefinido, que se baseia na localização do utilizador, pode ser subótimo das seguintes formas:

• Aumentar a latência para falhas de cache quando a localização do escudo predefinida está geograficamente distante da sua origem centralizada
• Redução da transferência da origem através da dispersão de pedidos de preenchimento da cache por várias localizações de proteção predefinidas globais, em vez de os concentrar

A proteção flexível ajuda a superar estas limitações configurando uma região geográfica única e específica para a proteção de origem, normalmente selecionada para estar perto da sua origem centralizada. Em seguida, a proteção flexível encaminha todos os pedidos de preenchimento da cache através de caches de proteção localizadas na região configurada ou perto desta. Isto consolida o carregamento na sua origem através dessas caches focadas na região.

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

• Taxa de resultados da cache na camada de proteção
• Descarga da origem
• Latência para falhas de cache e conteúdo não armazenável em cache
• Estabilidade do desempenho

A proteção flexível é compatível com qualquer tipo de origem configurado na RFC de multimédia.

Pedir redução

O pedido de redução reduz ativamente vários pedidos de preenchimento da cache iniciados pelo utilizador para a mesma chave da cache num único pedido de origem, por nó de limite.

Todas as camadas de colocação em cache suportam a redução de pedidos (ou união) para reduzir ainda mais a carga de origem. Com base em cargas de trabalho reais observadas em grande escala:

• > 95% do preenchimento da cache usa um nó de cache de cauda longa dedicado na região, de modo a reduzir os custos e a latência do preenchimento da cache.
• O preenchimento da cache entre a origem e a infraestrutura de proximidade da Google é feito inteiramente através da rede principal privada global da Google, o que reduz a latência de preenchimento da cache e melhora a fiabilidade. Ambos são benefícios ativos para cargas de trabalho de streaming em direto.
• As caches preenchem-se mutuamente quando é vantajoso fazê-lo, o que reduz ainda mais as taxas de preenchimento da cache.
• A RFC de multimédia tem uma capacidade de armazenamento significativa em todas as caches, o que minimiza as taxas de remoção, mesmo para conteúdo menos popular e de cauda longa.

Os clientes podem ver taxas de descarregamento diferentes consoante a configuração da cache, a carga do utilizador, as cargas de trabalho (como em direto versus a pedido), a distribuição dos utilizadores e a quantidade de conteúdo de cauda longa (tamanho total do conjunto de dados) que fornecem aos utilizadores em várias regiões.

Quando combinada com a proteção de origem, a redução de pedidos diminui ainda mais a carga de origem e as necessidades de largura de banda de saída, e é o comportamento predefinido para a RFC de multimédia.

Os pedidos reduzidos têm o pedido apresentado ao cliente registado e o pedido de preenchimento da cache (reduzido) registado. O líder da sessão reduzida é usado para fazer o pedido de preenchimento de origem, o que significa que a origem vê os cabeçalhos (incluindo o agente do utilizador) apenas desse cliente.

Não é possível comprimir pedidos que não partilham a mesma chave de cache.

Conetividade de origem

As secções seguintes descrevem como a RFC de multimédia se liga às origens, como são feitos os pedidos HTTP e como pode autenticar os pedidos.

Origens e protocolos suportados

A RFC de multimédia suporta diretamente qualquer ponto final de HTTP acessível publicamente como origem, incluindo o seguinte:

• Contentores do Cloud Storage, incluindo contentores privados através de contas de serviço da gestão de identidade e de acesso
• Balanceadores de carga de aplicações externos
• Contentores compatíveis com o Amazon S3, incluindo contentores privados 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 Web disponíveis publicamente, como VMs públicas ou anfitriões no local

A conetividade às origens é feita através de túneis seguros e da rede global da Google.

A tabela seguinte detalha os protocolos de origem suportados.

Protocolo	Suportado	SSL (TLS) necessário
HTTP/2	Sim (predefinição)	Sim
HTTPS (HTTP/1.1 através de TLS)	Sim	Sim
HTTP/1.1	Sim	Não

Por predefinição, a RFC usa o HTTP/2 (h2) para se ligar a uma origem. O HTTP/2 e o HTTPS requerem um certificado TLS (SSL) válido e publicamente fidedigno. Um certificado válido é um certificado que não expirou, que foi assinado por uma autoridade de certificação pública e que tem um nome alternativo do assunto correspondente ao nome do anfitrião enviado para a origem.

Notas:

• Se a sua origem não suportar HTTP/2, pode definir explicitamente o protocolo (por origem) como HTTP (HTTP/1.1) ou HTTPS (HTTP/1.1 através de TLS).
• Quando configura o HTTPS ou o HTTP/1.1 como o protocolo de origem, a RFC de multimédia não negoceia um protocolo alternativo (como o HTTP/2). Da mesma forma, quando configura o HTTP/2, a ligação não reverte para HTTP/1.1, para ser explícita acerca do comportamento da conetividade de origem.
• A RFC 2616 especifica que a porta 80 é a porta predefinida para o protocolo HTTP.80443

Cabeçalhos do pedido de origem

Quando se liga a uma origem, a RFC usa o cabeçalho Host do pedido do cliente por predefinição.

A tabela seguinte documenta o que a origem vê no pedido recebido em diferentes cenários de configuração:

Pedido do cliente	EdgeCacheService.hostRewrite	EdgeCacheOrigin.hostRewrite	originAddress	Cabeçalho do anfitrião / SNI do 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 contentor

A origem principal e quaisquer origens de ativação pós-falha veem o mesmo cabeçalho de anfitrião se partilharem a mesma configuração routeRule ou hostRewrite.

Todas as definições de hostRewrite são ignoradas quando usa um contentor do Cloud Storage como origem, porque os contentores do Cloud Storage não suportam valores de cabeçalho do anfitrião alternativos. O cabeçalho do anfitrião é definido automaticamente com base no nome do contentor.

O valor TLS SNI (Server Name Indication) no pedido (para pedidos HTTP/3, HTTP/2 e HTTPS) está definido para o mesmo valor que o cabeçalho do anfitrião enviado para a origem.

Para obter informações sobre como reescrever cabeçalhos de anfitrião para a configuração por rota, consulte o artigo Configure rotas de serviço. Para obter informações sobre como definir ações de substituição por origem, consulte o artigo Failover de origem sem redirecionamento seguinte.

Permita que a origem receba tráfego da RFC

Para reduzir o risco de acesso não autorizado ao seu conteúdo, use uma lista de autorizações de IPs na origem para bloquear o acesso a todos os endereços IP, exceto os intervalos de endereços IP específicos que a Google usa para enviar pedidos a origens externas. Desta forma, apenas a RFC de multimédia pode estabelecer ligação aos seus servidores de origem.

A tabela seguinte resume os intervalos de endereços IP de origem necessários para as regras de firewall:

Tipo de endereço IP	Intervalo de IP da origem do pedido
IPv4	136.124.4.0/22
IPv6	2001:4860:4864:a::/64

Nota: estes intervalos de endereços IP podem mudar. Para uma comunicação ininterrupta e segura com as suas origens, consulte as notas de lançamento da CDN de multimédia com frequência e, quando necessário, atualize os Google Cloud intervalos de endereços IP nas configurações da firewall

.

Use o seguinte URL para aceder ao ficheiro JSON que contém os intervalos de endereços IP atribuídos pela Google atualizados.

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

Comutação por falha e limites de tempo

As secções seguintes descrevem estas opções de configuração:

• Tempos limite: determine quanto tempo a RFC de multimédia aguarda para estabelecer ligação à sua origem ou para que esta responda a um pedido.
• Voltas a tentar: determine se a RFC de conteúdo multimédia volta a tentar um pedido HTTP de origem para a sua origem e em que condições.
• Failover: determine se a RFC tenta estabelecer ligação a uma origem de failover se a primeira não estiver disponível ou devolver um código de estado específico.

Nota: as tentativas de repetição ou de alternativa só são feitas para pedidos GET, HEAD e OPTIONS.

Limites de tempo de origem

Os limites de tempo permitem-lhe configurar quando os comportamentos de nova tentativa de origem e de comutação por falha são acionados e quando a comutação por falha do cliente subsequente pode ser acionada.

A seguir, são descritos os limites de tempo configuráveis suportados pela Media CDN:

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

  Ambos os limites de tempo incluem o tempo que a origem demora a devolver cabeçalhos e a determinar se deve usar uma alternativa ou um redirecionamento. connectTimeout aplica-se independentemente a cada tentativa de origem, enquanto maxAttemptsTimeout inclui o tempo necessário para estabelecer ligação em todas as tentativas de origem, incluindo as alternativas e os redirecionamentos. Seguir um redirecionamento conta como uma tentativa adicional de estabelecer ligação à origem e conta para o limite maxAttempts definido para a origem configurada.

  Quando a RFC encontra uma resposta sem redirecionamento, como de uma origem de redirecionamento ou de alternativa, os valores readTimeout e responseTimeout aplicam-se. As origens redirecionadas usam os valores connectTimeout, readTimeout e responseTimeout configurados para o EdgeCacheOrigin que encontrou o redirecionamento.

• responseTimeout e readTimeout controlam a duração de uma resposta transmitida. Depois de a RFC determinar que vai usar uma resposta a montante, nem connectTimeout nem maxAttemptsTimeout são importantes. Neste ponto, readTimeout e responseTimeout entram em vigor.

A RFC 7230 especifica que um cliente HTTP deve tentar novamente um pedido HTTP falhado, pelo menos, uma vez. O Media CDN faz, no máximo, quatro tentativas de origem em todas as origens, independentemente do maxAttempts definido por cada EdgeCacheOrigin. A RFC de multimédia usa o valor maxAttemptsTimeout da propriedade principal EdgeCacheOrigin. Os valores de tempo limite por tentativa (connectTimeout, readTimeout e responseTimeout) são configurados para o EdgeCacheOrigin de cada tentativa.

A tabela seguinte descreve os campos de limite de tempo:

Campo	Predefinição	Descrição
connectTimeout	5 segundos	O tempo máximo que a RFC de multimédia pode demorar desde o início do pedido à origem até determinar se a resposta é utilizável. Na prática, connectTimeout abrange o tempo que começa com a criação do pedido, seguido das procuras de DNS, dos handshakes TLS, do estabelecimento da ligação TCP/QUIC, até à obtenção dos cabeçalhos de resposta que contêm o código de estado HTTP. O limite de tempo tem de ser um valor entre 1 segundo e 15 segundos.
maxAttemptsTimeout	15 segundos	O tempo máximo em todas as tentativas de ligação à origem, incluindo origens de failover, antes de devolver um erro ao cliente. É devolvido um erro HTTP 504 se o limite de tempo for atingido antes de ser devolvida uma resposta. O limite de tempo tem de ser um valor entre 1 segundo e 30 segundos. Esta definição define a duração total de todas as tentativas de ligação de origem, incluindo origens de comutação por falha, para limitar o tempo total que os clientes têm de esperar que o conteúdo comece a ser transmitido em streaming. Apenas é usado o primeiro valor maxAttemptsTimeout, em que o primeiro é definido pela origem configurada para a rota especificada.
readTimeout	15 segundos	A duração máxima de espera entre leituras de uma única resposta HTTP. O valor de readTimeout é limitado pelo valor de responseTimeout. Todas as leituras da resposta HTTP têm de ser concluídas até ao prazo definido pelo responseTimeout. O limite de tempo tem de ser um valor entre 1 segundo e 30 segundos. Se este limite de tempo for atingido antes de a resposta estar concluída, a resposta é truncada e registada.
responseTimeout	30 segundos	A duração máxima permitida para a conclusão de uma resposta. O limite de tempo tem de ser um valor entre 1 segundo e 120 segundos. A duração é medida a partir do momento em que os primeiros bytes do corpo são recebidos. Se este limite de tempo for atingido antes de a resposta estar concluída, a resposta é truncada e registada.

Considere os seguintes exemplos:

• Origin A corresponde a pedidos para "/segments/" e tem um valor de maxAttemptsTimeout de 5s, um valor de maxAttempts de 1 e um valor de failover_origin de Origin B. O valor de connectTimeout está no valor predefinido de 5s. Se tentar estabelecer ligação a Origin A e ocorrer uma falha no prazo de 1 segundo devido a um certificado TLS inválido, tem cerca de 4 segundos para estabelecer uma ligação bem-sucedida a Origin B.

• Origin C corresponde a pedidos para "/manifests/*", tem um valor de maxAttemptsTimeout 10s, um valor de maxAttempts 3 e failover_origin não está configurado. O valor connectTimeout está no valor predefinido de 5s. A RFC tenta estabelecer ligação ao Origin C até três vezes, permitindo até 10 segundos (o limite de maxAttemptsTimeout) para estabelecer uma ligação bem-sucedida.

Tente novamente os pedidos de origem

A RFC de conteúdo multimédia suporta novas tentativas de origem, o que permite repetir pedidos sem êxito à origem. Pode especificar quantas vezes o origem atual pode ser tentado novamente antes de tentar uma origem de alternativa (se configurada).

• A RFC tenta alcançar a origem principal até ao valor maxAttempts configurado, que é 1 por predefinição.
• A RFC de multimédia tenta novamente as ligações de origem até um máximo de três vezes antes de falhar e devolver um erro HTTP 502 Bad Gateway ao utilizador. Isto inclui quaisquer ligações de origem de comutação por falha, que contam para o limite de três.
• Quando configura um recurso de origem, pode configurar uma origem principal através do campo originAddress e, em seguida, um failoverOrigin opcional. O elemento failoverOrigin aponta para um recurso de origem diferente.

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

Condição	Predefinição	Descrição
CONNECT_FAILURE	✔️	As novas tentativas em caso de falhas incluem erros de encaminhamento, DNS e handshake TLS, bem como tempos limite de TCP/UDP.
HTTP_5XX		Tentar novamente em qualquer código de estado HTTP 5xx.
GATEWAY_ERROR		Semelhante a 5xx, mas aplica-se apenas aos códigos de estado 502, 503 ou 504.
RETRIABLE_4XX		Tente novamente para códigos de estado 4xx que podem ser repetidos, incluindo 409 e 429.
NOT_FOUND		Volte a tentar com um código de estado HTTP 404.
FORBIDDEN		Volte a tentar com um código de estado HTTP 403.

Se precisar de verificações de estado ativas, round robin ou encaminhamento com reconhecimento de carga em várias origens, pode configurar um Application Load Balancer externo como a origem principal.

Comportamento de comutação por falha

A tabela seguinte descreve como funciona a comutação por falha e que resposta um cliente observaria:

Cenário	Failover configurado	Estado visível para o utilizador
A RFC tenta estabelecer ligação à sua origem e não recebe nenhuma resposta HTTP após duas tentativas (predefinição).	Não	HTTP 502 Bad Gateway
O RFC tenta estabelecer ligação à sua origem principal e não consegue estabelecer ligação (erro de handshake TLS). É feita uma tentativa contra a origem de alternativa configurada, que devolve um erro HTTP 404.	Sim	HTTP 404 Not Found
A RFC tenta estabelecer ligação à sua origem principal e de failover, mas não recebe nenhum código de estado HTTP.	Sim	HTTP 502 Bad Gateway

Se a RFC receber um código de estado correspondente a qualquer um dos retryConditionsconfigurados, como um erro HTTP 404 Not Found ou HTTP 429 Too Many Requests, e as tentativas subsequentes de repetição e de comutação por falha de pedidos de origem continuarem a falhar, é devolvido um erro HTTP 502 Bad Gateway ao cliente após esgotarem-se as tentativas de origem.

Práticas recomendadas para a comutação em caso de falha da origem

Quando configurar várias origens para a comutação por falha ou o equilíbrio de carga, verifique se o conteúdo multimédia e os comportamentos dos cabeçalhos Vary, ETag e Last-Modified são consistentes entre as origens.

Aviso: a configuração de redirecionamentos a partir de um serviço de origem não fidedigno ou controlado por um atacante pode expor a configuração da RFC de conteúdo multimédia a vulnerabilidades de redirecionamento aberto.

Como prática recomendada, configure o redirecionamento de origem apenas para origens fidedignas e que controla. Certifique-se de que confia em todas as origens numa cadeia de redirecionamentos, porque cada origem produz conteúdo publicado pelo seu EdgeCacheService.

O que se segue?

• Configure uma origem
• Use um contentor privado compatível com o Amazon S3 como uma origem
• Configure rotas de serviço