Latency (Opóźnienie)

Latency is the time data needs to travel from sender to receiver across a network. It is given in milliseconds (ms). It is usually measured in one of two ways: as one-way delay, or as round-trip time (RTT) — the time there and back. Low latency means the system responds almost instantly. High latency is something you feel: pages load sluggishly, games lag, and online calls break up. Latency is not the same as bandwidth. Even a very “wide” link can have high latency if the data has far to travel or sits waiting in queues.

What are the components of network latency?

Every device along the way (every hop) adds some delay. Total latency is the sum of all of it. There are four components:

• Propagation delay — the time required for a signal to cover the physical distance between endpoints. It is limited by the speed of light in a given medium. In fiber-optic cable, the signal travels at approximately 200,000 km/s, or roughly two-thirds of the speed of light in a vacuum. In practice, this corresponds to approximately 0.5 ms of one-way delay per 100 km of route, or around 1 ms RTT. On long-distance connections, this is often the most significant component. It is the only component that cannot be eliminated — it can only be reduced by placing the server closer to the user.
• Serialization delay — the time to clock all the bits of a frame onto the link. It depends on the link’s bandwidth. A 1500-byte frame on a 1 Gb/s link goes out in about 12 µs. The slower the link, the larger this component.
• Queuing delay — the time a packet waits in a device buffer while the link is busy. This is the most variable component. Under congestion and with oversized buffers (a problem called bufferbloat) it can spike sharply. It is the main source of jitter — the variation in latency.
• Processing delay — the time a router or switch takes to read the header, look up the route, and pass the packet along. On modern hardware it is in microseconds and usually negligible. It grows, however, with deep packet inspection (DPI), encryption, or address translation (NAT).

What is RTT and how does it differ from one-way delay?

RTT (round-trip time) is the time for a packet to reach the destination and for an acknowledgment to come back. Roughly RTT ≈ 2 × one-way delay, but it is rarely exactly double. The forward and return paths can differ, and so can the queues in each direction. RTT is easier to measure — you do not need synchronized clocks at both ends. It is RTT that governs the performance of acknowledgment-based protocols. The bandwidth-delay product (BDP) is at work here: the higher the RTT, the lower the real throughput a single TCP stream reaches, and the slower connections set up (TCP and TLS handshakes).

How is latency measured?

• Ping (ICMP echo) — the simplest RTT measurement to a host. It shows minimum, average, and maximum values, plus packet loss.
• Traceroute / MTR — latency and loss at each successive hop. Useful for finding a bottleneck on the path.
• TTFB (Time To First Byte) — the time to the first byte of an application’s response. It combines network latency with server-side work.
• Active probes — the TWAMP/OWAMP protocols, for precise measurement of latency (including one-way) and jitter between chosen network points.
• Passive measurement — analysis of real traffic (from flows and telemetry), without adding any packets of your own. The time between SYN and SYN-ACK approximates network latency, while the time between an application request and its response gives application latency.

How does latency differ from bandwidth, throughput, and jitter?

• Bandwidth — how much data a link can carry per unit of time (e.g. Gb/s). It is the “width of the pipe.” Latency is the time to flow through it. A wider pipe does not shorten latency.
• Throughput — the data rate actually achieved. It is lower than the nominal bandwidth because of latency, loss, and queuing (the BDP describes this).
• Jitter — the variation in latency between consecutive packets. For real-time applications (voice over IP, or VoIP, and video conferencing), jitter is often more harmful than high but stable latency.
• Packet loss — the percentage of packets that never arrive. It forces retransmissions, and at high RTT those further extend the effective latency.

What latency is acceptable?

Thresholds depend on the use case, but as a rough guide: below 30 ms RTT the impact is negligible; 30–60 ms is already noticeable in online gaming; up to about 100 ms is usually fine for VoIP and browsing; 100–150 ms brings clear sluggishness; above 150 ms it becomes problematic for anything happening live. For jitter, below 20–30 ms is a reasonable reference. These are indicative values. What matters here is not just the average, but above all stability and the worst cases — the p95/p99 percentiles (values that 95% and 99% of measurements, respectively, stay below).

What increases latency?

1. Geographic distance and the number of hops on the path.
2. Type of link — radio and satellite connections have higher latency than fiber.
3. Congestion and bufferbloat — overly long queues in loaded devices.
4. Server and application load — slow backend responses raise TTFB.
5. In-path processing — encryption, deep packet inspection (DPI), address translation (NAT), misconfigured QoS.

Why does latency matter for security and network monitoring?

Latency is more than a performance metric. It is also a telemetry signal used in network performance monitoring (NPM) and in threat detection (NDR, the work of SOC teams):

• Detecting volumetric attacks — a rise in latency and jitter (growing queues) can be an early sign of a DDoS attack or link saturation, before the service stops working entirely.
• Telling a network problem from an application problem — splitting latency into a network part (e.g. from the TCP handshake) and an application part shows whether the link is to blame, or an overloaded or attacked server. This shortens response time (MTTR).
• Baselining and anomaly detection — once you know the normal latency profile for paths and services (the baseline), deviations stand out: rerouted traffic (e.g. suspicious route changes in the BGP protocol), an unexpected new path, or degradation that may signal data exfiltration or an unauthorized intermediary (a man-in-the-middle attack, a planted proxy).
• Covert channels and tunneling — analyzing the distribution of latency and the gaps between packets helps detect timing channels and tunnels (e.g. in DNS or ICMP traffic) used to steal data.
• SLA and network hygiene — continuous measurement of latency, jitter, and loss against percentiles (p95/p99) underpins service-level agreement (SLA) enforcement and catches the slow degradation that can mask incidents.

How is latency reduced?

1. Bring content and services closer to users (CDNs, edge, server placement).
2. Shorten and tidy up paths (peering, removing unnecessary hops).
3. Apply QoS and active queue management (AQM, e.g. CoDel/FQ-CoDel) against bufferbloat.
4. Optimize the backend and use caching to lower TTFB.
5. Measure latency both actively and passively, establish a baseline, and alert on percentiles.

Learn more

• Secure Access Service Edge (SASE) — SASE can add latency because traffic may be inspected and routed through cloud security services.
• North-South vs East-West Traffic — Latency differs by traffic direction, affecting transfers between users, the internet, and internal systems.
• Internet Peering — Poor peering can increase latency by forcing traffic through longer or more congested network paths.
• Scrubbing Center — Traffic sent to a scrubbing center may experience extra latency during DDoS mitigation.
• Digital Experience Monitoring — Digital experience monitoring often measures latency as a key factor in user-perceived performance.
• Cloud Access Security Broker (CASB) — CASB inspection and policy enforcement can add latency to cloud application access.