How Browsers Manage TCP Connections and Image Loading: 5 Key Questions Answered

Browser TCP/HTTP behavior for pages containing many images

When a URL is entered, the browser must resolve the address, establish a TCP connection, perform a TLS handshake (if HTTPS), and issue HTTP requests to retrieve the HTML and any embedded resources such as <img> tags. The following five questions describe how modern browsers handle these steps.

Does a modern browser close the TCP connection after a single HTTP request, and under what conditions does it stay open?

How many HTTP requests can share one TCP connection?

Can multiple HTTP requests be sent simultaneously over the same TCP connection?

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

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

1. Persistent (keep‑alive) connections

In HTTP/1.0 the server closed the TCP socket after each response. To avoid the overhead of repeatedly creating sockets and performing TLS handshakes, many servers support the Connection: keep-alive header. HTTP/1.1 makes persistent connections the default; a connection is kept open unless the request contains Connection: close.

When the connection is kept alive, the browser can reuse the same socket for subsequent requests, eliminating the need for a new TCP three‑way handshake and a new TLS handshake. This reduces latency, especially for resources that are fetched in rapid succession (e.g., multiple images from the same host).

2. Number of HTTP requests per persistent connection

A single persistent TCP connection can carry an arbitrary number of sequential HTTP requests. The client sends the next request only after it has received the full response of the previous one. This sequential reuse is the basis for the typical “six‑connection” model used by browsers when HTTP/2 is not available.

3. Parallel request transmission on one connection

HTTP/1.1 defines pipelining , which allows a client to send multiple requests without waiting for each response. In practice browsers disable pipelining because:

Responses must be returned in the same order as requests, making it impossible to reliably match a response to its request without additional framing.

Head‑of‑line blocking: a slow first request delays all subsequent responses.

Many intermediate proxies and servers do not handle pipelined streams correctly.

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 drawbacks, modern browsers keep pipelining turned off.

HTTP/2 introduces multiplexing , which creates independent logical streams over a single TCP connection. Multiple requests and responses can be interleaved freely, eliminating head‑of‑line blocking.

4. SSL/TLS session reuse on page refresh

If the TCP socket remains open after a page load, the associated TLS session is also retained. A subsequent refresh that reuses the same socket does not need to perform a new TLS handshake, saving the round‑trip time of the handshake.

5. Per‑host TCP connection limits

Browsers limit the number of simultaneous TCP connections to a single origin to avoid overwhelming the server and to stay within client resource limits. For example, Chrome caps the number of concurrent connections to a host at six (other browsers use similar limits, e.g., Firefox 6, Safari 6, Edge 6).

When a page contains dozens of images, the browser opens up to the per‑host limit of parallel connections and queues the remaining requests. If the server supports HTTP/2, all image requests can be multiplexed over a single TLS connection, dramatically reducing the need for many parallel sockets.

In summary, for an HTML page with many <img> tags:

Browsers keep TCP connections alive by default (HTTP/1.1) and reuse them for multiple sequential requests.

HTTP/1.1 pipelining exists but is disabled in practice; browsers rely on sequential request ordering.

HTTP/2 multiplexing allows true parallelism on a single connection.

TLS sessions are reused as long as the underlying TCP socket remains open, so a refresh may avoid a new handshake.

Browsers enforce a per‑host connection ceiling (commonly six) when HTTP/2 is unavailable.

Reference: Chrome DevTools network limits – https://developers.google.com/web/tools/chrome-devtools/network/issues#queued-or-stalled-requests