comparison Networks
Latency vs bandwidth
Waiting is not the same as transferring. See how round-trip time, body size and goodput shape one simplified response.
What it means
Latency describes delay. Bandwidth describes capacity to move data at a particular layer and along a particular path. Neither alone tells you how long a web response will take. This example uses round-trip time for delay and a separately chosen goodput for the useful body-data rate. It does not equate a connection's advertised capacity with delivered application data. Capacity terminology
Try it
Change one value at a time. Watch the waiting and transfer portions of the same response. These are simulated inputs, not measurements of your connection.
Same question, different constraints
| Quantity | Unit here | What it changes in this model |
|---|---|---|
| Round-trip time | ms | The waiting portion |
| Body size | decimal kB | How much useful data must move |
| Goodput | Mbps | The rate used for the body transfer |
The distinction between network capacity and achieved throughput matters. A capacity figure needs a layer and a path; it is not automatically the rate available to a particular application. We therefore make the useful data rate an explicit input. Capacity terminology
Why the numbers change
Our deliberately narrow model is T = RTT + 8 × size / goodput, with time in milliseconds, size in decimal kilobytes and goodput in megabits per second. One kB is 1,000 bytes; eight bits make one byte. Converting both decimal units and seconds to milliseconds gives the factor of eight.
At the default settings, 1,000 kB at 20 Mbps needs 400 ms of transfer time. Add 80 ms of RTT and the model gives 480 ms. Doubling goodput halves the transfer portion, not the whole total. Setting the body size to zero leaves the RTT term. These values are arithmetic examples, not performance promises.
In practice
Use the controls to distinguish two hypotheses: “the response is small but starts slowly” and “the response starts promptly but contains a lot of data.” In this model, reducing RTT helps the first situation; increasing goodput or reducing size helps the transfer portion. The comparison has no universal winner.
Actual TCP throughput can depend on RTT, congestion and receive windows, loss and other conditions. Holding goodput independent of RTT is a teaching simplification, not a claim about TCP behavior. TCP throughput
About the boundary
Assume an already established connection, one response body, constant positive goodput and no separate server-processing time. DNS, connection/TLS setup, request bytes, headers, slow start, retransmissions, competing requests and browser rendering are not separately modeled. The formula is our two-term teaching model; RFC 6349 is context for TCP behavior, not its source.
Sources & model boundaries
Primary references used for this explanation. The interactive example is our own implementation.
- RFC 5136 — Defining network capacity
Sections 2 and 3. Capacity must be described at a defined layer and along a defined path.
Checked .
- RFC 6349 — TCP throughput testing
Sections 1, 1.2 and 3.3. RTT, bottleneck bandwidth, TCP windows and achieved throughput; not the teaching formula itself.
Checked .