What Is Bandwidth? Bandwidth vs Throughput vs Latency

A 1 Gbps link can never deliver more than 125 megabytes per second, and once Ethernet framing and TCP/IP headers are paid for, a single download tops out near 118 MB/s. That ceiling is the short answer to what is bandwidth: a capacity limit, not a promise of delivered speed. This explainer covers what bandwidth measures, a side-by-side table against throughput and latency, the Mbps vs MB/s conversion that trips up dashboards, worked math for streaming and large downloads, and a failure-mode matrix for confirming which constraint is actually slowing you down.

Bandwidth is the maximum rate a network path can carry data, measured in bits per second (Mbps, Gbps). As of 2026, a 1 Gbps Ethernet link caps TCP payload at roughly 949 Mbps (about 118.6 MB/s) on a standard 1,500-byte MTU, and the throughput a single application sees is usually lower, set by latency, packet loss and TCP window size.

Bandwidth meaning: what is bandwidth in a network?

In networking, bandwidth means the maximum data transfer rate a communication path can sustain, expressed in bits per second. It describes capacity: how much the pipe can carry. It says nothing about how much a given application actually receives, how long each packet takes to arrive, or how many bytes moved over a billing period.

The word gets attached to very different things, and the measurement point changes the number. A switch port reports its line rate. An ISP circuit may have a committed rate plus a burst allowance. A radio channel's bandwidth depends on modulation and signal quality, so it moves minute to minute. A traffic policer or shaper can impose a lower ceiling on a fast physical link. When two teams argue about "the bandwidth", they are often quoting different layers of the same path.

The effective bandwidth of an end-to-end path is the minimum across every hop: NIC, host queue, access link, transit, peering, and the far-end server. Upgrading one segment does nothing if another is narrower.

Bandwidth vs throughput vs latency: how they differ

On high-latency paths, a single flow's throughput is often limited by the TCP window rather than by the link's bandwidth.

Bandwidth vs. throughput: why the link is rarely the limit

Bandwidth is the maximum rate a path supports; throughput is the rate a real transfer achieves. Throughput is always equal to or lower than bandwidth, and the gap comes from latency, packet loss, congestion control, receive windows, CPU and disk limits on either host, and competing flows sharing the same queue.

The window math explains most of the gap. One TCP flow can move at most one window of data per round trip. A 4 MB window over an 80 ms RTT gives 32 megabits per 0.08 seconds, or 400 Mbps, no matter whether the link is 1 Gbps or 100 Gbps. To fill a path you need a window equal to the bandwidth-delay product: 1 Gbps multiplied by 80 ms is 80 megabits, or 10 MB. A host without window scaling, stuck at 64 KB, gets about 6.5 Mbps on the same path.

Loss compounds it. The classic Reno-style model puts single-flow throughput near 1.22 times MSS divided by RTT times the square root of the loss rate. With a 1,460-byte MSS, 100 ms RTT and 0.01% loss, that is about 14 Mbps. CUBIC and BBR behave better than this model, but the direction holds: past a certain point, more bandwidth stops helping and lower loss or RTT starts helping.

Bandwidth vs. latency

Latency is delay, bandwidth is capacity, and adding one does not reduce the other. A 10 Gbps transatlantic circuit still has roughly 70 to 80 ms of round-trip time from propagation alone. What latency does change is how much bandwidth a single connection can use, which is why moving content closer to users raises per-flow throughput without touching link speed.

Bandwidth vs. data transfer volume

Bandwidth is a rate; volume is a total. A link sustained at 1 Gbps for a 30-day month moves 125 MB/s multiplied by 2,592,000 seconds, about 324 TB. Providers bill on either axis: committed rate or 95th percentile for ports and transit, per-TB volume for most CDN and cloud egress. Mixing the two in a capacity plan produces wrong budgets.

How is bandwidth measured? Mbps vs MB/s and the counters behind it

Bandwidth is measured in bits per second: bps, Kbps, Mbps, Gbps and Tbps, using decimal prefixes (1 Mbps is 1,000,000 bits per second). File sizes and download speeds are usually shown in bytes, so divide the bit rate by 8. A 100 Mbps connection delivers at most 12.5 MB/s before protocol overhead.

Three conversions cover most confusion:

• Mbps to MB/s: divide by 8. 500 Mbps is 62.5 MB/s; 10 Gbps is 1.25 GB/s.
• Decimal vs binary: 12.5 MB/s is 11.92 MiB/s. Some operating systems label MiB as "MB", so a correct link can look 5% slow.
• Overhead: on a 1,500-byte MTU, TCP payload is about 94.9% of line rate without TCP options and about 94% with timestamps enabled.

Operationally, rates come from interface counters: octets, packets, drops, errors, discards and queue depth, sampled through SNMP, streaming telemetry, sFlow, NetFlow or IPFIX. The rate is the change in octets multiplied by 8, divided by the interval. Use the 64-bit counters (ifHCInOctets and ifHCOutOctets): a 32-bit octet counter wraps after about 4.29 GB, which on a busy 10 Gbps port is roughly every 3.4 seconds.

The sampling interval matters as much as the counter. A five-minute average of 40% utilization can hide bursts at 100% lasting a few milliseconds. As an illustration, a 10 Gbps port with a 12 MB buffer can absorb only about 9.6 ms of line-rate overflow before it drops, so microbursts cause loss that a five-minute graph never shows.

What happens when traffic exceeds available bandwidth?

When offered load exceeds bandwidth at any hop, the device buffers, delays, marks or drops packets. Buffers add latency first (bufferbloat), then overflow into drops. Active queue management and ECN marking signal congestion earlier, and policers drop anything above the contracted rate without queuing at all.

TCP responds through congestion control, shrinking its window when it sees loss or ECN marks and reducing throughput for every flow sharing the queue. UDP has no built-in response, so real-time media, QUIC stacks and game traffic must adapt at the application layer: lower bitrate, fewer packets, or forward error correction.

How much bandwidth do streaming and large downloads need?

Size bandwidth for peak and p99 demand, not averages. Multiply concurrent sessions by per-session bitrate, then add headroom for failover and bursts. For downloads, divide file size in bits by the target completion time. Model edge egress, origin traffic, cache fill, revalidation and ingest as separate paths, because each has its own bottleneck.

Worked examples, all arithmetic with stated assumptions:

• Video on demand: typical 1080p adaptive bitrate ladders top out around 5 to 8 Mbps and 4K around 15 to 25 Mbps (typical 2026 ranges, varying by codec). 10,000 concurrent viewers at 6 Mbps need 60 Gbps of edge capacity. At a 95% cache hit ratio the origin still serves 3 Gbps, and a new release with cold caches can push origin demand far above that.
• Large downloads: a 50 GB game build is 400 gigabits. At a delivered 1 Gbps it takes 400 seconds; at 100 Mbps, 66 minutes. A patch day with 20,000 simultaneous downloads at 50 Mbps each needs 1 Tbps across the delivery path.
• Enterprise WAN: backups, file sync, video calls, VoIP and VDI share the same queues. A nightly 2 TB backup over a 1 Gbps link needs about 4.5 hours at full rate, which collides with anything else scheduled in that window unless it is shaped.

The same capacity question applies at every layer: access links, cloud egress, transit ports, VPN tunnels, peering, load balancers and CDN paths. A CDN absorbs most edge capacity planning, but origin bandwidth, cacheability and cache-fill behavior during content churn still decide whether the origin holds up.

Bandwidth failure modes: what breaks and how to confirm it

Most "we need more bandwidth" tickets are throughput problems with a different root cause. The matrix below maps the symptom to the constraint and the measurement that confirms it.

Only one of these six rows is fixed by buying more bandwidth, so confirm the constraint before you upgrade the circuit.

What to check before buying more bandwidth

Pull one-second telemetry for the busiest path and line it up against drops, queue depth, discards, ECN marks, policer statistics and TCP retransmissions. If utilization shows spare capacity while users see slow transfers, you are monitoring the wrong segment, or measuring bandwidth when the real limit is throughput.

On Linux hosts, the common single-flow fix is socket buffer sizing: set net.core.rmem_max and net.core.wmem_max, plus the maximum (third) value of net.ipv4.tcp_rmem and net.ipv4.tcp_wmem, to at least the path's bandwidth-delay product. For 1 Gbps at 100 ms that is 12.5 MB, so 16777216 bytes (16 MB) leaves headroom. The trade-off is memory: large buffers on thousands of idle connections waste RAM, which is why autotuning only grows them under demand. Related terms such as latency and throughput get their own entries in the CDN and networking glossary.

FAQ: bandwidth meaning, units and throughput

What is the difference between bandwidth and throughput?

Bandwidth is the maximum rate a network path can carry, while throughput is the rate a real transfer actually achieves. Throughput is always lower or equal, limited by round-trip time, packet loss, TCP window size, congestion and host resources. A single flow with a 4 MB window over an 80 ms path tops out at 400 Mbps even on a 10 Gbps link.

Is 100 Mbps bandwidth the same as 100 MB/s?

No, 100 Mbps bandwidth equals 12.5 MB/s, because network bandwidth is measured in bits and file transfers in bytes, with 8 bits per byte. After TCP/IP and Ethernet overhead, expect about 11.8 MB/s of file data. Some operating systems display binary megabytes, which shows the same speed as roughly 11.3 "MB/s".

How much bandwidth do I need for 4K video streaming?

A single 4K video stream typically needs about 15 to 25 Mbps of sustained bandwidth in 2026, depending on codec and the top rung of the bitrate ladder. For a delivery platform, multiply peak concurrent viewers by average delivered bitrate: 10,000 viewers at 20 Mbps need 200 Gbps of edge capacity, plus failover headroom and origin cache-fill capacity.

Does more bandwidth reduce latency?

More bandwidth does not reduce propagation latency, which is set by distance and the speed of light in fiber. It can reduce queuing latency when a link is congested, because packets wait less in buffers. For per-flow speed on long paths, lowering round-trip time or packet loss usually helps more than adding link capacity.

Why is my download slower than my bandwidth?

A download runs slower than available bandwidth when something other than link capacity limits throughput: a TCP window smaller than the bandwidth-delay product, packet loss, a policer, server CPU or disk limits, or congestion at a peering point. Test with one flow and with several parallel flows; if parallel flows fill the link, the window or loss is the constraint.

Measure delivered throughput on your own traffic this week

Pick your heaviest delivery path and collect one-second interface counters alongside per-region TCP retransmission rate and RTT for seven days. Run a single-stream and an 8-stream iperf3 test across the same path, then compute the bandwidth-delay product for your p95 RTT and compare it with your hosts' socket buffer limits. If parallel streams win by more than 2x, tune windows before you buy capacity. For a public reference point, BlazingCDN publishes its 100 MB HTTPS download results, measured June 2026 (Europe 27 ms and 1.12 Gb/s, North America 24 ms and 1.11 Gb/s, Asia 47 ms and 761 Mb/s), with a test file on its CDN performance metrics page, so you can compare delivered throughput from your own clients.