O Media CDN oferece recursos avançados de roteamento HTTP mapear o tráfego para origens e configurações de borda específicas nível
Configurar uma regra de rota
Configure uma regra de rota para um serviço do Media CDN.
Console
No console do Google Cloud, acesse a página Media CDN.
Para abrir a página Detalhes do serviço em questão configure uma regra de rota, clique no nome do serviço.
Para mudar para o modo de edição, clique no botão Editar.
Para navegar até a seção Roteamento, clique em Próxima.
Especifique pelo menos uma regra de host. Clique em Adicionar regra de host. Depois, faça o seguintes:
Em Hosts, especifique pelo menos um host para correspondência.
Em Descrição, forneça uma breve descrição da regra de host.
Como alternativa, para editar uma regra de host, clique na seta para expandi-la.
Especifique pelo menos uma regra de rota. Clique em Adicionar regra de rota.
Como alternativa, para editar uma regra de rota, clique em
Edite na respectiva linha.No painel Editar regra de rota, em Prioridade, defina um valor para prioridade da rota.
Em Descrição, forneça uma breve descrição que ajude a identificar a regra em uma lista de regras.
Na seção Correspondência, especifique pelo menos uma condição de correspondência. Clique em Adicione uma condição de correspondência. Em seguida, faça o seguinte:
- Em Tipo de correspondência, selecione qualquer opção de correspondência de caminho.
Em Correspondência de caminho, especifique nomes, caminhos ou modelos. Considere usar a correspondência de padrões com caracteres curinga.
Se necessário, selecione Ativar a diferenciação de maiúsculas e minúsculas para o valor do caminho.
Opcional: selecione Correspondência de cabeçalhos e Correspondência de parâmetros de consulta. Em seguida, clique nos botões relevantes para adicionar cabeçalhos e parâmetros de consulta. Para cada um, especifique o nome, o tipo de correspondência e o valor.
Para mais informações, consulte Correspondência em cabeçalhos e parâmetros de consulta.
Para salvar a condição de correspondência, clique em Concluído.
Em Ação principal, selecione uma das seguintes opções:
Buscar a partir de uma origem: para direcionar solicitações a uma origem específica, selecione essa opção e depois uma origem.
Redirecionamento de URL: para redirecionar solicitações, selecione esta opção. Em seguida, especifique o tipo de redirecionamento, o caminho e o código de status.
Também é possível selecionar as opções para redirecionar todas as respostas para HTTPS. ou para eliminar a consulta.
Clique em Configurações avançadas.
Na seção Ação do cabeçalho, clique em Adicionar um item.
Selecionar um tipo de ação e especificar um cabeçalho como nome e valor par. Em seguida, clique em Concluído.
Na seção Rota de ação, clique em Adicionar um item.
Especifique um tipo de ação e as opções relacionadas. Em seguida, clique em Concluído.
Em Filtragem de método HTTP, selecione Personalizar filtragem de método HTTP.
Em seguida, selecione os métodos HTTP que você quer colocar em proxy na sua origem.
Para salvar a regra de rota, clique em Salvar.
Para salvar as alterações no serviço, clique em Atualizar serviço.
gcloud e YAML
Exporte a configuração do Media CDN para um arquivo YAML. Use o comando
gcloud edge-cache services export
.gcloud edge-cache services export SERVICE_NAME \ --destination=FILENAME.yaml
Substitua:
SERVICE_NAME
: o nome do serviço;FILENAME
: o nome do arquivo YAML
Atualize o arquivo YAML com a configuração necessária, conforme descrito nas seções desta página.
Para atualizar o serviço, importe a configuração do Media CDN. do arquivo YAML. Use o comando
gcloud edge-cache services import
.gcloud edge-cache services import SERVICE_NAME \ --source=FILENAME.yaml
Solicitações de correspondência
Uma configuração do Media CDN contém um conjunto de rotas definidas na seção
Roteamento
de um recurso
EdgeCacheService
.
Essas rotas correspondem a solicitações com base em (pelo menos) um host. Para mais detalhes sobre como
o tráfego é direcionado a uma origem, consulte
HostRule
e PathMatcher
.
Cada rota pode definir a própria configuração, regravações, redirecionamentos
Políticas CORS, cabeçalhos HTTP personalizados e mapeamento de origem.
As rotas podem compartilhar origens.
Por exemplo, você pode encaminhar solicitações de manifestos para uma origem específica e defina um TTL de cache de curta duração e um política de armazenamento em cache negativo. As solicitações de segmentos podem ser divididas em outra origem usando cabeçalhos e parâmetros de consulta para dividir tipos de manifesto ou usuários específicos.
O exemplo a seguir mostra como rotear solicitações que correspondem a um cabeçalho específico,
parâmetro de consulta e prefixo de caminho do host media.example.com
:
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 10 origin: staging-live-origin matchRules: - prefixMatch: /vod/ headerMatches: - headerName: "x-staging-client" presentMatch: true queryParameterMatches: - name: "live" exactMatch: "yes" routeAction: cdnPolicy: defaultTtl: 5s
Correspondência de caminho
O Media CDN é compatível com correspondência de caminho completa (exata), de prefixo e de caractere curinga. A correspondência de caminho pode ser combinada com um host, um cabeçalho e uma consulta com base em parâmetros para criar regras detalhadas de roteamento de solicitações.
Veja a seguir três maneiras de fazer a correspondência em um caminho de URL.
Campo | Descrição | Exemplo |
---|---|---|
matchRules[].fullPathMatch
|
A condição fullPathMatch corresponde ao caminho completo do URL,
que não inclui a string de consulta. Você deve especificar valores
barras, se relevante.
|
Uma rota com uma regra de correspondência de Uma |
matchRules[].prefixMatch
|
A condição prefixMatch corresponde ao prefixo do caminho do URL. URLs
que começam com a mesma correspondência de string.
|
Uma rota com uma regra de correspondência de |
matchRules[].pathTemplateMatch
|
A condição pathTemplateMatch oferece suporte
operadores de caractere curinga, permitindo corresponder padrões de URL complexos e caminhos
e capturar variáveis nomeadas para reescrever URLs.
|
Uma rota com uma regra de correspondência de
Tanto Para mais exemplos, consulte a seção de correspondência de padrão. |
Para mais detalhes, consulte a especificação da API para
MatchRule
Por exemplo, para corresponder a todas as solicitações que começam com /stream/
, crie uma regra de rota.
semelhante a:
name: prod-service routing: hostRules: - hosts: - media.example.com - *.vod.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 matchRules: - prefixMatch: /stream/
Este exemplo inclui explicitamente a barra final na regra de correspondência:
- Uma solicitação para
media.example.com/stream/id/1234/hls/manifest.m3u8
corresponde esse trajeto. - Fazer uma solicitação para
media.example.com/stream-eu/id/4567/hls/manifest.m3u8
não correspondem a este trajeto.
No segundo caso, o Media CDN retorna um erro HTTP 404
.
a menos que houvesse outro trajeto ou uma rota geral
configurada.
Para orientações sobre como funciona a predecência para trajetos com prefixos semelhantes, consulte a seção de prioridade e ordem da rota.
Correspondência de padrões (caractere curinga)
Com a correspondência de padrão, é possível corresponder várias partes de um URL, incluindo URLs parciais e sufixos (extensões de arquivo), usando uma sintaxe de caracteres curinga.
Também é possível associar um ou mais componentes de caminho a variáveis nomeadas em um campo pathTemplateMatch
e, em seguida, consultar essas variáveis ao reescrever o URL em um campo pathTemplateRewrite
. Isso permite reordenar e remover componentes de URL antes
a solicitação é enviada à sua origem.
O exemplo a seguir mostra como é possível fazer a correspondência em dois sufixos de URL diferentes:
# EdgeCacheService.routing.pathMatchers[] routeRules: - priority: 1 description: "Match video segments" matchRules: - pathTemplateMatch: "/**.ts" - pathTemplateMatch: "/**.m4s" origin: prod-video-storage
A sintaxe compatível inclui o seguinte.
Operador | Corresponde a | Exemplo |
---|---|---|
*
|
Corresponde a um único componente de caminho até o próximo separador de caminho: /
|
/videos/*/*/*.m4s correspondências
/videos/123414/hls/1080p5000_00001.m4s .
|
**
|
Corresponde a zero ou mais segmentos de caminho. Se presente, precisa ser o último operador. |
/**.mpd correspondências
/content/123/india/dash/55/manifest.mpd .
|
{name} or {name=*}
|
Uma variável nomeada que corresponde a um só segmento de caminho.
Corresponde a um único componente de caminho até o próximo separador de caminho:
|
/content/{format}/{lang}/{id}/{file}.vtt correspondências
/content/hls/en-us/12345/en_193913.vtt e captura
format="hls" , lang="en-us" e id="12345" .
e file="en_193913" como variáveis.
|
{name=videos/*}
|
Uma variável nomeada que corresponde a mais de um segmento de caminho. O componente do caminho
o videos/* correspondente é capturado como a variável nomeada.
|
/videos/{language=lang/*}/* correspondências
/videos/lang/en/video.m4s e preenche a variável de caminho
language com o valor lang/en .
|
{name=**}
|
Uma variável nomeada que corresponde a zero ou mais segmentos de caminho. Se presente, precisa ser o último operador. |
|
Observações:
- Se você não estiver reescrevendo um URL, use os operadores
*
e**
mais simples. - Ao usar variáveis para capturar componentes de caminho, qualquer parte do URL que
não forem capturadas por uma variável não poderão ser referenciadas em um
pathTemplateRewrite
: Para ver um exemplo, consulte seção captura de variáveis de caminho. - Não é possível fazer referência a variáveis em uma
pathTemplateRewrite
subsequente que não existem nopathTemplateMatch
no mesmo trajeto. - As variáveis diferenciam maiúsculas de minúsculas, com
{FORMAT}
,{forMAT}
e{format}
representando diferentes variáveis e valores. - É possível especificar até 10 operadores (caracteres curinga ou variáveis) em uma correspondência.
Os campos
pathTemplateMatch
epathTemplateRewrite
não podem exceder 255 caracteres.
Exemplo: correspondência em uma extensão de arquivo
O exemplo a seguir mostra um caso de uso comum para operadores de caractere curinga: correspondência todos os componentes do caminho até um sufixo.
Nesse caso, faça o seguinte:
- Buscar manifestos de vídeo (playlists) que terminam em
.m3u8
e.mpd
no do manifesto, aplicando um TTL curto (cinco segundos) a essas respostas porque mudam regularmente. - busca segmentos de vídeo que terminam em
.ts
e.m4s
na origem do segmento; aplicar um TTL mais longo (um dia) a essas respostas.
Essa abordagem é muito usada com a injeção de anúncios do lado do servidor (SSAI, na sigla em inglês) ou Serviços de Inserção de anúncios dinâmicos (DAI) e para vídeos ao vivo em que o manifesto é atualizados em intervalos de alguns segundos.
A configuração a seguir demonstra como definir seu Roteamento do Media CDN para dar suporte a isso:
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: # the first route only matches video manifests - priority: 1 matchRules: - pathTemplateMatch: "/**.m3u8" # "**" matches all path segments - pathTemplateMatch: "/**.mpd" origin: manifest-origin routeAction: cdnPolicy: cacheMode: FORCE_CACHE_ALL defaultTtl: 5s # the second route matches video segments, fetches them # from a separate origin server, caching them for a longer # duration (1 day). - priority: 2 matchRules: - pathTemplateMatch: "/**.ts" - pathTemplateMatch: "/**.m4s" origin: segment-origin routeAction: cdnPolicy: cacheMode: FORCE_CACHE_ALL defaultTtl: 86400s
Exemplo: capturar variáveis de caminho
O exemplo a seguir mostra como usar variáveis nomeadas para descrever uma ou mais componentes de caminho.
Essas variáveis podem ser usadas em um pathTemplateRewrite
para reescrever o caminho anterior.
à solicitação enviada à origem ou para fazer uma solicitação
pathTemplateMatch
autodescritivo.
routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 matchRules: # Matches a request of "/us/en/hls/123139139/segments/00001.ts" - pathTemplateMatch: "/{country}/{lang}/{format}/{id}/{file=**}" origin: my-origin routeAction: urlRewrite: # Rewrites to "/123139139/hls/segments/00001.ts" pathTemplateRewrite: "/{id}/{format}/{file}"
Especificamente:
- Cada variável
{name}
captura um único segmento de caminho. Um segmento de caminho é caracteres entre um par de/
("barras") em um caminho de URL. - Uma variável
{name=**}
captura todos os segmentos de caminho restantes. neste caso, isso corresponde asegments/00001.ts
emaster.m3u8
. - No
pathTemplateRewrite
no mesmo trajeto, você consulta algumas das variáveis capturadas nopathTemplateMatch
. Você explicitamente omitir as variáveis{country}
e{lang}
porque elas não correspondem à na origem.
Nesse exemplo, ocorre o seguinte:
- Há uma correspondência entre o URL de solicitação recebida de
/us/en/hls/123139139/segment_00001.ts
opathTemplateMatch
e é reescrito para/123139139/hls/segment_00001.ts
antes de serem enviados à origem. - Um URL de solicitação recebida de
/us/123139139/master.m3u8
não corresponde àpathTemplateMatch
e recebe uma resposta HTTP404 (Not Found)
. - Um URL de solicitação de
/br/es/dash/c966cbbe6ae3/subtitle_00001.vtt
também corresponde aopathTemplateMatch
e é reescrito para/c966cbbe6ae3/dash/subtitle_00001.vtt
antes de ser enviado à origem.
Para saber mais sobre como a correspondência de curinga interage com a substituição de URL, consulte a seção substituições.
Correspondência de host
Cada serviço pode corresponder a vários nomes de host, sendo que cada conjunto contém um grupo próprio de rotas (conhecidos como correspondências de caminho). No caso mais comum, todos os nomes de host de um serviço são mapeados para um único conjunto de rotas compartilhadas com um único lista de hosts e uma única correspondência de caminho.
name: prod-service routing: hostRules: - hosts: - media.example.com - *.vod.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: # list of routes for the configured hosts - priority: 999 matchRules: - prefixMatch: / origin: DEFAULT_ORIGIN
Os hosts não correspondentes recebem uma página HTTP 404
padrão. Para aceitar qualquer organizador,
é possível incluir o caractere curinga *
como uma entrada hostRules[].hosts[]
.
Também é possível definir grupos de trajetos, por exemplo, agrupar por país ou ao vivo em vez de sob demanda. Como cada serviço tem uma única política de segurança, geralmente recomendam ter um serviço para cada mercado (região geográfica) ou carga de trabalho que você tem.
Observações:
- Os cabeçalhos de host (ou HTTP/2
:authority
) que contêm uma porta são implicitamente correspondentes a um host configurado. Não é preciso especificar explicitamente portas. - Se a solicitação for feita por HTTP, uma entrada
hostRules[].hosts[]
de*.vod.example.com
corresponde aus.vod.example.com
eus.vod.example.com:80
. - Se a solicitação for por HTTPS (TLS), uma entrada
hostRules[].hosts[]
de*.vod.example.com
corresponde aus.vod.example.com:443
.
Para mais detalhes, consulte a especificação da API para
HostRule
Correspondência de cabeçalhos e parâmetros de consulta
É possível configurar rotas para corresponder a nomes específicos de parâmetros de consulta e cabeçalhos, bem como a presença de um valor de cabeçalho (prefixo, sufixo ou correspondência exata).
A correspondência de cabeçalho e parâmetro de consulta é "AND" lógico: a solicitação precisa corresponder a todos os parâmetros de consulta e chaves de cabeçalho (e valores, se especificados) para corresponder à rota especificada.
Por exemplo, se você quiser rotear solicitações com um nome de campo de cabeçalho específico e
para uma origem chamada alternate-origin
, configure a correspondência
condições em routeRules[].matchRules[].headerMatches[]
:
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: alternate-origin matchRules: - prefixMatch: "/videos/" headerMatches: - headerName: "x-device-name" exactMatch: "roku"
Neste exemplo, as solicitações com /videos/
no início do URL e o
cabeçalho x-device-name: roku
correspondem a essa rota. Solicitações sem esse cabeçalho
ou com um valor diferente não correspondem a esse trajeto.
Para mais detalhes, consulte a especificação da API para
HeaderMatch
.
Da mesma forma, para fazer correspondência com os parâmetros de consulta, especifique um ou mais
queryParameterMatches
da seguinte maneira:
name: prod-service routing: hostRules: - hosts: - media.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: eu-live-origin-prod matchRules: - prefixMatch: "/videos/" queryParameterMatches: - name: "playback_type" exactMatch: "live" - name: "geo" exactMatch: "eu"
Neste exemplo, uma solicitação do cliente de
https://cdn.example.com/videos/1234/abcd/xyz.m3u8?playback_type=live&geo=eu
corresponde a essa rota.
Para mais detalhes, consulte a especificação da API para
QueryParameterMatcher
Definir uma rota "pega-tudo" (padrão)
Por padrão, o Media CDN retorna um erro HTTP 404 (Not Found)
se uma solicitação
não corresponde a nenhuma rota configurada.
Para configurar uma rota pega-tudo, para um determinado pathMatcher
(coleção de
rotas), faça o seguinte:
- Crie uma
routeRule
com a prioridade mais baixa (número mais alto). Por exemplo: 999, que é a menor prioridade de rota possível. - Configurar um
matchRule
com um prefixo correspondente a/
(corresponde a todas as solicitações) caminhos). - Configure (uma de)
origin
ouurlRedirect
na rota.
Por exemplo, para configurar uma rota "pega-tudo" que direcione todas as solicitações não correspondentes
para uma origem padrão chamada my-origin
, crie uma nova rota com priority: 999
e um matchRules[].prefixMatch
de /
da seguinte maneira:
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 999 origin: my-origin matchRules: - prefixMatch: /
É possível reescrever o URL antes da busca da origem ou redirecionar para um página padrão (como a página de destino) em vez de enviar a solicitação "no estado em que se encontra" à origem.
Prioridade e ordem de rotas
Cada rota em uma matriz de routeRules[]
precisa ter uma priority
associada a
ela.
Rotas mais específicas devem ser definidas com prioridade mais alta (número menor). Uma
rota que corresponde a um prefixo de /stream/
com prioridade 1 impede que uma
rota mais específica de /stream/live/eu/
com prioridade 5 corresponda a qualquer
solicitação.
- A rota com maior prioridade é "1" e a mais baixa é "999".
- Não é possível configurar duas ou mais routeRules com a mesma prioridade. A prioridade de cada regra precisa ser definida como um número entre 1 e 999, inclusive.
- Definir uma rota "pega-tudo" permite que você envie todos solicitações não correspondentes para uma origem padrão ou redirecionamento a uma página de destino ou endpoint.
No exemplo a seguir, é possível ver que a rota /live/us/
nunca seria
correspondidos porque a rota /live/
está em uma prioridade mais alta:
routeRules: - priority: 1 description: "Live routes" matchRules: - prefixMatch: /live/ routeAction: cdnPolicy: defaultTtl: 5s - priority: 2 description: "U.S based live streams" matchRules: # This would never be matched, as the /live/ prefixMatch at priority 1 # would always take precedence. - prefixMatch: /live/us/ routeAction: cdnPolicy: defaultTtl: 5s - priority: 999 description: "Catch-all route" matchRules: - prefixMatch: /
Para resolver isso, coloque a rota mais específica (mais longa) em uma prioridade mais alta:
routeRules: - priority: 1 description: "U.S based live streams" matchRules: # The more specific (longer) match is at a higher priority, and now # matches requests as expected. - prefixMatch: /live/us/ routeAction: cdnPolicy: defaultTtl: 5s - priority: 2 description: "Live routes" matchRules: - prefixMatch: /live/ routeAction: cdnPolicy: defaultTtl: 5s - priority: 999 description: "Catch-all route" matchRules: - prefixMatch: /
Isso permite que a rota mais específica corresponda às solicitações corretamente. Uma solicitação
prefixado com /live/eu/
ainda seguiria para a rota /live/
em
prioridade 2.
Filtragem de métodos
Por padrão, o Media CDN faz o proxy somente de GET
, HEAD
e OPTIONS
à sua origem e filtra os métodos que podem modificá-la.
Para substituir esse comportamento padrão de uma regra de rota específica, especifique
os métodos que gostaria de colocar em proxy na sua origem. Além de GET
, HEAD
e OPTIONS
, o Media CDN oferece suporte a PUT
, POST
, DELETE
e
PATCH
.
Para configurar o suporte para um conjunto de métodos para uma regra de rota, especifique um
Seção routeMethods
que tem um valor allowed_methods
para cada método.
routeRules: - priority: 5 description: "Video uploads" routeMethods: allowedMethods: ["PUT", "POST", "OPTIONS"] matchRules: - pathTemplateMatch: "/uploads/**.ts" origin: prod-video-storage - priority: 10 description: "Video serving" routeMethods: allowedMethods: ["GET", "HEAD"] matchRules: - pathTemplateMatch: "/videos/**.ts" origin: prod-video-storage
Normalização de caminho
A normalização de caminho descreve como o Media CDN combina vários de um URL em uma única representação canônica em uma diferentes.
A normalização de caminho pode melhorar diretamente as taxas de ocorrência em cache reduzindo o número de URLs de solicitação que representam o mesmo conteúdo e atenuando erros de origem para origens que esperam caminhos normalizados.
As solicitações recebidas são normalizadas da seguinte maneira:
- Várias barras invertidas consecutivas são mescladas em uma única barra. Por exemplo, um
caminho de URL de
/videos///12345/manifest.mpd
é normalizado para/videos/12345/manifest.mpd
. - Os segmentos do caminho são normalizados de acordo com a
RFC 3986, seção 6.2.2.3.
Por exemplo, o caminho
/a/b/c/./../../g
é normalizado para/a/g
com base no as "remover segmentos de pontos" algoritmo definido na RFC 3986. Essa normalização acontece antes da verificação do cache ou do encaminhamento da solicitação para a origem. - As solicitações não são normalizadas com codificação percentual. Por exemplo, um URL com um
o caractere de barra codificado por porcentagem (
%2F
) não é decodificado como forma
Os URLs diferenciam maiúsculas de minúsculas e não são normalizados. Muitos URLs contêm codificações base64 que diferenciam maiúsculas de minúsculas, incluindo URLs com tokens de solicitação assinada.
Regravações e redirecionamentos
As seções a seguir fornecem exemplos sobre como reescrever solicitações e configurar redirecionamentos.
Reescrever URLs de solicitação
A Media CDN oferece suporte a substituições de host e caminho. As substituições mudam a URL enviado à origem que permite modificar hosts e caminhos conforme necessário. Hospedar e regravações de caminhos são feitas no nível da rota, permitindo que você defina quais solicitações reescritos com base em qualquer correspondente, incluindo caminho, parâmetro de consulta e solicitação cabeçalho.
Para mais detalhes, consulte a especificação da API para
RouteAction.UrlRewrite
Confira a seguir três maneiras de reescrever uma solicitação:
Campo | Descrição |
---|---|
urlRewrite.pathPrefixRewrite
|
Regrava o caminho, removendo o prefixo especificado no
Apenas um: |
urlRewrite.pathTemplateRewrite
|
Apenas um: |
urlRewrite.hostRewrite
|
Regrava o host antes que a solicitação seja enviada ao servidor de origem. |
Observações:
- Os URLs regravados não alteram a chave de cache. A chave de cache tem como base o URL de solicitação enviado pelo cliente.
- A regravação ocorre após a correspondência de rota e a validação da solicitação assinada. Trajetos não são correspondentes novamente a outra regra de correspondência.
Exemplo: remover um prefixo de caminho
Por exemplo, para reescrever um URL de solicitação de cliente de /vod/videos/hls/1234/abc.ts
para
/videos/hls/1234/abc.ts
(removendo /vod
do caminho), use o
recurso pathPrefixRewrite
:
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: my-origin matchRules: - prefixMatch: "/vod/videos/" routeAction: urlRewrite: pathPrefixRewrite: "/videos/"
Um pathPrefixRewrite
funciona substituindo todo o componente de caminho correspondente em
o matchRules[].prefixMatch
pelo valor de pathPrefixRewrite
.
Para reescrever um nome de host (por exemplo, reescrevendo cdn.example.com
para
my-bucket.s3.us-west-2.amazonaws.com
), configure o seguinte:
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 1 origin: my-origin matchRules: - prefixMatch: "/videos/" routeAction: urlRewrite: hostRewrite: "my-bucket.s3.us-west-2.amazonaws.com"
Nesse caso, o URL da solicitação de origem mudaria de
cdn.example.com/videos/*
para my-bucket.s3.us-west-2.amazonaws.com/videos/*
.
Também é possível combinar substituições de host e caminho em uma única rota.
Exemplo: usar variáveis para reescrever URLs
Para usar pathTemplateMatch
e pathTemplateRewrite
para reescrever partes de um
URL de solicitação de entrada, consulte a seção
captura de variáveis.
Solicitações de redirecionamento
A CDN para mídias oferece suporte a três tipos de redirecionamentos:
- Redirecionamentos de host, que redirecionam apenas o host (domínio), mantendo o caminho e os parâmetros de consulta inalterados.
- Redirecionamentos de caminho, que substituem o caminho completo.
- Redirecionamentos de prefixo de caminho, que substituem apenas o prefixo correspondente.
Redireciona por padrão para HTTP 301 (Moved Permanently)
, mas pode ser configurado para
retornam códigos de status de redirecionamento diferentes por trajeto.
A configuração a seguir é um exemplo de redirecionamento baseado em prefixo,
para onde você redireciona os usuários que visitam https://cdn.example.com/on-demand/*
para
https://cdn.example.com/streaming/*
.
name: prod-service routing: hostRules: - hosts: - cdn.example.com pathMatcher: example_routes pathMatchers: - name: example_routes routeRules: - priority: 10 matchRules: - prefixMatch: "/on-demand/" urlRedirect: # The prefix matched in matchRules.prefixMatch is replaced # by this value prefixRedirect: "/streaming/" redirectResponseCode: TEMPORARY_REDIRECT # corresponds to a HTTP 307
Este exemplo também altera o redirecionamento para um redirecionamento temporário, o que impede (como navegadores) armazenam os dados em cache. Isso pode ser útil se você espera alterá-la em um futuro próximo.
Os valores redirectResponseCode
compatíveis são mostrados na tabela a seguir.
Redirecionar o código de resposta | Código de status HTTP |
---|---|
MOVED_PERMANENTLY_DEFAULT |
HTTP 301 (movido permanentemente) |
FOUND |
HTTP 302 (encontrado) |
SEE_OTHER |
HTTP 303 (Consultar outro) |
TEMPORARY_REDIRECT |
HTTP 307 (redirecionamento temporário) |
PERMANENT_REDIRECT |
HTTP 308 (redirecionamento permanente) |
Observações:
- Uma rota pode direcionar o tráfego para uma origem ou retornar um redirecionamento para o
para o cliente. Não é possível definir
origin
eurlRedirect
ao mesmo tempo ao mesmo tempo. - As rotas que redirecionam para HTTPS exigem que pelo menos um certificado SSL seja anexado ao serviço.
Para mais detalhes, consulte a especificação da API para
RouteRule.UrlRedirect
Redirecionar todas as solicitações para HTTPS
Para redirecionar todas as solicitações para HTTPS (em vez de HTTP), configure cada um dos
seus serviços para redirecionar automaticamente todas as solicitações de clientes para HTTPS. Clientes
conectar por HTTP recebem uma resposta 301 (Permanent Redirect)
HTTP com o
Cabeçalho Location
definido como o mesmo URL usando "https://" em vez de "http://".
gcloud
gcloud edge-cache services update MY_SERVICE \ --require-tls
Request issued for: [MY_SERVICE] Updated service [MY_SERVICE].
O comando retorna uma descrição do serviço, com requireTls
definido.
para true
.
name: MY_SERVICE requireTls: true
Também é possível definir Strict-Transport-Security como cabeçalho de resposta para que clientes diretos sempre se conectem diretamente por HTTPS.
Usar back-ends de armazenamento de terceiros
O Media CDN oferece suporte à conexão com HTTP disponível endpoints fora do Google Cloud, incluindo buckets de armazenamento da AWS S3, Azure Blob Storage e outros provedores de armazenamento. Isso pode ser útil se você tiver um multicloud ou ainda não migraram dados para o Cloud Storage usando o Serviço de transferência do Cloud Storage.
Uma configuração mínima de origem que define uma bucket com hospedagem virtual no AWS S3:
name: MY_S3_ORIGIN originAddress: BUCKET-NAME.s3.REGION.amazonaws.com
Se você não usar um nome de bucket que corresponda aos nomes de host configurados para sua
EdgeCacheService
, também é necessário configurar uma regravação de host para rotas
associados a essa origem (ou origens). Caso contrário, o cabeçalho Host definido pela
solicitação do cliente é usado ao buscar da origem.
Por exemplo, se você quiser mapear todas as solicitações com um prefixo de caminho /legacy/
para sua
em um bucket externo, é possível configurar um hostRewrite
e um
pathPrefixRewrite
para remover esse prefixo da solicitação de origem:
routeRules: - description: legacy backend matchRules: - prefixMatch: "/legacy/" routeAction: urlRewrite: hostRewrite: BUCKET-NAME.s3.REGION.amazonaws.com pathPrefixRewrite: / cdnPolicy: cacheMode: CACHE_ALL_STATIC defaultTtl: 3600s
Para mais informações sobre como o cabeçalho do host é definido nas solicitações de origem, consulte os cabeçalhos da solicitação de origem; na documentação do Google Cloud.
Compartilhamento de recursos entre origens (CORS, na sigla em inglês)
O Compartilhamento de recursos entre origens
(CORS, na sigla em inglês) é uma abordagem centrada no navegador para fazer solicitações entre origens com segurança.
As políticas do CORS permitem que você defina automaticamente cabeçalhos CORS, como
Access-Control-Allow-Origins
, com base em uma política por rota.
Configurar o CORS
O Media CDN permite definir uma política de CORS em uma rota para um
EdgeCacheService
Uma política CORS define essas regras com um conjunto comum de cabeçalhos HTTP. Você pode
definir cabeçalhos CORS comuns em respostas, como
Access-Control-Allow-Origin
, Access-Control-Max-Age
.
e Access-Control-Allow-Headers
. Esses cabeçalhos permitem que você faça
chamadas de origem cruzada aos serviços do Media CDN que possam ser
hospedados em um domínio diferente (origem) do front-end do seu site e podem
evitar solicitações de origem cruzada que você não permite de forma explícita.
Por exemplo, player.example.com
e api.example.com
são origens diferentes
(no sentido do navegador), e talvez você queira que seu aplicativo de front-end
faça solicitações a api.example.com
para buscar a próxima lista de reprodução ou atualizar uma
listagem de conteúdo relacionado. Da mesma forma, player.example.com
pode precisar
Entre em contato com cdn.example.com
para buscar playlists de vídeo e segmentos de vídeo:
cdn.example.com
precisa indicar que está tudo certo e que
A player.example.com
é um allowed origin
, assim como qualquer outra regra
(cabeçalhos permitidos, se os cookies podem ser incluídos).
Para usar outro exemplo, se você quiser permitir stream.example.com
como origem
e um cabeçalho X-Client-ID
em solicitações CORS, é possível configurar corsPolicy
em uma
da seguinte forma:
corsPolicy: maxAge: 600 allowOrigins: ["stream.example.com"] allowHeaders: ["X-Client-ID"]
Um corsPolicy
é configurado em
routing.pathMatchers[].routeRules[].routeAction.corsPolicy
em um
EdgeCacheService. Cada routeRule
pode definir um corsPolicy
diferente conforme
necessárias ou nenhuma.
Se você definir um valor corsPolicy
e também um cabeçalho de resposta personalizado usando
usando os campos responseHeadersToAdd
em um trajeto com o mesmo nome, o
o cabeçalho de resposta personalizada tem precedência e é usado no lugar do
Valor de corsPolicy
.
Se a resposta de origem definir cabeçalhos HTTP e você tiver um valor corsPolicy
definido, os valores corsPolicy
serão usados. Os valores não estão recolhidos
ou combinados para evitar o envio de valores de cabeçalho inválidos a um cliente ou
configurar involuntariamente uma política mais permissiva do que o pretendido.
O {origin_request_header}
especial é preenchido com o cabeçalho HTTP Origin
na solicitação do cliente. Isso pode ser definido como um valor de cabeçalho de resposta personalizado em um
rota para o cabeçalho Access-Control-Allow-Origin
.
Para mais detalhes, consulte a API
especificação para
RouteAction.CORSPolicy
Campos da política de CORS
A tabela a seguir descreve os campos que uma política CORS contém.
Campo | Descrição | Exemplo |
---|---|---|
allowOrigins |
Define o cabeçalho de resposta
Por exemplo, se o conteúdo de vídeo for veiculado de
|
Access-Control-Allow-Origins: https://stream.example.com
|
maxAge |
Define o cabeçalho de resposta Alguns navegadores limitam isso a duas horas ou menos, mesmo se o valor máximo (86.400 s) é especificado. |
Access-Control-Max-Age: 7200
|
allowMethods |
Define o cabeçalho de resposta Por padrão, o Media CDN é compatível apenas com |
Access-Control-Allow-Methods: GET, OPTIONS, HEAD
|
allowHeaders |
Define o cabeçalho Isso geralmente é exigido por players de vídeo, que precisam acessar alguns cabeçalhos de resposta para conteúdo de vídeo ao solicitá-lo em origem cruzada. |
Access-Control-Allow-Headers: Content-Type, If-Modified-Since,
Range, User-Agent
|
exposeHeaders |
Define o cabeçalho de resposta Isso geralmente é exigido por players de vídeo, que talvez precisem acessar cabeçalhos de resposta específicos para conteúdo de vídeo ao solicitar conteúdo origem cruzada. |
Access-Control-Expose-Headers: Date, Cache-Status, Content-Type,
Content-Length
|
allowCredentials |
Define o cabeçalho de resposta Esse cabeçalho é omitido quando definido como falso. |
Access-Control-Allow-Credentials: true
|
disabled |
Desativa o corsPolicy sem removê-lo. Antes de um voo
Solicitações OPTIONS são encaminhadas para a origem.
|
N/A |
Exemplo de corsPolicy
O exemplo de configuração a seguir mostra uma configuração corsPolicy
básica:
routeRules: - priority: 1 matchRules: - prefixMatch: /stream/ routeAction: cdnPolicy: defaultTtl: 3600s corsPolicy: allowOrigins: - "https://stream.example.com" - "https://stream-staging.example.com" maxAge: 86400s # some browsers might only honor up to 7200s or less allowMethods: - "GET" - "HEAD" - "OPTIONS" allowHeaders: - "Content-Type" - "If-Modified-Since" - "Range" - "User-Agent" exposeHeaders: - "Content-Type" - "Content-Length" - "Date"
Resolver problemas de roteamento
Se algumas solicitações não recuperarem resultados correspondentes ou retornarem erros, verifique o seguintes:
- Um trajeto precisa ter um
matchRule
com exatamente um destesprefixMatch
.fullPathMatch
oupathTemplateMatch
definido. A API retornará um erro se não inclua um desses campos. - Verifique se o
priority
de cada trajeto está definido corretamente: mais específico rotas (mais longas) devem ter prioridade mais alta sobre rotas mais curtas e amplas correspondências de rota. - Por padrão, apenas as solicitações
GET
,HEAD
eOPTIONS
são aceitas. Para configurar a compatibilidade com outros métodos, consulte Métodos de rota. Os métodos que não estão ativados para uma rota específica são rejeitados com um erro HTTP405 (Method Not Allowed)
. - As solicitações HTTP
GET
com corpo ou qualquer solicitação com trailers são rejeitadas com um erro HTTP400
, porque os corpos das solicitações não são permitidos emGET
. solicitações. - O parâmetro de consulta e a correspondência de cabeçalho têm um "AND" lógico—a solicitação deve corresponder a todas as chaves de cabeçalho ou parâmetro de consulta (e valores, se especificados) para corresponder à rota especificada.
A seguir
- Analise a documentação sobre como configurar o armazenamento em cache.
- Entenda como se conectar a diferentes origens.
- Configure os certificados TLS (SSL) dos serviço.
- configurar solicitações assinadas para autenticação; acesso ao conteúdo.