How Browsers Manage TCP Connections, HTTP Persistence, Pipelining, and Multiplexing

When a URL is entered, the browser establishes a TCP connection to the server. In HTTP/1.0 the connection is closed after each response, but many servers support Connection: keep-alive to reuse the TCP link, reducing latency and avoiding repeated SSL handshakes.

HTTP/1.1 makes persistent connections the default; the connection remains open unless the request includes Connection: close . This allows multiple HTTP requests to be sent sequentially over the same TCP link.

A single TCP connection can carry multiple HTTP requests, but in HTTP/1.1 only one request may be active at a time. Pipelining, defined in RFC 2616, permits sending several requests without waiting for responses, but browsers disable it by default because of ordering constraints, head‑of‑line blocking, and proxy incompatibilities.

HTTP/2 introduces multiplexing, which allows many requests and responses to be interleaved concurrently over a single TCP connection, eliminating the need for pipelining and improving page load performance.

When many resources (e.g., dozens of images) are present, browsers open several parallel TCP connections to the same host—commonly up to six in Chrome—to fetch resources concurrently, respecting per‑host connection limits.

If the resources are served over HTTPS and the server supports HTTP/2, the browser will negotiate HTTP/2 after the TLS handshake and use multiplexing; otherwise it falls back to HTTP/1.1 with multiple TCP connections.

Finally, the article includes a promotional notice for a PHP online live class, which is unrelated to the technical discussion.