Evolución del cliente HTTP de Node con undici

Hola a todos. Mi nombre es Robert Nagy. Soy el desarrollador principal en Next Edition y un colaborador frecuente a Node.js y también miembro del TSC. Y voy a hablar un poco sobre algunos trabajos que hemos estado haciendo en el cliente HTTP en Node usando una biblioteca que creamos llamada Bitchy.

Entonces, primero que nada, hablemos un poco sobre el estado actual del cliente HTTP de Node. Creo que la mayoría de las personas están familiarizadas con la API de solicitud HTTP. Y las personas que están usando las bibliotecas de NPM como Got y Axios, etc., estas son generalmente solo envoltorios alrededor de la llamada de solicitud HTTP que proporciona Node Core. Ahora, esto tiene una larga historia y ha funcionado durante mucho tiempo. Pero aquellos de nosotros que hemos estado trabajando en el mantenimiento de esta API sentimos que hemos llegado al final de lo que podemos hacer con un esfuerzo razonable con esta API. Entonces, ¿cuáles son algunos de los problemas que vemos aquí? Entonces, en primer lugar, el objeto de respuesta que recibe de la API de solicitud no es realmente un flujo de Node. Solo pretende ser un flujo de Node. Hay varias razones, tanto de compatibilidad como de rendimiento para eso. Pero hay ligeras diferencias que pueden causar problemas extraños si tienes mala suerte. Especialmente si estás usando APIs que esperan flujos, y querías usarlo de manera fluida. No tiene soporte para el canalizado HTTP. El canalizado es una característica del protocolo HTTP que puede proporcionar algunas ventajas significativas de rendimiento. Además, el objeto de solicitud y el objeto de respuesta en esta API están intrínsecamente vinculados. Entonces, si destruyes, por ejemplo, la solicitud, incluso si ha completado, también matará la respuesta. Y este enlace es muy difícil de arreglar o eliminar sin romper todo el ecosistema. Está completamente basado en flujos, lo que causa algunas limitaciones de lo que podemos lograr en términos de rendimiento. Y muchos de los internos en la API son de acceso público, y tenemos módulos del ecosistema que dependen de los detalles de implementación internos. En aquel entonces, no teníamos símbolos por lo que no era posible ocultar cosas a los usuarios. Y todas estas cosas causan problemas que creemos que son muy difíciles de solucionar sin causar perturbaciones indebidas en todo el ecosistema. Entonces, hace unos años, Matteo o en realidad, otro punto aquí es que hemos intentado solucionar estos problemas varias veces, y eso ha causado problemas y hemos tenido que revertirlos. Soy una de las personas que ha pasado mucho tiempo tratando de resolver estos problemas. Y es bastante decepcionante cuando te ves obligado a revertirlos debido a regresiones de compatibilidad o rendimiento, etc. Entonces, aquí hay algunas solicitudes de extracción que simplemente revierten el trabajo que se ha hecho hacia esto. Entonces, hace unos años, Matteo Macalina creó esta biblioteca llamada Indichy, que es una nueva visión de lo que HTTP puede y podría, ser en Node. Y me involucré hace un año o así, y he hecho mucho trabajo para hacer esto listo para producción. Entonces, ¿cuáles son nuestros objetivos? ¿Qué es lo que estamos logrando o tratando de lograr dentro de Indichy? Entonces, queremos una API un poco más amigable para el usuario para que las personas no tengan que ir a un tercero

Y como mencioné, hay un problema con Keepalive que Nord Core no maneja, es que una vez que se establece una conexión, hay un tiempo de espera que el servidor mantendrá esa conexión viva, esperando más solicitudes antes de cerrar la conexión. Ahora, si tienes mala suerte, podrías enviar una solicitud en el momento exacto en que se produce el tiempo de espera del servidor y por lo tanto el servidor cerrará la conexión mientras tu solicitud está llegando. Ahora, algunos servidores proporcionan una pista de Keepalive en sus respuestas para que puedas averiguar durante cuánto tiempo el servidor espera mantener la conexión abierta, y por lo tanto, el cliente puede hacer cosas para evitar este cierre inesperado. Así que eso es algo que hemos solucionado en Umidigi. También hemos mirado el rendimiento así que con Umidigi fuimos capaces de lograr un rendimiento casi 10 veces mejor en comparación con el cliente de Node Core, lo cual tengo que decir que es un resultado bastante bueno. Lo estamos desarrollando fuera del núcleo en este momento para su inclusión posterior. Hay algunas ventajas de esto especialmente en términos de la velocidad de implementación y hemos ocultado todos los detalles internos detrás de los símbolos para que no tengamos una repetición de bibliotecas de terceros, dependiendo de los detalles de implementación. Y también estamos considerando implementar fetch en Umidigi. Así que la API más básica de Umidigi es la solicitud de Umidigi y básicamente haces un await Umidigi request donde obtienes un cuerpo, un código de estado y encabezados y el cuerpo es un flujo de nodo pero también hemos implementado algunas funciones de ayuda inspiradas en las especificaciones del cuerpo de fetch mixing así que tienes body.text.json.array buffer y puedes simplemente esperar a esos pero de lo contrario el cuerpo es un flujo normal de node.js. Así que esto es bastante simple. Una nota importante que he notado que algunas personas pasan por alto es que es muy importante, incluso si no te importa el cuerpo, debes consumirlo o destruirlo para liberar la conexión porque la forma en que funciona con el keep-alive es que a menos que la solicitud anterior haya terminado no puedes procesar la siguiente así que es importante destruir el cuerpo o volcarlo o consumirlo. Proporcionamos una ayuda llamada dump, que la desventaja de destruir el cuerpo es que eso en realidad causará la destrucción del socket. Tenemos una función de ayuda aquí llamada dump que en realidad intentará leer todo el cuerpo para que la conexión pueda ser reutilizada pero si el cuerpo o la respuesta del servidor excede un cierto umbral entonces elige eventualmente cerrar la conexión. Así que no tienes que descargar un gigabyte de datos antes de poder reutilizar la conexión. Y sí, si no haces esto entonces la conexión no será liberada para la próxima solicitud.

Tenemos soporte para señales como cualquier buen ciudadano del mundo de las promesas. También puedes realizar solicitudes POST. Simplemente pasas el cuerpo como una opción al método de solicitud. Por favor, evita usar HEAD. Las solicitudes HEAD tienen algunas limitaciones debido a problemas de compatibilidad con los servidores que pueden o no enviar un cuerpo con la respuesta HEAD y por lo tanto Enduci en realidad siempre elige cerrar las conexiones para estar seguro. Una solución para esto con el fin de mantener la funcionalidad similar con el mismo performance es simplemente usar una solicitud de rango si es posible o puedes leer un byte y puedes recibir mucha de la información que

Tenemos un límite, así que si el servidor proporciona una pista, esa pista puede ser de dos días, entonces tal vez no quieras usar eso. Así que tenemos un umbral máximo por lo que no iré más allá. Y también desde el tiempo de espera de la conexión es en realidad desde el momento o desde el momento en que el servidor envió la respuesta, hay un retraso en la respuesta siendo enviada a recibir por Undici. Así que tenemos un umbral de tiempo de espera que básicamente, si toma en cuenta las latencias de transporte. El tiempo de espera es de cinco segundos. Quitaremos un segundo por lo que el cliente asume que quedan cuatro segundos hasta que la conexión sea eliminada por el servidor. Eso es todo con eso. También puedes configurar el canalizado. Undici no hace canalizado por defecto. Así que puedes configurar aquí qué tan profundo quieres que sea el canal, cuántas solicitudes puede enviar Undici antes de recibir una respuesta. Cuál es el mejor valor aquí es un poco difícil de decir. Depende de tu caso de uso, pero dos o tres suele estar bien. Y luego también puedes elegir cuántas conexiones puede hacer Undici a un servidor. Así que si haces una solicitud a un servidor y no hay ninguna conexión disponible, entonces Undici iniciará una nueva conexión. Y de esta manera puedes limitar el número de conexiones, similar a cómo funciona en Node Core. Una cosa importante a tener en cuenta es, si tienes varias solicitudes en cola en el canal, y la que está al frente de la cola de canalización falla, entonces Undici automáticamente matará la conexión y volverá a intentar todo después de la que falló, si esas solicitudes son idempotentes, como las solicitudes get y put. De lo contrario, tendrás que volver a intentar las cosas tú mismo. Ahora, hay algunas otras APIs con las que hemos estado experimentando en Undici. Uno de los inconvenientes de la API de solicitud es que siempre crea esta transmisión de pegamento legible. Así, básicamente, Undici lee desde el socket, lo analiza con el LLHTP, y luego lo escribe en la transmisión legible, y luego lo lees de la transmisión legible para usarlo. Y esto tiene este sobrecarga de rendimiento innecesaria del pegamento. Puedes evitar eso usando la API de transmisión, que básicamente te permite devolver una transmisión escribible donde se debe escribir la respuesta, en lugar de esta transmisión de pegamento intermedia. Como habrás notado antes, hay un cierre

Hemos estado discutiendo la inclusión de Indichi en el núcleo. Es una discusión en curso con pros y contras, por lo que deberíamos incluirlo o no. Tiene, sí, yo diría que simplemente mira el problema y lee a través. Hay muchos pensamientos allí. Una de las ventajas importantes de tenerlo fuera del núcleo ha sido la velocidad de desarrollo. Pero a medida que las cosas se vuelven más estables y más pensadas, podría ser el momento de incluirlo en el núcleo. Ahora también hemos dedicado mucho trabajo a implementar fetch basado en Indichi, y en realidad estamos aterrizando soporte experimental en note 17. Así que está bajo la bandera experimental fetch. Así que ahora estamos llegando cerca de finalmente tener un fetch en el núcleo. Si ustedes quieren ayudar a hacer que no sea experimental, entonces por favor diríjanse al repositorio de Indichi y ayúdennos a mejorar la prueba Y siempre hay casos límite de cumplimiento de especificaciones que pueden ser encontrados y resueltos. Es bastante fácil contribuir a la implementación de fetch en Ditche. Estamos usando una forma muy literal de implementar la especificación en Indichi. Así que básicamente tomamos la especificación e intentamos seguir lo más de cerca posible los pasos de la especificación de manera tan literal como sea posible. Así que si quieres ayudar, simplemente lee la especificación. Hay algunas tareas pendientes aquí que puedes ver si puedes resolver. Pero es razonablemente fácil contribuir. Tenemos algunas diferencias con el Web Bear y principalmente cómo funciona la recolección de basura. En el navegador fetch se recolectará automáticamente la basura Estaba hablando de que siempre tienes que consumir el cuerpo. Eso es lo mismo en fetch. El navegador lo hace automáticamente durante la recolección de basura. Pero la recolección de basura

Trabajo futuro. Por supuesto, nos encantaría soportar HTTP 2 y 3. Entonces, eso es algo en lo que estamos trabajando. Sería genial tener búsqueda de DNS para soporte para balance pool y el pool. Estamos buscando mejorar fetch. También, la programación de pool, la forma en que las solicitudes son despachadas y programadas sobre múltiples conexiones. Hay cosas interesantes que puedes hacer allí. ¿Debería ser una programación de profundidad primero, amplitud primero? ¿Deberíamos ponderar diferentes conexiones basadas en su latencia y cuántas veces la solicitud ha fallado en una conexión o upstream? Entonces, hay muchas cosas interesantes que hacer allí. Y todavía nos falta soporte para las solicitudes HTTP 100 continue en la especificación HTTP 1. Y eso es todo lo que tengo. Si tienes alguna pregunta, espero poder responderlas. Y eso es todo. Gracias. Parece que tenemos un claro ganador. Entonces, el 48% de las personas usan fetch. ¿Te sorprende esto en absoluto? Tanto sí como no. Creo que fetch es la API con. Recientemente lo aterrizamos como experimental en Node.js. Así que supongo que ese movimiento fue bueno dado este resultado. Y personalmente, estoy más orientado a performance. Así que uso una solicitud que es la menos común aquí en la votación, lo cual también es bastante sorprendente. Entonces sí, eso es una buena pista de dónde poner más energía.

Sí, eso suena genial. Nuestra audiencia tiene muchas preguntas para ti. Pero yo tengo incluso más. Una cosa, así que hablaste sobre la implementación de Fetch en Node. Y también estoy bastante emocionado por eso. Espero que todos lo estén. ¿Utiliza undici? ¿Tiene algo en común?

Sí. Así que en realidad, el Fetch en Node se construye sobre undici. No exponemos nada de undici aparte de Fetch en Node, y esa es una decisión consciente para no exponer dos APIs experimentales que pueden cambiar y romperse más tarde. Pero la implementación de Fetch se hace sobre undici, y no sobre el código HTTP de Node normal.

Eso es genial. Supongo que todos los que ejecutan Node estarían esencialmente en undici ahora. Así que esa es la mejor manera de... Oh, tenemos una pregunta de nuestro orador, Joda Developer, quien preguntó, ¿cómo simular una solicitud en undici? Así que por ejemplo, hay una biblioteca Nock que te permite simular solicitudes. Así que si estás usando solicitudes de undici, ¿has intentado simularlo? ¿Y cómo lo harías?

Así que Nock no funciona porque depende de los internos del cliente HTTP. Tenemos implementada la simulación en undici. Así que hay un cliente simulado y un pool simulado y las herramientas que se requieren para hacer básicamente lo mismo que harías con Nock. Así que todo está ahí.

Eso es genial. También agentil1990 pregunta, ¿cómo será el soporte para Qwik en el futuro? Sé que NodeCore soporta Qwik ahora, ¿verdad? ¿Pero qué pasa con undicis?

Así que NodeCore aún no soporta Qwik. Creo que se lanzó como experimental, pero luego fue eliminado. Hay un PR en el que James está trabajando para lanzarlo. A menos que me haya perdido algo, pero una vez que se haya lanzado, debería ser bastante fácil añadir soporte para eso en undici para implementar HTTP1 sobre Qwik. Implementar el soporte para HTTP3 es un poco más de trabajo. Eso suena realmente interesante. Gracias. Otra pregunta es, ¿hay algún benchmark sobre el sobrecosto de crear una nueva conexión cada vez en comparación con el enfoque de undici?

Así que tenemos algunos benchmarks incluidos. Y sí, es difícil decir de dónde vienen todas nuestras mejoras de performance. Y de nuevo, depende de tu caso de uso. Pero diría que es significativamente más rápido mantener y reutilizar las conexiones que abrir y cerrarlas todo el tiempo,

Bien. Bueno, la siguiente pregunta es, ¿cuál es el plan o progreso actual para incluir Undici en Node Core? Acabamos de hablar sobre fetch y cómo fetch se ejecuta sobre Undici. Recuerdo que en el pasado ha habido múltiples solicitudes para agregar cosas como los streams de OWG a Node. ¿Crees que este hito de fetch que hemos logrado podría abrir la puerta a un número de otras cosas? El enfoque principal ha sido implementar todos los web standards en Node.js porque están bien especificados y no se esperan tantos cambios disruptivos en el futuro. Una vez que tengamos y una vez que aterricemos Undici en Core, eso pone algunas restricciones en lo que podemos hacer en Undici y cuán rápido podemos hacer las cosas. Así que siempre hay un equilibrio entre tenerlo en Node Core y darle una marca de que no romperemos cosas o tenerlo fuera y mantener la velocidad de desarrollo en él. Creo que estamos llegando, acercándonos al punto donde Undici se siente estable en términos de la superficie de la API. Así que podría valer la pena incluirlo en Core. Pero me gustaría ver un plan más grande en términos de servidor y cliente sobre cómo queremos que se vea el futuro de HTTP en Node antes de empezar a incluir nuevas APIs.

Sí, eso es realmente interesante. Una cosa, entonces, mencionaste acerca de agregar más de estas APIs web y luego Web standards, por así decirlo, en Node Core. Ahora, esto es un tema muy debatido, ¿verdad? No todo el mundo está de acuerdo en que agregar cosas como Fetch a Node sea una buena idea. Una de las razones que solían apoyar eso es diciendo que Fetch y todo están diseñados por organismos como WG, que se centran en casos de uso de navegadores, y por lo tanto una implementación alternativa de HTP que se preocupe más por los casos de uso del lado del servidor sería más apropiada para Node. ¿Cómo crees que se apila esto? Y por ejemplo, hay tantas cosas en Fetch que son específicas para los navegadores, como los frascos de cookies. ¿Cómo funciona eso en DG? Sí, quiero decir, siempre es un equilibrio entre hacer una solución a medida y una solución uniforme. Creo que muchas de las cosas con Fetch están mejorando la experiencia del desarrollador, facilitando la escritura de un buen código, ¿verdad? Porque la gente trabaja en el navegador, así que ellos necesitan conocer Fetch de todos modos. Y conocen los detalles y los casos límite allí. Y luego tener que aprender una tercera, cuarta, quinta y sexta API, incluso si esas son mejores para casos de uso específicos, tiene algunas desventajas. Por ejemplo, Fetch, undici Fetch, tiene un rendimiento más bajo que las otras APIs que proporcionamos como undici Request. Pero aún así es una buena idea incluirlo porque ayuda con la familiaridad del desarrollador. Y las horas de trabajo del desarrollador son mucho más caras que comprar un hardware más rápido. Así que creo que eso es un poco, esa es mi opinión sobre todo el asunto. Si sólo quieres hacer las cosas rápidamente y que funcione, ve con undici Fetch. Si el rendimiento es tu máxima prioridad, entonces recomendaría algunas de las otras APIs que aún no se han incluido.

Sí, eso suena realmente genial. Gracias. Creo que hice la pregunta demasiado larga pero intenté insistir en una segunda parte. La suite de pies, hay ciertos detalles de implementación en Fetch, que solo tienen sentido en un contexto de navegador. Cosas como las cookies y demás. Entonces, ¿cómo funciona eso en Undiji? Buena pregunta, y eso es algo que tenemos que manejar caso por caso. De hecho tenemos algunas, la forma en que implementamos Fetch en Undiji es que intentamos seguir literalmente la especificación. Así que realmente implementamos la especificación que no es posible alcanzar en un entorno de Node.js, con la esperanza de que en el futuro podamos modificar la especificación o hacer nuestras propias modificaciones para hacer que las cosas funcionen.

Por ejemplo, las redirecciones en Undiji Fetch funcionan un poco diferente que en el navegador. Hemos seguido la forma en que CloudFlare y Deno lo hacen. También hay problemas como la recolección de basura que pueden afectar cómo se comporta la implementación y si es importante consumir completamente todas las respuestas o no. En Undiji Fetch tienes que consumir respuestas mientras que en el navegador. Es un poco más agradable. Se limpiará durante la recolección de basura.

Sí, gracias. Eso fue realmente revelador. Tenemos otra pregunta de los espectadores que dice, ¿Es Undiji tu principal motivación para las muchas correcciones que has hecho a los streams de Node.Force? O en otras palabras, ¿fue la complejidad de los streams un obstáculo para el desarrollo de Undiji? Supongo que lo fue pero ni siquiera me di cuenta en ese momento. Así que he estado tratando de, pasé mucho tiempo trabajando en streams HTTP y el cliente y servidor HTTP en Node. Y mucho del trabajo fue para hacer que los streams funcionaran de una buena manera. Di una charla en no TLV sobre este problema con los streams y una vez que llegué tan lejos como pude con los streams y me encontré con el obstáculo con las cosas de HTTP, es cuando me fui a Undiji. Y sí, hay algunas correcciones en los streams inspiradas por problemas que encontré en Undiji. Sí, eso es bastante interesante. Recuerdo que este tema de reformar los streams de notas ha sido un tema tan largo y la gente ha pensado en esto durante tanto tiempo. Me alegra que estés avanzando en esto. Otra pregunta que tenía para ti. Entonces, ya tienes un montón de interesantes características, por así decirlo, en Undici. ¿Hay algún otro estándar web o característica web que esté en tu radar? ¿Hay algo que planeas hacer a continuación? Un poco de lo que hablamos, hay Quick y HTTP 2 y HTTP 3, y eso es lo que estamos buscando en Undici, y por supuesto en Node Core estamos esperando la clase File de la especificación web para poder implementar completamente Fetch. Genial. Bueno, eso es asombroso. Muchas gracias Robert, y esta fue una increíble presentación, y fue bastante informativa, al menos para mí, y espero que lo mismo se aplique a todos nuestros espectadores. Si no has terminado de hacer todas estas preguntas a Robert, es posible que quieras unirte a él en la sala de conferencias, así que hay un enlace a la sala de conferencias. Únete a él en Spatial Chat. Muchas gracias Robert. Gracias.