The challenge of measuring connections at scale
Every Internet interaction—browsing, streaming, or an API call—begins with a connection. The basic questions about these connections (“how long?”, “how big?”, “how often?”) are almost as old as the network itself, dating back to the influential 1991 paper “Characteristics of wide-area TCP/IP conversations.” Yet while anyone can inspect traffic locally with tools like Wireshark, characterizing connections across the wider Internet has remained effectively impossible due to scale and access. Operators rarely share their own observations, and client-side captures only show one side of the exchange.
By sharing aggregated telemetry from connections that traverse its global CDN—covering the roughly 70% of HTTP requests built on top of TCP—Cloudflare offers a rare server-side view of how connections actually behave. This kind of empirical insight is difficult to gather from any other vantage point.
Why connection statistics matter
Network designers need realistic models to predict the effects of new protocols or algorithms. Deploying directly on live traffic is risky: unexpected behavior could disrupt users, making a test-first approach essential. Simulation fills that gap, but simulations are only as good as the data they model.
Generating realistic synthetic traffic requires statistically sound distributions of the traffic's real-world characteristics, and those distributions must come from measurement and analysis first.
How the data was collected
Details matter in measurement—a dataset can only be interpreted with a clear view of how it was gathered, what it leaves out, and any biases in its coverage.
Which connections were included. The snapshot covers TCP connections seen at Cloudflare's edge servers that served HTTP 1.0, 1.1, or 2.0 requests. Connections labeled as Visitor to Cloudflare represent the majority of traffic handled at sample points.
- Sampling: A uniform 1% sample of all TCP connections was captured between October 7 and October 15, 2025, with sampling performed at each individual server to reduce biases that could skew results at the datacenter level.
- Traffic diversity: Cloudflare's workload is shaped by its many customers—who route various web applications, services, and user bases through the network—giving a broader view than operators whose traffic is heavily concentrated around their own search, social, or video services.
- Log entries: Each record contains socket-level metadata from the Linux kernel’s
TCP_INFOstructure, server name indication (SNI), and the number of requests per connection. No individual HTTP transactions or payload-level details, are recorded.
Which connections were excluded. The analysis requires that connections closed with a graceful FIN packet, filtering out those interrupted by RST, timeouts, or attack mitigations. An additional condition of at least one successful HTTP request ensures the connection served a useful purpose—a step that removes 11% of connections that terminate gracefully but carry no actual HTTP traffic.
Future investigation
Understanding the distribution of these standard metrics raises a central question: do common assumptions about connection behavior hold for the modern Internet? Data like the one described here allows us to check those baseline assumptions empirically rather than relying on approximations from earlier eras of the web.
The shape of real Internet connections
Connection-level telemetry across Cloudflare's edge reveals a consistently heavy-tailed view of Internet traffic. Practitioners have long spoken of "elephants and mice" — where most flows are tiny and a few are enormous — but concrete data on where that line falls has been scarce. The distributions below, expressed as empirical CDFs with log-scaled axes, help put concrete numbers on that intuition.
Packet counts: mostly small, occasionally massive
Looking at the number of response packets sent by Cloudflare servers back to clients, the median connection carries just 12 packets, while the average is roughly 240 packets. The 90th percentile sits at only 107 packets. This is the classic heavy tail: a small number of connections — large downloads, video streams — push the mean far above the median, while the bulk of interactions deliver small web objects, API responses, or microservice traffic in a handful of packets.
Breaking packet counts down by HTTP protocol version shows meaningful differences. HTTP/1.X (both 1.0 and 1.1) connections have a median of 10 response packets, with 90% of connections carrying fewer than 63. HTTP/2 connections, by contrast, show a median of 16 packets and a 90th percentile of 170. The larger HTTP/2 counts are consistent with multiplexing — multiple request/response streams share a single connection — plus the additional control-plane and flow-control frames HTTP/2 requires.
The asymmetry between what clients send and what servers reply with is another key measure. Across all connections, the median ratio of server-to-client packets is 0.91, meaning that in half of connections, clients transmit slightly more packets than servers respond with. Client-side overhead — TLS ClientHello, HTTP request headers, TCP ACKs — explains much of that excess, particularly in the low-volume flows that dominate the distribution. The mean ratio of 1.28 is dragged upward by a long tail of client-heavy flows typical of CDN workloads, and the variance of 3.71 reflects widely divergent upload- and download-heavy extremes.
Bytes sent and received: the same tail, deeper
Measuring the actual volume delivered per connection, using tcpi_bytes_sent (which covers retransmitted payloads but excludes the TCP header, per linux/tcp.h and RFC 4898), reinforces the packet-count picture. HTTP/1.X connections have a median of 4.8 KB delivered and a 90th percentile of 51 KB; HTTP/2 shows a median of 6 KB and a 90th percentile of 146 KB. The means are far higher — 224 KB for HTTP/1.X and 390 KB for HTTP/2 — driven by rare transfers reaching tens of gigabytes. At the other extreme, the smallest payloads observed were 115 bytes for HTTP/1.X and 202 bytes for HTTP/2.
Considering bidirectional traffic via tcpi_bytes_received, the median ratio of server-sent to client-received bytes is 3.78: in half of all connections, servers deliver nearly four times more data than they receive. The average ratio of 81.06 again exposes the long tail of download-heavy flows, with extreme cases pushing the ratio into the millions.
Duration and reuse: short by default, persistent when needed
Connection lifetimes are just as skewed as the byte and packet distributions. The median connection lasts 4.7 seconds, and the mean is 96 seconds. Most connections fall between 0.1 seconds (10th percentile) and 300 seconds (90th percentile). Some connections, however, live for multiple days — typically kept alive for reuse via TCP keep-alives before hitting default idle timeout limits, and usually associated with persistent sessions or streaming media rather than typical web interactions.
Request counts show how often connections are reused. Both HTTP/1.X and HTTP/2 have a median of one request per connection, underscoring how rarely connection reuse actually happens in practice. The means differ — around 3 for HTTP/1.X and 8 for HTTP/2 — and the 90th percentile for HTTP/2 reaches 10 requests, with rare multiplexed connections carrying thousands in cases amplified by connection coalescing. HTTP/1.X rarely exceeds two requests per connection even at the 90th percentile, reflecting its origins in a "one request per connection" model, despite persistent connections being available since HTTP/1.1.
Distinguishing client ASNs classified as data centers (likely automated) from user traffic offers a partial explanation. Non-DC traffic has a mean of 5 requests per connection and a 90th percentile of 5, consistent with browsers fetching multiple resources over a single connection. Data-center-originated traffic shows a mean of about 3 and a 90th percentile of 2 — validating the intuition that scripts and automated clients tend to open fresh connections rather than reuse existing ones. In both groups, however, the median remains exactly one request: regardless of who initiates traffic, most connections are genuinely brief.
Path Profiling Through TCP Telemetry
Beyond connection counts and duration, TCP connection metadata can reveal useful details about the underlying network paths. Three characteristics stand out: path MTU, initial congestion window behavior, and bandwidth-delay product.
Path MTU Distribution
Path MTU (PMTU) defines the largest packet that can traverse a connection without fragmentation. The Linux TCP stack on our servers records this value during Path MTU discovery, and the collected data shows a tight distribution: both the median and 90th percentile sit at 1,500 bytes, matching the standard Ethernet MTU. The 10th percentile drops to 1,420 bytes, indicating paths that traverse VPNs, IPv6-to-IPv4 tunnels, or older equipment with stricter size limits. At the low end, some IPv4 connections show MTUs as small as 552 bytes, which is the minimum allowed value in the Linux kernel.
Congestion Window at Slow Start Exit
The initial congestion window (ICWND) matters most for short-lived connections, which dominate Internet traffic as noted earlier. A window set too low forces extra round trips for small transfers; one set too high risks unnecessary loss. We estimated ICWND by looking at the congestion window size at the moment the sender exits slow start, using BBR’s calculation of that transition point.
The raw distribution looked suspicious: the median congestion window at slow start exit was roughly 464 KB, or about 310 packets at a 1,500-byte MTU, with extreme flows carrying tens of megabytes in flight. Those numbers reflect a mix of paths—not just between Cloudflare and end users, but also between our own datacenters—yet they still seemed unusually high. The explanation turned out to be specific to BBR’s design, which intentionally inflates its congestion window above its estimate of the path’s bandwidth-delay product (BDP).
Plotting BBR’s own BDP estimate alongside the congestion window confirms the discrepancy. The median BDP is roughly 77 KB, about 50 packets, and is far more stable across recently closed connections than the congestion window measurement.
These findings have practical implications. The congestion window default of 10 packets has stood since RFC 6928 was published over a decade ago. Our internal experiments show that ICWND choices can shift performance by 30–40% on smaller connections, so better-tuned initial values could have a meaningful impact.
Heterogeneity and Next Steps
The broader picture confirms what long-standing observations of “elephants and mice” traffic have suggested: Internet connections are highly heterogeneous, with strong heavy-tail characteristics. The ratio of upload to download bytes behaves as expected for large flows, but is surprisingly asymmetric for short ones, underscoring how lopsided typical Internet usage really is.
We plan to publish connection-level statistics on Cloudflare Radar so others can build on this work. We also invite researchers and academics interested in this area to contact us at [email protected].
