Deep Dive into Undici

Hola a todos, soy Matteo Collina, cofundador y CTO de Platformatic, y hoy voy a profundizar en Undici, la nueva biblioteca HTTP construida por el equipo de Node Core. Unas pocas palabras sobre mí, soy parte del Comité de Dirección Técnica de Node.js, así como miembro de la junta de la OpenJS Foundation. Creé algunas bibliotecas que podrías usar. Hablé sobre ellas en Node Congress algunas veces, así que podrías querer revisarlas, tanto Fastify como Pino si te gustan. Trabajé ocho años como consultor, luego decidí hacer una startup. Aquí está Platformatic. Tengo un boletín en node.landofdev, un canal de YouTube, y así sucesivamente. Puedes echarle un vistazo. Pero en todo esto, la parte importante es que probablemente estés usando mis cosas, porque mis módulos han sido descargados 22 mil millones de veces el año pasado, lo que probablemente te incluye a ti también, que estás viendo este video.

Hablemos un poco sobre Undici. Undici es un cliente HTTP relativamente nuevo o moderno escrito desde cero para Node.js. ¿Qué significa desde cero? Significa que no está basado en el módulo interno HTTP y HTTPS, sino que lo creamos desde nada. Undici, no de color aquí, significa 11 en italiano, y proviene de HTTP 1.1. También es una referencia a Stranger Things porque estaba viendo Stranger Things cuando esto comenzó a venir a mi mente.

¿Cómo funciona? Es muy fácil de comenzar a usar, para ser honesto. Puedes simplemente importar requests de Undici y simplemente poner tu URL, y obtienes todas las cosas que esperarías. Obtienes el código de estado, encabezados, trailers y cuerpo. Obtienes todas las cosas. Nota que ha implementado la misma mezcla de cuerpo de fetch, por lo que puedes esperar body.json, por ejemplo. Algo muy importante a recordar es que siempre que obtengas un cuerpo, por favor consume el cuerpo. Hay cierta lógica internamente que se asegurará de que las cosas se manejen correctamente, pero límpialo si es posible.

Undici también es el hogar de fetch para Node.js. Cuando usas fetch dentro de Node.js, en realidad, estás usando fetch de Undici y Node.js integra Undici internamente. Es un fetch compatible con las especificaciones que te gusta y amas. Eso es más o menos todo lo que necesita decirse. Estamos trabajando muy duro para tener la mayor compatibilidad con las especificaciones posible, por lo que esto debería, en teoría, funcionar lo más cerca posible al fetch que estás ejecutando en tu navegador y también en los otros entornos de ejecución. Si necesitas tener compatibilidad con las especificaciones, si quieres trabajar en la compatibilidad con las especificaciones para fetch, Undici es el lugar correcto.

¿Cuáles son las cosas buenas de Undici? Primero que nada, Undici tiene un rendimiento mejorado. Lo veremos más adelante. Tengo unas cuantas diapositivas geniales. También crea una separación completa entre la API, la API pública, la experiencia del desarrollador y cómo se maneja la gestión de conexiones. Algo que no estaba presente en HTTP.request y el módulo HTTP y HTTPS. También tiene múltiples implementaciones. Dije pool. Sí, dije pool. HTTP es un protocolo basado en conexiones, por lo que probablemente querrás hacer agrupación de conexiones. A pesar de que toda la literatura dice que HTTP es un protocolo sin estado, pero es sin estado porque estás hablando de un estado... ¿Cómo es esto posible? Bueno, sí, por supuesto, porque es sin estado en el sentido de semántica, pero está implementado sobre una conexión con estado, TCP y TLS, por supuesto. Hablaré sobre qué son los interceptores y cómo integrarse con ellos.

Además, es mantenido por el equipo de Node Core, el equipo de HTTP, y de hecho, la mayoría de nosotros pensamos que HTTP.request es casi irreparable y por eso es en lo que estamos trabajando en su lugar. Al principio, comenzó con soporte solo para HTTP 1.1, luego también agregamos recientemente soporte para HTTP 2.0, y ahora es... Sabes, el nombre Undici podría no ser la mejor referencia ya. De todos modos, así que... También tenemos HTTP 1.1. También tiene soporte para HTTP 1.1 pipelining. Entonces... También... Algo que es un poco... Hay algunas cosas que son diferentes en él, por lo que podrías experimentar algunos errores con los que podrías necesitar lidiar, esencialmente. Entonces, ¿por qué? Bueno, el problema es que los módulos HTTP, HTTP son un desastre, ¿de acuerdo? Principalmente porque usan la misma estructura de API para ambos, el cliente y el servidor de HTTP 1.0, y ambos están vinculados con la gestión de conexiones con la API pública. Entonces, ¿cómo puedes verlo? Bueno, tienes un request.socket, ¿de acuerdo? El hecho de que tengas una propiedad request.socket te dirá que hay este tipo de conexión, porque si tu sistema ya no está en socket, como en HTTP 2.0, ¿cómo implementarías eso? Y esta es la razón por la que no puedes soportar tanto HTTP 1.1 como HTTP 2.0 en la misma API.

Finalmente, por último pero no menos importante, no podemos cambiar esas clases sin romper express. Así que, sí, bueno, esa es la situación. Entonces, creamos undici.request para ser lo más rápido posible, porque hacer una solicitud HTTP no debería ser el cuello de botella de tu aplicación. También proporciona una buena DX, una muy buena DX, desde mi punto de vista. Es altamente configurable, utiliza Node.js stream, soporta HTTP 1.1 pipeline. Es genial. Solo usa esto. Este es probablemente el código que querrás estar usando, ¿de acuerdo? Undici Fetch está construido para cumplir con las especificaciones, ¿de acuerdo? Así que no está poniendo el rendimiento como la máxima prioridad. Es el cumplimiento de las especificaciones lo que es. Y ahora mismo, el 88% de las pruebas WPT que estamos ejecutando para Fetch, las estamos pasando. Así que, creo que es una compatibilidad bastante buena en general. Sin embargo, internamente, utiliza WhatWGstream, por lo que puedes usar Pipe2, WhatWGstream, todas las cosas, el Redible stream, como el navegador. Así que, todo el código que usa Undici Fetch y Fetch Node podría ser isomórfico. Nuevamente, el manejo del protocolo y la API están completamente separados, por lo que todas las cosas de las que vamos a hablar, Undici y la gestión de conexiones y demás, se aplican a ambos. Y esta es la razón por la que Undici Fetch fue construido sobre Undici. El Fetching Node fue construido sobre Undici. También soporta HTTP2, HTTP pipelining, debido a esta separación.

Bien, hablemos sobre el rendimiento, porque esto es lo crítico para ello, ¿de acuerdo? Entonces, sabes, los números son realmente significativos aquí, ¿de acuerdo? Como, Undici es prácticamente sin restricciones, ¿de acuerdo? Puedes usar, en este sistema de pruebas, puedes realmente usar Undici, una de las APIs de nivel más bajo, que es Undici.Dispatch, pero para ser honesto, esto no es lo que deberías estar usando, ¿de acuerdo? Es la parte subyacente, o Undici.Stream, que es, sabes, incluso más rápido, pero nuevamente, probablemente demasiado bajo nivel.

Puedes llegar a tener hasta una enorme cantidad de solicitudes saliendo de un solo proceso de nodo, ¿de acuerdo? Obtener 20,000, 21,000 solicitudes por segundo, es una gran cantidad de solicitudes que vas a enviar, ¿de acuerdo? Así que, esencialmente, nuestro objetivo es que hacer solicitudes HTTP no debería ser el cuello de botella de tu aplicación con Undici.Request. Y puedes ver cómo se están configurando las otras APIs. Así que, tenemos SuperAgent, tenemos HTTP de Node Core, tenemos Axios, cómo funciona Axios, tenemos el módulo de solicitud de la vieja escuela, cómo funciona eso hasta Undici.Fetch, que en realidad es más lento, ¿de acuerdo? Como dije, hay muchas cosas que se pueden optimizar aún, que es solo un poco más rápido que Node.Fetch, lo cual es genial, y luego tenemos al final.

Bien, solo para aclarar, todo esto es realmente muy importante de notar, que si estás experimentando algún problema de rendimiento al hacer solicitudes HTTP, probablemente deberías cambiar a Undici. Hablo mucho sobre HTTP 1.1 pipelining, y necesito, realmente quiero explicarlo, ¿de acuerdo? Porque de lo contrario probablemente no sabrás de qué estoy hablando. Entonces, en una solicitud HTTP normal cuando abres un cliente, una solicitud de un cliente a un servidor, ¿de acuerdo? Primero que nada, hay un ping pong, ¿de acuerdo?, de abrir la solicitud HTTP, ¿de acuerdo? Además de eso, necesitas agregar TLS si hay TLS. Así que, sí, muchos intercambios. Una vez que tienes esta conexión configurada, ¿de acuerdo? , el cliente envía una solicitud a ese socket, ¿de acuerdo? Una vez que el socket regresa, hace el procesamiento y lo devuelve al principio, y luego puede enviar una segunda solicitud en ese socket. Hablé mucho sobre la agrupación de conexiones. Entonces, tienes, esencialmente, si quieres hablar con otros microservicios en tu red, tienes, no sé, tres, cuatro, cinco, 10, 20, 50, las conexiones que sean. Entonces, quieres, ya sabes, asignar una conexión a una solicitud hasta que obtengas la siguiente, la solicitud, la siguiente solicitud después. Entonces, si tienes 50 conexiones, esencialmente, significa que solo puede haber 10 conexiones, lo siento, 50 solicitudes en vuelo en total, porque cada una conexión, una solicitud, ¿de acuerdo? El pipelining cambia eso. Entonces, con el pipelining, podemos enviar dos solicitudes al mismo tiempo, ¿de acuerdo? Podemos enviar una solicitud, podemos enviar dos solicitudes al mismo tiempo, una tras otra. Ahora, esto es genial porque realmente podemos reducir el tiempo de respuesta significativamente porque enviamos dos mensajes y podemos ahorrar todo el tiempo de ida y vuelta, ¿de acuerdo? Los servidores luego necesitarán analizar esos uno tras otro y luego enviarnos de vuelta los resultados, ¿de acuerdo? Lo cual está bien porque si deslizas en este ejemplo, toma 172 milisegundos obtener ambas respuestas mientras que en el otro es 228. Así que, en realidad estamos respondiendo antes y teniendo datos enviados de vuelta antes, pero hay una trampa, ¿de acuerdo? ¿Qué pasa si la primera solicitud se retrasa? Si la primera solicitud se retrasa, ¿de acuerdo? , como puedes ver en este ejemplo, en realidad estamos perdiendo mucho procesamiento, ¿de acuerdo? La segunda, la más corta, necesita esperar para ser enviada, ¿de acuerdo? Porque primero, necesito enviar la primera y luego necesito enviar la segunda. Este fenómeno se llama bloqueo de cabecera. Entonces, ¿de acuerdo?

Y primero que nada, queremos proporcionar la base para HTTP next. Y, como dije, separamos la API que los usuarios usan de la interna. Así que, hay dos capas separadas, completamente independientes entre sí.

Y todos los internos están basados en callbacks. No están basados en error backs y no están basados en eventos, ¿de acuerdo? Así que, están basados en un mecanismo de nivel inferior que es extremadamente rápido. Así que, no tenemos ningún tipo de sobrecarga.

También, gestionamos manualmente nuestro pool de conexiones, ¿de acuerdo? Y puedes hacer diferentes cosas. Y somos muy exigentes con la sobrecarga y la asignación de memoria. Por último, pero no menos importante, minimizamos la transición entre C, C++ y JavaScript.

Así que, la parte clave de la gestión de conexiones y cómo interactúas con los internos es mediante el concepto de un dispatcher. Y hay una API en Undici que se llama SetGlobalDispatcher. Así que, si quieres cambiar el dispatcher global o el mecanismo global para manejar la solicitud HTTP, puedes hacerlo en cualquier momento a través de la biblioteca Undici, llamando a SetGlobalDispatcher y pasando ya sea un agente o algo más de lo que hablaremos pronto. Puedes configurar muchas cosas. Puedes poner muchos parámetros aquí. Así que, échale un vistazo. Ahora, lo importante a tener en cuenta es que llamar a SetGlobalDispatcher desde Undici también cambiará el de fetch de Node.js, ya que las dos cosas están construidas para ser completamente interoperables.

Entonces, ¿cuál es la jerarquía de esos dispatchers? Así que, tenemos una clase abstracta Dispatcher, que incluye un montón de cosas. E incluye muchos de los métodos sofisticados. Y luego tenemos un abstracto que implementa el dispatcher para la gestión de conexiones. Y desde allí, tenemos el cliente, que envuelve un socket, una conexión. Luego tenemos el pool. Y el pool, es esencialmente un array de clientes. Así que, si el pool recibe una solicitud, dice, oh, dame un cliente libre. De lo contrario, espera. El balanced pool es un sistema alternativo que utiliza un algoritmo reciente que fue publicado en un artículo reciente que nos permite elegir el socket que ofrecerá la mejor latencia para esa solicitud específica. ¿Cómo funciona? Sí, es un algoritmo complejo. Así que, échale un vistazo. Utiliza mucho peso y matemáticas para hacer su trabajo. ¿Qué hace el agente? Bueno, el agente te permite trabajar a través de un grupo de pools. Uno para cada origen.

Así que, si tienes una combinación de dominio más puerto, o IP más puerto, entonces el agente es el sistema que lo coordina y envía una solicitud al pool correcto. Este sistema también nos permite implementar un agente simulado o un sistema simulado para Undici, que está incorporado. Así que, puedes configurar un agente simulado, y el agente simulado se puede configurar para interceptar solo algunas solicitudes. Así que, si configuras esto, puedes interceptar una solicitud y puedes envolverla a través del agente simulado. Parece fantástico, ¿verdad? No hay ningún parcheo de mono sucediendo, nada. Esto simplemente funciona de inmediato.

¿Por qué se llama dispatcher, entonces? Bueno, porque un dispatcher tiene los métodos más importantes para el dispatcher es el método dispatch. Y el método dispatch toma un objeto de opciones, que describe la solicitud, y un manejador para esa solicitud. Un manejador es un objeto complejo que implementa muchos callbacks para muchos estados diferentes de la solicitud HTTP. Y si estás llamando a dispatcher.request internamente para usar un manejador de solicitudes, y stream, manejador de stream, fetch, manejador de fetch, pipeline, manejador de pipeline, sí, parece correcto, ¿de acuerdo? Y así es como separamos entre la interfaz de bajo nivel, que es dispatch, y el nivel superior, como request, fetch, stream, y así sucesivamente.

¿Cuántos métodos hay? Bastantes, en realidad, porque necesitamos rastrear todas las cosas. Así que tenemos un connect, ¿de acuerdo? Tenemos un non-connect, onError, onUpgrade, onResponseStarted, onHeaders, onData, onComplete, y onBodySent. ¿Sí? Bastante genial, ¿verdad? Bueno, este sistema nos permite crear algo como un agente de reintento. Así que, imaginemos que quieres volver a intentar tu solicitud HTTP porque están fallando, por cualquier razón. Bueno, el agente de reintento simplemente hace eso, ¿de acuerdo? Está incorporado, ¿de acuerdo? Así que no necesito hacer mucho. Puedo configurarlo como un agente global, o simplemente puedo llamarlo. Funciona genial. Internamente, esto, implementa un manejador de reintento. Así que el agente de reintento, cuando recibes el método dispatch, crea un manejador de reintento, ¿de acuerdo? que esencialmente envuelve el manejador anterior y añade algo de lógica de reintento. ¡Hey! Eso funciona, ¿de acuerdo? Bastante ingenioso, ¿verdad? Y es interminable todo el camino hacia abajo. Y una de las opciones dentro del dispatcher son los interceptores de dispatcher, ¿de acuerdo? Lo siento, y los interceptores de dispatch esencialmente son solo objetos que tienen una función dispatch. Eso es todo, ¿de acuerdo? Que ofrece la misma API que la clase dispatcher, ¿de acuerdo? Pero un interceptor solo, es un objeto que solo tiene dispatch. El otro, dispatcher también tiene muchos otros métodos en él, ¿de acuerdo? Y por ejemplo, lo que he creado, es un sistema para emitir automáticamente tokens OIDC de máquina a máquina para cada solicitud que sale a un cierto destino. En este ejemplo, y puedes verlo, es un módulo separado llamado UndiciOIDCInterceptor.

Es compatible con cualquier cosa que sea compatible con OIDC y soporte tokens de máquina a máquina. Así que, desde mi punto de vista, es bastante genial. Pero ten cuidado, porque probablemente en la próxima versión de Undici v7, cambiaremos estas APIs. Así que estamos trabajando en algo mejor.

Así que, del código, el ejemplo que hicimos al principio, te preguntas por qué fetch es lento, ¿de acuerdo? Así que me tomé la libertad de ejecutar este benchmark. Muy simple, muy, para ser honesto, directo. Estamos emitiendo cien mil solicitudes fetch localmente y obteniendo el texto. Y eso es todo. Y te sorprenderá mucho dónde estamos gastando el tiempo. Todo el tiempo, la mayor parte del tiempo, el 50 por ciento del tiempo se gasta realmente en inicializar los streams WOTUG, ¿de acuerdo? No en el procesamiento HTTP, ni en nada más, solo en la inicialización.

¿Por qué los streams WOTUG son tan costosos en la inicialización? Bueno, esta es una respuesta larga, y desafortunadamente probablemente valga la pena una charla por sí sola, pero está relacionada con el hecho de que son transferibles. ¿Qué es eso? Sí, bueno, como dije, probablemente valga la pena una charla. Hablaré por sí sola. Así que algo que hace todo esto significa que puedes usar la lógica del dispatcher también para hacer algo de magia, ¿de acuerdo?

Así que, de hecho, debido a cómo funciona esto, el nuevo HTTP RFC 9110 simplemente separa la semántica de los transportes, de HTTP 1 y HTTP 2.2.

Así que básicamente, el formato de cableado es ahora solo un detalle de implementación. Así que básicamente, significa que podemos implementar la lógica HTTP, ¿de acuerdo? La semántica HTTP en esencialmente cualquier cosa, lo cual es fantástico. Así que significa que podemos esencialmente incluso desvincular completamente nuestro sistema del transporte HTTP. Y de hecho, esta es la lógica que usamos para el mux.