Understanding Browser TCP Connections, HTTP Persistence, Pipelining, and Multiplexing
The article explains how modern browsers manage TCP connections for HTTP requests, covering persistent connections, the number of requests per connection, pipelining limitations in HTTP/1.1, the advantages of HTTP/2 multiplexing, SSL reuse, and browser-imposed limits on concurrent connections per host.
A classic interview question asks what happens from entering a URL to page rendering; beyond DOM construction, the article focuses on how browsers download dozens of images embedded in HTML, examining the underlying TCP and HTTP mechanisms.
1. Persistent TCP connections: In HTTP/1.0 the connection is closed after each response, but keep‑alive support allows the TCP socket to remain open, avoiding repeated TCP and SSL handshakes. HTTP/1.1 makes persistent connections the default unless Connection: close is sent.
2. Requests per TCP connection: A single persistent TCP connection can carry multiple HTTP requests sequentially, so the answer to the second question is that one TCP connection can handle many requests.
3. Sending multiple requests simultaneously: HTTP/1.1 permits only one in‑flight request per connection; pipelining (sending several requests without waiting for responses) exists in the spec but is disabled in browsers due to ordering constraints, head‑of‑line blocking, and proxy incompatibilities. The article cites the RFC 2616 definition and shows example requests GET/query?q=A and GET/query?q=B that cannot be distinguished in responses without ordering.
Because of these limitations, browsers either keep a small pool of persistent connections or open several parallel connections (typically up to six per host in Chrome) to improve page load speed.
4. SSL reuse on refresh: When a persistent TCP connection is kept alive, the associated TLS session is also reused, so a page refresh may not require a new SSL handshake.
5. Connection limits per host: Browsers cap the number of simultaneous TCP connections to a single host (e.g., Chrome allows six), preventing resource exhaustion while still enabling parallel downloads.
When HTTPS is used and HTTP/2 is negotiated, multiplexing allows many HTTP requests to be interleaved over a single TCP/TLS connection, eliminating the need for multiple connections and overcoming HTTP/1.1 pipelining drawbacks.
If HTTP/2 or HTTPS is unavailable, the browser falls back to opening multiple TCP connections within the per‑host limit and reuses idle connections for new requests.
Architect's Tech Stack
Java backend, microservices, distributed systems, containerized programming, and more.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.