Understanding Browser TCP Connections, HTTP Persistence, Pipelining, and Multiplexing

When a URL is entered in a browser, many questions arise about how the HTML and its embedded images are fetched, such as the number of connections, the order of downloads, and the protocols used.

To answer these, five sub‑questions are examined:

Does a modern browser close a TCP connection after a single HTTP request, and under what conditions?

How many HTTP requests can share one TCP connection?

Can multiple HTTP requests be sent simultaneously over a single TCP connection?

Why does a page refresh sometimes avoid establishing a new SSL connection?

Is there a limit to the number of TCP connections a browser opens to the same host?

First Question

In HTTP/1.0 the server closed the TCP connection after each response, which was inefficient. Servers that support the Connection: keep-alive header keep the TCP connection open, allowing reuse for subsequent requests and avoiding the overhead of new SSL handshakes. HTTP/1.1 standardized this behavior: connections are persistent by default unless the request includes Connection: close .

Second Question

Because the connection can be kept alive, a single TCP connection can carry multiple HTTP requests sequentially.

Third Question

HTTP/1.1 allows only one active request per TCP connection; request lifetimes cannot overlap. Although the specification defines pipelining—sending several requests without waiting for responses—browsers disable it by default due to complexity and head‑of‑line blocking issues.

A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.

Because responses are not individually identifiable, the browser cannot match them to the original requests, leading to practical problems. Consequently, modern browsers keep pipelining disabled.

HTTP/2 introduces multiplexing, allowing many requests to be sent concurrently over a single TCP connection, solving the above limitation.

Fourth Question

SSL sessions can be reused when the underlying TCP connection is kept alive, so a page refresh may not need a new SSL handshake.

Fifth Question

Browsers limit the number of simultaneous TCP connections to a single host; Chrome, for example, allows up to six connections per host. When many images are present, the browser opens multiple connections (subject to this limit) to download resources in parallel.

If the resources are served over HTTPS on the same domain and the server supports HTTP/2, the browser will negotiate HTTP/2 after the TLS handshake and use multiplexing to fetch many assets over one connection. If HTTP/2 is unavailable, the browser falls back to multiple TCP connections, respecting the per‑host limit.

Thus, for a page with dozens of image tags, the browser typically reuses persistent TCP connections, may employ HTTP/2 multiplexing when possible, and otherwise opens several parallel connections (up to the browser’s limit) to download the images efficiently.