Hai ragione. La possibilità di ricevere più comunicazioni proteggerà da quel tipo di DoS, ovvero: aumenterà la "potenza" necessaria al DoS per essere dannoso (nello scenario single-client).
D'altra parte, tenere aperte più comunicazioni contemporaneamente avrà un impatto sul server (memoria e risorse ) che sono fondamentalmente di nuovo memoria, gestite da una quantità trascurabile di CPU). Quindi stai scambiando una vulnerabilità con "DoS lenti" con un'altra.
Per i sistemi tipici, ha senso, dato che hanno memoria da risparmiare e CPU da masterizzare, a meno che il protocollo o l'architettura non lo facciano, è desiderabile un supporto asincrono multiplo.
L'altra (più tipica) possibilità è che stiamo guardando una grande serie di comunicazioni parallele continue, cioè un gran numero di canali client HTTP persistenti. In tal caso, chiedete, se la latenza causa la caduta di N connessioni da M e la loro reintegrazione, causerà l'apertura simultanea delle connessioni M + N, quindi M + 2N, quindi M + 3N ...,; se la velocità di crescita supera la velocità con cui il server chiude le connessioni bloccate, le risorse del server saranno esaurite.
Ci sono diverse linee di difesa contro questo. Di solito, quando una connessione si interrompe (a livello HTTP), il server sarà a conoscenza del fatto a livello TCP, quando il client chiude il canale. A meno che il cliente non tenti di rilasciare la connessione senza un by-your-leave o mantenga vivo il vecchio socket e ne apra un altro (tali perdite sono principalmente dovute alla programmazione sciatta - ma succede); in tal caso il server noterà il fatto dopo un opportuno timeout TCP , che può essere ulteriormente ridotto utilizzando l'opzione keepalive. Questo potrebbe non funzionare contro i client sciatti, dal momento che il socket sottostante non è affatto morto.
Quindi, il server potrebbe essere in grado di riconoscere il client (ad esempio utilizzando sessioni o indirizzo IP, un firewall può anche fare quest'ultimo) e distruggere qualsiasi altra comunicazione esistente con lo stesso client in modo esplicito o implicito (es. il client ha uno "slot" assegnato e può essere occupato solo una volta, quindi la comunicazione in arrivo sostituisce la prima, ciò deve essere fatto dopo autenticazione di successo e autenticazione del client, poiché altrimenti aprirebbe la porta a un altro DoS).
Il riconoscimento della sessione del client può essere l'unico modo pratico per gestire i client sciatti se l'indirizzo IP non è un'opzione (ad esempio diversi client legit dietro un NAT che condivide il suo indirizzo); a parte l'aggiornamento del software client, ovviamente. Tale situazione sarebbe facilmente visibile con un semplice netstat su qualsiasi client di questo tipo.
Infine, uno scenario del genere richiederebbe che l'intera architettura fosse quasi a pieno regime; puoi evitarlo monitorando le prestazioni e la capacità di aggiornamento prima di entrare nella "zona pericolosa". Più rimani dalla linea rossa, maggiore sarà la potenza (e la dimostrabilità e la colpevolezza) che richiederà un DoS prima di portare il sistema fino a lì, e più avvertimento avrai quando succederà. In breve, mangiare il 5% della capacità del sistema potrebbe essere accidentale, consumando costantemente il 50% in meno. Ovviamente, un tale margine di sicurezza avrà i suoi costi.