Why Do Browsers Keep TCP Connections Alive? Uncovering HTTP/1.1, HTTP/2, and Image Loading

1. Does the browser close the TCP connection after a single HTTP request?

In HTTP/1.0 the connection is closed after each response; HTTP/1.1 introduced persistent connections via the

Connection: keep-alive

header, so the TCP connection remains open unless

Connection: close

is sent.

Keeping the connection reduces the overhead of establishing new TCP and SSL handshakes, as illustrated by the two screenshots showing the first request (with SSL handshake) and the second request (no handshake).

https://tools.ietf.org/html/rfc2616#section-8.1

2. How many HTTP requests can share one TCP connection?

With a persistent connection, a single TCP connection can carry multiple sequential HTTP requests.

3. Can multiple HTTP requests be sent simultaneously over one TCP connection?

In HTTP/1.1 only one request can be in flight at a time; the request lifetimes cannot overlap. Pipelining was defined to allow sending several requests without waiting for responses, but browsers disable it by default due to complexity, head‑of‑line blocking, and proxy incompatibilities.

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 of these issues, modern browsers keep pipelining off.

HTTP/2 solves the problem with multiplexing, allowing many requests to be processed concurrently over a single TCP connection, as shown in the following diagram.

4. Why does a page refresh sometimes avoid a new SSL handshake?

If the TCP connection is kept alive, the existing SSL session can be reused, eliminating the need for a new handshake.

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

Browsers limit concurrent connections per host (Chrome allows up to six). When many resources such as images need to be fetched, the browser opens several connections up to this limit, reusing idle connections for new requests.

When a page contains dozens of

<img>

tags served over HTTPS on the same domain, the browser first negotiates HTTP/2 if possible; otherwise it falls back to HTTP/1.1 with multiple TCP connections, using keep‑alive and, when available, multiplexing to improve loading efficiency.