Estás en lo correcto. La capacidad de recibir múltiples comunicaciones protegerá de ese tipo de DoS, o más bien: aumentará el "poder" que necesita el DoS para ser dañino (esto en el escenario de un solo cliente).
Por otra parte, mantener más comunicaciones abiertas al mismo tiempo tendrá un impacto en el servidor (memoria y recursos , que son básicamente memoria otra vez, manejados por una cantidad insignificante de CPU). Así que estás intercambiando una vulnerabilidad para "hacer lenta la DPS" con otra.
Para los sistemas típicos, tiene sentido, ya que tienen memoria de sobra y CPU para grabar. A menos que el protocolo o la arquitectura eviten hacerlo, es deseable un soporte asíncrono múltiple.
La otra posibilidad (más típica) es que estamos viendo una gran serie de comunicaciones continuas paralelas, es decir, una gran cantidad de canales de cliente HTTP persistentes. En ese caso, pregunta, si la latencia hace que las conexiones de N salgan de M y se restablezcan, las conexiones de M + N se abrirán simultáneamente, luego M + 2N, luego M + 3N ...,; si la tasa de crecimiento supera la velocidad a la que el servidor cierra las conexiones atascadas, los recursos del servidor se agotarán finalmente.
Hay varias líneas de defensa contra esto. Por lo general, cuando una conexión se cae (a nivel HTTP), el servidor será consciente del hecho en el nivel TCP, cuando el cliente cierre el canal. A menos que el cliente intente soltar la conexión sin dejar de lado su licencia o mantenga vivo el viejo socket y abre otro (tales fugas se deben principalmente a una programación descuidada, pero sucede); en ese caso, el servidor notará el hecho después de un tiempo de espera de TCP adecuado , que puede reducirse aún más mediante el uso de la opción keepalive. Es posible que esto no funcione contra clientes descuidados, ya que el socket subyacente no está muerto en absoluto.
Luego, el servidor puede reconocer al cliente (por ejemplo, mediante sesiones o dirección IP; un servidor de seguridad también puede hacer lo último), y eliminar cualquier otra comunicación existente con el mismo cliente de forma explícita o implícita (por ejemplo, porque el cliente tiene una "ranura" asignada y solo se puede ocupar una vez, por lo tanto, la comunicación entrante reemplaza a la primera; esto debe hacerse después de la identificación exitosa y la autenticación del cliente, ya que de lo contrario abriría la puerta a un DoS diferente).
El reconocimiento de la sesión del cliente puede ser la única forma práctica de tratar con clientes descuidados si la dirección IP no es una opción (por ejemplo, varios clientes legítimos detrás de un NAT que comparte su dirección); Además de actualizar el software del cliente, por supuesto. Tal situación sería fácilmente visible con un simple netstat en cualquier cliente.
Finalmente, tal escenario requeriría que toda la arquitectura esté casi en su capacidad; puede evitarlo controlando el rendimiento y mejorando la capacidad antes de ingresar a la "zona de peligro". Cuanto más lejos esté de la línea roja, más potencia (y voluntad demostrable y culpabilidad) requerirá un DoS antes de conducir el sistema hasta allí, y más advertencias tendrá cuando esto suceda. En pocas palabras, consumir hasta el 5% de la capacidad del sistema puede ser accidental, y consumir constantemente el 50% menos. Por supuesto, dicho margen de seguridad tendrá sus costos.