Cloudflare es más rápido que Zscaler

Cada Innovation Week, Cloudflare compara el rendimiento de nuestra red vs. la competencia. En las últimas semanas, nos hemos centrado en hasta qué punto somos más rápidos en comparación con proxies inversos como Akamai, o con plataformas que venden soluciones de edge computing comparables a nuestra supernube, como Fastly y AWS. Durante la CIO Week, queremos mostrarte una comparativa de nuestra red respecto a la competencia que ofrece servicios de proxy de reenvío. Estos productos forman parte de nuestra plataforma Zero Trust, que ayuda a proteger las aplicaciones y las experiencias de Internet en la red pública, a diferencia de nuestro proxy inverso, que protege tus sitios web de los usuarios externos.

Hemos realizado una serie de pruebas comparando nuestros servicios Zero Trust con Zscaler. Hemos comparado nuestro producto de protección de aplicaciones Zero Trust, Cloudflare Access, con Zscaler Private Access (ZPA). Hemos comparado también nuestra puerta de enlace web segura, Cloudflare Gateway, con Zscaler Internet Access (ZIA). Y, por último, hemos comparado nuestro producto de aislamiento remoto del navegador, Cloudflare Browser Isolation, con Zscaler Cloud Browser Isolation. Como resultado de nuestras pruebas, hemos determinado que Cloudflare Gateway es un 58 % más rápido que ZIA, Cloudflare Access es un 38 % más rápido que ZPA a nivel global, y Cloudflare Browser Isolation es un 45 % más rápido que Zscaler Cloud Browser Isolation en todo el mundo. Para cada una de estas pruebas, hemos utilizado pruebas de tiempo hasta el primer byte y pruebas de respuesta del percentil 95, que miden el tiempo que le lleva a un usuario realizar una solicitud y obtener el inicio de la respuesta (el tiempo hasta el primer byte) y el final de la respuesta (la respuesta). Estas pruebas se han diseñado con el objetivo de intentar medir el rendimiento desde la perspectiva de un usuario final.

En esta publicación abordaremos por qué el rendimiento es importante para cada uno de estos productos. Analizaremos detalladamente qué mediciones realizamos para mostrar que somos más rápidos. También explicaremos cómo hemos medido el rendimiento para cada producto.

El rendimiento es importante porque afecta a la experiencia de tus empleados y a su capacidad para realizar correctamente su trabajo. Tanto si se trata de acceder a servicios mediante productos de control de acceso, de conectarse a la red pública mediante una puerta de enlace web segura, o de proteger los sitios externos en riesgo mediante el aislamiento remoto del navegador, todas estas experiencias deben realizarse sin dificultades.

Supongamos que Anna, de Acme Corporation, se está conectando desde Sídney a Microsoft 365 o Teams para realizar un trabajo determinado. Si la puerta de enlace web segura de Acme se encuentra lejos de Anna, en Singapur, es posible que el tráfico de Anna salga de Sídney a Singapur y, a continuación, regrese a Sídney hasta llegar a su correo electrónico. Si Acme Corporation, como muchas empresas, requiere que Anna utilice Microsoft Outlook en el modo en línea, su rendimiento puede ser dramáticamente lento mientras espera el envío y la recepción de sus correos electrónicos. Microsoft 365 recomienda mantener la latencia lo más baja posible y el ancho de banda lo más alto posible. Ese salto adicional que Anna debe realizar a través de su puerta de enlace podría reducir el rendimiento y aumentar su latencia. Como resultado, la experiencia de Anna sería mala.

En otro ejemplo, si Anna se está conectando a una aplicación alojada protegida como Jira para completar algunos tickets, no quiere estar esperando constantemente a que se carguen las páginas o a que se autentiquen sus solicitudes. En una aplicación con control de acceso, lo primero que haces cuando te conectas es iniciar sesión. Si este inicio de sesión tarda mucho, podrías distraerte con cualquier mensaje de un compañero o decidir abandonar por completo el trabajo. Incluso si obtienes la autenticación, aún quieres que tu experiencia normal con la aplicación sea ágil y fluida. Si Zero Trust funciona de forma óptima, los usuarios no deberían notar su presencia.

Si estos productos o experiencias son lentos, las quejas de tus usuarios no son lo peor que podría pasar: estos pueden encontrar la manera de desactivar los productos u omitirlos. Y esto pone a tu empresa en riesgo. Un conjunto de productos Zero Trust es completamente ineficaz si nadie lo utiliza porque es demasiado lento. Para que una solución Zero Trust sea eficaz, es fundamental garantizar su rapidez. Si los empleados prácticamente desconocen su existencia, no querrán desactivarla ni se pondrán en riesgo.

Los servicios como Zscaler pueden superar a muchas soluciones anticuadas anteriores. No obstante, su red aún no puede estar a la altura de una red optimizada de alto rendimiento como la de Cloudflare. Hemos probado nuestros productos Zero Trust comparándolos con sus equivalentes de Zscaler. Te demostraremos que somos más rápidos. Analicemos los datos. Te mostraremos cómo y por qué somos más rápidos en tres situaciones Zero Trust críticas. empezando con la puerta de enlace web segura: la comparación de Cloudflare Gateway con Zscaler Internet Access (ZIA).

Una puerta de enlace web segura debe ser rápida porque actúa como un embudo para todo el tráfico de entrada a Internet de una organización. Si una puerta de enlace web segura es lenta, el tráfico de los usuarios a Internet será lento. Si el tráfico a Internet es lento, los usuarios pueden sentir el impulso de desactivar la puerta de enlace, y esto pone a la organización en riesgo de ataque.

No obstante, una puerta de enlace web eficaz no solo debe estar cerca de los usuarios. También debe estar correctamente emparejada al resto de Internet. Esto evita las rutas lentas a los sitios web a los que los usuarios quieren acceder. Recuerda que el tráfico a través de una puerta de enlace web segura sigue una ruta de proxy de reenvío: los usuarios se conectan al proxy, y el proxy se conecta a los sitios web a los que los usuarios intentan acceder. Por lo tanto, conviene que el proxy esté bien conectado para garantizar que el tráfico de los usuarios puede llegar a dónde debe ir, y de la forma más rápida posible.

Para comparar los productos de puerta de enlace web segura, enfrentamos Cloudflare Gateway y el cliente WARP a Zscaler Internet Access (ZIA), que realiza las mismas funciones. Por suerte para los usuarios de Cloudflare, la red de Cloudflare y Gateway no solo está integrada estrechamente en las redes de última milla, cerca de los usuarios. También es una de las redes mejor emparejadas del mundo. Utilizamos nuestra red más emparejada para ser un 55 % más rápida que ZIA en los escenarios de los usuarios de Gateway. A continuamos encontrarás un diagrama de caja que muestra el tiempo de respuesta del percentil 95 para Cloudflare, Zscaler y un grupo de control que no utilizó ninguna puerta de enlace:

Secure Web Gateway - Tiempo de respuesta

Percentil 95 (ms)

Control

142,22

Cloudflare

163,77

Zscaler

365,77

Estos datos muestran no solo que Cloudflare es mucho más rápido que Zscaler en los escenarios de Gateway. También muestran que Cloudflare realmente es más similar en la comparación al grupo que no utiliza ninguna puerta de enlace web segura que a Zscaler.

Para medir mejor la experiencia con Gateway de los usuarios finales, observamos el tiempo de respuesta del percentil 95 del usuario final: medimos cuánto tiempo lleva a un usuario atravesar el proxy, que el proxy realice una solicitud a un sitio web en Internet y, por último, que devuelva la respuesta. Esta medición es importante porque es una representación precisa de lo que ven los usuarios.

Para comparar las mediciones con Zscaler, nuestro cliente de usuario final intenta acceder a cinco sitios web distintos: un sitio web alojado en Azure, un Worker protegido por Cloudflare, Google, Slack y Zoom (sitios web a los que los usuarios se conectarían habitualmente). En cada uno de estos casos, Cloudflare superó a Zscaler. En el caso del Worker protegido por Cloudflare, Gateway incluso superó al grupo de control en el tiempo de respuesta del percentil 95. A continuamos encontrarás un diagrama de caja que muestra las respuestas del percentil 95 desglosadas según los distintos puntos finales que hemos consultado como parte de nuestras pruebas:

Independientemente de cuál sea tu destino en Internet, cuando observamos los tiempos de respuesta de extremo a extremo, Cloudflare Gateway supera a Zscaler Internet Access (ZIA). No obstante, ¿por qué somos mucho más rápidos que Zscaler? La respuesta está relacionada con lo que Zscaler denomina latencia de proxy.

La latencia de proxy es el tiempo que pasa una solicitud de usuario en una máquina Zscaler antes de su envío a su destino y su devolución al usuario. Este número excluye por completo el tiempo que lleva a un usuario llegar a Zscaler, así como el tiempo que lleva a Zscaler llegar al destino, y restringe la medición a los milisegundos que Zscaler pasa procesando las solicitudes.

El SLA de latencia de Zscaler indica que el 95 % de tus solicitudes pasarán menos de 100 ms en un dispositivo Zscaler. Zscaler se compromete a que la latencia que pueden medir en su perímetro, no la latencia de extremo a extremo, que es la que realmente importa, será de 100 ms o menos para el 95 % de las solicitudes de usuario. Incluso puedes ver estas métricas en Zscaler Digital Experience para realizar tú mismo la medición. Si podemos obtener esta latencia de proxy de los registros de Zscaler y compararla con el equivalente de Cloudflare, podemos ver nuestra comparación con las métricas del SLA de Zscaler. Aunque aún no tenemos estas métricas a disposición de los clientes, hemos podido activar el rastreo en Cloudflare para medir la latencia de proxy de Cloudflare.

Los resultados muestran que, en el percentil 95, Zscaler superaba su SLA, y la latencia de proxy de Cloudflare era de 7 ms. Además, cuando nuestra latencia de proxy era de 100 ms (lo que cumplía el SLA de Zscaler), sus latencias de proxy eran 10 veces más altas que la nuestra. La latencia de proxy de Zscaler es responsable de la diferencia de rendimiento que observamos en el percentil 95, entre 140 y 240 ms más lento que Cloudflare para cada uno de los sitios. Estos son los valores de la latencia de proxy de Zscaler en distintos percentiles para todos los sitios probados, desglosados a continuación por sitio:

Zscaler Internet Access (ZIA)

Latencia de proxy P90 (ms)

Latencia de proxy P95 (ms)

Latencia de proxy P99 (ms)

Latencia de proxy P99,9 (ms)

Latencia de proxy P99,957 (ms)

Global

06,0

142,0

625,0

1071,7

1383,7

Sitio de Azure

97,0

181,0

458,5

1032,7

1291,3

Zoom

206,0

254,2

659,8

1297,8

1455,4

Slack

118,8

186,2

454,5

1358,1

1625,8

Sitio de Workers

97,8

184,1

468,3

1246,2

1288,6

Google

13,7

100,8

392,6

848,9

1115,0

En el percentil 95, no solo sus latencias de proxy superaban el SLA. Estos valores muestran también la diferencia entre Zscaler y Cloudflare. Veamos Zoom como ejemplo: si Zscaler no tuviera la latencia de proxy, estaría a la par con Cloudflare y el grupo de control. El valor equivalente de latencia de proxy de Cloudflare es tan pequeño que utilizar Cloudflare es como utilizar la red pública:

Cloudflare Gateway

Latencia de proxy P90 (ms)

Latencia de proxy P95 (ms)

Latencia de proxy P99 (ms)

Latencia de proxy P99,9 (ms)

Latencia de proxy P99,957 (ms)

Global

5,6

7,2

15,6

32,2

101,9

Sitio de Azure

6,2

7,7

12,3

18,1

19,2

Zoom

5,1

6,2

9,6

25,5

31,1

Slack

5,3

6,5

10,5

12,5

12,8

Sitio de Workers

5,1

6,1

9,4

17,3

20,5

Google

5,3

7,4

12,0

26,9

30,2

La inclusión del percentil 99,957 puede parecer extraña, pero marca el percentil con el que las latencias de proxy de Cloudflare finalmente superaron los 100 ms. La latencia de proxy del percentil 99,957 de Cloudflare es aún más rápida que la latencia de proxy del percentil 90 de Zscaler. Incluso en la métrica que interesa a Zscaler y de la que se responsabiliza, a pesar de no ser la latencia de proxy que interesa a los clientes de la métrica, Cloudflare es más rápido.

No ha sido fácil obtener esta vista de los datos. Los marcos de pruebas existentes como Catchpoint no son adecuados para esta tarea porque la prueba de rendimiento requiere la ejecución del cliente ZIA o del cliente WARP en el punto final de prueba. Para medir el rendimiento de la mejor forma posible, también debíamos asegurarnos de que la prueba de Cloudflare y la prueba de Zscaler se realizaban en máquinas similares en la misma ubicación. Esto nos permite medir las respuestas de extremo a extremo procedentes de la misma ubicación donde se están ejecutando ambos entornos de prueba:

En nuestra configuración, hemos puesto tres máquinas virtuales en el lado de la nube, una junto a la otra: una ejecuta Cloudflare WARP conectado a Cloudflare Gateway, otra ejecuta ZIA y la tercera, como grupo de control, no ejecuta ningún proxy. Estas máquinas virtuales realizaron solicitudes cada tres minutos a los cinco puntos finales distintos mencionados anteriormente, y registraron en el navegador HTTP cuánto tiempo llevó cada solicitud. A partir de estos datos, podemos obtener una vista significativa del rendimiento, disponible para el usuario.

Un breve resumen hasta este punto: desde la perspectiva de un usuario final, Cloudflare es más rápido que Zscaler cuando protegemos a los usuarios de la red pública mediante una puerta de enlace web segura. Cloudflare es aún más rápido que Zscaler según la definición limitada de Zscaler de lo que significa el rendimiento mediante una puerta de enlace web segura. Sin embargo, analicemos los escenarios en los que necesitas acceder a aplicaciones específicas mediante un acceso Zero Trust.

El control de acceso debe ser fluido y transparente para el usuario: el mejor elogio que puede recibir una solución Zero Trust es que los empleados apenas notan su presencia. Los servicios como Cloudflare Access y Zscaler Private Access (ZPA) permiten a los usuarios almacenar en caché la información de autenticación en la red del proveedor. Esto garantiza el acceso seguro y rápido a las aplicaciones para proporcionar a los usuarios la experiencia eficaz que desean. Por lo tanto, una red que minimiza el número de inicios de sesión necesarios y al mismo tiempo reduce la latencia de tus solicitudes de aplicaciones ayudará a que la experiencia de Internet sea ágil y reactiva.

Cloudflare Access logra todo esto un 38 % más rápido que Zscaler Private Access (ZPA). Esto garantiza que, dondequiera que te encuentres, obtendrás una experiencia de aplicación rápida y segura:

ZT Access - Tiempo hasta el primer byte (global)

Percentil 95 (ms)

Cloudflare

849

Zscaler

1361

Cuando profundizamos más en los datos, observamos que Cloudflare es sistemáticamente más rápido en todas las partes del mundo. Por ejemplo, veamos Tokio, donde los tiempos hasta el primer byte del percentil 95 muestran que Cloudflare es un 22 % más rápido que Zscaler:

Cuando comparamos Cloudflare con Zscaler en los escenarios de acceso a aplicaciones, vemos dos escenarios distintos que es necesario medir individualmente. El primer escenario es cuando un usuario inicia sesión en su aplicación y debe autenticarse. En este caso, el servicio Zero Trust Access dirigirá al usuario a una página de inicio de sesión, el usuario se autenticará y, a continuación, se redirigirá a su aplicación.

Nombramos a este escenario nueva sesión, porque no hay ninguna información de autenticación almacenada en caché ni existe esta información en la red de Access. Denominamos al segundo escenario sesión existente, cuando un usuario ya se ha autenticado y esa información de autenticación se puede almacenar en la caché. Este escenario suele ser mucho más rápido, porque no requiere una llamada adicional a un proveedor de identidad para completarse.

Queremos medir estos escenarios por separado, puesto que al analizar los valores del percentil 95, si combináramos sesiones nuevas y existentes, casi siempre estaríamos mirando a sesiones nuevas. Sin embargo, en ambos escenarios, Cloudflare es sistemáticamente más rápido en cada región. Estos datos tienen el aspecto siguiente cuando tomamos una ubicación en la que es más probable que Zscaler tenga buenos emparejamientos: usuarios de Chicago (Illinois) que se conectan a una aplicación alojada en la región central de EE. UU.

ZT Access - Tiempo hasta el primer byte del percentil 95(Chicago)

Sesiones nuevas (ms)

Sesiones existentes (ms)

Cloudflare

1032

293

Zscaler

1373

338

A nivel global, Cloudflare también es aquí más rápido. Este es un histograma de los tiempos de respuesta del percentil 95 para las nuevas conexiones a nivel global:

Observarás que la red de Cloudflare realmente ofrece una mejora de rendimiento en el inicio de sesión. Esto ayuda a encontrar rutas óptimas de vuelta a los proveedores de autenticación para obtener la información de inicio de sesión. En esta prueba, Cloudflare nunca requiere más de 2,5 segundos para devolver una respuesta de inicio de sesión. Por el contrario, las respuestas del percentil 95 de Zscaler, con aproximadamente 4 segundos, casi duplican esa cifra. Esto sugeriría que la red de Zscaler no está tan bien emparejada, lo que causa latencia antes. No obstante, también puede sugerir que Zscaler puede mejorar el rendimiento cuando la conexión está establecida y todo está almacenado en caché. Pero en el caso de una conexión existente, Cloudflare aún obtiene mejores resultados:

Los resultados de la comparación de Zscaler y Cloudflare están más igualados en los grupos de latencia más baja. Sin embargo, los tiempos de respuesta de Cloudflare son mucho más coherentes. Puedes constatar que la mitad de las respuestas de Zscaler tardan casi un segundo en cargarse. Esto destaca aún más lo bien conectados que estamos: puesto que estamos en más ubicaciones, proporcionamos una mejor experiencia de la aplicación, y no tenemos tantos casos límite con alta latencia y un bajo rendimiento de la aplicación.

Queremos separar las sesiones nuevas y las sesiones existentes porque es importante analizar rutas de solicitud similares para realizar la comparación correctamente. Por ejemplo, si comparáramos una solicitud mediante Zscaler en una sesión existente y una sesión mediante Cloudflare en una sesión nueva, podríamos observar que Cloudflare es mucho más lento que Zscaler debido a la necesidad de autenticación. Por lo tanto, cuando hemos contratado a un tercero para diseñar estas pruebas, nos hemos asegurado de que tenían esto en cuenta.

Para estas pruebas, Cloudflare ha contratado a Miercom, un tercero que ha llevado a cabo un conjunto de pruebas cuyo objetivo era replicar un usuario final que se conecta a un recurso protegido por Cloudflare o Zscaler. Miercom configuró las instancias de la aplicación en 14 ubicaciones de todo el mundo, y diseñó una prueba que iniciaría sesión en la aplicación mediante distintos proveedores Zero Trust para acceder a un contenido específico. A continuación describimos la metodología de la prueba, pero puedes leer todo el informe de Miercom donde se detalla la metodología de la prueba aquí:

• El usuario se conecta a la aplicación desde un navegador que imita una instancia de Catchpoint - sesión nueva.

• El usuario se autentica en el proveedor de identidad.

• El usuario accede al recurso.

• El usuario renueva la página del navegador e intenta acceder al mismo recurso pero con credenciales ya existentes - sesión existente.

Esto nos permite comparar Cloudflare vs. Zscaler en cuanto al rendimiento de la aplicación tanto para sesiones nuevas como para sesiones existentes, y nos muestra que somos más rápidos. También somos más rápidos en los escenarios de la puerta de enlace web segura.

Tanto el escenario de la puerta de enlace web segura como el del acceso Zero Trust pueden estar más protegidos con el aislamiento remoto del navegador (RBI). RBI ofrece un método sin cliente para proteger el acceso a los datos en una aplicación y protección contra amenazas al explorar los recursos en la red pública.

Los productos de aislamiento remoto del navegador tienen una fuerte dependencia de la red pública: si tu conexión al producto de aislamiento remoto del navegador no es buena, tu experiencia con el navegador te parecerá rara y lenta. El aislamiento remoto del navegador depende extremadamente del rendimiento para que la experiencia de los usuarios sea fluida y normal: si todo es tan rápido como debería, los usuarios no deberían notar que están utilizando esta función. Para esta prueba, enfrentamos Cloudflare Browser Isolation a Zscaler Cloud Browser Isolation.

Cloudflare es, una vez más, más rápido que Zscaler en el rendimiento del aislamiento remoto del navegador. Comparando el tiempo hasta el primer byte del percentil 95, Cloudflare es un 45 % más rápido que Zscaler en todas las regiones:

ZT RBI - Tiempo hasta el primer byte (global)

Percentil 95 (ms)

Cloudflare

2072

Zscaler

3781

Cuando comparas el tiempo de respuesta total o la capacidad de un producto de aislamiento de navegador de devolver una respuesta completa al usuario, Cloudflare aún es un 39 % más rápido que Zscaler:

ZT RBI - Tiempo hasta el primer byte (global)

Percentil 95 (ms)

Cloudflare

2394

Zscaler

3932

Aquí realmente la red de Cloudflare brilla con luz propia para ayudar a proporcionar la mejor experiencia de usuario a nuestros clientes. Puesto que la red de Cloudflare está increíblemente bien emparejada cerca de los dispositivos de los usuarios finales, podemos reducir tanto nuestro tiempo hasta el primer byte como nuestro tiempo de respuesta. Esto ayuda a mejorar la experiencia del usuario final.

Para medir esto, volvimos a recurrir a Miercom para que nos ayudara a obtener los datos que necesitábamos. Los nodos de Catchpoint se conectan a Cloudflare Browser Isolation y Zscaler Cloud Browser Isolation en todo el mundo desde las mismas 14 ubicaciones, con dispositivos que simulan clientes que intentan acceder a las aplicaciones mediante los productos de aislamiento de navegador en cada configuración regional. Para obtener más información sobre la metodología de la prueba, puedes consultar ese mismo informe de Miercom, enlazado aquí.

En un entorno que no era Zero Trust, tú y tus equipos informáticos erais los operadores de la red, lo que os proporcionaba la capacidad de controlar el rendimiento. Aunque este control era tranquilizador, también era una carga enorme para los equipos informáticos, que tenían que administrar las conexiones de milla intermedia entre las oficinas y los recursos. Por el contrario, en un entorno Zero Trust, tu red es ahora… la red pública. Esto implica menos trabajo para tus equipos, pero mucha más responsabilidad para tu proveedor Zero Trust, que debe gestionar el rendimiento para cada uno de tus usuarios. Cuanto más mejore tu proveedor Zero Trust el rendimiento de extremo a extremo, mejor será la experiencia de tus usuarios y menor el riesgo al que estarás expuesto. En el caso de aplicaciones en tiempo real como las de autenticación y las puertas de enlace web seguras, una experiencia de usuario ágil es fundamental.

Un proveedor Zero Trust no solo debe proteger a tus usuarios en la red pública. También debe optimizar la red pública para garantizar que tus usuarios están continuamente protegidos. La adopción de Zero Trust no solo reduce la necesidad de redes corporativas. También permite un tránsito más natural del tráfico de los usuarios a los recursos. Sin embargo, puesto que tu proveedor Zero Trust será quien proteja a todos tus usuarios y todas tus aplicaciones, el rendimiento es un aspecto fundamental a evaluar para reducir las dificultades de tus usuarios así como la probabilidad de que estos se quejen, de que sean menos productivos o de que desactiven las soluciones. En Cloudflare mejoramos constantemente nuestra red para garantizar siempre a los usuarios la mejor experiencia. Esto es el resultado no solo de corregir el enrutamiento, sino también de ampliar la distribución de emparejamientos y de añadir nuevas ubicaciones. Gracias a estos esfuerzos constantes, somos el proveedor Zero Trust más rápido.

Consulta nuestra página de comparación para obtener más información sobre la comparación entre la arquitectura de red de Cloudflare y Zscaler.