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)  

Cloudflare Connect 2026 en San Francisco: Fórmate, Certificate y Lidera la Transformación.

Los días 19, 20 y 21 tendrá lugar Cloudflare Connect 2026 en San Francisco, el evento para Clientes, Partners y Creadores de Internet de Cloudflare. Es el evento del año de la compañía. El evento más importante si quieres entender hacia donde está llevando Cloudflare la construcción de Internet, donde podrás encontrarte con los Ingenieros, VPs, y Researchers de la compañía, pero donde además podrás CERTIFICARTE en las tecnologías de la compañía, que se hacen formaciones y exámenes directamente en el evento.

Figura 1: Cloudflare Connect 2026 en San Francisco.

Fórmate, Certificate y Lidera la Transformación.

Es el evento al que tienes que ir, o al que tienes que mandar a tu equipo técnico si estás usando o estás pensando el año que viene en moverte a tener las ventajas de Cloudflare. Así que registra tu plaza y tu viaje cuando antes.

Figura 2: Speakers en Cloudflare Connect 2026

La agenda es espectacular, con 149 sesiones de formación sobre todos los temas que puedas imaginarte que tienen que ver con Ciberseguridad, Inteligencia Artificial, Infraestructura de Internet, Agentic AI, Internet Business, y por supuesto, estará el C-Level de la compañía, para poder hablar cone ellos.

Figura 3: La agenda tiene 149 sesiones de formación

Yo estaré también dando una charla el día 21 de Octubre, sobre Seguridad, IA, y Guardarraíles, y estaré en múltiples reuniones y actividades paralelas que tienen lugar durante Connect, así que será un lugar para que nos podamos ver y hablar del futuro.

Figura 4: Mi charla en Cloudflare Connect 2026

Como os he dicho, par los técnicos es un sitio espectacular para formarse y certificarse, así que si quieres tener Cloudflare Experts en tu empresa, es una oportunidad de oro para enviarlos a formarse durante esos días. En una semana te los devolvemos transformados.

Figura 5: Cloudflare University con CERTIFICACIONES

Y si eres uno de nuestros Partners y quieres acelerar con nosotros - o quieres ser partner - tienes el día 19 el Global Partner Summit al que debes venir donde conocerás nuestra estrategia, nuestras tecnologías, y cómo trabajar más y mejor juntos.

Figura 6: Global Partner Summit de Cloudflare en Connect 2026

Por supuesto, es un evento lleno de tecnología y de ingenieros, y los "Alonso" estaremos allí dando nuestras charla con nuestros "sombreros", así que si vienes ya sabes cuál es el espíritu que te vas a encontrar.

Figura 7: Ven a conocer a los ingenieros de Cloudflare

Os he dejado información de mi charla por si vienes allí, que no se te olvide venir a verla, que será sólo un ratito pero tenemos que vernos ... y si quieres hacernos una foto para el recuerdo, pero sobretodo revisa la cantidad de buenos speakers que tienes allí para aprender de ellos.

Figura 8: Speakers de Cloudflare Connect 2026

No vas a tener oportunidad de formarte más rápido y con los mejores en menos tiempo para liderar la transformación al nuevo mundo de Agentic AI y los cambios en Ciberseguridad. Nos vemos en Cloudflare Connect 2026 en San Francisco.

¡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)  

Cómo configurar y Monitorizar un Cloud Web Application Firewall para proteger tu Web en un Internet muy peligroso

Puede que en tu empresa el problema sea que casi nadie lo esté mirando, pero la web está siendo atacada constantemente. Este fenómeno suele pasar desapercibido para la mayoría de organizaciones. En los últimos años, las noticias más visibles en el ámbito de la ciberseguridad han estado centradas en incidentes de gran impacto, como ataques de ransomware, filtraciones de datos personales o campañas avanzadas de amenazas persistentes (APT).

Figura 1: Cómo configurar y Monitorizar un Cloud Web Application Firewall

para proteger tu Web en un Internet muy peligroso

No obstante, rara vez se habla del volumen constante de escaneos y ataques automatizados que reciben diariamente las páginas y servicios web en Internet. Únicamente los ataques DDoS de gran magnitud suelen captar la atención mediática en lo que respecta a la seguridad de servicios web. Para que os hagáis una idea, en el Threat Report 2026 de Cloudflare, la compañía está bloqueando más de 230 Billones de amenazas al día. Ese es el nivel de agresividad que vivimos hoy en día en Internet.

En el caso de VapaSec, poco después de comenzar nuestra actividad, empezamos a monitorizar la seguridad de nuestras infraestructuras expuestas a Internet. A pesar de contar con un número reducido de sistemas, detectamos más de 15.000 eventos de seguridad en un corto periodo de tiempo. La gran mayoría de estos eventos se originaban en tan solo dos servicios web.

El impacto de un Web Application Firewall

Este hallazgo nos llevó a una conclusión relevante: disponer de un WAF (Web Application Firewall) no es suficiente si no está correctamente configurado y gestionado. Inicialmente, no estábamos bloqueando ninguno de estos ataques. 

Figura 2: Eventos de Seguridad en la web antes del WAF

Esto es comprensible, ya que, como ocurre con muchas soluciones de seguridad, su eficacia depende en gran medida de la configuración y del mantenimiento continuo.

Figura 3: Eventos de seguridad en la web tras configurar el WAF

Tras implementar una gestión activa del WAF, bloqueando el tráfico malicioso de forma proactiva, logramos reducir los eventos diarios a apenas una veintena.

Internet es un escáner permanente

El análisis del tráfico de cualquier aplicación o servicio web revela una realidad clara: no es necesario ser una organización conocida para convertirse en objetivo. Basta con estar conectado a Internet. Los atacantes no seleccionan objetivos de forma personalizada en la mayoría de los casos. Operan mediante escaneos masivos y automatizados en busca de sistemas vulnerables. Si encuentran una oportunidad, pueden utilizar el sistema comprometido para minar criptomonedas, distribuir malware, lanzar ataques contra terceros o interrumpir el servicio web y pedir un rescate para recuperar su actividad. Todas estas actividades no buscan otra cosa más que obtener un retorno económico.

Figura 4: Libro de "Hacking Web Technologies Silver Edition"

de Enrique Rando, Pablo González, Amador Aparicio,

Ricardo Martín y Chema Alonso

Una forma sencilla de comprobar si has sido escaneado, es revisando los logs del servidor web (Apache, Nginx, etcétera). Es habitual encontrar intentos de acceso a rutas sensibles como .env, .git, paneles de administración o copias de seguridad. También son frecuentes los ataques de fuerza bruta contra formularios de autenticación, procedentes de múltiples direcciones IP.

Figura 5: Eventos en el log que indican escaneos

Cabe destacar que muchos de estos ataques no se caracterizan por un alto volumen de peticiones, sino por su persistencia y automatización. En nuestra experiencia, solo aquellas empresas cuyo modelo de negocio depende directamente de la protección del contenido web muestran un mayor nivel de concienciación en materia de seguridad y gestión de la exposición en Internet.

Figura 6: Acciones de bloqueo diarias por dominios

Es común encontrar organizaciones que implementan plugins o frameworks de seguridad directamente en sus servidores. Aunque estas soluciones son útiles y mitigan una parte significativa de los ataques, presentan ciertas limitaciones:

• Consumen recursos locales (CPU, memoria y ancho de banda).
• No evitan que el tráfico malicioso alcance la infraestructura protegida.
• Pueden resultar insuficientes frente a ataques de denegación de servicio DDoS.

Por este motivo, resulta recomendable utilizar soluciones de WAF en la Cloud. Este enfoque permite filtrar y mitigar amenazas en un punto previo a la infraestructura que presta el servicio web. De esta forma se optimiza el uso de recursos y se mejora la resiliencia del servicio.

Figura 7: Cloudflare WAF

Dentro de estas soluciones, una de las más extendidas y usadas es Cloudflare WAF. Cloudflare dispone de plan gratuito, que permite a muchos creadores de contenidos y pequeñas empresas disfrutar de soluciones de primer nivel sin hacer un desembolso económico.

Mis dominios están en Cloudflare. ¿Quién los gestiona?

Migrar tus dominios a Cloudflare aporta mejoras significativas en el rendimiento y gestión de la infraestructura IT. Al utilizar Cloudflare consiguen un mejor rendimiento de los servicios Web y una gestión ágil y rápida del DNS. Además de la mejora en el rendimiento, Cloudflare permite establecer un nivel de seguridad avanzado configurando algunos parámetros de seguridad.

Sin embargo, es importante destacar que el simple hecho de migrar tu infraestructura a Cloudflare no establece por defecto un nivel de seguridad alto. La configuración del WAF y de las políticas de seguridad es un aspecto crítico.

Figura 8: VAPASEC en RootedCON Madrid 2026

En diferentes conversaciones mantenidas durante eventos como RootedCON, hemos detectado la excesiva confianza en que con el uso de Cloudflare, por sí solo, proporciona seguridad completa. La realidad es que estas herramientas requieren una gestión activa y continua para ser efectivas, para poder adecuarse a las amenazas cambiantes.

Primeros pasos para mejorar la seguridad

A continuación, os dejo algunas medidas iniciales que pueden ayudar a reforzar la seguridad de un sitio web, que como podéis ver, es algo que requiere trabajo de gestión y configuración, así como de mantenimiento y operación.

Figura 9: Hacking Web Applications: Client-Side Attacks
de Enrique Rando en 0xWord

El primer paso que se deben dar es activar el Proxy, de esta forma conseguimos beneficiarnos de la capacidad de caché y CDN que ofrece Cloudflare, pero también tenemos otra ventaja. No soy amigo de la seguridad por oscuridad, pero el activar el Proxy hace que la IP que vean los visitantes de nuestro sitio web no sea la de nuestra máquina si no una de las direcciones IP de entrada a la red de Cloudflare.

Figura 10: Configuración del Reverse Proxy en Cloudflare

Una vez activado el Proxy, podemos implantar reglas que protejan nuestro sitio web de visitantes no deseados. Una primera medida puede ser crear una regla que bloquee el acceso desde determinados países en los que mi organización no tiene actividad comercial. Por ejemplo si no tenemos actividad comercial en países como Afganistán, Irak, Irán, Ucrania, Rusia, Bielorrusia, Somalia o Korea del Norte, puede ser interesante bloquear el acceso desde esos países con una regla como esta.

Figura 11: Reglas de origen en el WAF de Cloudflare

Otro paso que se puede dar para mejorar la seguridad de nuestro sitio web es restringir el acceso de scripts o programas automáticos estén visitando nuestro sitio web. Por ejemplo, con esta regla podemos evitar que programas en Python o automatizaciones que usen curl nos resten recursos de nuestro servidor web.

Figura 12: Regla por USER-Agent de origen en el WAF de Cloudflare

Igual has terminado de leer este post y te has ido a revisar el log de tu servidor web y te has dado cuenta que hay algunos visitantes con direcciones IP de mala reputación que lanzan peticiones de manera constante, solicitando recursos en rutas muy sospechosas. Podrías bloquearlas o someterlas a un reto introduciéndolas en una regla.

Figura 13: Reglas en el WAF de Cloudflare por direcciones IP de origen

Por separado cada una de estas tareas no son una gran carga para el día a día del operador de ciberseguridad, pero hay que ejecutarlas todos los días y dependen del escaso tiempo de los operadores de seguridad, lo que puede llevar a que esta tarea no se ejecute.

Automatizacion de la protección: el enfoque de VapaSec

Hace tres años nos encontramos con esta misma problemática en VapaSec. La gestión manual de la seguridad web no era escalable, ni sostenible en el tiempo. Como respuesta, desarrollamos VapaSec Web Protection, inicialmente como herramienta interna, y posteriormente como solución accesible para terceros. Web Protection no es un WAF, Web Protection automatiza y mejora la gestión de tu WAF. Es una solución que protege los servicios web mediante múltiples capas de protección:

Figura 14: VAPASEC Web Protection

El primer nivel que implementamos consiste en el bloqueo de direcciones IP con mala reputación, que realizan escaneos constantes sobre nuestros servicios web. VapaSec Web Protection cuenta con un motor propio que permite evaluar la reputación de cada IP mediante un sistema de scoring de riesgo. En función de este score, determinamos automáticamente si se debe aplicar un bloqueo o un mecanismo de desafío (challenge) a dicha dirección.

Este sistema de reputación se apoya en una base de datos donde se almacena información sobre las direcciones IP que han mostrado comportamiento malicioso de forma recurrente contra nuestros clientes desde el inicio del servicio. La base de datos se mantiene actualizada mediante la integración de fuentes tanto públicas como privadas, lo que nos permite identificar direcciones IP que están participando activamente en ataques y aplicar medidas preventivas en los WAF que gestionamos. De este modo, evitamos que estos actores maliciosos accedan a los servicios protegidos. Asimismo, las direcciones IP  son eliminadas de la base de datos cuando dejan de presentar actividad maliciosa, garantizando así un enfoque dinámico y ajustado a la realidad del tráfico.

Además, esta información se comparte entre todos los dominios integrados en la solución a través de una funcionalidad que denominamos Inteligencia Colectiva. Gracias a este enfoque, cuando un atacante es detectado en uno de los dominios, queda automáticamente bloqueado en el resto, reforzando la protección de todo el ecosistema.

Otra de las medidas que implementamos en los dominios que protegemos consiste en restringir el acceso desde países en situación de conflicto bélico o que presentan un origen recurrente de actividad maliciosa. Este tipo de control es una práctica habitual en la configuración de WAF, ya que permite reducir la superficie de ataque filtrando tráfico en función de su procedencia geográfica . No obstante, es importante señalar que estos países no siempre representan el principal origen de los ataques bloqueados por Web Protection, tal y como se puede observar en la imagen inferior.

Figura 15: Bloqueos por países

En el segundo nivel implementamos reglas especializadas orientadas a la protección de los activos web. Estas reglas se nutren de información actualizada sobre amenazas activas en Internet, lo que nos permite anticiparnos y mitigar intentos de ataque antes de que impacten en los dominios que gestionamos.

Adicionalmente, establecemos políticas específicas para proteger los paneles de acceso de nuestros clientes. Para ello, incorporamos un mecanismo de control que limita el acceso a estos puntos críticos, de forma que únicamente los usuarios previamente identificados mediante su dirección de correo electrónico puedan acceder al formulario donde se introducen las credenciales de autenticación.

Figura 16: Protecciones con challenge

Otra de las capas de seguridad que incorporamos al servicio es la denominada Real Time Protection. Esta capa opera de forma continua, analizando las peticiones que recibe el servidor web protegido por Web Protection. En caso de detectar indicios de actividad maliciosa, el sistema responde automáticamente aplicando contramedidas sobre el visitante sospechoso.

En VapaSec consideramos que la mejor forma de evaluar este tipo de soluciones es mediante su uso en un entorno real. Siguiendo un enfoque similar al de Cloudflare con su plan gratuito, hemos desarrollado una prueba sin coste que permite utilizar Web Protection durante 30 días. De este modo, cualquier organización puede analizar de forma directa el volumen de tráfico no deseado que recibe diariamente y valorar el impacto real de la solución en su postura de seguridad.

Un saludo,

Autor: Pablo San Emeterio, fundador de VapaSec

Contactar con Pablo San Emeterio

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)