Cloudflare ha culminado uno de sus rediseños más profundos desde su nacimiento: FL2, una nueva implementación del “cerebro” que orquesta seguridad y rendimiento en su red global. Construido en Rust sobre el framework interno Oxy, FL2 sustituye progresivamente al histórico FL1 (NGINX/OpenResty/LuaJIT) y ya está ofreciendo –10 ms en la mediana de respuesta y un +25 % en pruebas de rendimiento independientes. Además, reduce a menos de la mitad el consumo de CPU y memoria, endurece la seguridad por diseño y acorta el tiempo de lanzamiento de nuevas funciones.
En paralelo, la compañía actualizó su radiografía de velocidad: hoy afirma ser la red más rápida en el 48 % de las 1.000 principales redes “eyeball” (operadores con mayor base de usuarios) entre noviembre de 2024 y marzo de 2025, frente al 44 % del periodo anterior. El salto se nota especialmente en África —gracias a despliegues Edge Partner en la última milla— y en mercados como Japón, donde la distancia con el segundo proveedor ya es de >5 % en p95 de conexión TCP. En Canadá, la carrera está en foto finish, con diferencias de apenas ~1 ms entre los tres primeros.
Por qué reescribir el “cerebro” de la red
Durante 15 años, FL1 acumuló lógica de seguridad y aceleración (WAF, DDoS, reglas, routing a Workers y R2…). Aquella flexibilidad tuvo costes crecientes: acoplamientos complejos, latencia incremental al añadir productos y mantenimiento delicado por bugs sutiles de LuaJIT. El diagnóstico fue claro: para sostener nuevos productos sin pagar peaje de latencia por cada novedad, hacía falta repensar la base.
FL2: Rust + Oxy + módulos con contratos estrictos
Rust en el núcleo. Rust aporta seguridad de memoria y rendimiento cercano a C, con chequeos en compilación que eliminan clases enteras de fallos (desbordamientos, data races). Sobre esa base, Oxy —el marco interno de proxies de alto rendimiento— aporta “plomería” reutilizable: telemetría, recarga suave, configuración dinámica y extensibilidad de L3 a L7.
Arquitectura modular. Toda la lógica de producto vive en módulos con fases definidas, entradas/salidas tipadas y una regla de oro: los módulos no realizan E/S directa. Si un módulo necesita la salida de otro, lo declara explícitamente. El compilador valida los contratos y evita dependencias implícitas. Resultado: menos trabajo innecesario, menos latencia y menos regresiones al introducir un producto nuevo.
Filtros por petición. Cada módulo define filtros para decidir cuándo se ejecuta. El sistema selecciona solo lo imprescindible en cada solicitud, eliminando el “coste fijo” por producto que lastraba a FL1.
Reinicios sin cortes. Con Oxy y systemd socket activation, las actualizaciones se despliegan sin romper WebSockets, streams ni APIs en tiempo real: el proceso nuevo arranca, el antiguo deja de aceptar conexiones pero sigue atendiendo las existentes hasta que terminen de forma natural.
Migrar sin parar: Rust dentro de FL1, testing masivo y fallbacks
- Módulos Rust en FL1. Para no mantener dos versiones por producto, Cloudflare permitió ejecutar módulos Rust dentro de OpenResty. Así los equipos migraron lógica sin frenar entregas.
- Pruebas end-to-end a escala. El sistema Flamingo lanza miles de pruebas concurrentes contra preprod y prod, comparando FL1 vs FL2 en comportamiento, uso de recursos y SLIs. Los rollouts por etapas se pausan o revierten de forma automática si algo no cuadra.
- Válvula de seguridad. Si FL2 recibe algo que aún no maneja, cede el flujo a FL1 (fallback a nivel de red). Esto reduce riesgo mientras crece el porcentaje de tráfico en FL2 y permite comparar salidas para asegurar equivalencia funcional.
Hoy, la mayoría de clientes ya se sirven con FL2. Falta completar la reescritura del servicio de terminación HTTP/TLS (aún en NGINX), que llegará en 2026 junto al apagado definitivo de FL1.
Qué significan los números (más allá de la métrica)
- –10 ms en la mediana y picos recortados en p95/p99 se traducen en mejor conversión en ecommerce, menos abandono en medios y menor jank en apps en tiempo real.
- < ½ CPU y memoria liberan margen para nuevas funciones (más inspección, más reglas, más Workers) sin penalizar latencia.
- Ciclos de entrega de 48 h (antes semanas) permiten responder a clientes estratégicos y ajustar producto a mercado sin fricción organizativa.
Dónde se gana velocidad de forma tangible
- África. Edge Partner (puntos de presencia embebidos en ISPs de última milla) evita desvíos a hubs lejanos.
- Japón. Más ubicaciones y peering local explican la ventaja frente al #2.
- Canadá. Competencia muy reñida: diferencias de ~1 ms separan a los tres primeros proveedores.
Seguridad por diseño y por proceso
Rust reduce la superficie de errores de memoria; la arquitectura modular acota el impacto de cambios. Aun así, Cloudflare mantiene estándares estrictos: linting fuerte, code review, baterías de pruebas y una política de investigar cualquier crash inexplicado. El efecto combinado: menos incidentes y más tiempo para análisis de causa raíz cuando algo ocurre.
Hoja de ruta
- Terminar HTTP/TLS en Rust y apagar FL1 a inicios de 2026.
- Optimizar interconexiones entre módulos, ampliar soporte a tráfico no-HTTP (RPC, streams) y seguir rascando microsegundos con medidas guiadas por RUM y peering quirúrgico allí donde los datos muestren margen.
Conclusión
FL2 no es “Rust por Rust”. Es arquitectura + proceso + operación al servicio de tres objetivos: menos latencia, más seguridad y más velocidad de entrega. Un “cerebro” modular que ejecuta solo lo necesario, proxies que se reinician sin cortar sesiones y una red que se mide a sí misma para decidir dónde invertir explican el salto: –10 ms en la mediana, +25 % de rendimiento y liderazgo en casi la mitad de las redes más relevantes del planeta. Lo que queda es simple de decir y difícil de hacer: donde no son #1, identificarlo, arreglarlo y contarlo.
Preguntas frecuentes
¿Qué es FL2 exactamente y en qué mejora a FL1?
FL2 es la nueva plataforma de orquestación de Cloudflare, escrita en Rust sobre Oxy. Sustituye a FL1 (NGINX/OpenResty/LuaJIT) con módulos tipados, filtros por petición y reinicios sin cortes. Resultado: –10 ms de latencia mediana, +25 % de rendimiento y < ½ de CPU/memoria.
¿Por qué elegir Rust para un plano de datos a escala?
Por seguridad de memoria (menos crashes y use-after-free) y rendimiento. En combinación con Oxy, Rust aporta recargas suaves, config dinámica y una base común para productos muy distintos, de Zero Trust a CDN.
¿Cómo evita FL2 romper conexiones en producción?
Con graceful restarts y systemd socket activation: el proceso nuevo entra, el antiguo sigue atendiendo conexiones vivas hasta que cierran. Así WebSockets/streams no se cortan durante despliegues o hotfixes.
¿Qué papel juegan los Edge Partner en las mejoras de velocidad?
Acercan el punto de servicio al usuario dentro de redes de última milla. En regiones con peering limitado, reducen saltos y latencias, como se ha visto en África y Japón.
¿Cómo sabe Cloudflare dónde invertir para ser más rápido?
Con RUM y comparativas continuas frente a otros CDNs (p. ej., p95 de conexión TCP). Si una región o ASN va por detrás, se prioriza peering, capacidad o nuevos PoPs.
¿Qué cambia para mi sitio o API si soy cliente?
Deberías notar mejores TTFB y menos variabilidad en horas punta. No hay cambios que exijan acción: FL2 es transparente para el cliente.
¿Cuándo estará todo “en Rust”?
La migración mayor ya está hecha; queda completar terminación HTTP/TLS y apagar FL1 a comienzos de 2026.
¿La modularidad no añade overhead?
Al contrario: los filtros por petición evitan ejecutar módulos irrelevantes. Menos trabajo total ⇒ menos latencia y mejor uso de CPU/memoria.
¿Qué implicaciones tiene para seguridad y cumplimiento?
Contratos tipados y módulos acotados reducen el riesgo de cambios laterales. Con reviews, testing y telemetría, mejora la trazabilidad para auditorías y respuesta a incidentes.
