Configure rotas de serviço

A RFC de multimédia oferece capacidades de encaminhamento HTTP avançadas que lhe permitem mapear o tráfego para configurações e origens específicas na extremidade da rede a um nível detalhado.

Configure uma regra de trajeto

Configure uma regra de encaminhamento para um serviço de RFC de conteúdo multimédia.

Pedidos de correspondência

Uma configuração da RFC de multimédia contém um conjunto de rotas definidas na secção Routing para um recurso EdgeCacheService. Estas rotas fazem corresponder pedidos com base (pelo menos) num anfitrião. Para mais detalhes sobre como o tráfego é direcionado para uma origem, consulte os artigos HostRule e PathMatcher. Cada rota pode definir a sua própria configuração de RFC, reescritas, redirecionamentos, políticas de CORS, cabeçalhos HTTP personalizados e mapeamento de origem. Os trajetos podem partilhar origens.

Por exemplo, pode encaminhar pedidos de manifestos para uma origem específica e definir um TTL da cache de curta duração e uma política de colocação em cache negativa. Os pedidos de segmentos podem ser divididos para outra origem através de cabeçalhos e parâmetros de consulta para discriminar tipos de manifestos ou utilizadores específicos.

O exemplo seguinte mostra como encaminhar pedidos que correspondem a um cabeçalho específico, a um parâmetro de consulta e a um prefixo do caminho para o anfitrião 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 caminhos

A RFC é compatível com a correspondência de caminhos completa (exata), de prefixos e de carateres universais. A correspondência de caminhos pode ser combinada com a correspondência baseada em anfitriões, cabeçalhos e parâmetros de consulta para criar regras de encaminhamento de pedidos detalhadas.

Seguem-se três formas de fazer a correspondência com um caminho de URL.

Para mais detalhes, consulte a especificação da API para MatchRule.

Por exemplo, para fazer corresponder todos os pedidos que começam por /stream/, crie uma regra de encaminhamento semelhante à seguinte:

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 invertida final na regra de correspondência:

• Um pedido para media.example.com/stream/id/1234/hls/manifest.m3u8 corresponde a este trajeto.
• Um pedido para media.example.com/stream-eu/id/4567/hls/manifest.m3u8 não corresponde a este trajeto.

No segundo caso, a RFC devolve um erro HTTP 404, a menos que exista outra rota ou uma rota genérica configurada.

Para orientações sobre como a precedência funciona para rotas com prefixos semelhantes, consulte a secção Prioridade e ordenação de rotas.

Correspondência de padrões (caracteres universais)

A correspondência de padrões permite-lhe fazer corresponder várias partes de um URL, incluindo URLs parciais e sufixos (extensões de ficheiros), através da sintaxe de carateres universais.

Também pode associar um ou mais segmentos do caminho a variáveis com nomes num campo pathTemplateMatch e, em seguida, referir-se a essas variáveis ao reescrever o URL num campo pathTemplateRewrite. Isto permite-lhe reordenar e remover segmentos de URL antes de o pedido ser enviado para a sua origem.

O exemplo seguinte mostra como pode fazer a correspondência com 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 suportada inclui o seguinte.

Notas:

• Se não estiver a reescrever um URL, use os operadores mais simples * e **.
• Quando usa variáveis para capturar segmentos de caminho, não é possível fazer referência a nenhuma parte do URL que não seja capturada por uma variável num pathTemplateRewrite subsequente. Para ver um exemplo, consulte a secção Capturar variáveis de caminho.
• Não pode fazer referência a variáveis num pathTemplateRewrite subsequente que não existam no pathTemplateMatch no mesmo trajeto.
• As variáveis são sensíveis a maiúsculas e minúsculas, com {FORMAT}, {forMAT} e {format} a representar diferentes variáveis e valores.
• Pode especificar até 10 operadores (caracteres universais ou variáveis) numa correspondência. Os campos pathTemplateMatch e pathTemplateRewrite não podem exceder os 255 carateres.

Exemplo: fazer correspondência com uma extensão de ficheiro

O exemplo seguinte mostra um exemplo de utilização comum para operadores de carateres universais: estabelecer correspondência com todos os segmentos do caminho até um sufixo.

Neste caso, faça o seguinte:

• Obter manifestos de vídeo (playlists) que terminam em .m3u8 e .mpd da origem do manifesto, aplicando um TTL curto (5 segundos) a estas respostas porque mudam regularmente.
• Obter segmentos de vídeo que terminam em .ts e .m4s a partir da origem do segmento e aplicar um TTL mais longo (1 dia) a estas respostas.

Esta abordagem é frequentemente usada quando se usam serviços de SSAI (inserção de anúncios do lado do servidor) ou DAI (inserção de anúncios dinâmicos) e para vídeo em direto em que o manifesto é atualizado a cada poucos segundos.

A configuração seguinte demonstra como configurar o encaminhamento da RFC para suportar esta funcionalidade:

name: prod-service
routing:
  hostRules:
  - hosts:
    - media.example.com
    pathMatcher: example_routes
  pathMatchers:
  - name: