2010-02-25 83 views
185

Suponiendo un rendimiento infinito del hardware, ¿puede una caja Linux admitir> 65536 conexiones TCP abiertas?¿Cuál es el número teórico máximo de conexiones TCP abiertas que puede tener una caja Linux moderna?

Entiendo que el número de puertos efímeros (< 65536) limita el número de conexiones de una IP local a un puerto en una IP remota.

La tupla (ip local, puerto local, IP remota, puerto remoto) es lo que define de forma única una conexión TCP; ¿Esto implica que se pueden admitir más de 65K conexiones si más de uno de estos parámetros son gratuitos? p.ej. conexiones a un número de puerto único en múltiples hosts remotos desde múltiples IP locales.

¿Hay otro límite de 16 bits en el sistema? ¿Número de descriptores de archivos quizás?

Respuesta

267

Un solo puerto de escucha puede aceptar más de una conexión simultáneamente.

hay un límite '64K' que se cita a menudo, pero que es por cliente al puerto del servidor, y necesita aclarar.

Cada paquete TCP/IP tiene básicamente cuatro campos para direccionamiento; estos son:

source_ip source_port destination_ip destination_port 
< client   > < server      > 

el interior de la pila TCP, estos cuatro campos se utilizan como una clave compuesta de hacer coincidir los paquetes a las conexiones (por ejemplo, los descriptores de fichero).

Si un cliente tiene muchas conexiones al mismo puerto en el mismo destino, tres de esos campos serán los mismos: solo source_port varía para diferenciar las diferentes conexiones. Los puertos son números de 16 bits, por lo tanto, la cantidad máxima de conexiones que un cliente determinado puede tener con un puerto de host determinado es de 64 K.

Sin embargo, varios clientes pueden tener hasta 64K conexiones con el puerto de cada servidor, y si el servidor tiene múltiples puertos o cualquiera de ellos es multi-hogar, puede multiplicarlo aún más.

Así que el límite real son los descriptores de archivos. A cada conexión de socket individual se le asigna un descriptor de archivo, por lo que el límite es realmente el número de descriptores de archivo que el sistema ha sido configurado para permitir y los recursos manejar. El límite máximo suele ser superior a 300 K, pero se puede configurar, p. con sysctl.

Los límites realistas de los que se jactan para las cajas normales son alrededor de 80 K, por ejemplo, los servidores de mensajería Jabber de subproceso único.

+1

En teoría, puede tener más de 64K conexiones salientes si (a) usa SO_REUSEADDR y (b) se dirige a diferentes direcciones IP de destino. Pero los límites de memoria del kernel probablemente te detengan primero. – Darron

+0

@Darron ¿Pensé que SO_REUSEADDR era para servidores vinculantes cuando se reinicia? – Will

+0

Sí, eso también. Básicamente relaja los controles tempranos para conflictos de direcciones para nuevos sockets. – Darron

13

Si usted está pensando en ejecutar un servidor y tratando de decidir cuántas conexiones puede servirse de una máquina, es posible que desee leer sobre the C10k problem y los problemas potenciales involucrados en el servicio a una gran cantidad de clientes al mismo tiempo.

+10

C10k tiene 10 años y ya no es divertido. [Lea esto] para ver cómo se puede abordar C1024K. – Chandranshu

+5

@Chandranshu - ¿leer qué? Supongo que quisiste poner un enlace en los comentarios ... – Krease

+0

bump 11 más para ir ... –

7

Si usó un socket sin procesar (SOCK_RAW) y reimplementó TCP en userland, creo que la respuesta está limitada en este caso solo por el número de tuplas (local address, source port, destination address, destination port) (~ 2^64 por dirección local).

Por supuesto, se necesita mucha memoria para mantener el estado de todas esas conexiones, y creo que tendrías que configurar algunas reglas de iptables para evitar que la pila TCP del kernel se molestara &/o respondieras en tu nombre .

Cuestiones relacionadas