Duda con metodo .listen() de NodeJS

[Diesan Romero]

Hola a todos. Mirando un poco la documentación de NodeJS, en el módulo http, existe un método llamado .listen(), este pasa varios parámetros, entre ellos el host y el port, que me queda clarísimo para que son, y también un callback. Pero he visto que antes del callback se pasan algunos otros parámetros más que no estoy muy claro para que son. Hay uno en particular que me llamó la atención y fue el backlog. Supuse que el backlog tiene que ver con http, pero no estoy muy seguro de que es y no se si estoy buscando bien en Internet. Se que a este parámetro se la pasa un número y en la documentación solo me dice lo siguiente: Common parameter of server.listen() functions. Y la verdad es que eso no me está diciendo mucho.

[MinusFour]

Hola a todos. Mirando un poco la documentación de NodeJS, en el módulo http, existe un método llamado .listen(), este pasa varios parámetros, entre ellos el host y el port, que me queda clarísimo para que son, y también un callback. Pero he visto que antes del callback se pasan algunos otros parámetros más que no estoy muy claro para que son. Hay uno en particular que me llamó la atención y fue el backlog. Supuse que el backlog tiene que ver con http, pero no estoy muy seguro de que es y no se si estoy buscando bien en Internet. Se que a este parámetro se la pasa un número y en la documentación solo me dice lo siguiente: Common parameter of server.listen() functions. Y la verdad es que eso no me está diciendo mucho.

La documentación dice esto:

All listen() methods can take a backlog parameter to specify the maximum length of the queue of pending connections. The actual length will be determined by the OS through sysctl settings such as tcp_max_syn_backlog and somaxconn on Linux. The default value of this parameter is 511 (not 512).

Que se traduce a "Especifica la longitud de la cola de conexiones pendientes."

[Diesan Romero]

La documentación dice esto:

Que se traduce a "Especifica la longitud de la cola de conexiones pendientes."

Muchas gracias. Ahora comprendo un poco más. No se si hay un límite, aunque buscando hace un rato vi que el valor por defecto es 1024 para sistemas que tienen alrededor de 128MB en memoria. Ahora bien ¿Con ese parámetro puedo aumentar ese tamaño en caso de que el servidor lo requiera? Y otra pregunta ¿Existen casos donde hay que incrementar el tamaño?

[MinusFour]

Muchas gracias. Ahora comprendo un poco más. No se si hay un límite, aunque buscando hace un rato vi que el valor por defecto es 1024 para sistemas que tienen alrededor de 128MB en memoria. Ahora bien ¿Con ese parámetro puedo aumentar ese tamaño en caso de que el servidor lo requiera? Y otra pregunta ¿Existen casos donde hay que incrementar el tamaño?

El limite del backlog está dado por /proc/sys/net/core/somaxconn. El limite es 4096 desde el kernel 5.4, 128 en kernels anteriores. /proc/sys/net/ipv4/tcp_max_syn_backlog es un parametro que controla el limite de conexiones entrantes que todavía no son establecidas (creo que de manera global, no por aplicación). Y este si tiene valores por defecto dependiendo de la cantidad de memoria. Su valor por defecto es 256, 128 para equipos con menos de 32MB de RAM y 1024 para equipos que tienen más de 128MB de RAM.

Hasta donde yo tengo entendido, estas son conexiones que son consideradas aceptadas (ACK) pero todavía no han pasado a control de la aplicación. No debería afectarte mucho porque si la cola de las conexiones que son consideradas aceptadas llega a su limite, el servidor simplemente ignora los paquetes (ACK) que convierten las conexiones pendientes en establecidas y al cabo de un tiempo envía otra vez (SYN/ACK) al cliente. Si la cola sigue llena se vuelve a repetir el proceso, el cliente envia ACK, el servidor lo ignora y al cabo de un tiempo vuelve a enviar SYN/ACK. Y así sigue hasta que el servidor se cansa y le dice al cliente que se vaya para otro lado.

En mi opinión, la unica razón por la cual tendrías que modificar el backlog es si tienes un servidor que no procesa las conexiones rapidamente. Ya sea en condiciones normales de tráfico o dependiendo de los picos que tengas.

Y en ese caso, quizás apunta más a que deberías buscar una forma de distribuir la carga através de varios servidores.

Por cierto, por conexiones pendientes se refieren a conexiones que no han pasado a control de la aplicación (creo que es así) y no es exactamente el estado de la conexión TCP.

Aquí hay un link que lo explica muy bien en mi opinión:

http://veithen.io/2014/01/01/how-tcp-backlog-works-in-linux.html

[Diesan Romero]

Aquí hay un link que lo explica muy bien en mi opinión:

http://veithen.io/2014/01/01/how-tcp-backlog-works-in-linux.html

Muchísimas gracias caballero.