What Really Happens When You Type a URL? Exploring TCP, HTTP, and Browser Connections

When a URL is entered, the browser performs DNS resolution, establishes a TCP handshake, optionally negotiates TLS, sends an HTTP request, receives the response, and finally renders the page. The core discussion examines how browsers manage connections when a page contains dozens of image resources.

Five key questions

Does a modern browser close the 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 the same TCP connection?

Why does a page refresh sometimes avoid re‑establishing an SSL connection?

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

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

In HTTP/1.0 the server closes the TCP connection after each response, which incurs high overhead. HTTP/1.1 introduced the Connection: keep-alive header, allowing the same TCP connection to be reused for subsequent requests. Keeping the connection alive also avoids repeated SSL handshakes, reducing latency.

Performance measurements show that the first request incurs both TCP and SSL setup costs, while a second request to the same host reuses the existing connection and eliminates these costs.

Because the connection is persistent, HTTP/1.1 makes persistent connections the default unless the request explicitly includes Connection: close.

2. Can a TCP connection handle multiple HTTP requests?

Yes. With a persistent connection, a single TCP socket can sequentially carry many HTTP requests and responses.

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

HTTP/1.1 defines pipelining, which allows a client to send several requests without waiting for each response. However, browsers disable pipelining by default because:

Some proxy servers mishandle pipelined requests.

Correct implementation is complex.

Head‑of‑line blocking: if the first request takes long, later responses are delayed.

Therefore, modern browsers keep pipelining off. HTTP/2 solves the problem with multiplexing, enabling multiple concurrent streams over a single TCP connection.

In HTTP/2, the green bars represent request latency, and the blue bars represent download time; both occur in parallel on the same connection.

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

The TCP connection may remain alive for a period, allowing the SSL session to be reused without a full handshake.

5. How many simultaneous TCP connections can a browser open to the same host?

Chrome permits up to six concurrent connections per host; other browsers have similar but sometimes different limits.

When a page contains many images, the browser reuses existing connections up to the per‑host limit and opens additional connections as needed. If the server supports HTTP/2, multiplexing may be used to fetch all resources over a single connection.