When a link runs near full and the checkout page still times out, bytes are moving and work is not getting done. The rate of work that still gets done is goodput, and it is the number a DDoS test reads first when it wants to know whether a service is serving anyone. Formally it is the throughput of useful, legitimate application data actually delivered to real users, as distinct from raw throughput, which counts every byte on the wire including the attack traffic and the retransmissions it provokes.
What it leaves out
The benchmarking definition in RFC 2647 is blunt about it: bits forwarded to the correct destination, minus any bits lost or retransmitted. Everything a device moved that did not end up as useful delivery is subtracted. That covers three things a bandwidth graph happily counts: the attack packets themselves, protocol overhead, and every segment that had to be sent twice.
For an application, a fourth item belongs on that list. A response that arrives after the client has given up is not goodput. The server did the work and the link carried the bytes, but the user had already seen an error, so the delivery counts for nothing.
Why it matters under attack
Under load the two numbers do not just drift apart; they can move in opposite directions. Loss triggers TCP retransmissions, failed requests trigger client retries, and both add traffic. A link can show more bytes per second during an attack than before it while completing fewer real transactions.
This is old knowledge. RFC 896 described "congestion collapse" in 1984: a network so busy carrying retransmitted copies that almost nothing useful arrives. A flood recreates that state on purpose. Throughput hides it and goodput shows it, because the throughput graph looks like a busy, healthy pipe the whole way down.
What a DDoS test measures
Production rarely has a clean goodput number, because it cannot tell which requests were real. A test can. It runs its own legitimate clients beside the attack and counts only their transactions that completed correctly inside the client timeout.
The output is a goodput floor: the lowest rate of real work served during each attack phase, as a share of the pre-attack baseline, reported per transaction type and next to throughput so the gap between them is visible. A login path and a static asset path rarely degrade together, so one blended figure hides the path that failed. Goodput is also the honest input to availability, which is only as good as the requests it counts as served.
How goodput separates a usable mitigation from one that sheds real users along with the flood is worked through in Layer 7 DDoS Testing.