Visão geral das origens

O Media CDN permite buscar conteúdo da sua origem infraestrutura local, seja o conteúdo hospedado no Google Cloud na nuvem ou no local.

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

As origens têm os seguintes recursos:

  • As origens podem ser definidas por host e por rota, o que permite Recurso EdgeCacheService para mapear a várias origens que contêm, por exemplo, manifestos, segmentos de vídeo e outros elementos conteúdo.
  • As origens podem ser acessadas por HTTP/2, HTTPS e HTTP/1.1 não criptografado.
  • Novas tentativas e comportamentos de failover são configurados por origem e podem permitir serviço faça o failover em erros de hardware (como falha de conectividade) ou tente novamente com base em respostas HTTP 404 Not Found ou HTTP 429 Too Many Requests.
  • Acesso a recursos privados dentro do Google Cloud ou no local configurando um balanceador de carga de aplicativo externo origem do Google Cloud por trás do Media CDN.
  • O comportamento de redirecionamento é configurado por origem. É possível ativar 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 precisará 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. Caso suas origens sejam compatíveis apenas com HTTP/1.1, é possível definir o campo "protocolo" explicitamente para cada origem.

Proteção de origem

O Media CDN oferece uma infraestrutura de borda profundamente em camadas projetado 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 veiculam a maior parte do tráfego e descarregam uma rede de provedores de serviços.
  2. A borda de peering do Google, conectada a milhares de ISPs e atua como cache de camada intermediária para caches de borda e, para casos em que presentes em um determinado ISP, o cache voltado ao usuário.
  3. Caches de cauda longa na rede do Google preenchidas por outros caches downstream de antes da origem. Esses caches dão suporte a fan-in, capacidade substancial de armazenamento em cache e atuar como proteção 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 armazenamento em cache oferecem suporte ao recolhimento (ou coalescência) de solicitações para reduzir a carga de origem. Baseado em cargas de trabalho reais e observadas em escala:

  • > 95% do preenchimento do cache usa um nó de cache de cauda longa dedicado região, a fim de reduzir a latência e os custos de preenchimento de cache.
  • O preenchimento do cache entre a origem e a infraestrutura de borda do Google é inteiramente pela rede de backbone privada global do Google, o que reduz o cache a latência em tempo real e aumenta a confiabilidade, já que ambos são benefícios cargas de trabalho de streaming.
  • Os caches são preenchidos de forma cruzada uns com os outros quando vantajoso para isso, e reduzindo as taxas de preenchimento de cache.
  • O Media CDN tem capacidade de armazenamento significativa em caches, o que minimiza as taxas de remoção mesmo para casos de cauda longa, conteúdo.

Os clientes podem ver taxas de descarga diferentes dependendo do cache configuração, carga do usuário, cargas de trabalho (como ao vivo versus sob demanda), distribuição do conteúdo e quanto conteúdo de cauda longa (tamanho total do corpus) eles são veiculados usuários em todas as regiões.

Recolhimento da solicitação

O recolhimento da solicitação recolhe ativamente vários objetos com base no usuário solicitações de preenchimento de cache para a mesma chave de cache em uma única solicitação de origem, por nó de borda.

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

As solicitações recolhidas têm a solicitação do cliente registrada e o (recolhida) de solicitação de preenchimento de cache registrada. O líder da sessão recolhida é usada para fazer a solicitação de preenchimento da origem, o que significa que a origem vê o cabeçalhos (incluindo o user agent) 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 autenticar as solicitações.

Origens e protocolos compatíveis

O Media CDN oferece suporte direto a qualquer endpoint HTTP acessível ao público 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 privados que usam versão 4 da assinatura da AWS
  • 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 o backbone global do Google em uma rede VPC.

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 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 expirou, assinado por um certificado público e tem um Nome alternativo do assunto correspondente ao nome do host enviado ao origem.

Observações:

  • Caso sua origem não ofereça suporte a HTTP/2, será possível definir explicitamente o protocolo (por origem) para 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 como HTTP/2). Da mesma forma, ao configurar o HTTP/2, a conexão voltam para HTTP/1.1 para sermos explícitos sobre a conectividade de origem do seu modelo.
  • O Media CDN usa automaticamente a porta correta com base protocolo: porta 80 para HTTP ou 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 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 são definidos automaticamente com base no nome do bucket

A origem primária e as origens de failover veem o mesmo cabeçalho de host se compartilham a mesma configuração de routeRule ou hostRewrite.

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

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

Para informações sobre como reescrever cabeçalhos de host para configuração por rota, consulte Configure rotas de serviço. Para mais informações sobre como configurar 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 à sua origem ou que ele responda a uma solicitação.
  • Novas tentativas: determinar se o Media CDN tenta executar uma nova tentativa HTTP à sua origem e em quais condições.
  • Failover: determina se o Media CDN tenta se conectar a uma origem de failover se a primeira não estiver disponível ou retornar um status específico o código-fonte é alterado.
.

Tempos limite de origem

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

Confira a seguir os tempos limite configuráveis que o Media CDN suporta:

  • connectTimeout e maxAttemptsTimeout limitam o tempo de duração do Media CDN para encontrar uma resposta utilizável.

    Ambos os tempos limite incluem o tempo que a origem leva para retornar cabeçalhos e determinar o uso de failover ou redirecionamento. Sujeito a connectTimeout de forma independente para cada tentativa, 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 tentativa de conexão com a origem e conta para o conjunto maxAttempts para a origem configurada.

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

  • O responseTimeout e o readTimeout controlam por quanto tempo uma resposta transmitida pode pode necessitar. Depois que o Media CDN determina que ele vai usar uma resposta upstream, nem connectTimeout nem maxAttemptsTimeout não importa. readTimeout e responseTimeout entram em vigor.

O Media CDN faz no máximo quatro tentativas de origem em todas as origens, independentemente do maxAttempts definido por cada EdgeCacheOrigin. O Media CDN usa o valor maxAttemptsTimeout do EdgeCacheOrigin. Os valores de tempo limite por tentativa (connectTimeout, readTimeout e responseTimeout) estã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 iniciando a solicitação para 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 e depois executa as verificações do Google, fazer handshakes de TLS, estabelecer uma conexão TCP/QUIC para conseguir os cabeçalhos de resposta que contêm o código de status HTTP.

O tempo limite deve ser um valor entre 1 segundo 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 erro HTTP 504 retornado se o tempo limite for atingido antes que uma resposta seja retornada.

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

Esta configuração define a duração total para todas as origens tentativas de conexão, incluindo origens de failover, para limitar a tempo total que os clientes têm para esperar o conteúdo começar a transmitir. Somente o primeiro O valor maxAttemptsTimeout é usado, em que o primeiro é definido pela origem configurada para o trajeto especificado.
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 dentro do prazo definido pelo responseTimeout: O tempo limite deve ser um valor entre 1 segundo e 30 segundos. Se esse tempo limite for atingido antes que a resposta seja concluída, o a resposta fique truncada e registrada.
responseTimeout 30 segundos

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

O tempo limite deve 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 esse tempo limite for atingido antes que a resposta seja concluída, o a resposta fique truncada e registrada.

Veja estes exemplos:

  • Origin A corresponde a solicitações para "/segments/". e tem um Um valor maxAttemptsTimeout de 5s, um valor maxAttempts de 1 e um Valor failover_origin de Origin B. O valor connectTimeout está o padrão é 5s. Se você tentar se conectar à rede Origin A e ela falhar em 1 devido a um certificado TLS inválido, restam cerca de quatro segundos para 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 O valor de connectTimeout está no padrão de 5s. CDN de mídia tenta se conectar ao Origin C até três vezes, permitindo até 10 segundos (o limite de maxAttemptsTimeout) para fazer uma conexão.

Repetir solicitações de origem

O Media CDN oferece suporte a novas tentativas de origem, solicitações à origem sejam repetidas. É possível especificar quantas vezes o a origem atual pode ser repetida antes de uma origem de failover (se configurada) de segurança.

  • O Media CDN tenta alcançar a origem primária até o valor de maxAttempts configurado, que tem o padrão 1.
  • O Media CDN faz novas tentativas das 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 o 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 falhas aciona 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 aplica-se somente a 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 direção com reconhecimento de carga entre origens, é possível configure um balanceador de carga de aplicativo externo como 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. não recebe resposta HTTP após duas tentativas (padrão). Não HTTP 502 Bad Gateway
O Media CDN tenta se conectar à sua origem principal, e falha na conexão (erro de handshake de TLS). É feita uma tentativa contra sua origem de failover configurada, que retorna um erro HTTP 404 erro. Sim HTTP 404 Not Found
O Media CDN tenta se conectar às suas contas principal e origem de failover, mas não recebe códigos de status HTTP. Sim HTTP 502 Bad Gateway

Se o Media CDN receber um código de status correspondente a retryConditions, 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 continuam falhar, um erro HTTP 502 Bad Gateway será retornado ao cliente após a origem tentativas se esgotarem.

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 estão consistentes entre suas origens.

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

A seguir