Aumentar el número máximo de conexiones TCP / IP en Linux

Estoy programando un servidor y parece que mi número de conexiones está limitado ya que mi ancho de banda no está saturado, incluso cuando he establecido el número de conexiones en "ilimitado".

¿Cómo puedo aumentar o eliminar un número máximo de conexiones que mi caja de Ubuntu Linux puede abrir a la vez? ¿El sistema operativo limita esto, o es el enrutador o el ISP? ¿O es otra cosa?

El número máximo de conexiones se ve afectado por ciertos límites tanto en el lado del cliente como del servidor, aunque de manera un poco diferente.

En el lado del cliente: aumente el rango de puertos ephermal y disminuya eltcp_fin_timeout

Para conocer los valores predeterminados:

sysctl net.ipv4.ip_local_port_range
sysctl net.ipv4.tcp_fin_timeout

El rango de puertos ephermal define el número máximo de sockets salientes que un host puede crear desde una dirección IP particular. El fin_timeoutdefine el tiempo mínimo de estas tomas permanecerán en TIME_WAITestado (inutilizable después de ser utilizado una vez). Los valores predeterminados habituales del sistema son:

• net.ipv4.ip_local_port_range = 32768 61000
• net.ipv4.tcp_fin_timeout = 60

Esto básicamente significa que su sistema no puede garantizar consistentemente más de (61000 - 32768) / 60 = 470sockets por segundo. Si no está satisfecho con eso, podría comenzar aumentando el port_range. Establecer el rango en 15000 61000es bastante común en estos días. Podría aumentar aún más la disponibilidad disminuyendo el fin_timeout. Suponga que hace ambas cosas, debería ver más de 1500 conexiones salientes por segundo, más fácilmente.

Para cambiar los valores :

sysctl net.ipv4.ip_local_port_range="15000 61000"
sysctl net.ipv4.tcp_fin_timeout=30

Lo anterior no debe interpretarse como los factores que afectan la capacidad del sistema para realizar conexiones salientes por segundo. Pero más bien, estos factores afectan la capacidad del sistema para manejar conexiones concurrentes de manera sostenible durante grandes períodos de "actividad".

Los valores predeterminados de Sysctl en un cuadro típico de Linux para tcp_tw_recycley tcp_tw_reuseserían

net.ipv4.tcp_tw_recycle=0
net.ipv4.tcp_tw_reuse=0

Estos no permiten una conexión desde un zócalo "usado" (en estado de espera) y obligan a los zócalos a durar el time_waitciclo completo . Recomiendo configurar:

sysctl net.ipv4.tcp_tw_recycle=1
sysctl net.ipv4.tcp_tw_reuse=1 

Esto permite un ciclo rápido de los enchufes en time_waitestado y su reutilización. Pero antes de hacer este cambio, asegúrese de que no entre en conflicto con los protocolos que usaría para la aplicación que necesita estos sockets. Asegúrese de leer la publicación "Enfrentando el TCP TIME-WAIT" de Vincent Bernat para comprender las implicaciones. La net.ipv4.tcp_tw_recycle opción es bastante problemática para los servidores públicos, ya que no manejará las conexiones de dos computadoras diferentes detrás del mismo dispositivo NAT , lo cual es un problema difícil de detectar y espera para morderte. Tenga en cuenta que net.ipv4.tcp_tw_recyclese ha eliminado de Linux 4.12.

En el lado del servidor: el net.core.somaxconnvalor tiene un papel importante. Limita el número máximo de solicitudes en cola a un socket de escucha. Si está seguro de la capacidad de su aplicación de servidor, aumente el valor predeterminado de 128 a algo así como 128 a 1024. Ahora puede aprovechar este aumento modificando la variable de backlog de escucha en la llamada de escucha de su aplicación, a un número entero igual o superior.

sysctl net.core.somaxconn=1024

txqueuelenEl parámetro de sus tarjetas Ethernet también tiene un papel que desempeñar. Los valores predeterminados son 1000, por lo tanto, amplíelos hasta 5000 o incluso más si su sistema puede manejarlo.

ifconfig eth0 txqueuelen 5000
echo "/sbin/ifconfig eth0 txqueuelen 5000" >> /etc/rc.local

Del mismo modo aumentar los valores de net.core.netdev_max_backlogy net.ipv4.tcp_max_syn_backlog. Sus valores predeterminados son 1000 y 1024 respectivamente.

sysctl net.core.netdev_max_backlog=2000
sysctl net.ipv4.tcp_max_syn_backlog=2048

Ahora recuerde iniciar las aplicaciones del lado del cliente y del servidor aumentando los límites de FD en el shell.

Además de la técnica anterior más utilizada por los programadores, es reducir la cantidad de llamadas de escritura tcp . Mi preferencia es usar un búfer en el que inserto los datos que deseo enviar al cliente y luego, en los puntos apropiados, escribo los datos almacenados en el zócalo real. Esta técnica me permite usar grandes paquetes de datos, reducir la fragmentación, reduce la utilización de mi CPU tanto en el terreno del usuario como a nivel del núcleo.

Hay un par de variables para establecer el número máximo de conexiones. Lo más probable es que primero te estés quedando sin números de archivo. Verifique ulimit -n. Después de eso, hay configuraciones en / proc, pero las predeterminadas son decenas de miles.

Más importante aún, parece que estás haciendo algo mal. Una sola conexión TCP debería ser capaz de usar todo el ancho de banda entre dos partes; si no lo es:

• Compruebe si la configuración de su ventana TCP es lo suficientemente grande. Los valores predeterminados de Linux son buenos para todo, excepto para enlaces inet realmente rápidos (cientos de mbps) o enlaces satelitales rápidos. ¿Cuál es su producto de retraso de ancho de banda *?
• Verifique la pérdida de paquetes usando ping con paquetes grandes ( ping -s 1472...)
• Verifique la limitación de velocidad. En Linux, esto se configura contc
• Confirme que el ancho de banda que cree que existe realmente existe, por ejemplo, iperf
• Confirme que su protocolo es cuerdo. Recuerda la latencia.
• Si se trata de una LAN gigabit +, ¿puede usar paquetes jumbo? ¿Es usted?

Posiblemente he entendido mal. Tal vez estás haciendo algo como Bittorrent, donde necesitas muchas conexiones. Si es así, debe averiguar cuántas conexiones está utilizando realmente (intente netstato lsof). Si ese número es sustancial, podría:

• Tiene mucho ancho de banda, por ejemplo, 100mbps +. En este caso, es posible que necesite subir el ulimit -n. Aún así, ~ 1000 conexiones (por defecto en mi sistema) son bastantes.
• Tiene problemas de red que ralentizan sus conexiones (por ejemplo, pérdida de paquetes)
• Haga que algo más lo desacelere, por ejemplo, el ancho de banda de E / S, especialmente si lo está buscando. ¿Lo has comprobado iostat -x?

Además, si está utilizando un enrutador NAT de nivel de consumidor (Linksys, Netgear, DLink, etc.), tenga en cuenta que puede exceder sus capacidades con miles de conexiones.

Espero que esto ayude un poco. Realmente estás haciendo una pregunta sobre redes.

Para mejorar la respuesta dada por derobert,

Puede determinar cuál es el límite de conexión de su sistema operativo capturando nf_conntrack_max.

Por ejemplo: cat / proc / sys / net / netfilter / nf_conntrack_max

Puede usar el siguiente script para contar el número de conexiones tcp a un rango determinado de puertos tcp. Por defecto 1-65535.

Esto confirmará si está maximizando o no el límite de conexión de su sistema operativo.

Aquí está el guión.

#!/bin/bash
OS=$(uname)

case "$OS" in
    'SunOS')
            AWK=/usr/bin/nawk
            ;;
    'Linux')
            AWK=/bin/awk
            ;;
    'AIX')
            AWK=/usr/bin/awk
            ;;
esac

netstat -an | $AWK -v start=1 -v end=65535 ' $NF ~ /TIME_WAIT|ESTABLISHED/ && $4 !~ /127\.0\.0\.1/ {
    if ($1 ~ /\./)
            {sip=$1}
    else {sip=$4}

    if ( sip ~ /:/ )
            {d=2}
    else {d=5}

    split( sip, a, /:|\./ )

    if ( a[d] >= start && a[d] <= end ) {
            ++connections;
            }
    }
    END {print connections}'

En un nivel de aplicación, aquí hay algo que un desarrollador puede hacer:

Del lado del servidor:

1. Compruebe si el equilibrador de carga (si lo tiene) funciona correctamente.

2. Convierta los tiempos de espera TCP lentos en 503 Respuesta inmediata rápida, si el equilibrador de carga funciona correctamente, debería elegir el recurso de trabajo para servir, y es mejor que quedarse allí con masajes de error inesperados.

Por ejemplo: si está usando un servidor de nodo, puede usar demasiado ocupado desde npm. Implementación algo como:

var toobusy = require('toobusy');
app.use(function(req, res, next) {
  if (toobusy()) res.send(503, "I'm busy right now, sorry.");
  else next();
});

¿Por qué 503? Aquí hay algunas buenas ideas para la sobrecarga: http://ferd.ca/queues-don-t-fix-overload.html

También podemos hacer algo de trabajo en el lado del cliente:

1. Intente agrupar las llamadas por lotes, reduzca el tráfico y el número total de solicitudes en blanco y negro cliente y servidor.

2. Intente construir una capa intermedia de caché para manejar solicitudes duplicadas innecesarias.