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