Cloudflare libera Origin Range Requests para arquivos grandes sem ajuste de faixa
Recurso de cache da Cloudflare entrega pedaços de arquivos grandes sem calibrar faixa de bytes; no R2, latência p99 caiu cerca de metade.
Foto: Nothing Ahead (Pexels)
A Cloudflare liberou nesta sexta-feira (23) o Origin Range Requests, recurso de cache que entrega pedaços de arquivos grandes sem exigir que o cliente escolha o tamanho das faixas de bytes. A função, descrita no blog da empresa, passa a estar disponível em autosserviço em todos os planos, ativada por uma regra de Cache.
O anúncio responde a um gargalo clássico de redes de distribuição de conteúdo (CDN): quando um player pede poucos megabytes no meio de um filme, a implementação antiga podia puxar dezenas ou centenas de mebibytes da origem e espalhá-los entre data centers — às vezes depois que o espectador já tinha saído.
O que aconteceu
Segundo o post assinado por Matthew Gumport, pedidos HTTP com cabeçalho Range pedem só parte de um recurso, e o servidor responde com status 206 Partial Content e Content-Range. O padrão é comum em vídeo com seek, downloads retomáveis, gerenciadores de pacotes e leitura do fim de um arquivo sem baixar tudo.
A Cloudflare já suportava cache de ranges com configuração estática por zona, mapeando cada pedido a faixas de tamanho fixo escolhido pelo cliente. Faixas pequenas geravam muitas requisições à origem e pressão de memória; faixas grandes faziam a rede baixar muito mais do que o pedido. Mudar o tamanho invalidava entradas de cache, porque esse valor entrava na chave. Pedidos na mesma faixa podiam bloquear uns aos outros, e o cache em nginx não combinava bem ranges com streaming concorrente.
A migração para um servidor baseado em Pingora permitiu redesenhar o fluxo. Como o Pingora já guarda arquivos em pedaços fixos no disco, o tamanho da faixa deixa de ser ajuste do cliente e passa a ser o próprio chunk do cache. O edge serve bytes já cacheados, busca na origem o que falta em faixas alinhadas aos chunks e devolve ao cliente só o intervalo pedido. Um coordenador monta a resposta a partir de disco, downloads em andamento e novas buscas; se um download já cobre bytes de outro pedido, o segundo pode se anexar a ele. Antes de compor, valida-se a mesma representação e o If-Range; quando o range não é seguro, devolve-se o arquivo completo.
Antes de abrir o recurso a todos, a empresa migrou usuários da implementação antiga. No R2, armazenamento de objetos da Cloudflare, o tamanho configurado era de 64 MiB; uma leitura pequena que cruzasse o limite podia custar 128 MiB entre data centers. Depois da mudança, o tempo até o primeiro byte no percentil 99 caiu cerca de metade em acertos e erros de cache. Um ajuste seguinte misturou bytes já em disco com bytes do upstream numa só resposta; o tráfego de cache em camadas para o R2 e cargas parecidas caiu cerca de 6% semana a semana — petabytes a menos entre data centers por dia, segundo a companhia.
Para ligar o recurso, basta criar uma Cache Rule no painel ou via API com origin_range_requests no modo on. A origem precisa aceitar byte ranges. Ativar o recurso não torna cacheável o que antes não era.
O que isso pode mudar
Se a adoção acompanhar a intenção da Cloudflare de tornar esse o caminho padrão para certos tipos de arquivo — ainda ajustável por regras de cache —, operadores de vídeo seekable em MP4, repositórios de software, imagens de disco e cargas de inteligência artificial que movem modelos grandes podem reduzir idas à origem e tráfego interno sem calibrar faixas à mão.
A hipótese é que seeks e retomadas fiquem mais ágeis e que a conta de banda entre origem e CDN fique mais previsível. O ganho depende de origem compatível com ranges e de conteúdo elegível a cache; pedidos menores que o chunk ainda podem puxar o pedaço inteiro, e ranges desalinhados geram trabalho extra — agora limitado e previsível, mas não zero.
Fontes: Cloudflare Blog
Leia mais em: www.mundodosnegocio.com.br