La negazione del servizio e il sovraccarico del traffico sono due cose diverse, quindi l'utilizzo di un generatore di traffico non è davvero la strada da percorrere. I generatori di traffico sono ottimi per modellare l'utilizzo del mondo reale di una risorsa (ad esempio utenti che arrivano in momenti casuali (distribuzione di Poisson), modelli di navigazione casuali o registrati, ricerche comuni ed errori ...). La maggior parte degli DDoS è poco più di GET / HTTP/1.0 , ma in lotti di lavoro. Grandi lotti di lavoro . Questo non è vero "traffico".
Se vuoi vedere cosa succede quando il sistema ottiene DoSed e scarica le sue risorse, puoi ad es. disabilitare la protezione semiaperta SYN (SYN cookies) se presente, e utilizzare alcune utility DoS per simulare le connessioni di apertura. Oppure mantieni aperta la connessione tramite, per esempio, uno script Perl.
Oppure puoi inviare richieste a quegli endpoint con un carico di sistema più elevato (ad es. per richiedere l'interrogazione del database).
I dati malformati verranno probabilmente intercettati agli strati esterni del router Django (se non da WSGI stesso) e generano il minimo carico. Dipende dalla malformazione , ovviamente.
Rallentare la velocità di invio dovrebbe accentuare Apache più del resto dello stack (Django invia il suo output in modalità fire-and-forget), mentre le richieste pulsanti dovrebbero colpire Django più pesantemente, specialmente se sono costruite contro il più endpoint costosi.