Pregunta ¿Qué limita el número máximo de conexiones en un servidor Linux?


¿Qué parámetro del kernel u otras configuraciones controlan la cantidad máxima de sockets TCP que se pueden abrir en un servidor Linux? ¿Cuáles son las ventajas y desventajas de permitir más conexiones?

Me di cuenta al cargar la prueba de un servidor Apache con ab que es bastante fácil maximizar las conexiones abiertas en el servidor. Si deja de lado la opción ab-k, que permite la reutilización de la conexión y le permite enviar más de aproximadamente 10,000 solicitudes, Apache atiende las primeras 11,000 solicitudes y luego se detiene durante 60 segundos. Una mirada a la salida de netstat muestra 11,000 conexiones en el estado TIME_WAIT. Al parecer, esto es normal. Las conexiones se mantienen abiertas un valor predeterminado de 60 segundos, incluso después de que el cliente haya terminado con ellas durante Razones de fiabilidad TCP.

Parece que esta sería una forma fácil de hacer un servidor DoS y me pregunto cuáles son los ajustes y precauciones habituales para ello.

Aquí está mi salida de prueba:

# ab -c 5 -n 50000 http://localhost/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 5000 requests
Completed 10000 requests
apr_poll: The timeout specified has expired (70007)
Total of 11655 requests completed

Aquí está el comando netstat que ejecuto durante la prueba:

 # netstat --inet -p | grep "localhost:www" | sed -e 's/ \+/ /g' | cut -d' ' -f 1-4,6-7 | sort | uniq -c 
  11651 tcp 0 0 localhost:www TIME_WAIT -
      1 tcp 0 1 localhost:44423 SYN_SENT 7831/ab
      1 tcp 0 1 localhost:44424 SYN_SENT 7831/ab
      1 tcp 0 1 localhost:44425 SYN_SENT 7831/ab
      1 tcp 0 1 localhost:44426 SYN_SENT 7831/ab
      1 tcp 0 1 localhost:44428 SYN_SENT 7831/ab

85
2018-05-21 16:18


origen




Respuestas:


Finalmente encontré la configuración que realmente limitaba el número de conexiones: net.ipv4.netfilter.ip_conntrack_max. Esto se estableció en 11,776 y lo que yo establezca es el número de solicitudes que puedo atender en mi prueba antes de tener que esperar tcp_fin_timeout segundos para que haya más conexiones disponibles. los conntrack tabla es lo que el kernel usa para rastrear el estado de las conexiones, así que una vez que está lleno, el kernel comienza a soltar paquetes e imprimir esto en el registro:

Jun  2 20:39:14 XXXX-XXX kernel: ip_conntrack: table full, dropping packet.

El siguiente paso fue hacer que el núcleo recicle todas esas conexiones en el TIME_WAIT Estado en lugar de caer paquetes. Podría conseguir que eso suceda ya sea encendiendo tcp_tw_recycle o aumentando ip_conntrack_max para ser más grande que el número de puertos locales disponibles para conexiones por ip_local_port_range. Supongo que una vez que el núcleo está fuera de los puertos locales, comienza a reciclar las conexiones. Esto utiliza más conexiones de seguimiento de memoria, pero parece ser la mejor solución que encender tcp_tw_recycle ya que los documentos implican que eso es peligroso.

Con esta configuración puedo ejecutar ab todo el día y nunca quedarme sin conexiones:

net.ipv4.netfilter.ip_conntrack_max = 32768
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_orphan_retries = 1
net.ipv4.tcp_fin_timeout = 25
net.ipv4.tcp_max_orphans = 8192
net.ipv4.ip_local_port_range = 32768    61000

los tcp_max_orphans La configuración no tuvo ningún efecto en mis pruebas y no sé por qué. Pensaría que cerraría las conexiones en TIME_WAIT Estado una vez que había 8192 de ellos, pero no lo hace por mí.


62
2018-06-03 16:02



¿Dónde configuramos estos parámetros? - Codevalley
@Codevalley Eso puede depender del sistema, pero en Ubuntu Server van en /etc/sysctl.conf - Ben Williams


Realmente desea ver lo que el sistema de archivos / proc tiene para ofrecerle a este respecto.

En esa última página, puede encontrar lo siguiente que sea de su interés:

  • / proc / sys / net / ipv4 / tcp_max_orphans, que controla el número máximo de sockets mantenidos por el sistema no apegado a algo Elevar esto puede consumir hasta 64kbytes de memoria no intercambiable por toma huérfana.
  • / proc / sys / net / ipv4 / tcp_orphan_retries, que controla la cantidad de reintentos antes de que un socket quede huérfano y cerrado. Hay una nota específica en esa página sobre servidores web que le interesa directamente ...

23
2018-05-21 18:15



tcp_max_orphans es interesante pero parece que no está funcionando. Cuando trato de medir sockets huérfanos durante mi prueba, veo 11,651 de ellos mientras que tcp_max_orphans es 8,092. # netstat --inet -p | grep "localhost: www" | sed -e 's / \ + / / g' | corte -d '' -f 1-4,6-7 | ordenar uniq -c 11651 tcp 0 0 localhost: www TIME_WAIT - - Ben Williams
Mire la configuración de tcp_orphan_retries: la idea es que los enchufes se "eliminan" más rápido ... - Avery Payne
La sugerencia de @Jauder Ho + tcp_orphan_retries suenan como una posible victoria para su situación. - Avery Payne


No creo que haya un ajuste ajustable para establecer eso directamente. Esto cae bajo la categoría de ajuste de TCP / IP. Para saber qué puedes sintonizar, prueba 'man 7 tcp'. El sysctl ('man 8 sysctl') se utiliza para configurar estos. 'sysctl -a | grep tcp 'le mostrará la mayor parte de lo que puede sintonizar, pero no estoy seguro de si los mostrará a todos. Además, a menos que esto haya cambiado, los sockets TCP / IP se abren como descriptores de archivos. Asi que esta y la siguiente sección en ese enlace puede ser lo que está buscando.


3
2018-05-21 17:31





Intenta configurar lo siguiente y configura tcp_fin_timeout. Esto debería cerrar TIME_WAIT más rápidamente.

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

2
2018-05-21 19:38



¡Cuidado aquí! Experimentado el camino difícil. "Esto puede provocar la caída de marcos con balanceo de carga y NAT, solo use esto para un servidor que se comunique solo a través de su red local". - wiki.archlinux.org/index.php/Sysctl - Henk
@Henk supongo que es tcp_tw_recycle Eso es potencialmente peligroso. tcp_tw_reuse Es más seguro y no veo ninguna razón para usarlos simultáneamente. - Vladislav Rastrusny


El apache de valores (1) solía venir predefinido para admitir solo 250 conexiones simultáneas; si deseaba más, había un archivo de encabezado que se podía modificar para permitir más sesiones simultáneas. No sé si esto sigue siendo cierto con Apache 2.

Además, debe agregar una opción para permitir un mayor número de descriptores de archivos abiertos para la cuenta que ejecuta Apache, algo que los comentarios anteriores no señalan.

Preste atención a la configuración de su trabajador y al tipo de tiempo de espera de actividad que tiene dentro de Apache, cuántos servidores de reserva tiene a la vez y qué tan rápido se eliminan estos procesos adicionales.


2
2018-05-21 21:21





Podría reducir el tiempo empleado en el estado TIME_WAIT (Establecer net.ipv4.tcp_fin_timeout). Podría reemplazar Apache con YAWS o nginx o algo similar.

Los intercambios de más conexiones generalmente implican el uso de memoria, y si tiene un proceso de bifurcación, hay muchos procesos secundarios que inundan su CPU.


1
2018-05-21 16:26



tcp_fin_timeout no es para establecer la caducidad de TIME-WAIT, que no se puede cambiar fuera de la reconstrucción del kernel, sino para FIN, como lo indica el nombre. - Alexandr Kurilin


El número absoluto de sockets que se pueden abrir en una sola dirección IP es 2 ^ 16 y está definido por TCP / UDP, no por el núcleo.


0
2018-05-30 16:42



No, no lo es. Puede abrir más, ya que el puerto local no necesita ser único siempre que las direcciones remotas sean diferentes. Además, el OP dice por servidor, y puede tener> 1 dirección por servidor. - MarkR


La herramienta de evaluación comparativa del servidor HTTP Apache, ab, en la versión 2.4 tiene el -s tiempo de espera opción. Ver también Error ab (banco de Apache): apr_poll: el tiempo de espera especificado ha caducado (70007) en Windows.

Esta opción resuelve tu problema.


0
2018-02-08 17:56