Why Chromium Limits HTTP/1.1 Connections to Six Per Host

This article explains why the Chromium web browser enforces a strict limit of six concurrent TCP connections per host origin when using the HTTP/1.1 protocol. This architectural decision is a carefully calibrated compromise designed to maximize page loading speeds while preventing server overload, mitigating network congestion, and conserving client-side system resources. While modern protocols like HTTP/2 and HTTP/3 bypass this issue through multiplexing, the six-connection limit remains a vital safeguard for HTTP/1.1 traffic.

The Problem of HTTP/1.1 Head-of-Line Blocking

To understand the six-connection limit, you must first understand how HTTP/1.1 handles data. In HTTP/1.1, a single TCP connection can only process one request and response at a time. If a browser needs to download an HTML file, three CSS stylesheets, and ten images, doing so over a single connection means each file must wait for the previous one to finish. This is known as head-of-line blocking.

To load web pages faster, browsers open multiple parallel TCP connections to the same host (domain and port). However, opening an unlimited number of connections creates severe problems for both the user and the server.

Evolution from the Original RFC Standard

In 1999, the official specification for HTTP/1.1 (RFC 2616) recommended that a client should open a maximum of two concurrent connections per server. As websites evolved from simple text documents into complex applications requiring dozens of assets, two connections became a major bottleneck.

Browser vendors, including the developers behind Chromium, experimented with higher limits and eventually settled on six connections per host. In 2014, the updated specification (RFC 7230) removed the two-connection rule, acknowledging that six had become the practical industry standard.

Preventing Server Exhaustion

Every active TCP connection consumes memory, CPU cycles, and file descriptors on the hosting web server. If Chromium allowed a single user to open 50 or 100 simultaneous connections to download a heavy webpage, a moderate spike in website traffic would instantly exhaust the server's resources.

By capping the limit at six, Chromium ensures that a single browser cannot accidentally perform a Denial of Service (DoS) attack against a web server simply by loading a resource-heavy page. It forces the browser to queue the remaining requests and process them as the active connections become free.

Avoiding Network Congestion

More connections do not automatically equal faster download speeds. A user's internet connection has a fixed amount of bandwidth. If a browser opens 30 TCP connections at once, all 30 connections must compete for that same bandwidth.

Furthermore, every new TCP connection begins with a mechanism called "TCP Slow Start," which tests the network's capacity before sending data at full speed. Opening too many connections simultaneously floods the network routers with packets, leading to packet loss, retransmissions, and a phenomenon known as congestion collapse. Six connections are generally enough to saturate a standard broadband connection without triggering network-level bottlenecks.

Conserving Client-Side Resources

The six-connection limit also protects the user's device. Establishing and maintaining a TCP connection requires the operating system to allocate local memory and an ephemeral port. Furthermore, if the website uses HTTPS, each of those connections requires a computationally expensive TLS handshake to establish encryption. Limiting the browser to six connections per host prevents Chromium from draining the device's battery, spiking CPU usage, and exhausting the operating system's available network ports.

Moving Beyond the Limit

For years, web developers bypassed Chromium's six-connection limit using a technique called "domain sharding"—splitting assets across multiple subdomains (e.g., img1.example.com, img2.example.com) so the browser would allow six connections for each subdomain.

Today, this workaround is obsolete. Newer protocols like HTTP/2 and HTTP/3 solve the HTTP/1.1 bottleneck by introducing multiplexing. Multiplexing allows Chromium to open just a single connection to a host and send dozens of requests and responses simultaneously over virtual streams, rendering the six-connection limit strictly an HTTP/1.1 fallback mechanism.