--- title: "Cloudflare acelera y blinda su red con Rust: FL2 recorta 10 ms de latencia, sube un 25 % el rendimiento y prepara la próxima década" description: "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 s..." url: https://revistacloud.com/cloudflare-acelera-y-blinda-su-red-con-rust-fl2-recorta-10-ms-de-latencia-sube-un-25-el-rendimiento-y-prepara-la-proxima-decada/ date: 2025-10-06 modified: 2025-09-28 author: "Antonio" image: https://revistacloud.com/wp-content/uploads/2025/06/rust-c-video.jpg categories: ["Análisis y opinión", "Empresas"] tags: ["Cloudflare", "Rust"] type: post lang: es --- # Cloudflare acelera y blinda su red con Rust: FL2 recorta 10 ms de latencia, sube un 25 % el rendimiento y prepara la próxima década 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](https://revistacloud.com/tag/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](https://revistacloud.com/tag/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.