throughput

If bandwidth is how wide a pipe is, throughput is how much water you actually get out the other end per second. It is the real, measured rate at which useful data is successfully delivered from sender to receiver — what you experience when a file downloads, not just what the link is rated for. Throughput is always at most the bandwidth, and usually less.

Why less? Because a path is only as fast as its narrowest point. If your data crosses several links of rates R1, R2, R3, the end-to-end throughput is limited by the bottleneck — the slowest link, min(R1, R2, R3). It also drops because of shared contention (your packets queue behind others), packet loss and retransmissions, protocol overhead (every packet carries header bytes), and the ramp-up of TCP's congestion control. So a 1 Gbps home link might deliver only 300 Mbps of real throughput to a distant, busy server.

Throughput is the number you usually care about in practice ('how fast did my file actually transfer?'), and it is distinct from both bandwidth (the ceiling) and latency (the delay). A useful relative is goodput: throughput counting only the application's real payload, excluding retransmissions and header overhead. A long-distance transfer can also be throttled by latency through the bandwidth-delay product — over a high-latency path, a single TCP connection cannot fill a fat pipe unless its window is large enough.