Cloudflare opera la red más rápida del planeta. Hoy hemos anunciado nuestras últimas novedades relacionadas con la renovación de la tecnología de software que acelera todos nuestros servidores, y cómo esto mejora la velocidad en todo el mundo.
Sin embargo, nuestro trabajo va más allá. Para mejorar aún más la velocidad, también debemos garantizar que nuestra red gestiona con rapidez la congestión que afecta a diario a Internet a nivel global, enrutando el tráfico a nuestros servidores ahora más rápidos.
Llevamos años invirtiendo en el control de la congestión. Hoy nos complace anunciar cómo estamos aprovechando la enorme ventaja que ofrece nuestra red (nuestra enorme base de usuarios del plan gratuito) a fin de optimizar el rendimiento y encontrar la mejor manera de enrutar el tráfico a través de nuestra red para todos nuestros clientes a nivel mundial.
Los primeros resultados han mostrado un aumento del rendimiento que, de media, supone una aceleración del 10 % respecto a la línea base anterior. Para lograr estos resultados, hemos aplicado distintos métodos algorítmicos para mejorar el rendimiento en función de los datos que observamos a diario en Internet. Nos complace comenzar a implementar estas mejoras para todos los clientes.
¿Cómo llega el tráfico a nuestra red?
Internet es un conjunto masivo de redes interconectadas, y cada una de ellas se compone de muchas máquinas ("nodos"). Los datos se transmiten dividiéndolos en pequeños paquetes y pasándolos de una máquina a otra (a través de un "enlace"). Cada una de estas máquinas está vinculada a muchas otras, y cada enlace tiene una capacidad limitada.
Cuando enviamos un paquete a través de Internet, este recorrerá, en una serie de "saltos", los enlaces de A a B. En algún momento habrá un enlace (un "salto") que tenga la menor capacidad disponible en esa ruta. Ese salto será el cuello de botella, independientemente de dónde se encuentre en la conexión.
Sin embargo, este sistema presenta una dificultad: cuando envías datos a través de Internet, no sabes qué ruta van a seguir. De hecho, cada nodo decide por sí mismo qué ruta utilizar para enviar el tráfico, y distintos paquetes que van de A a B pueden seguir rutas completamente distintas. La naturaleza dinámica y descentralizada del sistema es lo que hace que Internet sea tan eficaz. Sin embargo, también dificulta calcular cuántos datos se pueden enviar. Por lo tanto, ¿cómo puede un remitente saber dónde se encuentra el cuello de botella y a qué velocidad enviar los datos?
En el caso de una ruta que recorre los nodos de Cloudflare, nuestro producto Argo Smart Routing aprovecha nuestra visibilidad de la red global para acelerar la comunicación. Del mismo modo, cuando iniciamos conexiones con los servidores de origen de los clientes, podemos utilizar Argo y otra información para su optimización. No obstante, la velocidad de una conexión desde tu teléfono o portátil (el "Cliente" en el gráfico siguiente) al centro de datos de Cloudflare más cercano dependerá de la capacidad del salto que es el cuello de botella en la cadena desde ti hasta Cloudflare, lo que se produce fuera de nuestra red.
¿Qué sucede cuando llegan demasiados datos a la vez?
Si llega un volumen excesivo de datos a un nodo de la red que se encuentra en la ruta de una solicitud que se está procesando, el solicitante sufrirá retardos debido a la congestión. Los datos se pondrán cierto tiempo en cola (con el riesgo de bufferbloat), o algunos de ellos simplemente se descartarán. Algunos protocolos, como TCP y QUIC, responden a la pérdida de paquetes retransmitiendo los datos. Sin embargo, esto supone un retardo e incluso puede empeorar el problema al sobrecargar aún más la capacidad limitada.
Si los proveedores de infraestructura en la nube como Cloudflare no gestionan con cuidado la congestión, corremos el riesgo de sobrecargar el sistema, lo que ralentizaría la velocidad de la transferencia de datos. De hecho, esto es lo que sucedía en los primeros tiempos de Internet. Para evitar este problema, la comunidad de proveedores de infraestructura de Internet ha desarrollado sistemas para controlar la congestión, que permiten a todos los usuarios enviar sus datos por turno, sin sobrecargar la red. Este desafío sigue evolucionando a medida que aumenta la complejidad de la red, y la búsqueda del mejor método para implementar el control de la congestión es una búsqueda constante. Se han desarrollado muchos algoritmos distintos, que utilizan una gran variedad de fuentes de información y señales, emplean un método determinado para la optimización y responden a la congestión de distintas formas.
Los algoritmos de control de la congestión emplean varias señales para calcular la velocidad adecuada para el envío del tráfico, sin saber cómo está configurada la red. Una señal importante ha sido la pérdida. Cuando se recibe un paquete, el receptor envía un mensaje "ACK", que indica al remitente la recepción del paquete. Si el paquete se pierde en algún punto del recorrido, el remitente nunca recibirá el acuse de recibo y, tras un tiempo de espera, considerará que el paquete se ha perdido.
Los algoritmos más recientes han empleado datos adicionales. Por ejemplo, el popular algoritmo BBR (Bottleneck Bandwidth and Round-trip propagation time), que hemos estado utilizando para gran parte de nuestro tráfico, intenta crear, durante cada conexión, un modelo que defina la cantidad máxima de datos que se pueden transmitir en un periodo de tiempo determinado, utilizando estimaciones del tiempo de ida y vuelta, así como la información sobre la pérdida.
La decisión sobre cuál es mejor algoritmo en cada caso suele depender de la carga de trabajo. Por ejemplo, para el tráfico interactivo (como una videollamada) un algoritmo que tienda a enviar demasiado tráfico podría causar acumulación de colas, lo que generaría una alta latencia y una experiencia de vídeo deficiente. Si se optimizara únicamente para ese caso de uso y se evitara esta situación enviando menos tráfico, la red no aprovecharía al máximo la conexión para los clientes que realizan descargas masivas. El resultado de la optimización del rendimiento varía según una gran diversidad de factores. ¡Pero gracias a nuestra visibilidad podemos identificar muchos de ellos!
BBR fue un desarrollo interesante en la estrategia del control de la congestión, Pasamos de enfoques reactivos basados en la pérdida a una optimización proactiva basada en modelos, lo que mejoró considerablemente el rendimiento para las redes modernas. Nuestros datos nos brindan la oportunidad de avanzar aún más, gracias a la aplicación de diversos métodos algorítmicos para mejorar el rendimiento.
Todos los algoritmos existentes están restringidos a utilizar solo la información recopilada durante la vida útil de la conexión actual. Afortunadamente, siempre disponemos de mucha más información adicional sobre Internet. Con la perspectiva de Cloudflare sobre el tráfico, vemos mucho más de lo que cualquier cliente o proveedor de acceso a Internet podría ver en cualquier momento.
Cada día, vemos tráfico de prácticamente todas las redes más importantes del planeta. Cuando llega una solicitud a nuestro sistema, sabemos con qué dispositivo cliente nos estamos comunicando, qué tipo de red permite la conexión y si se trata de proveedores de acceso a Internet o de proveedores de infraestructura en la nube.
Conocemos los patrones de carga en Internet en todo el mundo y las ubicaciones donde creemos que los sistemas están sobrecargados, ya sea dentro o fuera de de nuestra red. Sabemos qué redes tienen propiedades estables, cuáles sufren una alta pérdida de paquetes debido a las conexiones de datos móviles, y cuáles atraviesan enlaces satelitales de órbita terrestre baja y cambian radicalmente sus rutas cada 15 segundos.
Hemos migrado nuestra pila tecnológica de red para utilizar una nueva plataforma, basada en Rust, que proporciona más flexibilidad para probar distintos parámetros en los algoritmos utilizados para gestionar el control de la congestión. Para ello necesitábamos datos.
Los datos que impulsan estos experimentos deben reflejar la medida que estamos tratando de optimizar, es decir, la experiencia del usuario. No es suficiente con que enviemos datos a casi todas las redes del planeta. Debemos ser capaces de ver cómo es la experiencia de los clientes. Por lo tanto, ¿cómo lo hacemos, teniendo en cuenta nuestra gran escala?
En primer lugar, tenemos registros "pasivos" detallados de la velocidad a la que se pueden enviar los datos desde nuestra red y el tiempo que tarda el destino en confirmar la recepción. Esto abarca todo nuestro tráfico y nos da una idea de la rapidez con la que el cliente ha recibido los datos. Sin embargo, no nos garantiza la información sobre la experiencia del usuario.
A continuación, disponemos de un sistema para recopilar datos de mediciones de usuarios reales (RUM), que registra la información en los navegadores web compatibles sobre distintas métricas, como el tiempo de carga de la página. Cualquier cliente de Cloudflare puede activar esta función para recibir información detallada en su panel de control. Además, utilizamos estos metadatos en todo el conjunto de todos nuestros clientes y redes para comprender cómo es realmente la experiencia de los clientes.
Sin embargo, los datos de mediciones de usuarios reales (RUM) solo estarán disponibles para un pequeño porcentaje de las conexiones en nuestra red. Por lo tanto, hemos estado trabajando para encontrar una manera de predecir las mediciones de usuarios reales (RUM) a partir de la extrapolación de los datos que solo vemos en los registros pasivos. Por ejemplo, aquí están los resultados de un experimento que realizamos comparando dos algoritmos distintos con la línea base cúbica.
A continuación, tienes la misma escala temporal, observada a través de la predicción basada en nuestros registros pasivos. Las curvas son muy similares, pero más importante aún es la gran similitud de la proporción entre las curvas. ¡Esto es fantástico! Podemos utilizar una cantidad relativamente pequeña de datos de medidas de usuarios reales (RUM) para validar nuestros hallazgos. Sin embargo, podemos optimizar nuestra red de una manera mucho más precisa utilizando el flujo completo de nuestros registros pasivos.
Una extrapolación excesiva resulta poco fiable. Por este motivo, también estamos colaborando con algunos de nuestros clientes más grandes para mejorar nuestra visibilidad del comportamiento de la red desde la perspectiva de sus clientes, lo que nos permite ampliar aún más este modelo predictivo. A cambio, podremos proporcionar a nuestros clientes información sobre la auténtica experiencia de sus clientes (lo que ninguna otra plataforma puede ofrecerles).
Actualmente, estamos llevando a cabo nuestros experimentos y ejecutando nuestros algoritmos mejorados para el control de la congestión en todo nuestro tráfico QUIC de los planes gratuitos. A medida que obtengamos más información, realizaremos la verificación para los clientes de mayor complejidad y la ampliemos al tráfico TCP. Realizaremos esta implementación de forma gradual para todos nuestros clientes, para todo el tráfico, a lo largo de 2026 y en adelante. ¡Los resultados han llevado a una mejora de hasta un 10 % en comparación con la línea base!
Estamos colaborando con un grupo seleccionado de empresas para probar esta función en un programa de acceso anticipado. Si quieres obtener más información, ¡ponte en contacto con nosotros!