"The request took 300 ms" describes an outcome, not a cause.

Those 300 ms may include name resolution, connection setup, data moving across several links, waiting behind other packets, server processing, and response transfer. Different causes require different fixes, so useful latency analysis breaks the total into stages.

At the network level, four delays appear at each hop:

An application request adds endpoint and protocol work around those network delays. Understanding both levels turns one opaque timing number into a sequence of measurable intervals.

A packet moving from one device to the next can experience four distinct kinds of delay.

The components occur repeatedly along an end-to-end path:

The diagram separates work inside a device from movement across a link. Each outgoing interface can also have its own queue and transmission rate.

Processing delay is the time a device spends examining a packet and deciding what to do with it.

A router may perform work such as:

Switches, firewalls, network address translators, load balancers, proxies, and VPN gateways perform their own forms of packet or connection processing. A path with more middleboxes can therefore have more processing stages than its visible router count suggests.

At an endpoint, packet handling continues through the network interface, operating-system networking stack, socket buffers, and process scheduler before application code receives the data. The return path performs the reverse sequence.

Processing delay is often small per packet, but small costs can become visible at high packet rates or on an overloaded device. It can also vary. A packet handled in dedicated hardware may take a different path from one sent to a device's general-purpose CPU for exceptional processing.

Application processing is related but should be measured separately. A database query that takes 80 ms contributes to API latency, but it is not router processing delay.

An outgoing link can transmit only one sequence of bits at a time. If a packet arrives while that link is busy, the packet waits in a queue.

Queueing delay is the time between entering the queue and beginning transmission.

With Q bits ahead of a packet on a link operating at R bits per second, a simple estimate is:

If 2 MB of data is already queued ahead on a 100 Mbps link:

The packet gains 160 ms of delay before its own transmission begins.

Queueing is usually the most variable of the four per-hop components. An idle queue adds nearly no waiting. A burst arriving a moment later may fill the same queue. This variation contributes directly to jitter and tail latency.

Average traffic below link capacity can still create queues. Traffic arrives in bursts rather than as a perfectly smooth stream. When sustained arrival rate approaches the service rate, queues have less time to drain between bursts. Throughput may remain high while latency increases because packets spend more time waiting.

Queues exist beyond routers. Packets can wait:

The last item is application queueing rather than packet queueing, but both add waiting time to the same request.

Large Queues and Bufferbloat

Dropping traffic immediately during a short burst wastes available buffering, so network devices maintain queues. Excessive queue capacity creates a different problem: packets can wait for hundreds of milliseconds while the link remains fully utilized.

This condition is called bufferbloat. A bulk upload can fill a long queue, causing an unrelated interactive request to wait behind the queued data. The connection still reports high throughput, yet the interactive request experiences poor latency.

More buffering can prevent packet loss without improving completion time. Queue occupancy and queueing delay matter alongside link utilization.

Transmission delay, also called serialization delay, is the time required to place every bit of a packet onto a link.

For a packet containing L bits and a link rate of R bits per second:

A 1,500-byte packet contains 12,000 bits. Its transmission time differs greatly by link rate:

Transmission delay depends on packet size and link rate. It does not depend on the physical length of the link.

The first bit begins propagating as soon as transmission starts. The last bit begins propagating only after the complete transmission delay has elapsed. On one link, the last-bit arrival time relative to the start of transmission is approximately:

Each link on a path has its own transmission rate. Under a simplified store-and-forward model, a router receives a complete packet before transmitting that packet on the next link. The packet therefore incurs transmission delay on every link.

For a stream of many packets, routers can pipeline them. While packet 1 moves across a later link, packet 2 can cross an earlier link. The time for a large transfer is therefore not calculated by multiplying every packet's size by the sum of all link rates. The bottleneck link usually controls the sustained serialization rate after the pipeline fills.

Propagation delay is the time for a signal to travel across the physical medium from one end of a link to the other.

For distance D and propagation speed S:

Signals in fiber commonly travel at roughly 200,000 kilometers per second, about two-thirds of the speed of light in vacuum. A 10,000 km fiber path therefore has a theoretical one-way propagation delay near:

The corresponding propagation contribution to RTT is near 100 ms before adding transmission, processing, queueing, or endpoint work.

Actual network routes are longer than straight-line geographic distance. Cables follow available corridors, traffic may pass through distant interconnection points, and the route can change. Repeaters, optical equipment, and routers add further delay.

Propagation delay depends on distance and the medium's signal speed. It does not depend on packet size. Increasing a link from 100 Mbps to 1 Gbps reduces transmission delay but does not make the signal cross the same fiber faster.

This physical limit explains why a remote service cannot achieve local-network latency through bandwidth upgrades alone.

The two terms are easy to confuse because both occur while data crosses a link.

Consider a truck entering a long road through a narrow gate. The time for the entire truck to pass through the gate resembles transmission delay. The time to drive from the gate to the destination resembles propagation delay.

The analogy maps to the formulas:

Changing packet size does not change how fast the first bit propagates. Changing bandwidth does not change the propagation speed. A large payload on a slow local link can be dominated by transmission, while a tiny message across an ocean can be dominated by propagation.

For one packet crossing several links, the simplified one-way network delay is:

Consider one 1,500-byte packet crossing three links and two routers:

Transmission delay across the three links is:

Propagation delay is approximately:

The estimated one-way delay is:

If the reverse path had identical conditions, these network components would contribute about 54.064 ms to RTT. Real forward and reverse paths can differ in route, load, and link rate, so RTT should not be assumed to be exactly twice a one-way estimate.

The calculation also describes one packet, not a complete application transaction. Connection setup, server work, loss recovery, and payload transfer can add substantially more time.

Many network operations contain sequential exchanges. One stage must finish before the next can begin, so their delays add.

An HTTPS request on a new connection can involve:

The exact number of exchanges depends on protocol versions, cached state, connection reuse, and network conditions. The important latency property is dependency: if security negotiation cannot start before connection setup finishes, those stages lie on the same serial path.

Reusing already available state removes work from the request path. For example, a cached address avoids a live lookup, while an established connection avoids new connection setup. This changes the latency breakdown even when the physical route stays the same.

Parallel stages behave differently. If two independent lookups take 20 ms and 30 ms and run concurrently, they add about 30 ms to the critical path, not 50 ms. Latency analysis must identify both the duration of each stage and the dependencies between stages.

Network RTT is only one part of request latency. Before a request leaves and after it arrives, endpoints perform additional work.

On the client, delay can come from:

On the server, delay can come from:

After the response reaches the client, decompression, parsing, rendering, or other processing can extend user-visible latency beyond network completion.

For a small HTTP response, time to first byte can be approximated as:

Total response time adds the transfer of the remaining response body and any client work included in the measurement boundary:

The formulas are decompositions rather than protocol guarantees. Some stages may be absent, reused, overlapped, or measured under different boundaries.

A lost packet consumes time even when the transport eventually recovers it.

The sender must detect that data is missing, retransmit it, and wait for the replacement to arrive. Detection can come from acknowledgment patterns or a timer, so the added delay can range from part of an RTT to a longer timeout.

Reliable ordered delivery can also delay later data that arrived successfully. If the receiver is missing earlier bytes, the application may be unable to consume subsequent bytes until recovery completes.

Loss therefore affects more than throughput. It can create sudden latency spikes, especially when the request or response cannot complete without the missing packet.

Wireless links may perform local retransmissions below the transport layer. These can hide packet loss from TCP while still adding variable delay. A capture at the endpoint may show no TCP retransmission even though link-layer recovery increased RTT.

curl exposes several cumulative timing points for an HTTPS request:

A representative output might be:

These values are cumulative from the start of the operation. Convert them into stage durations by subtracting adjacent timestamps:

The 85 ms interval still combines request transmission, network travel, server queueing, server processing, and first-byte return travel. Client timing alone cannot separate those components.

Server-side timing can narrow the boundary. If the server records 35 ms from request acceptance to first response write, then approximately 50 ms of the 85 ms interval remains outside that server measurement. That remainder can include transit, proxy work, and scheduling around both endpoints. The subtraction is useful only when the timestamps measure compatible events.

One request does not characterize a service. Repeat the measurement, separate cold and reused connections, keep response sizes consistent, and report latency percentiles.

Different tools illuminate different parts of the latency path.

ping reports ICMP probe round-trip time from one host to another. The reported RTT does not include name resolution, TCP, TLS, application processing, or response-body transfer.

traceroute attempts to reveal intermediate hops and reports response timing associated with probes. A hop's displayed time is not the forwarding delay introduced by that router alone. It is a round trip to that hop, and routers can delay, deprioritize, or ignore probe responses.

Packet captures show when packets reach the capture point. They can reveal connection setup, retransmissions, acknowledgment timing, and gaps on the wire, but they do not directly expose time spent inside an application before a packet was created.

Application traces and server metrics expose queueing and processing stages that packet tools cannot see. They need precise timestamps and consistent boundaries to align with client observations.

No single measurement identifies every latency component. A useful breakdown combines observations from the client, network, and server.

"Latency is determined by distance." Distance sets a propagation lower bound. Processing, queueing, transmission, protocol exchanges, and endpoint work add to it.

"More bandwidth reduces every kind of delay." A higher link rate reduces transmission time and may help queues drain faster. It does not reduce propagation distance or application processing time.

"Transmission delay is travel time." Transmission places bits onto a link. Propagation moves their signal across the link.

"Every packet has the same latency." Queue occupancy, scheduling, route changes, wireless contention, and loss recovery make delay variable.

"A router shown as 80 ms in traceroute added 80 ms." The displayed value is a probe round trip to that hop, not an isolated per-router forwarding cost.

"Low ping time guarantees a fast API." Ping excludes connection setup, security negotiation, server queueing, server processing, and payload transfer.

"High throughput means queues are healthy." A full queue can keep a link busy while adding substantial latency.

"Client timing can identify server processing exactly." Client measurements combine several stages. Server-side timestamps are needed to isolate server work.

"RTT is always twice one-way delay." Forward and reverse traffic can follow different routes and encounter different load.

End-to-end latency combines processing, queueing, transmission, and propagation delays across every link and device. Queueing is often the most variable; transmission time is packet size divided by link rate, while propagation depends on distance and signal speed. More bandwidth reduces transmission time but not propagation on a fixed route.

Sequential protocol exchanges add round trips, whereas independent parallel work contributes its longest stage. Endpoint scheduling, server queues, computation, dependencies, response processing, and packet-loss recovery also add time. Client, network, and server measurements expose different parts of the total.

Define the measurement boundaries and divide total latency into stages; the dominant source then becomes measurable instead of speculative.