Ative a compressão dinâmica

A compressão dinâmica comprime automaticamente as respostas publicadas pela RFC. O tamanho dos dados enviados através da rede é reduzido entre 60% e 85% nos casos típicos.

A redução do tamanho acelera a transferência de recursos importantes, como folhas de estilos (CSS), scripts (JavaScript) e manifestos de vídeo (HLS/DASH), o que pode reduzir significativamente os tempos de carregamento de páginas e de início de vídeos.

As playlists de vídeo em direto grandes (manifestos) têm uma quantidade significativa de dados e obtenções repetidos, incluindo o prefixo do anfitrião e do caminho de cada segmento, bem como os metadados da playlist HLS ou DASH. Quanto mais rapidamente a playlist for carregada ou as atualizações da playlist puderem ser transferidas, menos tempo um cliente tem de esperar para analisar e começar a transferir os segmentos de vídeo referenciados. As playlists HLS e DASH sofrem frequentemente uma redução total do tamanho superior a 90%.

Para mais informações sobre as vantagens da compressão de respostas, consulte o guia Web Fundamentals.

Como funciona a compressão dinâmica

Quando a compressão dinâmica está ativada, o conteúdo compressível publicado a partir da origem pode ser comprimido antes de ser enviado se o cliente aceitar um dos algoritmos de compressão suportados (br ou gzip).

A RFC de multimédia adiciona um cabeçalho Vary: Accept-Encoding a todas as respostas elegíveis para compressão. Para informações relacionadas, consulte o artigo Conteúdo não comprimível.

Além disso, se o cabeçalho Accept-Encoding do pedido indicar uma preferência por conteúdo comprimido especificando br ou gzip (e, opcionalmente, incluindo um parâmetro q diferente de zero), a RFC de multimédia faz o seguinte:

  • Remove o cabeçalho Content-Length da resposta. Isto é necessário para permitir que a resposta seja publicada o mais rapidamente possível, porque o comprimento total do conteúdo é desconhecido até que toda a resposta tenha sido comprimida. Para HTTP/1.1 e versões anteriores, a RFC de multimédia usa Transfer-Encoding: chunked na resposta quando não usa Content-Length.

    Depois de uma resposta ser comprimida e colocada em cache, a RFC pode incluir o cabeçalho Content-Length nas respostas subsequentes e definir o valor para o comprimento do conteúdo do corpo comprimido.

  • Define Accept-Ranges como none. Isto informa os clientes de que os pedidos de intervalo para este recurso são ignorados.

  • Enfraquece todos os cabeçalhos de resposta ETag fortes, conforme exigido pela secção 8.8.3 da RFC 9110. Por exemplo, ETag: "xyzzy" é substituído por ETag: W/"xyzzy".

  • Define o cabeçalho Content-Encoding como br ou gzip, o que significa o algoritmo de compressão escolhido.

    A RFC 7230 define o cabeçalho Content-Encoding como a forma de compressão usada para transmitir o recurso. O Media CDN escolhe o melhor algoritmo de compressão com base na taxa de compressão prevista da resposta e na velocidade de compressão ou no débito.

    • A compressão Brotli é usada se o cliente a suportar, mesmo que outros algoritmos de compressão tenham valores q mais elevados no cabeçalho Accept-Encoding.

    • Os manifestos HLS são comprimidos apenas com gzip.

    A RFC determina o nível de compressão para equilibrar o tamanho total da transferência e o custo da CPU no cliente. Os níveis de compressão mais elevados nem sempre beneficiam o desempenho, especialmente em dispositivos móveis com menor potência.

Configure a compressão dinâmica

Pode ativar a compressão dinâmica em rotas que atendem pedidos.

Antes de começar

Faça o seguinte:

Ative a compressão dinâmica para uma regra de encaminhamento

Por predefinição, o modo de compressão de uma regra de encaminhamento está desativado.

Se definir o modo como automático, ativa a compressão dinâmica para todas as respostas elegíveis. Além disso, indica à RFC para escolher automaticamente o melhor algoritmo de compressão.

Para ativar a compressão dinâmica, faça o seguinte:

Consola

  1. Na Google Cloud consola, aceda à página RFC de multimédia.

    Aceda à RFC de multimédia

  2. Para abrir a página Detalhes do serviço para o qual quer configurar uma regra de encaminhamento, clique no nome do serviço.

  3. Para mudar para o modo de edição, clique no botão Editar.

  4. Para navegar para a secção Encaminhamento, clique em Seguinte.

  5. Para editar uma regra de anfitrião, clique na seta para a expandir.

  6. Para editar uma regra de encaminhamento, clique em Editar na linha respetiva.

  7. No painel Editar regra de encaminhamento, clique em Configurações avançadas.

  8. Opcional: para a ação Route, adicione um item Política de RFC.

    Uma política da RFC permite que a RFC de multimédia comprima o conteúdo uma vez e o forneça várias vezes, o que poupa largura de banda e acelera o fornecimento.

  9. Na secção Compressão dinâmica, selecione Ativar compressão.

  10. Para guardar a regra de encaminhamento, clique em Guardar.

  11. Para guardar as alterações ao serviço, clique em Atualizar serviço.

gcloud e YAML

  1. Exporte a configuração da RFC de conteúdo multimédia para um ficheiro YAML. Use o comando gcloud edge-cache services export.

    gcloud edge-cache services export SERVICE_NAME \
    --destination=FILENAME.yaml

    Substitua o seguinte:

    • SERVICE_NAME: o nome do seu serviço
    • FILENAME : o nome do seu ficheiro YAML

  2. Na definição do trajeto no ficheiro YAML, em routeAction, defina compressionMode como AUTOMATIC, conforme mostrado no exemplo seguinte:

    routing:
hostRules:
- hosts:
  - media.example.com
  pathMatcher: routes
pathMatchers:
- name: routes
  routeRules:
    - priority: 2
origin: origin1
matchRules:
- pathTemplateMatch: "/**.m3u8" # HLS playlists
- pathTemplateMatch: "/**.mpd" # DASH manifests
routeAction:
  cdnPolicy:
    defaultTtl: 5s
  compressionMode: AUTOMATIC

  3. Para atualizar o serviço, importe a configuração da RFC de multimédia a partir do ficheiro YAML. Use o comando gcloud edge-cache services import.

    gcloud edge-cache services import SERVICE_NAME \
    --source=FILENAME.yaml

Terraform

O seguinte fragmento do Terraform mostra uma regra de encaminhamento com a compressão dinâmica ativada.

route_rule {
  description = "a route rule with dynamic compression, priority=2 (high)"
  priority    = 2
  match_rule {
    path_template_match = "/**.m3u8" # HLS playlists
  }
  match_rule {
    path_template_match = "/**.mpd" # DASH manifests
  }
  origin = google_network_services_edge_cache_origin.default.name
  route_action {
    cdn_policy {
      cache_mode = "FORCE_CACHE_ALL"
      client_ttl = "300s"
    }
    compression_mode = "AUTOMATIC"
  }
  header_action {
    response_header_to_add {
      header_name  = "x-cache-status"
      header_value = "{cdn_cache_status}"
    }
  }
}

A sua configuração é propagada rapidamente para todas as localizações periféricas.

Quando a compressão dinâmica está ativada para uma rota e a nova configuração entra em vigor nas máquinas de produção, a RFC de conteúdo multimédia começa a comprimir as respostas elegíveis, mesmo que existam versões em cache não comprimidas. Enquanto a rede de CDN de multimédia obtém e comprime novo conteúdo, pode haver um aumento temporário no tráfego para a sua origem.

Desative a compressão dinâmica para uma regra de encaminhamento

Para desativar a compressão dinâmica, faça o seguinte:

Consola

  1. Na Google Cloud consola, aceda à página RFC de multimédia.

    Aceda à RFC de multimédia

  2. Para abrir a página Detalhes do serviço para o qual quer configurar a regra de encaminhamento, clique no nome do serviço.

  3. Para mudar para o modo de edição, clique no botão Editar.

  4. Para navegar para a secção Encaminhamento, clique em Seguinte.

  5. Para editar uma regra de anfitrião, clique na seta para a expandir.

  6. Para editar uma regra de encaminhamento, clique em Editar na linha respetiva.

  7. No painel Editar regra de encaminhamento, clique em Configurações avançadas.

  8. Na secção Compressão dinâmica, desmarque a opção Ativar compressão.

  9. Para guardar a regra de encaminhamento, clique em Guardar.

  10. Para guardar as alterações ao serviço, clique em Atualizar serviço.

gcloud e YAML

  1. Exporte a configuração da RFC de conteúdo multimédia para um ficheiro YAML. Use o comando gcloud edge-cache services export.

    gcloud edge-cache services export SERVICE_NAME \
    --destination=FILENAME.yaml

    Substitua o seguinte:

    • SERVICE_NAME: o nome do seu serviço
    • FILENAME : o nome do seu ficheiro YAML

  2. Na definição do trajeto no ficheiro YAML, defina compressionMode como DISABLED.

  3. Para atualizar o serviço, importe a configuração da RFC de multimédia a partir do ficheiro YAML. Use o comando gcloud edge-cache services import.

    gcloud edge-cache services import SERVICE_NAME \
    --source=FILENAME.yaml

Se tiver problemas com a compressão dinâmica para um trajeto específico, como problemas de compatibilidade com determinados clientes (por exemplo, smart TVs ou dispositivos de streaming), para impedir que a rede CDN de multimédia forneça conteúdo comprimido nesse trajeto, desative a compressão dinâmica.

A desativação da compressão dinâmica para uma rota faz com que a RFC de multimédia deixe de publicar conteúdo comprimido a partir da cache. Todas as respostas comprimidas em cache anteriormente tornam-se inválidas e a RFC obtém versões não comprimidas da sua origem.

Tipos de conteúdo compressíveis

A compressão dinâmica aplica-se aos seguintes tipos MIME, com base no cabeçalho de resposta HTTP Content-Type. As respostas que não têm um cabeçalho Content-Type não são comprimidas.

Os tipos de conteúdo comuns e os respetivos tipos MIME incluem o seguinte:

  • Conteúdo HTML: text/html
  • Folhas de estilos: text/css
  • JavaScript: application/javascript
  • JSON: application/json
  • Playlists HLS: application/x-mpegURL ou application/vnd.apple.mpegURL
  • Manifestos DASH: application/dash+xml

A tabela seguinte resume a forma como o tipo MIME afeta a compressibilidade.

  Tipos MIME compressíveis
Correspondência exata application/csv
application/javascript
application/json
application/json+protobuf
application/signed-exchange
application/wasm
application/x-javascript
application/x-nacl
application/x-plist
application/x-pnacl
application/x-protobuf
application/x-protobuffer
application/x-sdch-dictionary
application/xml
audio/mpegURL
font/eot
font/otf
font/ttf
image/pwg-raster
image/svg+xml
image/vnd.microsoft.icon
image/x-icon
video/vnd.mpeg.dash.mpd
Correspondência de padrões application/*+json
application/*+xml
application/*mpegURL
text/*

Os formatos de imagem e vídeo (como image/jpeg, image/png e video/mpeg4) estão quase sempre comprimidos. Assim, a RFC de multimédia na nuvem não os comprime. A recompressão de uma resposta já comprimida raramente reduz o tamanho do ficheiro, e os clientes podem apresentar um comportamento inesperado quando recebem uma resposta deste tipo.

Respostas não comprimíveis

A RFC de multimédia não comprime uma resposta que tenha uma ou mais das seguintes características:

  • A resposta não tem um cabeçalho Content-Type que corresponda a um tipo de conteúdo comprimível.
  • A resposta não tem um cabeçalho Content-Length.
  • A resposta tem um cabeçalho Content-Encoding. Isto implica que a origem já comprimiu a resposta. Por isso, a RFC de multimédia não pode fazer nenhuma compressão dinâmica adicional.

  • A resposta tem menos de 1 KiB.

    O tempo gasto na compressão e descompressão compensa frequentemente quaisquer vantagens. Também existe menos conteúdo para comprimir, o que pode reduzir a eficácia da compressão e originar uma taxa de compressão mais baixa.

  • A resposta tem mais de 1 MiB.

    A RFC 7233 define o intervalo de bytes como um intervalo de bytes específico num recurso. O CDN de multimédia comprime as respostas até ao tamanho permitido para objetos de colocação em cache sem colocação em cache de intervalo de bytes.

  • A resposta tem um cabeçalho Cache-Control: no-transform.

  • A resposta tem um cabeçalho Vary: Accept-Encoding, o que implica que a compressão dinâmica não é necessária porque a origem pode comprimir a resposta.

Registo e monitorização

Quando a compressão está ativada, a métrica https/response_bytes_count existente em edgecache.googleapis.com/EdgeCacheRouteRule indica o tamanho da resposta comprimido. Pode esperar uma diminuição no total de bytes de resposta e na taxa de transferência de dados de saída para conteúdo comprimível.

Os registos da RFC de multimédia incluem um campo compressionAlgorithmApplied no jsonPayload, que indica se a resposta foi comprimida pelo balanceador de carga, bem como o tipo de compressão.

{
  insertId: "1c02hw9g3gjay67"
  jsonPayload: {
    @type: "type.googleapis.com/google.cloud.edgecache.v1.EdgeCacheLogEntry",
    cacheId: "IAD-862d661f",
    cacheStatus": "hit,stale",
    compressionAlgorithmApplied: "br"
  },
}

Faturação

Quando uma resposta é comprimida pela rede CDN de multimédia, as taxas de transferência de dados de Internet ou de cache de saída relevantes baseiam-se nos bytes comprimidos finais enviados para o cliente.

Se estiver a publicar uma grande quantidade de respostas comprimíveis, isto pode resultar numa redução das taxas de transferência de dados de saída mensais, bem como num aumento do desempenho para os utilizadores finais.

O que se segue?