Stress Testing - Connection Saturation

Question

I've made a quick stress tester in C# (UDP packet flooder).

I've used another computer in my house as a testing target.

At the first time, I flooded the computer at a rate of 80Mbps.

That killed the internet connection (in the target computer) in seconds, making visiting ANY page impossible.

But later, I flooded the target computer at a rate of 1Gbps (which is more than 10 times stronger than the first attack), and to my surprise, it didn't kill the internet connection.

While the 1Gbps flood DID make the internet connection a lot slower, it didn't kill it. The page successfully loaded after a few minutes. Yes, slow, but still alive.

But in the 80Mbps flood, the page didn't load at all, even after an hour. The 80Mbps killed it completely.

How could this be?

Answer 1

So at 80 Mbps you were sending 28 million packets per second, and at 1 Gbps you were sending 16,400 packets per second. The problem isn't the amount of data but the number of packets. There's a certain amount of per-packet overhead. Not only is there data overhead, but there's switching overhead, both in the network hardware and in the software that has to decode the packets.

If you increased the packet size on the 80 Mbps test, it wouldn't fail.

Response to comments

Calculating the number of packets is a simple matter of dividing the data rate by the packet size. 80 Mbps divided by 3 bytes per packet comes out to about 28 million.

I don't know what software you used to generate the flood attack. The whole point of a UDP flood attack is to send as many packets as possible in a short period of time. So you want the packet data to be very small. Sending a large packet in the 1 Gbps test prevented it from sending as many packets.

A UDP packet header is 8 bytes. Add the three bytes for data that you used in the 80 Mbps test, and round up (to allow for likely overhead) to 16 bytes. Your 1 Gbps test used a packet length (including header) of 65,500 bytes, or 2^16 (65,536). So a single one of those large packets could hold 2^12 (4,096) of the smaller packets. Using two threads only doubled your packet rate. It still didn't come close to the packet rate you were running then the packets were only 3 bytes (plus header).