How Internet Speed Tests Work and Why Benchmark Results Vary

When network users test their broadband connections across different online speed test platforms, they frequently observe starkly contradictory results. A test run on one popular web utility might report 95 Mbps, while another platform tested thirty seconds later reports only 42 Mbps [1, 2].

These discrepancies rarely indicate erratic ISP provisioning. Instead, they reflect fundamental differences in testing methodology: the number of concurrent TCP connections, transport protocol choices (HTTP/WebSocket vs raw TCP), server geographic proximity, upstream peering capacity, and browser JavaScript overhead [1, 2]. In this technical guide, we examine how modern speed tests measure throughput, contrast single-stream versus multi-stream methodologies, and explain how network conditions govern benchmark outcomes [1, 2, 3].

1. The Anatomy of a Speed Test: TCP Mechanics

A speed test does not measure bandwidth instantaneously; it measures the rate at which data successfully transfers over an IP network during a specified time window [1, 2]:

$$\text{Throughput} = \frac{\text{Bytes Acknowledged}}{\text{Measurement Duration}}$$

The TCP Three-Way Handshake and Slow Start

Transmission Control Protocol (TCP) is a connection-oriented, reliable transport protocol [2, 3]:

1. Three-Way Handshake: The client and benchmark server negotiate connection parameters via SYN, SYN-ACK, and ACK packets [3].
2. Slow Start: TCP begins with a conservative Congestion Window (CWND). With each successful round-trip acknowledgment, the sender doubles its transmission rate until packet loss occurs or the receiver's window (RWND) ceiling is reached [2, 3].
3. Steady State: Once maximum capacity is determined, the algorithm oscillates slightly around the available link bandwidth.

If a speed test runs for only five seconds on a high-latency international connection, the TCP algorithm may not exit its slow-start ramp-up phase before the test concludes, yielding artificially low throughput readings [2].

2. Single-Threaded vs Multi-Threaded Testing

The most significant source of variance between speed test engines is stream concurrency [2]:

Multi-Threaded Testing (Multi-Stream)

Most consumer-facing platforms open 4 to 32 simultaneous TCP connections in parallel:

• How it works: Multiple concurrent streams saturate the subscriber's physical link, masking the performance degradation caused by packet latency or packet loss on any single connection [2].
• Use case: Demonstrates the absolute theoretical capacity of the physical link when multiple household users are downloading files simultaneously [1].

Single-Threaded Testing (Single-Stream)

Advanced engineering tools (such as iPerf3 or single-connection test options) utilize a single TCP stream:

• How it works: Single-stream throughput is heavily constrained by Round-Trip Time (RTT) and TCP window scaling limits according to the Bandwidth-Delay Product (BDP) [2, 3]: $$\text{BDP} = \text{Bandwidth (bits/sec)} \times \text{RTT (seconds)}$$
• Use case: Reflects the actual performance of real-world applications that operate over a single connection, such as SSH sessions, large file transfers via SFTP, single video streams, or software downloads [2].

Technical Comparison of Speed Test Methodologies

3. Server Proximity and Peering Paths

A speed test measures performance only between your client device and that specific test server—not "to the entire internet" [1]:

• On-Net ISP Servers: When a speed test server resides inside your ISP's local data center, traffic never leaves the provider's autonomous system (AS). These tests report near-flawless speeds and single-digit ping times, reflecting local access loop health rather than global transit capacity [1].
• Off-Net Transit Servers: Testing against a server in another country forces packets across international submarine cables, third-party transit carriers, and public Internet Exchange Points (IXPs). Peering congestion or high propagation delay on international links significantly reduces throughput [1, 2].

4. Latency Under Load (Bufferbloat)

Modern speed test utilities (including the Deprogit Speed Test suite) measure both unloaded ping and loaded ping [1]:

• Unloaded Latency: Measured while the connection is completely idle (e.g., 12 ms).
• Loaded Latency (Bufferbloat): Measured while max-capacity upload and download streams are running simultaneously. If latency jumps from 12 ms to 320 ms during active file transfers, the router or modem is excessively buffering packets, causing real-time applications to stall [1, 2].

Practical Recommendations for Accurate Benchmarking

To achieve reproducible, diagnostically valid speed measurements:

1. Test Exclusively Over Wired Cat6 Gigabit Ethernet: Disconnect all Wi-Fi clients. Wireless radio interference, channel contention, and CPU throttling introduce massive testing variance [1].
2. Terminate Background Applications: Ensure operating system background updates, torrent clients, cloud storage synchronizers, and streaming video tabs are closed during the test [2].
3. Compare Multiple Geographical Targets: Test against both a local IXP server (to verify local loop delivery) and an international transit target (to evaluate global routing performance) [1, 2].

Experience standardized, multi-metric network testing directly on our Tools & Speed Tests suite.

Key Takeaways

• Speed tests measure achieved data transfer rates over time, not instantaneous physical bandwidth.
• Multi-stream tests mask packet loss to show link ceilings; single-stream tests reveal real-world application performance.
• Server location and peering paths determine whether a test reflects local ISP access or international transit capacity.
• Measuring latency under load exposes bufferbloat issues that degrade real-time voice and video communications.

Need help with this? Contact us.

Sources

[1] International Telecommunication Union (ITU), "Recommendation ITU-T Y.1540: Internet protocol data communication service - IP packet transfer and availability performance parameters", 2019. URL: https://www.itu.int/rec/T-REC-Y.1540 (International standard establishing measurement methodologies for IP throughput, delay, and access performance).

[2] IETF, "RFC 6349: Framework for TCP Throughput Testing", 2011. URL: https://www.rfc-editor.org/rfc/rfc6349.html (Standards-track engineering framework for measuring TCP network capacity and identifying transmission bottlenecks).

[3] IETF, "RFC 7323: TCP Extensions for High Performance", 2014. URL: https://www.rfc-editor.org/rfc/rfc7323.html (Standards-track specification for TCP window scaling, round-trip time measurement, and high-bandwidth transmission).

Last reviewed: October 2026