85 votos

Lo que limita el número máximo de conexiones en un servidor Linux?

¿Qué parámetro del kernel o de otros ajustes de controlar el número máximo de conexiones TCP que se pueden abrir en un servidor Linux? ¿Cuáles son las ventajas y desventajas de permitir más conexiones?

Me di cuenta mientras que la prueba de carga de un servidor Apache con ab que es muy fácil sacar el máximo partido a las conexiones abiertas en el servidor. Si deja fuera de ab opción-k, lo que permite la reutilización de conexiones, y enviar más de 10.000 solicitudes, a continuación, Apache sirve la primera de 11.000 o así lo solicite y, a continuación, se detiene durante 60 segundos. Un vistazo al resultado de netstat muestra de 11.000 conexiones en el estado TIME_WAIT. Al parecer, esto es normal. Se mantienen abiertas las conexiones de un valor predeterminado de 60 segundos, incluso después de que el cliente se hace con ellos para TCP motivos de confiabilidad.

Parece que esta sería una manera fácil para DoS un servidor y me pregunto lo que los ajustes y las precauciones para que son.

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 puedo ejecutar 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

23voto

Avery Payne Puntos 11379

Usted realmente quiere mirar lo que el sistema de archivos /proc tiene para ofrecer en este sentido.

En la última página, se puede encontrar lo siguiente para ser de su interés:

  • /proc/sys/net/ipv4/tcp_max_orphans, que controla el número máximo de tomas a cabo por el sistema no conectado a algo. La recaudación de este puede consumir tanto como 64kbyte de la no-swap de memoria por huérfano de socket.
  • /proc/sys/net/ipv4/tcp_orphan_retries, que controla la cantidad de reintentos antes de un socket es huérfano y cerrado. Hay una nota en la página acerca de los servidores web que es de interés directo para ti...

16voto

Jauder Ho Puntos 3172

Pruebe la configuración de la siguiente así la configuración de tcp_fin_timeout. Esto debe cerrar TIME_WAIT más rápidamente.

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

11voto

Ian Nelson Puntos 20020

Finalmente encontré el valor que realmente era limitar el número de conexiones: red.ipv4.netfilter.ip_conntrack_max. Esto fue creado para 11,776 y lo que me puse a es el número de peticiones que puede servir en mi prueba antes de tener que esperar tcp_fin_timeout segundos para obtener más conexiones disponibles. El conntrack tabla es lo que el núcleo se utiliza para registrar el estado de las conexiones, de forma que una vez lleno, el núcleo comienza a caer los paquetes y la impresión de esta en el registro:

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

El siguiente paso fue conseguir el kernel para reciclar todas las conexiones en el estado TIME_WAIT, en lugar de bajar los paquetes. Yo podría conseguir que eso suceda, ya sea girando en tcp_tw_recycle o el aumento de ip_conntrack_max a ser mayor que el número de puertos disponibles para las conexiones ip_local_port_range. Supongo que una vez que el kernel está fuera de los locales de los puertos se inicia el reciclaje de las conexiones. Este utiliza más memoria de seguimiento de conexiones, pero parece que la mejor solución que encender tcp_tw_recycle desde el docs implica que eso es peligroso.

Con esta configuración me puede ejecutar ab todo el día y nunca se ejecuta fuera de las 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

El tcp_max_orphans ajuste no tiene ningún efecto en mis pruebas, y yo no sé por qué. Yo creo que sería cerca de las conexiones en el estado TIME_WAIT una vez que hubo 8192 de ellos, pero no lo hace para mí.

5voto

Devdas Puntos 589

Usted puede reducir el tiempo de permanencia en el estado TIME_WAIT (Set net.ipv4.tcp_fin_timeout). Usted podría reemplazar Apache con el PIAN o nginx o algo similar.

Los equilibrios de más conexiones generalmente implican el uso de la memoria, y si usted tiene una bifurcación proceso, muchos de los procesos hijos que se pantano de la CPU.

1voto

Kyle Brandt Puntos 50907

Yo no creo que hay un sintonizable para establecer que directamente. Esto cae bajo la categoría de TCP/IP de optimización. Para averiguar lo que usted puede sintonizar, a tratar de 'el hombre 7 tcp". El sysctl ( 'man 8 sysctl' ) se utiliza para establecer estos. 'sysctl-a | grep tcp" se muestran más de lo que usted puede sintonizar, pero no estoy seguro de si se muestran todos ellos. También, a menos que esto ha cambiado, los sockets TCP/IP abierta hasta ver como descriptores de archivo. Para esta sección y la siguiente en la que el vínculo puede ser lo que usted está buscando.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: