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. As configurações de origem informam ao Media CDN como se conectar à sua 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 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 tente novamente
com base nas respostas HTTP
404 Not Found
ou HTTP429 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 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
ouETag
(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çãoRange GET
. O cabeçalhoContent-Range
precisa ter um valor válido no formatobytes x-y/z
(em quez
é 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:
- Caches de borda profunda, que veiculam a maior parte do tráfego e descarregam uma rede de provedores de serviços.
- A borda de peering do Google, conectada a milhares de ISPs e que 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.
- Caches de cauda longa na rede do Google que outros caches downstream preenchem 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:
Todas as camadas de cache oferecem suporte ao recolhimento de solicitações (ou coalescência) para reduzir ainda mais 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 de cache entre a origem e a infraestrutura de borda do Google é feito totalmente pela rede de backbone global particular 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 fazer isso, 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 da solicitação
O recolhimento da solicitação recolhe ativamente vários objetos definidos pelo 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 carga de origem e largura de banda de saída, e é o comportamento padrão para 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 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 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 de confiança pública. 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) ouHTTPS
(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 não recorre ao HTTP/1.1 para explicitar o comportamento de conectividade de origem.
- O Media CDN usa automaticamente a porta correta com base
protocolo: porta
80
para HTTP ou443
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 | são definidos automaticamente com base no nome do bucket |
A origem principal e todas as origens de failover vão ver 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
o 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 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.
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 que o Media CDN suporta:
connectTimeout
emaxAttemptsTimeout
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, enquantomaxAttemptsTimeout
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 conjuntomaxAttempts
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
eresponseTimeout
são aplicados. As origens redirecionadas usamconnectTimeout
,readTimeout
, eresponseTimeout
configurados para oEdgeCacheOrigin
que encontrou o redirecionamento.responseTimeout
ereadTimeout
controlam o tempo que uma resposta transmitida pode levar. Depois que o Media CDN determina que ele vai usar uma resposta upstream, nemconnectTimeout
nemmaxAttemptsTimeout
não importa.readTimeout
eresponseTimeout
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
) 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
iniciando a solicitação para a origem até que o Media CDN determine
se a resposta é utilizável. Na prática, 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. 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
O valor |
readTimeout | 15 segundos | A duração máxima de espera entre as leituras de uma única resposta HTTP.
O |
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 valormaxAttemptsTimeout
de5s
, um valormaxAttempts
de1
e um Valorfailover_origin
deOrigin B
. O valorconnectTimeout
está no o padrão é5s
. Se você tentar se conectar à redeOrigin A
e ela falhar em 1 devido a um certificado TLS inválido, restam cerca de quatro segundos para conexão bem-sucedida comOrigin B
.Origin C
corresponde a solicitações para "/manifests/*, tem um valormaxAttemptsTimeout
de10s
, um valormaxAttempts
de3
efailover_origin
não configurado. O O valor deconnectTimeout
está no padrão de5s
. CDN de mídia tenta se conectar aoOrigin C
até três vezes, permitindo até 10 segundos (o limite demaxAttemptsTimeout
) 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 principal até o
valor
maxAttempts
configurado, que é padrão1
. - 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 contam para o limite de três. - Ao configurar um recurso de origem, defina uma origem primária
usando o campo
originAddress
e, em seguida, umfailoverOrigin
opcional. OfailoverOrigin
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
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. 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 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
estão
consistentes entre suas origens.
Como prática recomendada, configure o redirecionamento de origem apenas para origens em que você confia
e controla. Confie em todas as origens de uma cadeia de redirecionamento
cada origem produz conteúdo que é veiculado pelo EdgeCacheService
.
A seguir
- Configurar uma origem
- Usar um bucket particular compatível com o Amazon S3 como origem
- Configurar rotas de serviço