goodput
/ GOOD-put /
Imagine paying movers by the lorry-load, then noticing that much of each lorry is packing foam, paperwork, and the occasional box that had to be carried twice because it fell off. What you actually care about is how much of your real furniture arrived, not how full the lorries were. Goodput is that idea for networks: of all the bits a link carried, how many were useful application data that arrived correctly the first time and counted.
Throughput measures every bit that crossed the link; goodput measures only the bits the application actually wanted. The difference is everything you do not count: protocol headers (each packet carries Ethernet, IP, and TCP headers wrapping the payload), control packets like acknowledgments and handshakes, and especially retransmissions — when a packet is lost and sent again, those bytes cross the link twice but count toward goodput only once. So goodput is always less than or equal to throughput. A simple way to see it: if a 1 GB file finishes downloading in 100 seconds, the goodput is about 1 GB / 100 s regardless of how many extra bytes of overhead and resends the link actually carried to make that happen.
Goodput matters because it is the number a user feels. A link can show high raw throughput while delivering poor goodput if loss is forcing constant retransmission, or if tiny packets mean headers dominate the payload. It is the honest measure of "useful work done" and the right yardstick when comparing protocols: a design that cuts overhead or avoids needless resends raises goodput even if total throughput is unchanged. Tools like iperf can report application-level throughput that approximates goodput, but be clear which one a given number is.
A wireless link reports 50 Mbps of raw throughput, but radio errors force 20% of packets to be retransmitted and headers eat another slice. The file you download actually completes at about 38 Mbps — that 38 Mbps is the goodput, the rate of useful bytes you received, while the extra 12 Mbps was overhead and resends.
Goodput counts only useful application data delivered once; throughput counts every bit including headers, control packets, and retransmissions.
Goodput is always less than or equal to throughput, never more: it excludes headers, control traffic, and retransmissions. A high raw throughput can hide a poor goodput when loss is forcing constant resends.