How Browsers Manage TCP Connections and Image Loading: Key Answers Explained

A classic interview question asks what happens from entering a URL to the page being displayed. This article examines how browsers download dozens of images, the number of connections, order, and protocols involved.

Do modern browsers close a TCP connection after a single HTTP request? 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 can open to the same host?

First Question

In HTTP/1.0 the server closes the TCP connection after each response. To avoid the overhead, many servers support Connection: keep-alive, allowing the connection to be reused for subsequent requests, which also saves SSL handshake cost. Two screenshots illustrate the timing differences when the connection is reused versus a fresh connection.

Persistent connections are the default in HTTP/1.1 unless Connection: close is sent, so the TCP connection remains open.

Second Question

When a connection is kept alive, a single TCP connection can carry multiple HTTP requests.

Third Question

In HTTP/1.1 a single TCP connection can handle only one request at a time; request lifetimes cannot overlap. Although HTTP/1.1 defines pipelining, browsers keep it disabled by default.

Pipelining allows a client to send multiple requests without waiting for each response, and the server must reply in the same order. However, practical issues such as proxy incompatibility, implementation complexity, and head‑of‑line blocking have led browsers to disable it.

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 problems, modern browsers do not enable HTTP pipelining. HTTP/2, however, provides multiplexing, allowing multiple requests to be processed concurrently over a single TCP connection, as shown in the following diagram.

The green bars represent request‑to‑response latency, and the blue bars represent download time, all occurring on the same connection.

Thus, in HTTP/1.1 pipelining is theoretically possible but practically disabled, while HTTP/2’s multiplexing enables parallel request handling.

To improve page load performance in the HTTP/1.1 era browsers use two main techniques:

Keep the TCP connection alive and process multiple requests sequentially.

Open multiple TCP connections to the server.

Fourth Question

A page refresh may not require a new SSL handshake because the underlying TCP connection can be kept alive, and the existing SSL session is reused.

Fifth Question

Browsers limit the number of simultaneous TCP connections per host. Chrome, for example, allows up to six concurrent connections to the same host, though limits vary across browsers.

If images are served over HTTPS from the same domain and HTTP/2 is negotiated, the browser can use multiplexing on a single connection. Otherwise, multiple TCP connections are opened, respecting the per‑host limit, and idle connections are reused for new requests.

Reference: zhuanlan.zhihu.com/p/61423830 (copyright belongs to the original author).