Cloudflare TV

Estas Semanas en Cloudflare en Español

Presented by Alex Mayorga Adame
Originally aired on 

Learn about the latest in the world of Cloudflare and the Internet — presented in Spanish by Alex Mayorga.

Spanish
News

Transcript (Beta)

Hola, ¿qué tal? Bienvenidos a estas semanas en Cloudflare en español. Buenos días, buenas tardes o buenas noches.

Donde quiera que nos estén viendo hoy en vivo o reproduciendo la transmisión de este programa de Cloudflare TV.

Bueno, como quizás ya sabrán por las transmisiones anteriores, esta semana en Cloudflare es la Semana de la Velocidad y vamos a revisar un poco las novedades publicadas en el blog acerca de esta Semana de la Velocidad.

Tenemos para comenzar un blog de nuestro CTO John Graham Cunning en donde hacemos un benchmark del desempeño de la red contra algunos competidores de Cloudflare.

Bueno, comienza John haciéndonos un resumen de varios de los anuncios que tuvimos en esta semana, como el lanzamiento de Argo 2.0, la presentación de Orpheus, la presentación del servicio de optimización de imágenes, así como las expansiones en la red que se hicieron y el crecimiento de la red de Cloudflare en un incremento de 25%, como nos menciona aquí.

Pero bueno, nos cuenta que solo anunciar mejoras no es necesariamente la mejor forma de incrementar el desempeño y por eso nos cuenta cómo se inició este proyecto de hacer mediciones con el desempeño real para los usuarios finales.

Bueno, el blog de John es súper detallado, los invito a revisarlo a conciencia cuando tengan un minuto disponible.

Pero bueno, nos cuenta aquí que se hicieron mediciones a través de las mil redes más grandes en Internet y también que se hicieron mediciones ya sea a la media y al percentil 95 en este caso.

Nos da una explicación un poco de por qué decidimos hacer estas mediciones independientemente.

Nos cuenta aquí que Cloudflare tiene algunos proveedores de mediciones que ya utilizamos, pero se decidió hacer este análisis para tener una visión más detallada a nivel de cada una de las redes que hay en Internet.

Después nos va contando bien a detalle nuevamente cómo se realizaron todas estas mediciones.

Vemos aquí los días en que se realizaron, la forma en que se midió, nos indica aquí que la medición se hizo con un archivo PNG de 100 kilobytes y también que nos explica un poco la parte de la identificación de las redes o los sistemas autónomos.

Y bueno, nos detalla también que se seguirán haciendo estas mediciones y obviamente optimizando las mismas conforme vayamos progresando en mejorar este desempeño.

Bueno, nos cuenta John también que actualmente hay más de 70 mil sistemas autónomos, pero no todos estos se observan con tráfico.

Nos cuenta aquí que se observaron 21 mil de ellos, nos deja el número exacto, que fueron 20 mil 728 sistemas autónomos.

Y nos cuenta que la razón de esto es que no todas las redes se observan externamente, sino que muchas simplemente transmiten tráfico entre una y otra.

Después nos cuenta que se utilizó esta API que se llama Resource Timing, que está disponible, nos menciona en la mayoría de los navegadores y que es precisa hasta 5 microsegundos.

Aquí nos deja un poco un diagrama de cómo funciona una solicitud, en este caso vemos que se revisan los cachés, se hace el DNS, la conexión de TCP, se hace la solicitud y se envía la respuesta, que es lo que se está midiendo con esta API en todos los browsers.

Nos deja aquí un poco el código que se utilizó para realizar estas mediciones.

Y nos cuenta que se midió la conexión de TCP, el tiempo del primer byte y el tiempo del último byte.

Y nos deja ahí una descripción bien exacta de cada uno de estos.

Después, bueno, ya empezamos a ver más a fondo, nos explica un poco de las tablas o los cuadros que se generaron en este caso, midiendo, como ya decíamos, las mil redes más grandes por cuenta de IPs.

Y se cuenta, por ejemplo, aquí en cuántas de esas redes cada uno de los proveedores obtuvo mejores resultados.

Vemos en esta tabla que en el caso de Cloudflare, pues casi 400 de las redes se obtuvieron el tiempo al primer byte en el %95 en Cloudflare.

Después ahí vemos a otros competidores como Google Fastly, Cloudfront y Akamai.

Y bueno, esto muestra que en el caso de esta particular medición, Cloudflare tiene el tiempo más bajo de respuesta en la mayoría de las redes.

Después también nos cuenta un poco más en algunos operadores en particular, en los Estados Unidos, como vemos ahí, a Cox y Comcast listados.

Y nos da los detalles de sus números de redes y las mediciones exactas en milisegundos.

Por ejemplo, podemos ver ahí que Cloudflare tuvo 332.6 milisegundos, seguido de Fastly con 357.6, Google con 380.3, Cloudfront de Amazon con 404.4 milisegundos y Akamai con 441.5 milisegundos.

Bueno, ahí demostrando o indicándonos que Cloudflare fue 7% más rápido que el siguiente competidor.

Y también mismo detalle con Comcast, que en este caso Cloudflare fue más rápido por 0.2%.

Y bueno, finalmente vemos las tablas que ya mencionábamos. Nos cuenta también ahí John, que obviamente por la precisión de las mediciones, no en todas Cloudflare es el más eficiente, pero nos cuenta también cómo estaremos trabajando para lograr tener el número uno en todas estas mediciones.

Y bueno, las tablas ahí las pueden revisar en el blog, directamente en blog.Cloudflare.com.

Y también tenemos las mediciones en el tiempo al primer byte, que en este caso, como podemos ver, Cloudflare es el más rápido en todas ellas.

Igualmente en la mayoría de las tablas de tiempo al último byte, exceptuando una acá que tenemos, en donde Fastly es más rápido en más redes.

Y bueno, nos cuenta lo que se interesará estar optimizando a nivel de la red para lograr que estas mediciones sean, como mencionábamos, Cloudflare aparezca como el número uno en todas ellas.

Después nos deja acá un mapa en donde vemos una distribución por países, en donde cada uno de los competidores es más rápido.

Como podemos ver, la mayoría del mapa está cubierto de naranja en este caso, porque Cloudflare en todos esos países es más rápido.

Y bueno, nos cuenta aquí también un caso específico de Indonesia, donde vemos que en este caso en particular, en la red de Biznet, Cloudflare está teniendo el primer byte en 677.7 milisegundos, seguido de Fastly con 744 milisegundos, Google con 872.8 milisegundos, Cloudflare de Amazon con 1.239.9 milisegundos y finalmente Akamai con 1.248.9 milisegundos.

Para cerrar el blog, John nos platica que estará todo el equipo trabajando en mejoras en el desempeño, aquí indica en el 10% de las redes en las que actualmente no somos el número uno, con la intención de mejorar en todas esas tablas que ya veíamos arriba.

Y bueno, nos promete estas mejoras para la semana de cumpleaños de Cloudflare.

Seguimos en el blog, tenemos un blog de Joao, que nos anuncia el proyecto Torpentine, que es una forma fácil de remover Varnish en este caso.

Bueno, nos cuenta un poco sobre la historia de Varnish y su lenguaje de configuración, conocido como VCL, que nos cuenta fue presentado hace ya cerca de 15 años y que se utilizaba para configurar el caching en los servidores.

Bueno, y nos cuenta que desde que esta tecnología fue presentada, pues ha habido muchos cambios en Internet y ahora tenemos las CDNs que se espera que hagan, por ejemplo, balanceo de carga, protección contra denegación de servicio, servicios de limitación de velocidad, respuestas sintéticas, transformaciones, ruteo y muchas más cosas.

Entonces, nos cuenta aquí que no todo mundo sabe utilizar este tipo de configuraciones con Varnish y como es un poco una tecnología de nicho en este caso.

Y bueno, también nos cuenta que la tecnología, dado los avances en otras tecnologías, se vieron estresadas a hacer cosas que normalmente no hacían y lo mismo causa algunas frustraciones que algunos clientes de Cloudflare nos han expresado y bueno, esto fue lo que dio la razón de crear este proyecto Turpentine.

Nos cuenta aquí Joao que se trata de un convertidor de VCL a TypeScript y también cómo convierte las configuraciones para que sean las más efectivas y eficientes utilizando este lenguaje más moderno como es TypeScript.

Nos cuenta que, bueno, esto utiliza Workers que como quizás ya sepan es la plataforma más rápida de serverless actualmente.

Vemos aquí un poco de una conversión que ya está hecha y nos detalla Joao cómo se hace, se hace el parsing de la configuración no es una transcripción exacta pero se busca siempre aplicar la mejor solución disponible de forma nativa en Cloudflare.

Se hace también una limpieza y optimización del código en donde se remueve cualquier ineficiencia o redundancia y bueno, nos vuelve a mencionar la parte de que la configuración estará corriendo en Workers que es la plataforma más rápida en el mundo actualmente.

Y finalmente se hace una impresión que sea fácil de leer para los humanos.

Acá nos cuenta que, bueno, que el proyecto Torpentine se encuentra en beta privada con algunos de nuestros clientes y también nos deja acá un enlace si están interesados en participar en la beta pueden hacer click en este enlace y contactarnos para participar en la beta.

Seguimos con otro blog de Alex que nos presenta Early Hints que es una forma en la que Cloudflare puede optimizar la carga de sitios web hasta 30%.

Nos cuenta que también, bueno, esta es otra beta que se anunció esta semana, entonces si están interesados en tenerla la pueden activar en la pestaña de velocidad de su dashboard de Cloudflare y nos cuenta que está disponible para todos los clientes de manera gratuita porque obviamente uno de los intereses de Cloudflare como parte de nuestra misión de ayudar a construir un mejor Internet es obviamente hacerlo más rápido para todos.

Nos cuenta Alex un poco sobre Early Hints. Básicamente Early Hints es un nuevo código de estado de HTTP que es el código 103 que permite enviar estos códigos a los clientes antes de enviar el código 200 de OK o no tener errores y esto para indicarles a los clientes lo que pueden ir cargando.

Acá está un poco un diagrama de cómo esto funciona.

El cliente hace un GET. El Cloudflare en su caso podría solicitarlo al servidor pero mientras se está enviando la respuesta 200 tanto cliente como servidor están intercambiando estos Early Hints para indicarle al cliente lo que puede precargar en este caso y sin tener que esperar la respuesta de 200 en este caso para poder de una manera más eficiente y rápida empezar a dibujar la página.

Nos cuenta aquí que por el momento este es experimental pero ya está trabajando.

Uno de los beneficios de tener Cloudflare en la red de borde de Cloudflare es que esta se encuentra más cercana a nuestros usuarios y podemos hacer este tipo de mejoras directamente sin hacer modificaciones en los servidores de origen.

Nos muestra aquí con un diagrama un poco de los tiempos de espera que se harían en una carga de una página y obviamente la intención de Early Hints es hacer que estas cargas sean paralelas.

Nos deja aquí también un comentario de Colin Bendel que es el director de Desempeño e Ingeniería en Shopify que nos cuenta que en este caso cuando hay un aumento en la velocidad de respuesta de la primera página en un 10% se tiene hasta un 7% más de conversiones en los visitantes.

Y nos deja aquí un poco cómo funcionan estos códigos de respuesta que está enviando basados en la parte del link de cada uno de ellos donde vemos que tienen preload.

Se envían estos con el 103 antes de enviar el código 200 de OK. Nos cuenta que esto no es necesariamente una idea nueva sino que ya también existía con server push en HTTP 2.

Pero nos cuenta que algunos navegadores están considerando deprecar server push porque en los casos de la vida real no se ve que haya sido ampliamente implementado o que sea eficiente en la mayoría de los casos.

Y nos cuenta que este tipo de cambios pueden también tener el problema del huevo o la gallina entonces como Cloudflare está trabajando para que este no sea el caso en el caso de Early Hints nos cuenta que está trabajando con partnerships en distintos navegadores como Chrome y otros browsers para que haya masa crítica en la adopción de Early Hints desde el comienzo.

Y también lo que comentábamos ya que se pueden activar directamente en Cloudflare sin tener que requerir soporte para tener Early Hints en los servidores origen.

Nos cuenta ahí también que se ha estado trabajando en colaboración cercana con Shopify en este caso.

Y aquí vemos un poco cómo funcionan los pasos de este proceso que nos cuenta, en este caso se tienen los headers de link que indican que haya preloading de ciertos recursos y entonces Cloudflare utiliza esos headers para enviarlos como Early Hints con la respuesta 103.

Y cuando hay subsecuentes solicitudes envía inmediatamente el Early Hint en este caso y después envía la respuesta completa del servidor con el código 200 en este caso.

Vemos aquí un poco los navegadores que lo estarán soportando.

Vemos Chrome, Edge y Firefox que han indicado que planean implementar Early Hints en cada uno de sus browsers y nos cuenta un poco cómo se puede ya probar en la versión de desarrollo de Chrome a partir de la versión 94 con estos argumentos.

Y también nos dice cómo se pueden hacer pruebas utilizando WebPageTest y nos deja los pasos exactos.

Entonces, si habilitan esto en sus sitios web podrán ver, como ya mencionaba Alex, hasta un 30% de mejora en el desempeño de su propiedad web.

Y nos deja también aquí los pasos de cómo activar la beta en nuestra cuenta de Cloudflare que la podemos hacer en la pestaña de velocidad y dentro de la subpestaña de optimización.

Entonces, también si hay algún ingeniero interesado en optimización, los invita Alex a unirse a nuestro equipo.

Seguimos con un blog de Kenny y Tim que nos hablan sobre la plataforma de Zero Trust de Cloudflare One y cómo esta fue creada pensando en que sea más veloz.

Bueno, como quizás ya sepan tenemos la oferta de Cloudflare for Teams que se ofrece para reemplazar aplicaciones o soluciones legadas de redes privadas y como una forma de hacer todo esto de manera más rápida.

Bueno, también nos cuenta que toda esta solución está creada en Workers que es la plataforma más rápida de serverless disponible actualmente.

Así como Gateway está creado sobre la misma tecnología que se utiliza en el resolver 1 .1.1.1 que es el más rápido actualmente en el mundo y por lo tanto tiene también estos beneficios de velocidad.

Y como esto obviamente hará más eficiente y rápida la navegación de sus usuarios en el caso de utilizar estas soluciones.

Bueno, nos cuenta sobre la migración de ya mencionábamos estos sistemas legados a una solución más rápida.

Vemos aquí un poco cómo funciona esto utilizando Cloudflare Tunnel. Conectamos la infraestructura que tengamos en nuestros centros de datos a la red de borde de Cloudflare y Cloudflare directamente conecta al dispositivo del usuario en su navegador.

Bueno, vemos aquí un poco la cobertura de la red que ahora está presente en 250 ciudades alrededor del mundo y a menos de 50 milisegundos del 95% de la población actualmente conectada a Internet.

Vemos también aquí un poco del diagrama del backbone de Cloudflare y las expansiones que se planean hacer y están en progreso.

Bueno, toca también sobre la parte de que está hecho en la plataforma serverless más rápida del mundo actualmente.

Lo que ya mencionábamos del resolver de 1.1.1 y como gateway utiliza las mismas tecnologías para hacer el resolver más rápido en este caso.

Y bueno, nos dejan aquí un poco unas gráficas sobre el desempeño contra algunos otros competidores como Cisco Umbrella, Cscaler, McAfee y Menlo.

Vemos aquí la línea de Cloudflare al fondo que en este caso, bueno, menor tiempo es mejor.

Nos dejan las mediciones ahí en 10 segundos y también con la solución de browser isolation.

Mismo caso, podemos ver en las distintas regiones cómo Cloudflare es más eficiente y tiene un menor tiempo de respuesta en todas estas gráficas que nos dejan aquí.

Finalmente, nos invitan a probar obviamente la solución que como se menciona aquí, estas herramientas están disponibles de manera gratuita para los primeros 50 usuarios y las pueden activar en el dashboard de Teams que localizan en dash.teams.Cloudflare.com.

Seguimos con el blog.

Tenemos un blog de Annika que nos cuenta un poco como la magia de hacer sus redes más rápidas.

Bueno, nos cuenta Annika sobre el lanzamiento, o nos recuerda más bien, sobre el lanzamiento de Magic Transit hace ya dos años y bueno, los recientes anuncios de Magic One y Magic Firewall y bueno, que son soluciones que ayudan a proteger su red.

Nos cuenta que, bueno, este blog como parte de la Semana de la Velocidad nos va a hacer una descripción más detallada de lo que lo hace que sea tan mágico en este caso.

Tenemos, bueno, nos cuenta Annika que Magic One puede reemplazar las soluciones legadas de Arquitecturas One a través de MPLS que pudieran tener los clientes.

Y, bueno, un punto importante que es el hecho de que todo esto se hace con Anycast, lo que nos permite crear este túnel GRE de un punto a todas las 250 locaciones de Cloudflare.

Nos cuenta también, bueno, que todos los servicios de Cloudflare se encuentran en todos los servidores en toda la red, lo que permite que sea más eficiente en lugar de tener que estar enviando tráfico a centros de limpieza o cosas por el estilo.

Nos cuenta también un poco sobre Cloudflare One que ya veíamos en el blog anterior de Kenny y de Tim.

Y, bueno, nos cuenta que al tener mejor conectividad se incrementa la velocidad de nuestro tráfico.

Vemos aquí algunas tablas de algunas mejoras en distintas ubicaciones, como podemos ver, mejoras de hasta 36% a nivel global y de hasta 13% en ciertas locaciones en el caso que se hizo esta prueba.

Nos cuenta cómo esta arquitectura se elimina las partes del trombón que se hace con el tráfico y básicamente que el hub de conexión se encuentra en absolutamente todos lados.

Vemos aquí todos los puntos de esta red se conectan directamente a la red global de Cloudflare, lo que hace que se hagan reducciones, como se ve en esta tabla, de la latencia de esta en un 70%.

Y, obviamente, con los anuncios de las mejoras de Argo Smart Routing, pues se hace aún más eficiente este proceso.

Nos deja aquí Annika los enlaces al anuncio de Argo 2.0 y también más detalles sobre Argo 2.0.

Ahí nos enlaza en dos ocasiones al blog.

Bueno, entonces, invitarles a contactarse con nosotros si las soluciones de Magic Transit pudieran ser de utilidad para ustedes.

Vamos a revisar si tenemos alguna pregunta que haya llegado.

En este caso parece ser que no hay ninguna. Y vamos a ver, creo que será el último blog que vamos a revisar el día de hoy.

Así es. Bueno, recordarles estar al pendiente de nuestro blog en blog.Cloudflare.com y, bueno, también si desean alguno de estos productos, pues pueden contactar a nuestro equipo de ventas con estos enlaces que se encuentran aquí arriba.

Mi nombre es Alex y les agradezco nuevamente por haberse sintonizado el día de hoy y los espero en la siguiente emisión de estas semanas en Cloudflare en Español.

Que tengan un excelente viernes y un excelente fin de semana.

Hasta luego. Subtítulos realizados por la comunidad de Amara.org Subtítulos realizados por la comunidad de Amara.org