1. Introducción a HTTP y Node.js
Hoy voy a hablar sobre clientes HTTP, servidores y cómo mejorar el rendimiento de nuestro cliente HTTP en Node.js. Tengo un buen entendimiento de las necesidades de los usuarios y mantengo Node.js. Como parte de mi trabajo, trabajo con servidores en la nube y tengo experiencia en la construcción de aplicaciones rápidas y escalables en Node.js. También soy coautor de Fastify.
Hola a todos. Soy Matteo Collina y hoy voy a hablarles sobre HTTP. clientes, servidores, tal vez microservicios un poco, y cómo podemos duplicar o incluso triplicar el rendimiento de nuestro cliente HTTP en Node.js.
Primero, un poco sobre mí, soy Matteo Collina. Soy parte del comité técnico de Node.js. Soy el co-creador del framework web FASTI5 y PinnoLogger. Soy arquitecto de software y consultor de profesión, y, ya saben, soy director técnico en NearForm. Síganme en Twitter en Matteo Collina.
Así que un par de notas. También tengo tal vez 6 mil millones de descargas en NPM durante todo el 2020. No sé. Me quedé totalmente asombrado por esto. Tal vez sé de lo que estoy hablando, tal vez no. Tú decides lo que quieras creer.
Entonces, lo que hago normalmente es ayudar a las empresas a construir aplicaciones rápidas y escalables en Node.js. Esto es una de las cosas clave de lo que hago como parte de mi trabajo. También soy parte de los mantenedores de Node.js y una parte clave de su ecosistema con 6 mil millones de descargas al año. Probablemente tengo una buena comprensión de las necesidades de nuestros usuarios y de lo que se quejan, y así sucesivamente. Necesito equilibrar todo el tiempo esas dos cosas. Por un lado, ayudar a nuestros clientes y por otro lado, mantener Node.js. Esto me da mucha perspectiva sobre lo que puedo hacer, lo que necesito hacer para el desarrollo de aplicaciones en Node.js si es un ecosistema. Así que las dos partes de mi trabajo se refuerzan mutuamente hasta cierto punto.
Como parte de mi trabajo, la mayor parte del tiempo trabajo con servidores en la nube. Entonces hay un cliente, típicamente un navegador web o una aplicación móvil que se comunica con la nube y, específicamente, con un servidor, que puede ser múltiples instancias, pero sigue siendo lo mismo que se ejecuta. Es lo que llamamos un monolito en este momento. Saben, también escribí— Como dije, soy coautor de Fastify, así que aquí va un poco de publicidad. Usen esta cosa. En realidad funciona muy bien. Esta tarea no está actualizada. Ah, lo siento.
2. Introducción a Microservicios y Node Core HTTP
Esta parte discute el uso de un servidor web rápido y un marco de trabajo para Node.js, que es adecuado para construir aplicaciones pequeñas y grandes, incluyendo monolitos y microservicios. El orador destaca la necesidad de los microservicios para escalar equipos y evitar responsabilidades superpuestas. También abordan el problema de la comunicación excesiva en los sistemas de microservicios y enfatizan la importancia de la comunicación entre los microservicios. El orador luego presenta el Node Core HTTP como el enfoque de la presentación, explicando su papel como respaldo para los clientes HTTP populares. Discuten el proceso de creación de un socket TCP y la latencia potencial involucrada. Además, mencionan el concepto de la ventana de congestión para los nuevos sockets.
Entonces, básicamente, este es un servidor web muy rápido, un marco de trabajo para Node.js. Puedes construir aplicaciones pequeñas y grandes con esto, y funciona muy bien tanto para monolitos como para microservicios.
Ahora, ¿por qué necesitarías microservicios? Porque necesitas escalar equipos. Los microservicios son una forma clara de escalar equipos para que puedas tener diferentes equipos que mantengan diferentes partes de tu sistema y evitar que se superpongan entre sí. Es realmente genial.
Sin embargo, uno de los problemas de los sistemas de microservicios es su comunicación excesiva. De hecho, todos los microservicios se comunican mucho entre sí, y necesitas llamar a datos que son administrados por otros microservicios. Así que hay mucha comunicación entre los diversos microservicios. A veces, alguien lo llama una malla de microservicios. Y en lo que nos vamos a enfocar la mayor parte del tiempo en esta presentación es en este enlace entre microservicios. He estado investigando este problema durante tres, cuatro, cinco años, algo así. Ha estado madurando en mi cabeza durante algún tiempo.
Puedes tener un servidor HTTP con todo, todos pueden trabajar, incluso los más básicos. Así que consideremos un servidor muy simple en el que simplemente hacemos un pequeño tiempo de espera de un milisegundo. Muy simple. Esto simula una base de datos muy rápida que siempre nos responde con `hola mundo` en un milisegundo. Es genial. Y un cliente HTTP, el Node Core HTTP. ¿Por qué nos enfocamos solo en el Node Core HTTP? Bueno, porque Axios, Node fetch, request got, todos lo usan como respaldo. Es genial. Y cada vez que haces esas cosas que estamos haciendo, ya sabes, crean un socket TCP.
Entonces, básicamente, cuando abres un socket TCP, necesitas hacer un pequeño baile. Esto suele ser una ronda completa para establecerlo, lo cual es bastante, ¿vale? Porque, ya sabes, dependiendo de la latencia, la distancia física entre los dos, incluso puede llevar algo de tiempo. Puede ser de 10, 20 milisegundos, algo así. Estamos hablando de números muy pequeños. Pero recuerda, tal vez tienes 200 milisegundos para responder a tu cliente o tal vez 400, lo que quieras. Pero, ya sabes, cuantas más esperanzas hagas, mayor será tu latencia. Así que no quieres perder tiempo porque no has... Una vez que se ha establecido el 3NShake, ni siquiera has transferido ningún dato, ¿verdad? Solo has creado el socket. Ten en cuenta que si estás utilizando TLS o SSL, lleva aún más tiempo. Pero eso no es todo, porque una vez que creas un socket TCP, de hecho, hay un concepto que se llama ventana de congestión, que se considera lento al principio para los sockets nuevos establecidos.
3. Understanding TCP and Latency
El servidor envía bytes al cliente, que luego debe confirmar su recepción. A medida que la ventana de congestión crece, se pueden enviar más bytes sin necesidad de confirmación. El éxito de TCP radica en su capacidad para funcionar en redes con ancho de banda variable. La necesidad de confirmaciones surge para evitar la pérdida de datos, pero introduce latencia.
¿Por qué? Esto significa que necesitas hacer más de un viaje de ida y vuelta para mover la misma cantidad de
data, porque, ya sabes, la ventana de congestión te indica cuánto debe enviar el servidor antes de que el cliente pueda enviar un hack, o enviarme más, básicamente. Entonces, lo que sucede a la izquierda, como puedes ver a la izquierda, es que el servidor envía algunos bytes, luego el cliente necesita confirmar su recepción y luego envía más bytes, y así sucesivamente. Una vez que la ventana de congestión se ha vuelto más grande, de hecho, puede enviar una gran cantidad de bytes sin necesidad de confirmación. Esta es la razón por la cual TCP es tan exitoso, por cierto, porque le permite funcionar en redes con un ancho de banda muy pequeño o muy alto. ¿Por qué necesitarías todos esos hacks? Porque si pierdes algún mensaje en el medio, esta es la cantidad máxima de
data que perderás. Sin embargo, esto tiene un costo.
4. Maximizing Performance with HTTP Keep-Alive
Para maximizar el ancho de banda, es crucial reutilizar las conexiones existentes para evitar perder el trabajo realizado por la capa de red. En Node.js, la función HTTP 1.1 llamada KEEPALIVE permite reutilizar los sockets HTTP, lo cual es especialmente importante para TLS. Al utilizar clientes HTTP con Keep-Alive activado, podemos aumentar el rendimiento y el rendimiento de nuestras aplicaciones. Para probar esto, se utilizó un escenario con un cliente que realiza 500 solicitudes paralelas a un servidor, y los resultados mostraron mejoras significativas. Sin embargo, es importante tener en cuenta que estos resultados pueden variar según el sistema, por lo que se recomienda ejecutar pruebas de referencia para medir el impacto real.
que es la latencia. Por lo tanto, uno de los problemas clave con esto es que si deseas tener el máximo ancho de banda, debes reutilizar la conexión existente. Una vez que hayas establecido una conexión, envía algunos
data, aumenta la ventana de congestión, esto crece con el tiempo, por cierto, que es genial, una de las mejores características de TCP, debemos reutilizar la conexión existente. Si no reutilizas las conexiones, estás perdiendo todo el trabajo que se hizo por ti en la capa de red. Para hacer esto en
Node.js, debes usar una función HTTP 1.1, que se llama KEEPALIVE, que puedes ver aquí. Puedes ver KEEPALIVE true y puedes establecer el número máximo de conexiones para MANTENER ABIERTAS. Esto te permite reutilizar los mantener los sockets, tus sockets HTTP para mantenerlos activos. Más importante aún, es aún más importante con TLS, porque en realidad puedes evitar el establecimiento completo del contexto criptográfico, el contexto seguro entre los dos. Por lo tanto, es realmente muy, muy importante también para TLS.
Entonces, esta es la teoría. Deberíamos poder aumentar nuestro rendimiento, nuestro rendimiento en nuestras aplicaciones simplemente utilizando clientes HTTP con Keep-Alive activado. ¿Es este el caso? ¿Es este el caso? Bueno, veamos. Escenario. Tenemos un cliente que llama a un servidor con 500 solicitudes paralelas en la misma ruta. Y más o menos esto es igual que 500 solicitudes entrantes paralelas. Y el servidor objetivo tarda 10 milisegundos en procesar la solicitud y tiene un límite de 50 sockets. Así que esto es completamente sintético, ¿de acuerdo? No coincide con tu sistema, así que siempre mide estas cosas. No confíes en mí. Ejecuta tus pruebas de referencia.
5. HTTP 1.1 Pipelining and Reliability
Siempre utiliza un agente. La canalización de HTTP 1.1 es una función poco conocida que se puede utilizar en el servidor pero no en el cliente HTTP de Node.js. Sufre de bloqueo de cabeza de línea y solo funciona para archivos pequeños. No funciona bien en enlaces poco confiables, pero es menos problemático en centros de datos confiables.
Ahora, esta es la diferencia entre los dos. Así que si olvidas algo de esta charla, siempre utiliza un agente. Eso es todo. Esa es la única cosa que necesitas recordar. Siempre utiliza un agente. La diferencia es tan grande que ni siquiera puedes considerar no usar uno.
Pero ¿podemos seguir mejorando las cosas? Porque he estado investigando este tema durante un tiempo, así que podría tener algo más que decir hasta cierto punto. Bueno, sí, podemos. De hecho, hay algo que se llama canalización de HTTP 1.1. Ahora, esta es una de las características más desconocidas de HTTP 1.1, y decir que no se debe usar esto es incorrecto. El navegador no lo usa, no es compatible con el navegador, pero es parte del estándar, y en realidad se puede usar en el servidor. Entonces, el servidor HTTP de Node.js admite la canalización de forma predeterminada, no necesitas hacer nada para habilitarla. Sin embargo, el cliente HTTP de Node.js no, por lo tanto, necesitas hacer algo más, no utilizarás esta técnica.
En la canalización de HTTP 1.1, todas las respuestas deben recibirse en orden. Esto significa que estás sufriendo de bloqueo de cabeza de línea, y una solicitud lenta puede detener la canalización. Entonces, básicamente, si la primera solicitud que haces es muy lenta, o las otras solicitudes se acumularán, esperando a que la primera termine. Esto es un problema. La canalización de HTTP solo funciona para archivos pequeños. Entonces, el problema siempre son las retransmisiones. Entonces, en el momento, si comienzas a perder un paquete y un paquete, todo se vuelve loco. Entonces, en realidad no puedes hacer nada Lo siento. No funciona realmente bien en enlaces poco confiables. Sin embargo, nuestros propios data centros son enlaces confiables. Entonces, si necesitamos llamarlos de un microservicio a otro, esos enlaces, esas conexiones, esos sockets son realmente confiables. No fallan. No es como si alguien estuviera moviéndose con su iPhone y estuviera conectado con diferentes celdas, por lo que la conexión se activa y desactiva. Esto es en realidad... Sabes, son muy confiables en el centro de data. Entonces, esto es menos problemático en el centro de data.
6. Node.js Event Loop and Performance
El bucle de eventos de Node.js funciona programando las E/S para que se realicen de forma asíncrona. El bucle de eventos espera a que ocurra algo y luego realiza una llamada de vuelta a C++. Para mejorar el rendimiento de la aplicación, es importante minimizar el tiempo de bloqueo del bucle de eventos. Se pueden utilizar gráficos de llamas para visualizar y minimizar las llamadas de función.
Ahora, una cosa más de la que preocuparse. Es realmente importante tener en cuenta cómo funciona el bucle de eventos de Node.js. Entonces, cada vez que obtienes un socket TCP, cada vez que hacemos cualquier E/S, básicamente, tu código JavaScript programa alguna E/S para que se realice de forma asíncrona. Y luego realiza una llamada de vuelta y comienza en la cola de eventos. En la práctica, ¿qué significa esto? Esto significa que el bucle de eventos está esperando a que ocurra algo. Luego realiza una llamada de vuelta a C++, y desde C++ realiza una llamada a JavaScript, y desde JavaScript, termina, realiza la siguiente iteración, realiza promesas y así sucesivamente, termina C++, y luego comienza nuevamente el bucle de eventos. Ahora, hay un momento entre estos dos donde el bucle de eventos está bloqueado. Cuando se ejecuta la función C++ y JavaScript. Entonces, ¿qué significa esto? Significa que si queremos mejorar el rendimiento de nuestras aplicaciones, necesitamos minimizar el tiempo en el que estamos bloqueando nuestro bucle de eventos. Y básicamente, es la estrategia clave para aumentar el rendimiento. Y realmente puedes usar gráficos de llamas, usar gráficos de llamas para visualizar las funciones y minimizarlas. Es bastante genial,
7. Timeouts, Echo Resets, and Introducing Undici
Ahora, este es uno de los problemas que estamos tratando de resolver: los tiempos de espera y los reinicios de eco. Si usas agentes, es posible que te encuentres con reinicios de eco y tiempos de espera. El problema es que un socket puede morir y quieres minimizar esto. Por defecto, Node.js utiliza una estrategia FIFO, pero recientemente se agregó una nueva estrategia de programación llamada LIFO al agente HTTP en Node.js. Este enfoque LIFO minimiza los tiempos de espera y los reinicios de eco reutilizando los sockets que funcionaron la última vez. Ahora, permíteme presentarte una nueva biblioteca llamada undici, que proviene de http 1.1.11 y se traduce como 'once' en italiano.
funciona muy bien. Ahora, este es uno de los problemas, ¿verdad? El siguiente que estamos tratando de resolver, y este es el punto extra, son los tiempos de espera y los reinicios de eco. Entonces, si usas agentes, está bien, es posible que te encuentres con reinicios de eco. Y ¿qué son esos, y los tiempos de espera? Entonces, el problema es que un socket, si los estás usando, puede morir. Y si mueren, lo que necesitas hacer es reprogramarlos. Entonces, si mueren, es un problema, porque puede suceder y puedo decir, oh, estoy enviando
data en este socket. Estoy tratando de reutilizar lo. Cuando lo uso, muere. Ya no está disponible. Estoy obteniendo un registro de eso. Es realmente malo. Entonces, lo que quieres hacer es minimizar esto. Por defecto, la estrategia original para
Node.js era FIFO primero en entrar, primero en salir, lo que significa que estaba reutilizando todos los sockets para tratar de crear la menor cantidad. Ahora, el problema con ese enfoque es que todos los sockets son los más propensos a agotarse porque son antiguos. Y así, recientemente, agregamos una nueva programación para el agente HTTP en
Node.js. Se llama LIFO. Es una estrategia diferente. Último en entrar, primero en salir significa que el último que usaste, intentamos usarlo. Lo que significa que en realidad vamos a crear más sockets porque, esencialmente, dejamos que más sockets expiren. Sin embargo, con el enfoque LIFO, realmente se minimiza la cantidad de tiempos de espera y reinicios de eco porque en realidad vas a reutilizar los sockets que funcionaron la última vez. Entonces sabes que esto funciona. Está ahí. Entonces es mucho, mucho más probable que tu solicitud se realice. Bien, ya conocemos todas estas cosas. Permíteme presentarte una nueva biblioteca llamada undici. Entonces, ¿qué es undici? Bueno, undici proviene de http 1.1.11. Y sabes que 11 es una palabra secular, ¿verdad? Pero en italiano significa 'once'.
8. Introducción a Undici
Undici es un nuevo cliente para node.js que utiliza las funciones internas de Node Core. Admite tanto HTTP como HTTPS, utiliza la programación lithos y permite conexiones ilimitadas. Elimina la necesidad de múltiples agentes y ofrece opciones de configuración sencillas.
Undici significa undici. Así que puedes traducir 11 como undici. Por eso se llama undici. Y también sabes que es una referencia a Stranger Things, por si te lo estabas preguntando. Entonces, ¿qué hace undici? Undici es un nuevo cliente para
node.js implementado desde cero utilizando las funciones internas de Node Core. Es genial. Puedes usarlo con un agente global que mantendrá viva tu conexión de forma predeterminada. Utiliza la programación lithos, no utiliza pipelining y permite conexiones ilimitadas. Por lo tanto, funcionará más o menos de la forma en que estás acostumbrado. Admite tanto HTTP como HTTPS al mismo tiempo. No es necesario hacer malabarismos con múltiples agentes y cosas por el estilo. Simplemente lo hace todo. Y eso es bastante genial. Incluso puedes configurar agentes HTTP en el agente. Puedes configurarlo o usarlo directamente. Funciona muy bien, desde mi punto de vista. Puedes crear un conjunto de pipelining, establecer el número de conexiones para cada dominio, y así sucesivamente. Incluso puedes usar el pool. El pool es lo que el agente utiliza para comunicarse con un solo host, por lo que puedes crear un solo cliente HTTP. Puedes crear un solo pool para un solo destino y realizar las solicitudes utilizando ese pool. Y esto es bastante genial. Incluso puedes crear un solo cliente, que es básicamente una sola conexión. Tiene diferentes métodos, por lo que puedes hacer una solicitud, puedes hacer un stream, hay otros que son aún más rápidos. Son bastante geniales. Todos son bastante geniales. Básicamente, están ahí para minimizar la sobrecarga en caso de que lo necesites. ¿Cómo se compara undici con el cliente HTTP de Node Core? Bueno, en realidad es muy rápido. Y cuando activas el pipelining, puedes llegar a obtener hasta 3 veces lo que haría un cliente HTTP de Node Core con Kipallite. Undici también es mucho más estricto en términos de HTTP, así que hay esa diferencia. He hecho algunas pruebas y con undici, un buen pool de conexiones y una buena configuración, realmente puedes obtener muy buenos resultados, y realmente funciona muy, muy bien. Resolvió mi problema con el proxy HTTP de
Fastify. Gracias por aguantarme durante esta larga charla, y esto es lo que debes recordar, siempre usa un agente HTTP o HTTPS. Puedes usar undici para reducir drásticamente la sobrecarga de tu sistema distribuido, pero tendrás que hacer algunas pruebas porque esta es una nueva API. Y quiero agradecer a Robert Nagy que básicamente tomó undici y lo hizo listo para producción, porque fue un trabajo fantástico, Robert, gracias. También necesitamos ayuda, más pruebas, hay un undici fetch que está siendo desarrollado por Ethan, así que es bastante genial, para ser honesto, y hay un futuro brillante por delante para undici. Me gustaría recomendarte un libro, este es realmente un libro importante de Ilia Grigorik, deberías leerlo, es una obra maestra, por favor. También hay una guía de eventos, échale un vistazo, y luego está
Fastify y Undici. Gracias, soy Matteo Collina, y soy un guía técnico para Uniform. Muchas gracias. ¡Adiós!
Node Congress 2023
