¿Un host crea un hilo separado para cada solicitud de TCP SYN? ¿O depende de la implementación del socket para el host?
Excepto en el caso de la red de espacio de usuario, el sistema operativo maneja completamente el protocolo TCP completo en el kernel y notifica a la aplicación solo una vez que la conexión está completamente establecida. La parte del kernel se maneja de manera liviana, es decir, por lo general no hay hilos del kernel involucrados. Lo que sucede en el espacio de usuario después de que se establece la conexión depende de la aplicación. Algunas aplicaciones crean un nuevo hilo o un nuevo proceso para cada nueva conexión, mientras que otras lo manejan dentro del mismo hilo y proceso.
La forma en que una pila de red maneja múltiples conexiones es absolutamente específica del sistema operativo. De hecho, incluso es específico del hardware de red, ya que la mayoría de las mejores tarjetas de red pueden realizar gran parte del manejo de TCP por sí mismas.
Por lo tanto, generalmente no se puede asumir que una pila de red es multihebra inherentemente o no, desde un punto de vista de flujo puro, una tarjeta de red obtiene y procesa un paquete Ethernet después del otro, y por lo tanto, siempre puede procesar secuencialmente en software.
Sin embargo, podría tener ventajas (principalmente: poder dividir la carga de trabajo entre los núcleos de la CPU) para hacer que su sistema operativo maneje las redes de forma multiproceso. Tenga en cuenta que es probable que este subproceso no tenga la forma de subprocesos de territorio de usuario como probablemente los conoce, sino de tareas del sistema operativo; pero no hay garantía de que el manejo de TCP para las conexiones existentes no se realice en el terreno del usuario dentro del contexto del proceso que utiliza un socket. Es una decisión de diseño del sistema operativo.
Por otra parte, hay buenas razones para no redes de múltiples hilos, especialmente en situaciones de baja carga o cuando solo hay un receptor o remitente de paquetes dominante en su espacio de usuario (principalmente: la sincronización es difícil y, por lo tanto, a menudo es más costoso que simplemente analizar un encabezado TCP, y en realidad perdería más de lo que gana al decidir qué núcleo de CPU debería manejar un paquete después de que un núcleo ya lo haya tocado). De nuevo, esto a menudo se resuelve de manera muy adaptativa mediante sistemas operativos o en tarjetas de red de gama alta, incluso en hardware que se le puede indicar que transfiera contenido de paquetes a diferentes regiones de memoria y, por lo tanto, permita que cierto tráfico sea "pegajoso" a un núcleo específico.
Dado que este es el seguridad de la información SE e usted implicó el tema de DDOS: todo es altamente adaptable. Pero se puede suponer que la comprobación del estado en los sistemas operativos modernos se puede hacer bastante antes de que llegue la próxima interrupción de la tarjeta de red, y luego, la gestión / generación de paquetes SYN-ACK se puede hacer normalmente, por ejemplo. un bucle de evento principal o en tareas de trabajo.
SYN flooding solía ser un método efectivo hace unos 20 años. Simplemente no sé si ese sigue siendo el caso: a las máquinas modernas simplemente no les importa cuando la tabla de conexiones que tienen que manejar en un estado SYN-pero-todavía-no-ACK alcanza varios cientos de kilobytes (¡gaaasp!). Claro, al buscar las pocas solicitudes de SYN de clientes legítimos, se pueden tardar cientos de nanosegundos o incluso varios microsegundos en un formato de almacenamiento de datos medio eficiente para escenarios de ataques en los que el atacante no ha recibido un carril de 10 Gbit / s a su servidor ... Mi impresión es que una computadora portátil mediocre puede en estos días realizar firewall con estado (al menos con la conexión por defecto de Linux), NAT y TCP a una velocidad de cable de 1Gbit / s sin romper demasiado sudor. Saturar estas capacidades con entradas a una tabla aburrida de conexiones medio abiertas será bastante difícil.