Cloudflare lanza Origin Range Requests sin ajustes

Una petición de un reproductor de video que salta al minuto 40 de una película puede obligar a una CDN a descargar 128 MiB desde el origen para entregar apenas unos megabytes. Cloudflare acaba de abrir Origin Range Requests, una función self-service disponible en todos los planes que elimina el ajuste de tamaño de rango y que, según la compañía, redujo aproximadamente a la mitad el p99 de tiempo hasta el primer byte (TTFB) en R2, su almacenamiento de objetos.

Para cualquier startup que sirva video, binarios o pesos de modelos de IA, el cambio importa por una razón simple: el rendimiento de los archivos grandes dejó de depender de una configuración que casi nadie sabía calibrar.

¿Qué es una range request y por qué debería importarte?

Una range request es una petición HTTP que pide solo una parte de un archivo en lugar del archivo completo. El cliente envía un GET normal con la cabecera Range y, si el servidor la soporta, responde 206 Partial Content con la cabecera Content-Range que identifica los bytes devueltos.

Es el mecanismo detrás de cosas cotidianas: un reproductor de video pide los bytes alrededor del punto donde el usuario hizo seek, un gestor de descargas retoma un archivo interrumpido, un gestor de paquetes baja solo una parte de un artefacto, y un cliente puede inspeccionar el final de un archivo sin descargar todo lo anterior.

El cliente decide si pide un rango y Cloudflare no cambia esa petición. Lo que cambió es cómo la satisface.

El problema: el tamaño del rango era un ajuste imposible de acertar

Cloudflare soportaba caché de range requests desde hace años mediante configuración estática de zona. Cada petición de cliente se mapeaba a rangos de tamaño fijo del archivo, con el tamaño y las extensiones configurados por zona. Ese diseño se parecía al cache slicing descrito en un post de nginx.

El tamaño del rango creaba un trade-off sin salida: rangos pequeños generaban muchísimas peticiones pequeñas al origen y presión de memoria por el coalescing en memoria, mientras que rangos grandes hacían que Cloudflare descargara mucho más de lo que el cliente pidió. Y como el tamaño formaba parte de la cache key, cambiarlo invalidaba las entradas.

Había más problemas. Peticiones concurrentes que caían dentro del mismo rango podían bloquearse entre sí, sin importar cuán lejos estuviera el rango pedido por cada cliente. La caché basada en nginx tampoco podía combinar range caching con streaming concurrente, la función que permite a varios clientes leer un archivo desde caché mientras se sigue escribiendo: al activar ambas, las respuestas se cortaban, y los archivos populares necesitaban un fetch al origen por cada rango.

Los bytes extra además cruzaban varias capas de la caché distribuida: del origen a un data center, entre tiers de caché y hacia el cliente. Cada salto multiplicaba el desperdicio.

Cómo funciona ahora: chunks fijos y un coordinador

La solución vino de algo que Pingora ya hacía. Para facilitar la reanudación de descargas interrumpidas, Pingora guarda cada archivo cacheado en disco en chunks de tamaño fijo. Si la caché ya piensa en chunks, el tamaño del rango no necesita ser un ajuste: es el chunk. Vale la pena recordar que Pingora es el componente que ejecuta las búsquedas en caché o va al origen dentro del proxy central de Cloudflare, según NetworkWorld.

Ante una range request, Cloudflare revisa qué bytes pedidos ya están en caché y los sirve directamente. Para los que faltan, va al origen con rangos alineados a los límites de esos chunks, guarda el resultado en los mismos chunks que usa el almacenamiento normal y devuelve únicamente los bytes que el cliente pidió. Una petición de los bytes 150-250 puede provocar la descarga del chunk alineado que los contiene, pero la respuesta downstream sigue conteniendo solo 150-250.

Esto no elimina el trabajo extra para peticiones más chicas que el chunk, y Cloudflare asume más trabajo en rangos no alineados. La diferencia es que ese trabajo es acotado y predecible, y ya no depende de un ajuste elegido por el cliente que podía tener efectos impredecibles sobre la red y sobre los orígenes.

Lo difícil no es parsear la cabecera Range, sino producir una respuesta correcta cuando los bytes pedidos están repartidos entre datos cacheados, una respuesta del origen y descargas en curso. El edge funciona como coordinador: busca los headers y la metadata de cobertura de rangos, lee lo que puede de disco o de streaming en memoria, pide al origen lo que falta con rangos alineados, escribe los bytes nuevos y registra el rango completado, y combina las piezas fijando Content-Range y Content-Length.

Si una descarga en curso ya cubre los bytes que pide otra petición, la segunda se engancha a esa descarga en lugar de iniciar otra al origen. Eso comparte trabajo durante los picos de archivos grandes populares.

Antes de componer, el sistema valida: cada respuesta del origen debe corresponder al rango pedido, el tamaño total del asset debe ser estable y el entity tag consistente entre subpeticiones. La cabecera If-Range permite pedir un rango solo si la representación sigue coincidiendo con un validador conocido; si no coincide, Cloudflare devuelve la representación completa en lugar de mezclar bytes de versiones distintas. También evita componer rangos de una representación que está por descomprimir. El resultado es HTTP estándar: 206 para rangos satisfacibles, 416 Range Not Satisfiable para los que no, y representación completa cuando no se puede servir un rango con seguridad.

Qué cambió en producción: los números de R2

R2, el almacenamiento de objetos de Cloudflare, fue el mayor usuario interno de la función. Su tamaño de rango configurado era de 64 MiB, así que una lectura pequeña que cruzara un límite de rango podía costar 128 MiB de transferencia entre data centers. En el sistema anterior los tamaños configurados iban de decenas de kilobytes a decenas de gigabytes, y ambos extremos causaron incidentes operativos reales.

Tras migrar R2 a la nueva implementación, Cloudflare reporta dos resultados concretos:

• p99 de tiempo hasta el primer byte reducido aproximadamente a la mitad en todas las regiones de almacenamiento de R2, tanto en cache hits como en cache misses.
• Tráfico de tiered cache para R2 y cargas similares con una caída de cerca del 6% semana contra semana, equivalente a petabytes menos de datos moviéndose entre data centers cada día. Ese cambio vino de enseñar al coordinador a combinar bytes ya en disco con bytes traídos de upstream en una sola respuesta; antes, una petición se servía enteramente desde caché o enteramente desde upstream.

Para dimensionar la escala: según InfoQ, la red de Cloudflare opera en más de 335 ciudades y R2 ofrece once nueves de durabilidad con APIs fuertemente consistentes. En ese orden de magnitud, un 6% de tráfico entre data centers deja de ser una optimización cosmética.

¿Para qué tráfico conviene activarlo?

Origin Range Requests está pensado para tráfico donde los clientes piden naturalmente partes de un objeto grande y cacheable:

• Video progresivo y con seek, como MP4
• Descargas grandes reanudables
• Distribución de software y repositorios de paquetes
• Imágenes de disco, archivos comprimidos y objetos de varios gigabytes
• Cargas de entrenamiento e inferencia de IA que transfieren archivos de modelo grandes o piden regiones específicas de un artefacto
• Clientes que buscan metadata o una región pequeña de un archivo mayor

Cloudflare dice que su intención es que esta sea la forma por defecto en que ciertos tipos de archivo se sirven en su red, modificable por cache rules. Dos advertencias: la función no cambia la elegibilidad de caché, es decir, activarla no vuelve cacheable una respuesta que no lo era, y el origen debe soportar byte ranges para que los fetches parciales sirvan de algo.

¿Qué significa esto para tu startup?

Si tu producto entrega archivos grandes, esta es una de esas mejoras de infraestructura que llegan sin que tengas que reescribir tu backend. Pero conviene aprovecharla con criterio.

• Audita qué tráfico tuyo es de archivos grandes. Si sirves MP4, instaladores, imágenes de disco o pesos de modelos detrás de Cloudflare, crea una Cache Rule que matchee ese tráfico y activa Origin Range Requests. No hay tamaño de rango que calibrar ni ticket de soporte que abrir.
• Verifica que tu origen soporte byte ranges. Si tu servidor no responde a la cabecera Range con un 206 y un Content-Range correcto, la función no puede hacer fetches parciales y el beneficio se pierde. Es un chequeo de cinco minutos que evita una activación inútil.
• Instrumenta antes y después. TTFB p99 y bytes de egress son las dos métricas que Cloudflare reporta como mejoradas. Toma una línea base de ambas antes de activar para poder atribuir el cambio.
• Cuidado con la compresión on-the-fly. Cloudflare evita componer rangos sobre una representación que está por descomprimir y sirve la respuesta completa transformada. Si tu caso de uso depende de rangos, sirve el archivo sin transformar.
• Mira la factura, no solo la latencia. Menos bytes movidos entre data centers y menos transferencia desde el origen se traducen en costo. Si pagas egress de tu storage, este es el tipo de cambio que se ve en el cierre de mes.

Conclusión

El aprendizaje de fondo va más allá de una feature de Cloudflare: cuando un ajuste obliga al cliente a entender la arquitectura interna del proveedor para no romper nada, el problema no es del cliente. Cloudflare tardó una migración completa de nginx a Pingora para poder eliminar ese ajuste y reemplazarlo por algo que ya existía en su propia caché.

Para un founder, la lección práctica es doble. Primero, revisa si tu stack tiene ajustes heredados que solo una persona del equipo sabe tocar: suelen esconder deuda operativa. Segundo, si sirves archivos grandes, activa la función y mide. La mitad de latencia en el p99 y un 6% menos de tráfico entre data centers son mejoras que no requieren una línea de código de tu parte.

Fuentes

• Origin Range Requests: Serving large files without range-request tuning (fuente original)
• Cloudflare K2 Builds Event Streams on R2 Object Storage
• How a bot management file push crippled Cloudflare's global network