Cloudflare: El "exoesqueleto" de seguridad y aceleración en Internet para el 25.7% de los dominios de Internet mundiales

Cuando tengo conversaciones sobre Cloudflare, algunas personas me llevan el debate a las características de productos o servicios, algo que es interesante, pero quizá no lo más relevante, posiblemente. Cuando detecto esa situación, yo suelo preguntar: "¿Sabes realmente qué es Cloudflare?". Para explicar esto, suelo hacer un dibujo de Internet, y sobre los ISPs, los ASNs, y los proveedores de cables de interconexión, sitúo en el la red de Cloudflare, formada por sus datacenters, líneas de interconexión, y ubicaciones en el Edge.

Figura 1: Cloudflare el "exoesqueleto" de seguridad y aceleración

en Internet para el 25.7% de los dominios de Internet mundiales

En ese momento, cuando la persona lo entiende, suele aparecer un brillo de entendimiento en sus ojos, porque no es sencillo para todos entender el concepto de una única plataforma desplegada por más de 750 ubicaciones, en más de 335 ciudades, en más de 135 países, funcionando como una única plataforma en un red AnyCast que funciona con Post-Quantum Cryptography e  IPv6, conectada directamente a 13.000 redes, con capacidades de almacenamiento, cómputo e inferencia en el Edge, que es una única plataforma que funciona de manera orquestada, lo que la convierte, además, en una plataforma única en Internet.

Figura 2: La plataforma mundial de Cloudflare. 

Eso quiere decir que cuando se publica un servicio en Cloudflare ese servicio está publicado en todo el mundo al mismo tiempo, en esa red, y eso hace que el tiempo de latencia sea de 50 milisegundos en el 95% de las conexiones del mundo, y en Europa de unos 20 milisegudos. Y sí, sobre ese anillo perimetral está el stack completo de servicios de seguridad que bloquea diariamente más de 232 Billones de ataques.

Figura 3: Gráfica de evolución de tecnologías de Reverse Proxy

Es decir, cuando un cliente tiene un servicio de seguridad de Cloudflare, ese servicio que está atendiendo a la empresa, lo hace en todo el mundo al mismo tiempo. No importa de dónde venga el tráfico, a los 50ms está en la red de Cloudflare y los servicios de seguridad de todos los clientes están respondiendo en el Edge. 

Figura 4: Datos de tendencia histórica de uso de Reverse-Proxy

Esto hace que la propuesta sea insuperable hoy en día por nadie que no tenga esa red funcionando de manera única y coordinada. A esto súmale los servicios gratuitos, y tendrás el resultado de este mes de Septiembre en W3Techs, donde Cloudflare es el frontal de seguridad y aceleración del 25.7 % de los dominios de Internet, funcionando como Reverse Proxy.

Figura 5: Porcentaje y Market Share de Reverse Proxy

Si miramos la tabla, veremos que el gran competidor es "None", o lo que es lo mismo, dominios de Internet que no tienen ningún Reverse Proxy dando protección y aceleración, como el 25.7% de los dominios de de Internet que están en Cloudflare. Si miramos esto con perspectiva, vemos que el 85% de los dominios que tienen un Reverse Proxy están en Cloudflare.

Figura 6: Sites using Cloudflare recently

Al final, los Digital Natives tienen en Cloudflare una plataforma de seguridad y aceleración mundial que no necesita de despliegues en regiones, que tiene todas las piezas de seguridad perimetral by design (WAF, SWG, email Security, API GW, MCP GW, AI GW, Bot Manager, Guardrails, CASB, DLP, VPN, SASE, ZTNA, ADDoS ... you name it), todo lo necesario para hacer Application Performance (CDN, Durable Objects, R2, Workers), y todo lo que necesites de Connectivity Cloud para tener redes privadas virtuales globales. 

Figura 7: Popular sites using Cloudflare

A esto súmale la misión de Cloudflare de hacer un mejor Internet, y los servicios gratuitos que ofrece para cientos de millones de dominios, y tienes los resultados. Como esa lista de sitios populares es corta, le he pedido a Gemini que me la haga un poco más larga, para que veáis un poco mejor qué sitios usan  es Cloudflare hoy en día en Internet.

Figura 8: 25 dominios usando Cloudflare hoy en día

Y aquí la continuación de la lista, que como era muy larga la he puesto en dos partes para que sea más fácil ampliarlas - haciendo clic en las imágenes.

Figura 9: Del 26 al 50 de dominos de la lista hecha con Gemini

Es solo un ejemplo, de dominios que usan Cloudflare, pero lo más importante es entender el "porqué" y la razón es la plataforma de Cloudflare del principio. Esa red mundial con computo que permite crear todos los casos de uso de seguridad y aceleración que permiten construir un mejor Internet (más seguro y más rápido).

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

La propuesta del Internet Protocol Version 8 (IPv8) para tener compatibilidad con IPv4 e ignorar IPv6

Estamos en el proceso de migrar todo el tráfico IPv4 a IPv6 desde hace ya unos años, y la verdad es que poco a poco esto está creciendo, pero aún estamos lejos de llegar al objetivo de tener más tráfico IPv6 que tráfico IPv4 en las redes de todo el mundo. Sin embargo, existen algunas otras propuestas de cambios para IPv4 distintas a la de IPv6, y recientemente se ha publicado la propuesta hecha por James Thain de, en lugar de migrar a IPv6, hacerlo a IPv8, que es cuanto menos interesante.

Figura 1: La propuesta del Internet Protocol Version 8 (IPv8)

para tener compatibilidad con IPv4 e ignorar IPv6

La propuesta fue publicada hace menos de un mes, con una serie completa de documentos para definir los protocolos necesarios para pasar a IPv8, como serían los protocolos DHCP8, WHOIS8, y el conjunto mínimo de protocolos de gestión del enrutamiento de tráfico IPv8 en las redes de Internet de hoy en día.

Figura 2: Propuesta de Internet Protocol Version 8 (IPv8)

El objetivo principal de esta propuesta, como bien se explica a lo largo de todo el documento, que la verdad, es bastante sencillo de leer, consiste en mantener la compatibilidad hacia atrás con todo lo construido hasta el momento, haciendo un cambio muy pequeño, que es cambiar la dirección IPv4 por la dirección IPv8.

Figura 3: Paquete de dirección IPv8

La gran diferencia, como se puede ver en el paquete IPv8 es que se añaden las cabeceras ASN de 32 bits tanto a la dirección IP de origen, como a la dirección IP de destino, lo que permite a los protocolos de enrutamiento reenviar correctamente al ASN correspondiente el paquete correctamente.

Figura 4: Compatibilidad hacia atrás de IPv8 con IPv4

Al añadir el Autonomous System Number (ASN), marcado como r.r.r.r, en los cuatro primeros bytes, una dirección IPv8 sería la suma de la parte de ASN r.r.r.r más la parte de IPv4 clásica, a la que se llama en el documento como n.n.n.n. 

Figura 5: Direcciones IPV8

Esto sería como tener 2 a la 32 veces el tamaño de direcciones IPv4 que tenemos hoy en día, y dejando la dirección 0.0.0.0.n.n.n.n como la red de IPv4 que tenemos en Internet funcionando ahora mismo.

Figura 6: r.r.r.r igual 0.0.0.0 sería el IPv4 de hoy en día.

Es decir, con un cambio sencillo en el envío de paquetes de red IPv4 se podría resolver el problema de que se acaben las direcciones IPv4 manteniendo todo el software construido sobre él funcionando. Y la propuesta es porque está costando ir más rápido a IPv6 de lo que se estaba esperando al inicio. Si miramos radar, podemos ver en Radar de Cloudflare que en los últimos doce meses el tráfico sobre IPv6 está estable en un 30% más o menos.

Figura 7: Trafico IPv4 vs. Tráfico IPv6 en Radar de Cloudflare

Claro, mantener la compatibilidad hacia atrás implica que sigan funcionando todos los ataque en redes de datos IPv4 que ya conocemos, además de todas sus medidas de seguridad. Es decir, se supone que el conocimiento que tenemos de estos protocolos debemos usarlos en hacerlos más seguros y no en migrarlos.

Figura 8: Ataques en redes de datos IPv4&IPv6 (4ª Edición) de

JL. Rambla, ampliado y revisado por Pablo González y Chema Alonso

Los cambios que sí que habría que hacer son los relativos a la interconexión de redes, por lo que todos los protocolos de enrutamiento de tráfico y gestión de redes deberían cambiar a IPv8, como serían BGP8, OSPF8, WHOIS8, SNMP8, etcétera, que están definidos en sus correspondientes documentos.

Figura 9: Documentos para los protocolos de gestión de redes IPv8

Y por supuesto, crear los tipos de redes especiales con direccionamientos reservados, al igual que tenemos en IPv4 e IPv6, que están descritos con detalle en el documento de Internet Protocol Version 8 (IPv8) del que estamos hablando.

Figura 10: Tipos de redes en IPv8

El documento recoge también las direcciones especiales que deben existir en estas redes IPv8, donde los nodos de enrutamiento dentro de tráfico a través de los ASNs deben ser tenidos en cuenta de manera especial, así que en la definición de estándar están especificados.

Figura 11: Direcciones especiales en IPv8

En definitiva, me parece una propuesta súper bonita como trabajo técnico de arquitectura de redes. Me falta criterio tan pronto para decir si es una opción mejor que ir hacia IPv6 o no, pero desde luego mis felicitaciones a James Thain por este trabajo tan bonito que ha publicado. Así es la investigación y la innovación, proponer ideas concretas que puedan ser evaluadas y aprender de ellas. 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Multipath Reliable Connection (MRC): Un protocolo de red diseñado para los LLMs

Este fin de semana he estado leyendo sobre este nuevo protocolo de red creado especialmente para resolver el problema de la congestión del tráfico de red que se produce en los mega-datacenters utilizados para entrenar los nuevos LLM cuando se mueven datos de GPU a GPU en los centros de datos. En estos casos, estamos hablando de interconexión de datos entre clusters que pueden contener centenares de miles de GPUs, por lo que los protocolos que envían los datos por la red son críticos en la reducción del tiempo de entrenamiento, mediante una reducción de la latencia de envío de paquetes de red y, por consiguiente, reducción del consumo de energía. 

Figura 1: Multipath Reliable Connection (MRC).

Un protocolo de red diseñado para los LLMs

MRC está creado específicamente para resolver esos problemas, y ha sido publicado en el paper de Open Compute "Multipath Reliable Connection (MRC) Specification" donde equipos de OpenAI, Microsoft, NVIDIA, Broadcom y AMD han estado trabajando para definir el nuevo protocolo que ya han puesto en producción en los clusters de entrenamiento de OpenAI y Microsoft, incluidos centros de datos de entrenamiento de Oracle.

Figura 2: Multipath Reliable Connection (MRC)

El protocolo MRC se basa en RoCEv2 (RDMA over Converged Ethernet v2), es decir, que sigue aprovechando las capacidades de RDMA (Remote Direct Access Memory) para enviar tráfico por la red de computador a computador desde la memoria de uno hasta la memoria de otro sin pasar por la CPU utilizando RoCEv2, que está diseñado especialmente para las redes Ethernet.

Figura 3: La red es el punto de congestión de los mega-datacenters

Sin embargo, en entornos de alta congestión - como es el de entrenar un LLM de frontera en un datacenter con cientos de miles des GPUs pasándose datos - , es que la red necesita una arquitectura de capas (Tiers) para conectar switches, de tal manera que dependiendo de la distancia física que exista entre las GPUs que se pasan los datos, hay que atravesar muchas capas de Switches de interconexión, y es ahí donde se produce la congestión. 

Figura 4: La propuesta de OCP es MRC con Packet Spraying

Para resolver esto, la solución es ampliar el número de capas, ampliando la latencia, para que existan más rutas posibles, lo que tampoco es una solución perfecta. Lo que propone MRC es utilizar Packet Spraying, es decir, dividir los datos que se van a enviar en pequeños paquetes de red que utilizarán, cada uno de ellos, una ruta diferente dentro de las rutas posibles.

Figura 5: Arquitectura en Tiers de Switches

Para eso es necesario conocer el estado de calidad de la red, los puertos disponibles, y poder crear una ruta para cada paquete de la red. Esto se hace con un protocolo llamado  SRv6 (Segment Routing over IPv6) que se encarga de crear la ruta para cada paquete dentro de la estructura de Tiers de los Switches de interconexión. 

Figura 6: Control de Congestión con QPCP

La especificación completa, donde se definen los estados de los protocolos de control de la congestión y calidad de la red en cada momento QP Congestion Protocol (QPCP) están todos correctamente descritos en la especificación, ya que se trata de un protocolo abierto, y tienes el paper académico de Resilient AI Supercomputer Networking using MRC and SRv6 con las pruebas realizadas publicado.

Figura 7: Resilient AI Supercomputer Networking using MRC and SRv6

Este es un ejemplo de cómo la necesidad de innovar con Inteligencia Artificial está impulsando la innovación en otras áreas adyacentes de forma masiva, como es la gestión de la energía, los protocolos de red o la gestión de grandes volúmenes de datos. 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cloudflare Talks en Londres: The Intelligent Network, Connect on Tour & Futurenet World en Abril.

Esta semana que viene, el día 15 de Abril, voy a estar en The Wave, en Zaragoza, dando una conferencia con Cloudflare y Nunsys, pero también subiré el día antes a Londres donde tenemos una semana de eventos con Cloudflare Connnect on Tour. Pero además también regresaré la semana de después, para participar en Futurenet. Viajes interesantes a la capital de UK que os dejo hoy por aquí.

Figura 1: Cloudflare Connnect on Tour.

Mi primera charla será en The Intelligent Network el día 14 de Abril, que es un evento sólo para un grupo de CXO y que tendrá lugar en Londres la próxima semana. No os puedo dejar más información, ya que el evento va solo por invitación, pero habrá en abierto otros. Pero del que sí os puedo dejar información es de Cloudflare Connect on Tour London 2026, que tendrá lugar el día 15 de Abril.

Figura 2: Cloudflare Connnect on Tour.

La lista de Speakers es de primera linea, con Stephanie Cohen, Chief Strategy Officer de Cloudflare, Grant Bourzikas, Chief Security Officer de Cloudflare, Ramy Houssaini Chief Cyber Solutions Officer Cloudflare o Tony Van den Berge, Geo Vice President, EMEA Cloudflare. Puedes registrarte en la web, pero date prisa que queda poco tiempo.

Figura 3: Regístrate al Cloudflare Connect on Tour London 2026

Después estos dos eventos, la tercera cita será en Futurenet World, que tendrá lugar a la semana siguiente, los días 21 y 22 de Abril, también en Londres, y donde yo estaré dando una charla el primer día, para hablar de "cómo fortificar despliegues de IA en la empresa".

Figura 4: Chema Alonso en Futurenet World

O sea, que si estás por Londres estos días, puede que te cruces conmigo "at random" por la city, y si vienes a alguna de las charlas, pues nos vemos seguro, que estaré trabajando en la ciudad "de los cielos grises".

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Pon a prueba la calidad de tu conexión a Internet con Cloudflare

El equipo de Radar en Cloudflare acaba de incorporar el Test de Velocidad para tu conexión a Internet que puedes probar gratuitamente desde las herramientas disponibles. Con este test se miden cosas como la velocidad de descarga de datos, de subida de datos, pero también condiciones de latencia, y lo mejor, una comparativa con otras conexiones cercanas geográficamente a ti, así que puedes darle una prueba rápida, a ver qué descubres.

Figura 1: Pon a prueba la calidad de tu conexión a Internet con Cloudflare

Yo lo he probado desde mi piso en Lisboa, donde mi conexión a Internet está compartida y ya sabéis que no es un Internet tan rápido y bueno como el de España, así que los resultados no han sido muy espectaculares, por lo que mejor aún porque me sirve para ver que tengo espacio para mejorar en la calidad de mis conexiones a Internet.

Figura 2: Network Quality Test en Cloudflare Radar

Para hacer el test, se consume la descarga de 200Mb de tráfico sintético desde tu dirección IP a servidores de Cloudflare, donde se tienen medidos todos los tests que se realizan con este proceso de comparación de la calidad de la conexión.

Figura 3: Funcionamiento del Test en Cloudflare Radar

En mi caso, como podéis ver, la conexión la he hecho desde Lisboa, Portugal, y utilizando conexión IPv6 que como me conecto con el cliente WARP a Internet, mi tráfico va todo en IPv6 y PQC por defecto.

Figura 4: Datos de conexión en el Test

Y los resultados, pues a parte de tener los números en la primera captura, tenemos las gráficas que nos sitúan en comparación con otras conexiones y test realizados desde mismas ubicaciones geográficas, que en mi caso es que yo estoy por debajo de la media en velocidad de descarga y de subida.

Figura 5: Por debajo en ancho de banda de tráfico de subida y bajada

Y sin embargo, en latencias estoy por encima, es decir peor, porque mi conexión genera más retraso en las peticiones de transferencia de paquetes, así que tengo espacio para mejorar con mi proveedor de Internet en donde vivo aquí.

Figura 6: Comparativa de latencias. También peor que la media

Si quieres más detalles, puedes aún tener más información de tu conexión, si te vas a utilizar la herramienta de Speed Test de Cloudflare, que es una versión con algunos datos extras, aunque en el fondo veréis que los puntos de medición son los mismos.

Figura 7: Ataques en redes de datos IPv4&IPv6 (4ª Edición) de

JL. Rambla, ampliado y revisado por Pablo González y Chema Alonso

Para ello te vas a Speed Test Cloudflare, y allí seleccionas la opción de realizar ejecutar el test de velocidad y listo. No tiene ninguna complejidad más que dar al botón de Start.

Figura 8: Realizar un test en Sppedtest Cloudflare

Una vez realizado, como lo estoy haciendo desde el mismo equipo y la misma red, y la prueba es la misma, podéis ver que los datos son muy similares, a excepción de detalles de anomalías puntuales de contexto en la red. En este caso, prácticamente iguales. 

Figura 9: 95.4 Mbps de descarga, 13.2 de subida

Como podéis ver, la conexión es buena para ver vídeo en streaming, pero para jugar online o vídeo conferencias múltiples es una conexión "Average". Vamos, del montón, por culpa de la latencia, que no da buenos resultados.

Figura 10: Medidas de latencia con 0 pérdidas de paquetes.

Como podéis ver, mi conexión es desde el Barrio de Alcantara en Lisboa, y usando IPv6 para conectarme al servidor de medición en la red de Cloudflare.

Figura 11: Conexión a la red de Cloudflare con cliente WARP

Del funcionamiento del cliente WARP os publiqué un artículo hace unas semanas, que te permite tener la conexión acelerada, evitar bloqueos de red, navegar con WAF de protección, utilizando IPv6 y con criptografía PQC (Post-Quantum Criptography), así que más que recomendado. 

Figura 12: Un clic en WARP y conexión Securizada

Y por supuesto, tienes también las mediciones detalladas del tráfico de subida y tráfico de bajada para que tengas los detalles de cómo se ha hecho el test de velocidad con tu conexión.

Figura 13: Detalles de las mediciones de tráfico de bajada

Como véis, se hacen los 200Mb en 4 tests de 25Mb, en 6 tests de 10Mb, 8 tests de 1Mb y 10 tests de 100Kb, para ver cómo se comporta la red ante diferentes tipos de tamaños de descargas. Y lo mismo para la subida de tráfico.

Figura 14: Detalles de las mediciones de subida de tráfico

Esta información te puede dar una buena idea de dónde estás con tu conexión a Internet. Yo te recomiendo que hagas la prueba con tu conexión, y luego te instales el Cliente WARP y pruebes lo que es navegar con la aceleración del Edge de Cloudflare, la seguridad del WAF por defecto, las conexiones IPv6 y el cifrado PQC. Ya te lo he dicho.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)